Epoch Nexus

Legacy layer-1 networks hit the same wall from three directions at once.

Serial agreement. Most networks push every transaction through a single ordering pipeline. Adding validators improves security but not capacity, so demand beyond the pipeline's limit becomes a queue and then a fee auction.

Static partitioning. Sharding fixes part of this by splitting state, but partition boundaries chosen at genesis assume load is spread evenly. Real demand is not: one popular application turns one shard into a hot spot while others sit almost idle. Users on the hot shard pay more and wait longer even though the network as a whole has room.

Timing assumptions. Partially synchronous protocols are safe only while messages arrive within a bound the operators guessed in advance. Under attack or during a regional outage, they stall or fork, and the recovery depends on someone retuning a timeout.

Applications end up designing around congestion instead of relying on the network: batching, queuing and retry logic that users never see but always pay for.

Measure, forecast and rebalance continuously, without ever trusting the forecaster.

An epoch is a fixed consensus window in which the validator committee finalizes a set of certified batches. Epoch boundaries are the only moments at which the network may safely change its own configuration, including shard boundaries. Everything in this paper follows from taking that boundary seriously.

• Safety is never learned. Machine learning influences performance only. Correctness rests on aBFT rules that a formal model can check.
• No clocks in the trust base. Liveness and safety hold under arbitrary message delay, so a slow network degrades speed, not security.
• Load follows the work. Buckets of state move toward spare capacity ahead of demand, not after users complain.
• Local first. Neural nodes sit near the data they observe and share compact forecasts instead of raw telemetry.
• Everything auditable. Forecast inputs, outputs and the deterministic checks that accept or reject a plan are committed on-chain.

Three layers with one rule between them: information flows up as telemetry, and proposals flow down as plans that consensus may reject.

Each validator gathers transactions into batches and reliably broadcasts them. When 2f+1 validators acknowledge a batch, its author assembles a certificate proving the data is available. Data moves in parallel across the whole validator set, and everything downstream works on 32-byte certificate digests instead of full batches. This is why ordering does not become the bottleneck as volume grows.

Certificates reference certificates from the previous round, forming a directed acyclic graph. Committees run an asynchronous commit rule over that graph, using a threshold common coin to pick a leader certificate after the round's certificates are fixed. Committing the leader commits its entire causal history in a deterministic order. Section 4 gives the detail.

Neural nodes are ordinary participants that bond stake and run compact forecasting models. They observe mempool arrival rates, account contention and access patterns in their locality, and publish signed forecasts of load per bucket. State is hashed into 4,096 buckets, and a shard is simply a set of buckets. A reshard plan is a list of bucket moves. Section 5 covers how plans are formed, checked and executed.

The network has n = 3f + 1 validators, of which up to f may be Byzantine. Messages between honest validators are eventually delivered, but the delay is unbounded and controlled by the adversary. No protocol step waits on a timeout to preserve safety, and the protocol terminates with probability one thanks to the common coin. The design follows published work on DAG-based asynchronous BFT (references 2 to 5) and adds the layering, sharding and reconfiguration described here.

Because the coin is revealed only after the round's certificates are fixed, an adaptive adversary cannot know which leader to attack in advance. When the network behaves well, an optimistic path commits in a single wave; under attack it falls back to the coin path without any view-change timeout.

Finality is dominated by message delays, not computation. The arithmetic below assumes four message delays per commit and two network scenarios: a regional deployment with 30 ms one-way delay, and a global deployment with 75 ms.

Certificates use aggregate BLS signatures over BLS12-381, so a light client verifies finality with one signature. The common coin is a threshold BLS scheme. Account signatures default to Ed25519. All schemes are versioned protocol parameters, so a post-quantum migration is a governed upgrade, not a hard fork.

A forecast that can be wrong is safe to use only if being wrong is cheap. The engine is designed so that it is.

Each locality runs a small forecasting model, on the order of tens of megabytes, over local mempool arrival rates, contention on hot accounts and recent access patterns. Nodes publish a signed forecast of load per bucket for the next several epochs. A locality's forecasts are combined with a trimmed mean, so a minority of dishonest or faulty neural nodes cannot move the result far.

The engine proposes a reshard plan. The ordering layer accepts it only if a deterministic evaluator, which uses no learned component and reads only on-chain telemetry from past epochs, confirms all of the following:

• No more than 2% of buckets move in one epoch, and no bucket moves twice within eight epochs.
• No shard falls below its minimum bucket count or exceeds its maximum.
• The plan reduces the measured imbalance score of the previous epochs by at least the governed threshold.

If any check fails, the plan is a no-op and the network continues unchanged. A broken model therefore costs performance for an epoch, never funds or correctness.

Figure 3. Illustrative simulation input showing the intended effect. It is not a measured result; the milestone M2 exit criterion in section 8 defines how it will be measured.

The source shard freezes a bucket at an epoch boundary and publishes a Merkle-committed snapshot. The destination verifies the root against the value committed on-chain, then activates the bucket in the next epoch. Transactions that touch the bucket during the handoff are re-queued rather than dropped. Once the destination has served an epoch, the source releases its copy.

Neural nodes bond stake and earn rewards according to a proper scoring rule that compares each forecast with the load that actually arrived. Signing two conflicting forecasts in one epoch is provable misbehavior and is slashed. Forecast accuracy is the only way to earn, so honest, careful forecasting is the profitable strategy.

Each shard executes committed batches deterministically. Transactions declare the state they read and write, which lets a shard execute non-conflicting transactions in parallel and re-execute conflicting ones serially. Because inputs and order are fixed by consensus, every honest replica reaches the same state.

A transaction that touches several shards uses certified receipts. The coordinator shard locks the input versions in epoch e and issues a receipt certificate. Each participating shard verifies the certificate and applies its part in epoch e+1 or later. If any participant rejects, the coordinator issues a rollback certificate that releases the locks. Time limits are counted in epochs, so the protocol keeps its asynchrony guarantees. The design target is completion in about two epochs.

tx.lock(inputs @ version v)         # epoch e, coordinator shard
receipt = certify(2f+1 sigs)        # availability plus validity
for shard in participants:
    apply(receipt) at epoch >= e+1    # verified against committed root
on any reject: rollback_cert -> unlock(inputs)

The security goal is that no honest history is ever reverted (safety) and that valid transactions eventually finalize (liveness), assuming fewer than one third of validators in each committee are Byzantine. The table lists the main threats and how the design contains each.

The token exists to pay for network work and to make honest work the profitable choice. It is not a claim on revenue or profit.

• Fees. Users pay a per-shard base fee plus an optional tip for execution and data availability.
• Staking. Validators stake to join committees; stake at risk backs the safety assumption.
• Bonds. Neural nodes bond tokens that are slashed on provable misbehavior.
• Governance. Holders vote on parameters and treasury spending (section 9).

Figure 4. Illustrative starting parameters, subject to legal review and community governance. Core contributor tokens vest over four years with a 12-month cliff. Validator and neural-node rewards are emitted over ten years on a declining schedule.

Each shard adjusts its base fee every epoch by up to 12.5% toward a 50% utilization target, in the manner of EIP-1559 (reference 7). A hot shard therefore prices congestion locally, and that price is one of the signals the engine reads. The engine moves buckets toward spare capacity; the fee market discourages load from piling up while it does. The two mechanisms push in the same direction and neither depends on the other for safety.

Each milestone ends with an exit criterion that a third party can check. A milestone is complete only when its criterion is met and the evidence is public. Dates are indicative and will move if evidence says they should.

Three bodies share control. Token holders vote on protocol parameters and treasury spending. A validator council must ratify consensus-critical upgrades by a two-thirds supermajority. Every approved change passes a 14-day time-lock before it activates, so users and operators can exit or object. An emergency circuit breaker may pause cross-shard transfers and resharding only. It cannot alter balances, and it expires 18 months after mainnet general availability.

This document is for information only. It is not an offer or solicitation to sell any security, token or other instrument, and it is not financial, legal or tax advice. Statements about performance, features, schedules and token parameters describe intentions and design targets, not commitments, and they may change. Digital assets are volatile and may lose all value. Nothing here creates any right to revenue, profit, ownership or governance in any entity. Regulatory treatment varies by jurisdiction; readers are responsible for complying with the laws that apply to them and should seek independent professional advice.

1. 1 Castro, M. and Liskov, B. Practical Byzantine Fault Tolerance. OSDI 1999.
2. 2 Miller, A. et al. The Honey Badger of BFT Protocols. ACM CCS 2016.
3. 3 Keidar, I. et al. All You Need is DAG. ACM PODC 2021.
4. 4 Danezis, G. et al. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. EuroSys 2022.
5. 5 Spiegelman, A. et al. Bullshark: DAG BFT Protocols Made Practical. ACM CCS 2022.
6. 6 Zamani, M. et al. RapidChain: Scaling Blockchain via Full Sharding. ACM CCS 2018.
7. 7 Buterin, V. et al. EIP-1559: Fee market change for ETH 1.0 chain. 2019.