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.
The roadmap starts from what is already running in production on chain 2800, not from a blank page.
Three items are active. They are numbered because the order is the decision, not a preference.
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.
Where it stands, 2026-10-30. Every validator refuses a commit without a valid post-quantum seal of its author, and nine of the ten refuse any consensus message without one: the nine validators that run the primary, Besu-derived client since 2026-09-08 (commits since 2026-09-05), while the tenth, which runs the independent second, Nethermind-derived client, has refused unsealed commits since 2026-09-11 and applies the rule to proposal, prepare and round-change messages since block 24,300,000 (AIP-22 stage 4, 2026-10-25); since 2026-09-29 every 32nd block carries a certificate of at least seven of the ten validators' Falcon-512 seals under its hash, as many as the quorum (below block 24,148,752 the seals proved those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01, and from that block a certificate that carries the quorum of one round proves the decision), and every 128th block SLH-DSA seals as well (every 128th block with at least six per scheme from 2026-09-05 to 2026-09-29); since 2026-09-30 the validators are named in consensus by post-quantum ids. Native post-quantum transactions (AIP-20, type 0x50, ML-DSA-87) are accepted on mainnet since block 19,900,000 (2026-09-23), and per-block post-quantum finality evidence (AIP-21, aere_getPqFinality) is kept by the validator nodes of both clients; the public RPC endpoints answer the method too, with unavailable, because the seals travel only between validators, and the record of the tenth validator, on the second client, is readable with a JSON-RPC POST of aere_getPqFinality to https://client2.aere.network/finality and through Aere Cloud (GET /v1/pq/finality/latest?network=mainnet; without that parameter the route answers for testnet 28001); measured on the three endpoints on 2026-10-26 (corrected 2026-10-27: this sentence gave both addresses without the method and the parameter, and opened as written the first answers 405). The last stages, post-quantum finality end to end (AIP-22: per-block post-quantum finality and a header without ECDSA), are proven stage by stage on the public testnet 28001, with a conformance corpus both clients pass; stages 1 to 5 and stage R of AIP-22 are live on chain 2800 (stage R since block 24,148,752, stage 4 since block 24,300,000, stage 5 since block 25,080,000, 2026-10-30); stage 6 and rule 4 of section 4 are not. The finality that stages 4 and 5 define was withdrawn as written on 2026-10-01 (AIP-22 erratum) until the post-quantum commit seal bound the consensus round, which it does since block 24,148,751 (2026-10-24). Per-block finality on mainnet rests, for a validator, since block 24,300,000 (AIP-22 stage 4), on votes that every validator attributes only through their verified post-quantum seals (since block 25,080,000, AIP-22 stage 5, headers no longer carry ECDSA commit seals and are admitted on the Falcon-512 seal of their proposer alone; a commit still carries the ECDSA commit seal of its validator as an additional check), and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it. (Corrected 2026-10-09: until that date this paragraph said that since 2026-09-05 no consensus message is accepted without such a seal; that date is the commit layer's alone, and the second client's exception was missing.)
Announced 2026-10-22. Activation of the last stages on the live network is a Foundation decision; it was taken on 2026-10-22 for stage R and stage 4, both now active. On chain 2800, since block 24,148,752 (crossed on 2026-10-24) the anchor certificate has its v3 form (AIP-22, stage R), and the post-quantum commit seal carries the consensus round from its parent, block 24,148,751; every validator and both public endpoints carried this height from 2026-10-21, before it was reached. Since block 24,300,000 (crossed on 2026-10-25, AIP-22 stage 4) every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; that height was set on the nodes before it was reached. The public node package already carries both heights; the published verifier (tools/verify-anchor.mjs) carries the first, from which it expects v3 certificates, and does not need the second, since it pronounces no finality. The stage that removes ECDSA from the header (stage 5) is active since block 25,080,000 (2026-10-30).
Where all of this is going, component by component, with what is live, what is being built and where each ends: the direction page, dated 2026-09-27.
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:
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.
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.
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.
Aere Network runs today on ten validators operated by the Foundation (ten validators since 2026-09-11). We say that plainly rather than dressing it up, because a chain that hides its starting point cannot be trusted about anything else. Ten validators under one operator are 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 has been the tenth validator since 2026-09-11.
One clarification, because two true statements can look like a contradiction. The validator set stays small, ten validators since 2026-09-11, while the post-quantum anchor certificate is enforced. That is an engineering threshold, measured: at ten the quorum is seven and the chain tolerates three 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.
Everything else proposed for the protocol is below, in two groups. The group is the ranking.
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
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.
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.
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.
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 finality 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.