Protocol · Direction · Order

Roadmap, ordered by unique before faster

One question sorts every item on this page. The approved order comes first, the full queue follows, and the rule that governs both is stated at the end. This page carries order and intent. It does not carry delivery dates.

Does it make the network unique, or only faster?

The distinction is not a matter of taste. Anything that only makes a chain faster can be built by anyone with enough capital and enough engineers. Anything that makes a chain categorically different cannot. When the two compete for the same quarter, the second one wins.

Aere Network is not short of good engineering. The risk a roadmap has to defend against is subtler: a year of real, measurable improvement that leaves the network in exactly the category it started in. Everything below is sorted so that does not happen.

Where the network stands today

The roadmap starts from what is already running in production on chain 2800, not from a blank page.

0.5s deterministic finality

QBFT, no re-orgs by construction

Post-quantum verification on chain

Native NIST verifier precompiles, live

Full EVM equivalence

Standard tooling, unmodified

2,800,000,000 AERE

Fixed supply, zero mint

In progress, in the approved order

Three items are active. They are numbered because the order is the decision, not a preference.

Post-quantum, carried by consensus itself

Makes us unique

Aere Network already verifies NIST post-quantum signatures on chain, on mainnet, through native precompiles that anyone can call read-only against chain 2800. The next step carries the post-quantum guarantee further in: from something the network can verify on request into something the network's own consensus commitment carries as a matter of course.

This is the one item that decides whether Aere Network is the first chain to do this or merely an early one. It is an execution item, not a research item: the design is settled, it is carried by more than one independent client implementation, and the remaining work is the disciplined, unglamorous kind. Rehearse it on a separate network first, then activate it at a decided height, the way every serious chain ships a consensus change.

Activation on the live network is a Foundation decision. It will be announced when it is taken, and not before.

Execution Kernel, written as architecture first

Makes us unique

The L1 EVM becomes an L1 Execution Kernel. The EVM stays the first virtual machine on it, and the kernel gains room for others, RISC-V among them. Consensus does not change. The state model does not change. This is the item that changes what the network is, rather than how fast it runs.

It is being written as an architecture document before a line of it is built, and that is deliberate rather than cautious. A kernel is rewritten once. If the boundary between kernel and virtual machine is drawn in the wrong place, nobody finds out for a year. The document has to answer three questions, and it does not move past them:

Where is the boundary? Exactly what the kernel sees, exactly what the virtual machine sees, and the interface that crosses between them.
What stays fixed? Consensus and the state model, named explicitly, together with the parts of them that are not permitted to move.
Which three measurements say it was worth doing? Numbers with a stated method. Not adjectives.

The execution work that lands on this kernel is already scoped: dependency-aware execution, deterministic scheduling, no speculative aborts, a fully parallel commit pipeline, parallel trie updates, parallel witness and proof generation, hardware-aware and NUMA-aware scheduling, a lock-free hot path, GPU-assisted cryptography where it earns its place, and predictive conflict analysis.

Cryptographic abstraction layer

Makes us unique

Today cryptography reaches the protocol directly: algorithm to protocol. The target is protocol, then interface, then algorithm, with the protocol never naming a primitive.

This is not polish. Primitives evolve, standards bodies revise their recommendations, and the field moves faster now than it did five years ago. On the day a recommendation changes, the difference between a week of work and six months of it sits entirely in this layer. It is inexpensive to build now and expensive to retrofit later, which is why it is third rather than tenth.

The road to full decentralization

This one is not ranked with the rest, because it is not an optimisation. It is the direction the network is committed to, and it is written here so it can be held against us.

∞

From a Foundation-operated set to a network no single party can stop

Makes us unique

Aere Network runs today on nine validators operated by the Foundation. We say that plainly rather than dressing it up, because a chain that hides its starting point cannot be trusted about anything else. Nine operators under one roof is a beginning, not a destination.

The commitment is full decentralization: validator keys held by parties we cannot compel, client software written by more than one independent team, and a set that keeps producing blocks when any single operator, including us, walks away. Each of those is a separate piece of work, and each is measurable. Independent client diversity is already under way; the second implementation exists and follows the chain today.

One clarification, because two true statements can look like a contradiction. The validator count stays at nine while the post-quantum consensus commitment is armed. That is an engineering threshold, measured: at nine the quorum is six and the chain tolerates two faulty validators. It is a decision about when to change a parameter, not a retreat from the direction. Growing the set is a matter of when and with whom, not whether.

No dates are promised here. Decentralization that is announced by calendar and delivered by press release is the failure mode we are trying to avoid. Each step will be visible on chain when it lands.

The queue, sorted by the same question

Everything else proposed for the protocol is below, in two groups. The group is the ranking.

Makes the network unique

Post-quantum consensus, end to end

Validator signatures, consensus messages, peer authentication, slashing proofs, checkpoint signatures, light clients and bridge signatures. Not quantum ready. Quantum native. This is the direct continuation of item 01 above, and it is the reason item 01 is first.
Native zero-knowledge execution proofs

Every block produces a proof of its own execution automatically, as the default behaviour rather than as an option someone switches on. It changes what the chain guarantees, not how quickly it guarantees it.
Execution Kernel

Already active as item 02 above.
Cryptographic abstraction layer

Already active as item 03 above.

Makes the network faster

Every one of these is worth building and none of them changes the category the network competes in. They follow the work above rather than competing with it. Makes us faster

Block-STM, second generation
Conflict prediction, dependency graph, parallel scheduling, proof of correct parallelization.
Trie engine, second generation
Verkle, SIMD hashing, cache locality, compressed witnesses, parallel hashing, incremental commitment.
Fully parallel commit
Execution, state update, trie, hashing, witness and proof, all in one parallel pipeline.
Adaptive QBFT
Adaptive timeout, proposer selection, batching, peer selection and retransmission.
Post-quantum engine, second generation
SIMD, GPU, FPGA, AVX512, batching, proof cache, speculative verification.
New network stack
QUIC, multipath, adaptive gossip, erasure coding, congestion-aware routing, prioritization, binary propagation.
New scheduler
NUMA-aware, CPU-topology-aware, SIMD-aware, cache-aware, allocation-free.
Native block builder
Built for throughput, trie locality, cache locality, dependency locality and verification cost.
New state cache
Multi-layer, predictive, trie-aware, witness-aware.
Rewritten RPC engine
Asynchronous, zero-copy, binary, streaming.
Validator runtime
Lock-free, wait-free where it is possible, allocation-free, copy-free.
Storage layer
io_uring, direct I/O, huge pages, asynchronous writes, adaptive compaction.
Signature aggregation
More aggressive, applied everywhere the protocol allows it.
Light client
Fewer proofs, less data, fewer hashes.
Mempool
Conflict-aware, dependency-aware, priority-aware and locality-aware.
Economic verification
Model checking, SMT solving, invariance proofs and simulation proofs for the fee flywheel.

Stated as a decision, not an omission

Formal verification, aimed rather than blanket

Formal verification is pointed at the invariants that matter: the ones whose failure would stop the chain or move value incorrectly. The target is complete coverage of the critical invariants, not of the lines of code. Blanket line coverage would consume precisely the engineers and the months that the work above needs, and it would buy less safety per month spent. That trade is written down here so it is a decision anyone can hold us to, rather than something quietly skipped.

The rule that applies to the whole roadmap

Twenty building sites do not open at once. One item is built, it is proven, and only then does the next one start. A roadmap that reports twenty things in progress has said nothing about any of them.

Every item above counts as finished only with a measurement and a negative control: its own test has to be capable of turning red. A check that has never failed cannot be believed, so each one is deliberately made to fail once before it is trusted to pass.

And no dates. This page states sequence and intent, which are things we control. A published date is a promise about a future we have not measured yet, and Aere Network would rather be held to an order it keeps than to a date it invented.

What the network is intended to carry

Everything below is future work. None of it is offered as a product today, none of it is priced, and nothing here should be read as a service Aere Network currently sells. It is published for one reason: so that anyone can see the direction, and hold us to the order rather than to a press release.

Read this first, because it is the honest frame. Chain 2800 is currently idle: sampled blocks carry no transactions. Every mechanism below that takes a share of activity therefore yields, today, essentially nothing. The mechanisms that are already written into contracts are marked as such and can be read on chain; the rest are intentions. We would rather publish that plainly than publish a catalogue that implies revenue we do not have.

A second honest note on scope: several of these areas are regulated activities in most jurisdictions, custody and compliance attestation above all. Listing them as direction is not a claim that we are licensed to perform them, and we will not perform them before we are.

Twelve engines, not a hundred products

The list below is deliberately grouped. A hundred separate offerings would be a hundred separate things to operate, and operating them badly is worse than not offering them. The grouping is the plan: each new capability the protocol gains has to feed one of these twelve, or it stays a laboratory result.

01 · The Layer 1 itself

Written into contracts today. Transaction fees split by code: a Foundation treasury share, a developer share, and the remainder to burn and validators under the published mechanism. Nothing here is a proposal; it is the fee split the chain already runs. Its output scales with usage, and usage is currently near zero.
02 · Developer economy

Written into contracts today. A registered contract earns a share of the gas its own usage generates, and that right is issued as a transferable token, so it can be held, split or sold independently of the contract. Intended next: a marketplace for templates, components and integrations, and tooling for fractionalised revenue rights.
03 · The agent economy

The settlement fee is written into the contract today at a fixed 25 basis points, routed to the owner-less sink. Intended around it: machine accounts with prepaid balances and spending limits, agent identity anchored to a post-quantum key registry, agent reputation, and bonding so an autonomous agent can be held to its commitments before it transacts.
04 · Compliance and proofs

The primitives are deployed: sanctions enforcement, Travel Rule messaging, zero-knowledge attribute proofs, jurisdiction and eligibility proofs, and an anchored attestation layer. Intended: making these usable by parties outside the chain, as verification rather than as data collection. Regulated in most jurisdictions; direction, not an offer.
05 · Institutional settlement

Deterministic sub-second finality with no re-orgs is the property that makes settlement meaningful, and it exists today. Intended: the surrounding work an institution actually needs, which is reconciliation, reporting, treasury movement and stablecoin rails, plus cross-border routing between currencies and tokenized assets.
06 · Post-quantum custody

A threshold account already exists in which no single key can move funds, and from 2026-08-09 a post-quantum account is live on chain 2800 that authorizes purely through the native Falcon-512 verifier with no classical fallback. Intended: policy engines, approval workflows and key rotation on top. This is the most distinctive direction on the page and also the one most bound by licensing.
07 · Real-world assets

Intended: issuance, the compliance wrapper around it, lending against tokenized collateral, and the reporting an issuer is obliged to produce. The lending engine exists and has been demonstrated; the issuance and reporting work around it does not yet.
08 · Trading

An automated market maker and a native central limit order book with price-time priority are deployed, and a batch settlement path exists that clears at a uniform price and removes the ordering advantage sandwich attacks depend on. No market is listed on them yet. Intended: market making programmes, a permissionless bonded solver set, and an execution interface institutions can actually connect to.
09 · Cross-chain

Intended: routing and intent execution across chains, and interoperability built on proofs rather than on a trusted set of signers. The honest current state is that the bridge components are deployed and the trust-minimized version is the work, not the starting point.
10 · Infrastructure for builders

Public read access and an indexer exist and stay free. Intended alongside them: higher-rate access, historical data and event streaming for teams whose applications outgrow a shared endpoint, and the support arrangements that go with running something in production.
11 · Compute and AI

A compute marketplace runs end to end today, with provider stake, requester escrow, job settlement, dispute and slashing. Intended: inference and training as first-class job types, provenance for which model and version produced a result, and a proof that an inference happened without publishing the prompt or the response, which is the shape the EU AI Act's record-keeping obligation asks for.
12 · Payments and consumer finance

Account abstraction, passkey authentication and four sponsorship patterns are deployed, so an application can carry its users' fees and a user can hold no native token at all. Intended: card settlement, merchant settlement, and a white-label stack a fintech can put its own name on.

How new technology reaches this list

The rule that governs the twelve above is the same one that governs the rest of this page. A capability that does not feed one of them stays a laboratory result, however good it is. Post-quantum consensus is not an upgrade note, it is what makes 06 defensible. Parallel execution is not a benchmark, it is what 05 and 08 need at volume. An encrypted mempool is not research, it is what 08 owes its users. A second production client is not a diversity statistic, it is what 05 requires before anyone regulated will rely on it.

And the constraint we will not pretend away: one thing at a time, finished and proven, before the next one starts. Twelve engines is the destination, not a description of this year. A roadmap that reports a hundred things in progress has said nothing about any of them.