Developer Update #3 - Native Bitcoin Reward Execution & Everlight App Control Plane V1.8

2026-02-07

Status: Internal testnet / controlled simulation phase

---

0. Executive Summary

This update formalizes the transition of the Bitcoin Everlight node network to native Bitcoin (BTC)–denominated rewards, distributed through a deterministic entitlement system and executed via direct Bitcoin L1 transactions.

Key properties of this upgrade:

• No wrapped BTC

• No synthetic representations

• No smart-contract custody

• No bridge dependency

• Bitcoin L1 settlement only

The newly deployed Bitcoin Everlight App functions as the authoritative control plane, coordinating node identity, reward entitlement, payout visibility, and epoch reconciliation.

---

1. Design Constraints & Motivation

Bitcoin Everlight deliberately operates under the following constraints:

1. Bitcoin is not programmable in the EVM sense

2. Reward logic cannot live on-chain

3. BTC custody must be minimized and auditable

4. Node operators must be able to verify payouts independently

5. The system must tolerate partial failures without fund loss

This architecture embraces those constraints instead of abstracting them away.

---

2. System Architecture Overview

Macro Architecture

┌─────────────────────────────────────┐
│        Everlight Node Network        │
│  (execution, validation, transport) │
└───────────────┬─────────────────────┘
                │ signed telemetry
                ▼
┌─────────────────────────────────────┐
│   Off-Chain State Aggregation Layer  │
│  (epoch accounting & scoring engine)│
└───────────────┬─────────────────────┘
                │ deterministic ledger
                ▼
┌─────────────────────────────────────┐
│    Reward Entitlement Resolution     │
│   (BTC-denominated allocations)     │
└───────────────┬─────────────────────┘
                │ signed payout intents
                ▼
┌─────────────────────────────────────┐
│   Bitcoin Treasury & TX Orchestrator │
│   (UTXO selection, signing, broadcast)│
└───────────────┬─────────────────────┘
                │ raw BTC tx
                ▼
┌─────────────────────────────────────┐
│          Bitcoin Mainnet             │
└─────────────────────────────────────┘

---

3. Node Identity & Cryptographic Anchoring

Each node is registered with:

• A node public key

• A BTC payout address

• A node identifier hash

Node Identity Record

{
  "node_id": "EL-NODE-92A17F",
  "node_pubkey": "02a1f4c9...",
  "btc_address": "bc1q9x4...",
  "registration_epoch": 1819,
  "status": "active"
}

This identity is immutable within an epoch window.

---

4. Telemetry, Heartbeats & Proof of Participation

Nodes emit signed heartbeats at protocol-defined intervals.

Heartbeat Structure

{
  "node_id": "EL-NODE-92A17F",
  "epoch": 1842,
  "timestamp": 1736289123,
  "uptime_ms": 3598000,
  "tasks_completed": 312,
  "avg_latency_ms": 84,
  "errors": 0,
  "signature": "30440220..."
}

Validation Rules

• Timestamp drift tolerance enforced

• Duplicate heartbeat rejection

• Signature verification against registered node key

• Epoch mismatch rejection

if (!verifySignature(payload, nodePubKey)) reject();
if (heartbeat.epoch !== currentEpoch) reject();

---

5. Epoch Model & Finality

Bitcoin Everlight operates on fixed-length epochs.

• Epochs define:

  • Reward budgets

  • Eligibility windows

  • Payout boundaries

• Once an epoch is finalized:

  • No retroactive modification

  • No re-weighting

  • No reward reassignment

enum EpochState {
  OPEN,
  FINALIZED,
  PAID
}

---

6. Performance Scoring Engine

Node contribution is quantified using a weighted, normalized scoring model.

Inputs

• Uptime ratio

• Task throughput

• Latency performance

• Error penalties

Scoring Function

score =
  (uptimeWeight * uptimeRatio) +
  (taskWeight * normalizedTasks) +
  (latencyWeight * (1 / avgLatency)) -
  (errorPenalty * errorCount);

Scores are normalized across the full node set for the epoch.

---

7. BTC Reward Budget Resolution

Each epoch defines a fixed BTC reward pool:

epochBTCBudget = 1.25 BTC;

Node reward entitlement:

nodeBTC =
  (nodeScore / totalNetworkScore) * epochBTCBudget;

Final amounts are resolved in satoshis to avoid rounding ambiguity.

---

8. Deterministic Entitlement Ledger

Before any BTC transaction is constructed, the system produces a full entitlement ledger.

Ledger Entry

{
  "epoch": 1842,
  "node_id": "EL-NODE-92A17F",
  "btc_sats": 2845000,
  "checksum": "e19fbc..."
}

This ledger is:

• Immutable post-finalization

• Fully auditable

• Reproducible from raw telemetry

---

9. Bitcoin Treasury Model

Treasury Design Goals

• Segregated funds

• Minimal hot exposure

• Deterministic UTXO selection

• Replay-safe signing

Treasury funds are never co-mingled with operational wallets.

---

10. BTC Transaction Construction

UTXO Selection

const utxos = selectUTXOs({
  targetAmount: totalEpochPayout,
  minimizeChange: true
});

Transaction Assembly

const tx = {
  inputs: utxos,
  outputs: payouts.map(p => ({
    address: p.btcAddress,
    value: p.sats
  })),
  locktime: 0
};

Fee Estimation

Dynamic fee selection based on mempool pressure:

feeRate = estimateFeeRate("medium");

---

11. Signing & Broadcast Safeguards

Transactions are only signed if:

• Treasury balance matches ledger

• Output totals match entitlement ledger

• Epoch state is FINALIZED

• No duplicate payout flags detected

if (!ledgerMatchesTX(tx)) abort();
if (!epochFinalized) abort();

---

12. Failure Modes & Recovery

If broadcast fails:

• Funds remain in treasury

• Epoch remains unpaid

• Retry window opens next cycle

If partial confirmation occurs:

• TXID is tracked

• Confirmation depth enforced

• No rebroadcast without manual override

---

13. Everlight App – Control Plane

The Bitcoin Everlight App is the authoritative interface for:

• Node lifecycle management

• BTC address binding

• Reward tracking

• Epoch verification

---

14. App Authentication & Authorization

JWT-based auth with role separation:

Authorization: Bearer <signed-jwt>

Permissions scoped to:

• Node ownership

• Read-only network state

• Write-limited epoch windows

---

15. BTC Address Binding Rules

• Address changes locked per epoch

• Multi-sig supported (optional)

• Cold wallet payouts supported

if (epochActive) denyAddressChange();

---

16. Reward Transparency

Each payout surfaces:

• Epoch ID

• BTC amount (sats)

• TXID

• Confirmation depth

• Timestamp

Operators can independently verify on Bitcoin explorers.

---

17. Security Model Summary

Vector	Mitigation
Replay attacks	Epoch locking
Address hijack	Write-once rules
Double payout	Ledger checksums
Treasury drain	Multi-layer validation
Bridge risk	None (BTC native)

---

18. Why This Architecture Matters

This system intentionally does not pretend Bitcoin is programmable.

Instead, it:

• Uses Bitcoin where Bitcoin is strongest (final settlement)

• Uses off-chain systems where logic is required

• Keeps custody minimal and visible

• Aligns node incentives directly with BTC

Node operators are paid Bitcoin, not abstractions.

---

19. Forward Work

Planned enhancements:

• Advanced UTXO fragmentation reduction

• Adaptive batching during mempool congestion

• Extended app-side telemetry

• Cold-storage payout routing

• Optional payout delay compounding