Developer Update #4 – Shard Architecture, Activation Mechanics & Validation Mapping

Overview

Bitcoin Everlight introduces Shards as a structured activation layer designed to align user participation with network validation and BTC-denominated rewards.

A Shard is not an NFT, synthetic derivative, or cosmetic tier. It is a protocol-defined participation unit that maps staked BTCL to managed validation infrastructure.

Shards serve three primary roles:

• Network validation participation

• BTC-denominated fee distribution

• Structured presale engagement

---

Shard Model

Each Shard is activated by locking a fixed quantity of BTCL.

Let:

• SiS_iSi​ denote Shard tier iii

• LiL_iLi​ denote the fixed BTCL lock requirement for tier iii

• UUU denote a user

• A(U)A(U)A(U) denote the set of Shards activated by user UUU

Activation condition:

U activates Si  ⟺  BTCLU≥LiU \text{ activates } S_i \iff \text{BTCL}_U \ge L_iU activates Si​⟺BTCLU​≥Li​

Shard tiers are defined by fixed BTCL thresholds:

L1<L2<L3L_1 < L_2 < L_3L1​<L2​<L3​

There is no hard cap on the number of Shards that may be activated across the network.

---

Activation & Staking

Shard activation requires locking BTCL into the protocol contract.

Let:

• TlockT_{lock}Tlock​ = time of lock

• TunlockT_{unlock}Tunlock​ = time of unlock

• Δt=Tunlock−Tlock\Delta t = T_{unlock} - T_{lock}Δt=Tunlock​−Tlock​

Staking is reversible unless otherwise constrained by protocol conditions.

Upon activation:

1. BTCL is locked.

2. A Shard instance is registered.

3. That Shard is mapped to validation infrastructure.

4. Reward eligibility begins.

Unlocking reverses eligibility and releases BTCL, subject to protocol-defined timing constraints.

---

Validation Infrastructure

Shards do not require users to operate physical hardware.

Activated Shards are programmatically mapped to managed backend validation nodes.

Let:

• NNN = set of validation nodes

• f(Si)→Njf(S_i) \rightarrow N_jf(Si​)→Nj​ = mapping function assigning Shard tier iii to node cluster jjj

Each active Shard increases the validation weight of the network proportionally.

Network validation throughput can be expressed as:

Vtotal=∑k=1nwkV_{total} = \sum_{k=1}^{n} w_kVtotal​=k=1∑n​wk​

Where:

• wkw_kwk​ = validation weight contributed by active Shard kkk

Shard weight may scale proportionally with tier:

w1<w2<w3w_1 < w_2 < w_3w1​<w2​<w3​

---

Reward Mechanics

Rewards are denominated in BTC.

BTC rewards are sourced from BTC-denominated routing fees generated through network activity.

Let:

• FBTCF_{BTC}FBTC​ = total BTC routing fees collected in a given epoch

• SactiveS_{active}Sactive​ = total active Shards

• wkw_kwk​ = weight of Shard kkk

Reward allocation per Shard:

Rk=FBTC⋅wk∑i=1SactivewiR_k = F_{BTC} \cdot \frac{w_k}{\sum_{i=1}^{S_{active}} w_i}Rk​=FBTC​⋅∑i=1Sactive​​wi​wk​​

This ensures:

• No artificial emissions

• No inflationary BTCL reward simulation

• Rewards scale with real network usage

---

Presale Functionality

During the presale phase, Shards serve an additional structural role.

Activated Shards:

• Contribute to early validation modeling

• Participate in presale reward allocation mechanisms

• Establish early participation weight within the network

While validation infrastructure may operate in a managed or simulated mode during presale, Shard logic and activation mechanics remain consistent with post-launch architecture.

Presale participation does not alter long-term reward design principles.

---

Economic Characteristics

Key properties of the Shard model:

• Fixed BTCL thresholds per tier

• Unlimited activations permitted

• BTC-denominated rewards

• No NFT dependency

• Reversible staking model

• Fee-based reward source

The design ensures:

• Alignment between network activity and rewards

• Absence of inflationary emissions

• Scalable validation participation

---

Security Considerations (High-Level)

• Validation infrastructure is managed and audited.

• Shard activation logic is contract-enforced.

• Reward distribution is deterministic.

• Mapping logic between Shards and validation clusters is protocol-controlled.

Further technical documentation on infrastructure topology and audit results will be provided separately.

---