A network that sees the load coming.
Epoch Nexus pairs asynchronous BFT consensus with a distributed intelligence engine that moves work to spare capacity before congestion forms. The design target is finality in under a second.
Pre-testnet. Figures on this page are design targets. The dial is a simulation for illustration, not live network data.
Twelve shards, each arc showing load against capacity. Try the buttons.
Capacity exists. It is just in the wrong place.
Sharded networks split state to scale, but they fix the split at launch. Demand does not stay where it was planned, so one popular application overloads one shard while the rest sit idle.
- Ordering
- Every transaction goes through one pipeline. More validators add security, not capacity.
- Data moves in parallel; ordering runs on small certificate digests.
- Partitioning
- Static shards fixed at genesis. A hot application means a hot shard.
- 4,096 movable buckets; boundaries change at epoch boundaries.
- Timing
- Safety depends on timeouts someone tuned in advance.
- Fully asynchronous. No clock is trusted.
- Congestion
- Fees spike locally while global capacity goes unused.
- Per-shard fees feed the engine, which moves load to spare capacity.
Three layers, one rule: the intelligence layer proposes, consensus decides.
Distributed Intelligence Engine
Localized neural nodes read mempool arrival rates, account contention and access patterns, then publish signed forecasts of load per bucket. Their combined forecast becomes a reshard plan: a list of bucket moves.
A plan takes effect only if a deterministic check passes:
- No more than 2% of buckets move in one epoch, and none twice within eight epochs.
- No shard falls below its minimum size or exceeds its maximum.
- Measured imbalance from past epochs improves by the governed threshold.
If any check fails, the plan does nothing. A broken model costs performance for an epoch, never funds or correctness.
Asynchronous BFT ordering
Certificates form a DAG. A threshold common coin picks a leader certificate after the round's certificates are fixed, and committing the leader commits its entire history in a deterministic order. Safety holds with fewer than one third Byzantine validators and no timing assumption.
- Aggregate BLS signatures let a light client verify finality with one signature.
- Committees are resampled every epoch from unbiasable randomness.
- Cross-shard transactions use certified receipts, with expiry counted in epochs, not seconds.
Parallel dissemination
Each validator batches transactions and reliably broadcasts them. When 2f+1 validators acknowledge a batch, an availability certificate proves the data is there. Ordering then works on 32-byte digests instead of full batches, so it does not become the bottleneck as volume grows.
Where the time goes.
Finality is dominated by message delays, not computation. A commit takes four message delays plus a fixed 115 ms for batching and verification. Move the slider to see what your network delay does to the budget.
Design arithmetic, not a benchmark. The 600 ms median target leaves headroom for queuing and stragglers.
Seven milestones, each with an exit anyone can check.
A milestone is complete only when its criterion is met and the evidence is public. Dates are indicative, from Q4 2026 to Q4 2028, and move if the evidence says they should.
M0 Specification and simulatorQ4 2026 Up next
Deliverables
Protocol spec v0.9, TLA+ models, deterministic simulator, open reference repository.
Exit criterion
Simulator upholds safety and liveness over 10,000 randomized schedules with f Byzantine nodes; two external research reviews.
M1 Devnet alphaQ1 2027 Planned
Deliverables
Single-shard aBFT core on 64 validators; benchmark methodology and raw data published.
Exit criterion
Median finality 400 ms or less on a regional network; 72-hour soak with zero safety violations.
M2 Intelligence Engine v0Q2 2027 Planned
Deliverables
Neural nodes, forecast aggregation, deterministic evaluator, bucket migration on an 8-shard devnet.
Exit criterion
At least 40% lower worst-shard overload than static shards on a skewed replay; zero unsafe migrations under fault injection.
M3 Incentivized public testnetQ3 to Q4 2027 Planned
Deliverables
Permissionless validators and neural nodes, chaos-testing campaign, bug bounty.
Exit criterion
200+ validators and 50+ neural nodes across 5+ regions; 30-day median finality 700 ms or less.
M4 Audits and formal verificationQ4 2027 to Q1 2028 Planned
Deliverables
Two independent audits (consensus and cryptography; economics and contracts), mechanized safety proof.
Exit criterion
All critical and high findings fixed; audit reports and proof published.
M5 Mainnet betaQ2 2028 Planned
Deliverables
Guarded launch with validator cap, per-shard circuit breakers and value limits.
Exit criterion
90 days without a critical incident to lift caps; measured median finality 600 ms or less.
M6 Mainnet general availabilityQ3 to Q4 2028 Planned
Deliverables
On-chain governance, treasury and grants, TypeScript and Rust SDKs, cross-shard app framework.
Exit criterion
First parameter change ratified by on-chain vote; SDKs released with reference apps.
A token for network work, not a claim on profit.
The token pays for execution and data availability, backs validator stake and neural-node bonds, and carries votes on parameters and treasury spending. Half of every base fee is burned, 40% goes to the committee, and 10% rewards accurate forecasts.
Allocation is illustrative, pending legal review and governance. Token value can fall to zero. Nothing here is an offer or solicitation.
- Ecosystem and grants30%
- Validator and neural-node rewards25%
- Core contributors18%
- Treasury12%
- Community and strategic sale10%
- Liquidity and market operations5%
The whitepaper, 10 pages.
Architecture, the consensus protocol, the intelligence engine and its guardrails, the security model, token economics, and the full milestone plan with exit criteria. Read it here, or take the PDF.