> For the complete documentation index, see [llms.txt](https://bitcoin-everlight.gitbook.io/bitcoin-everlight-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bitcoin-everlight.gitbook.io/bitcoin-everlight-docs/developer-updates/developer-update-4-shard-architecture-activation-mechanics-and-validation-mapping.md).

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

{% hint style="success" %}
**Status:** Live - Version 1.29.2 
{% endhint %}

### 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.

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://bitcoin-everlight.gitbook.io/bitcoin-everlight-docs/developer-updates/developer-update-4-shard-architecture-activation-mechanics-and-validation-mapping.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.