e4cead319d
Aere Network public source. Everything here can be checked against the live chain (chain id 2800, https://rpc.aere.network). Scope note, stated up front rather than buried: consensus on chain 2800 is classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at the signature, precompile, account and transport layers. Nothing here makes the consensus post-quantum, and no document in it should be read as claiming so.
36 KiB
spec-25: The Aere Improvement Proposal (AIP) Process, Index, and Design-Decision Records
| Field | Value |
|---|---|
| Spec | 25 |
| Title | The Aere Improvement Proposal (AIP) Process, Index, and Design-Decision Records |
| Author | Aere Network Foundation |
| Status | For publication |
| Created | 2026-07-19 |
| Chain | Aere Network, chain ID 2800 |
0. Purpose of this document
This document does three things.
- It formalizes the AIP process: what an Aere Improvement Proposal is, the lifecycle it moves through, who may propose one, where proposals live, and how they are ratified today.
- It publishes a canonical index of every AIP that currently exists in the Aere repositories, with its real number, title, status, and path. It records the real state, including the fact that the process is young and the numbering is short.
- It drafts the key design-decision records for load-bearing architecture choices that are not yet captured under a numbered AIP, continuing the real existing numbering.
The goal is a transparent, numbered, dated record of Aere's reasoning that any auditor, integrator, or automated agent can read and, if they disagree, fork. This is the same intent behind Ethereum's EIP/ERC process and Rust's RFCs. Because it is published, everything in it must be honest.
0.1 Honesty note on community review (read this first)
An AIP process is worth running from day one, even before an external technical community exists, because its first job is transparent decision documentation: a stable, plain-text home for the motivation, mechanism, on-chain proof, and honest limitations of each change. That value does not depend on anyone commenting.
The comment and review mechanism defined below is open: anyone may author an AIP, raise an issue on one, or fork the record. But it must be stated plainly that Aere has essentially no external technical community commenting yet. The network's decentralization is thin (an effective Nakamoto coefficient of about 1, since all validators are Foundation-operated on a single client), and real external usage is thin. Public comment on AIPs becomes meaningful only as an external developer and validator community forms.
Therefore this document, and the AIPs it indexes, contain no fabricated community discussion: no invented "the community debated," no fake review threads, no imagined external participants, and no comment counts. Where an AIP records a decision, it records who actually decided (today, the Foundation) and on what evidence. The review mechanism exists now; organic external comment is expected later, and will be recorded honestly when it happens, not simulated in advance.
1. The process
1.1 What an AIP is
An AIP (Aere Improvement Proposal) is a design document describing a change to the Aere Network (chain ID 2800), its contracts, its consensus parameters, or its processes. An AIP records the motivation for a change, the exact mechanism, the rationale for the design, and, when the change is already live, the on-chain addresses and transactions that prove it exists. AIPs are Aere's equivalent of Ethereum's EIP/ERC process. They exist so that a reader, human or machine, can reconstruct why the chain works the way it does from a single canonical plain-text source instead of from marketing pages.
What belongs in an AIP: a protocol or consensus change (block time, fee routing, precompiles); a new contract standard or interface other builders integrate against; a token-standard or account-standard convention (ARC); a process or governance change (Meta).
What does not belong in an AIP: bug-fix redeploys that preserve an existing interface (tracked in the SDK address registry's deprecation notes), routine parameter tuning inside an already-ratified bound, and pure documentation.
1.2 Lifecycle
The normative lifecycle is Draft -> Review -> Last Call -> Final. Living replaces Final for standards that keep evolving (an index, a registry). Withdrawn and Stagnant are the off-ramps.
| Status | Meaning |
|---|---|
| Draft | Well-formed, has an author, may still change substantially. |
| Review | Author has requested wider scrutiny; open questions are tracked in the AIP. |
| Last Call | A stated final-review window (default 14 days). If no blocking issue is raised, it advances. |
| Final | Accepted. For shipped work, live on chain 2800. Breaking changes after Final require a new AIP that supersedes it. |
| Living | Accepted and expected to keep being updated. |
| Withdrawn | Abandoned. Terminal; the number is retired, not reused. |
| Stagnant | Inactive in Draft or Review beyond 6 months. Revivable by any author. |
Retro-filed AIPs (documents written after the change already shipped) enter directly at Final or Living and state in their Abstract that they backfill history.
1.3 Categories and types
Types are Standards Track, Meta, and Informational. Informational AIPs give guidance and do not mandate anything. A Standards Track AIP names exactly one category:
- Core: consensus, block production, fee and burn accounting, precompiles, genesis and client configuration.
- Networking: peer-to-peer protocol and sync.
- Interface: contract interfaces, ABIs, RPC conventions, verification surfaces.
- ARC (Aere Request for Comment): application and token standards (ERC-20, ERC-4626, ERC-4337, ERC-6551 conventions as adopted on Aere).
Meta and Informational carry no category.
1.4 Roles
- Author. Anyone may author an AIP. The author writes the document, drives it through the statuses, and answers review questions.
- Editor. Checks that an AIP is well-formed, correctly numbered and categorized, and technically coherent, and that every cited address, transaction, and number is real. The editor does not judge whether a proposal is a good idea; that is the ratifier's job. Until decentralization, the editor is the Foundation.
- Ratifier. The party whose approval moves an AIP to Final. Until decentralization this is the Foundation account
0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3, a single-key, Foundation-controlled account (not a deployed multisig).
1.5 How to file an AIP
- Copy the template to
AIP-N.md, where N is the next free integer. - Fill in every required section (Preamble, Abstract, Motivation, Specification, Rationale, Backwards Compatibility, Security Considerations, Reference Implementation and On-Chain Deployment, Copyright). A section that does not apply keeps its header with the body "None".
- Cite on-chain addresses verbatim from the canonical SDK registry (
sdk-js/src/addresses.ts). Never invent an address, transaction hash, or gas number. If a number has not been measured, write "to be measured". - Add a row to the index.
- Open it for editorial review. Anyone may raise an issue against it. Until decentralization, the editor and ratifier is the Foundation.
1.6 Where AIPs live
- Canonical scaffold:
aerenew/aips/holdsREADME.md,aip-template.md, and the retro-filed records AIP-1 through AIP-7. This is the seed of a public AIP repository. - AIP-8 currently lives as a standalone Draft at
aerenew/docs/AIP-PQ-TX-2026-07-18.mdand has not yet been moved into theaerenew/aips/index. This document records that real state; consolidating it into the scaffold index is a housekeeping step. - Earlier publish-staging copy:
aere-research-repo/aips/holds AIP-1 through AIP-6 with an older governance note (it says "three validators" and describes the Foundation account as a "multisig"). It is stale relative toaerenew/aips/, which reflects the current reality of seven validators and a single-key Foundation account. Theaerenew/aips/copy is authoritative where the two differ.
1.7 Sourcing rules (binding on every AIP)
- Every on-chain address is copied verbatim from the canonical SDK registry. No address is guessed. If unsure, omit it.
- Every gas figure, transaction hash, and block number is reproducible from the chain or a repo fixture. Unmeasured quantities are written as "to be measured", never invented.
- Design ceilings (for example a theoretical maximum throughput) are never presented as measured throughput.
1.8 Honest governance note and the decentralization path
Aere is not yet trustlessly governed. Today the network runs seven QBFT validators (f=2, commit quorum 5-of-7) under a single operator, on one client (Hyperledger Besu), with no external security audit and thin real usage. In that reality an AIP is not ratified by an on-chain vote of independent stakeholders. It is Foundation-ratified: the Foundation account is the final editor and approver. Every AIP that predates validator and client decentralization carries the label "Foundation-ratified (pre-decentralization)" so no reader mistakes editorial ratification for trustless governance.
The intended migration, each step of which will be its own Meta AIP: (1) open the validator set beyond the current seven Foundation-operated validators and run a second client as a live producer; (2) introduce a public review period the Foundation cannot unilaterally shorten; (3) move ratification to stake-weighted or validator-weighted approval once an independent staker and validator base exists. Until step 3, all Standards Track AIPs carry the pre-decentralization label. The chief risk of a pre-decentralization process, that a single party can both author and ratify, is mitigated only partially today by the editor's sourcing rules and by keeping the honesty label on every proposal; it is fully mitigated only when independent ratifiers exist. This weakness is stated rather than hidden.
2. Index of existing AIPs (real state)
The numbering is contiguous from 1 to 8, with no gaps. AIP-1 through AIP-7 are ratified and live in aerenew/aips/. AIP-8 is a Draft in aerenew/docs/. No AIP numbered 9 or higher exists in any Aere repository as of this writing; the records in Section 3 below are the first drafts of AIP-9 onward.
| AIP | Title | Type / Category | Status | Path |
|---|---|---|---|---|
| 1 | AIP Purpose and Process | Meta | Living | aerenew/aips/AIP-1.md |
| 2 | Coinbase Fee-Burn Routing (37.5%) | Standards Track / Core | Final | aerenew/aips/AIP-2.md |
| 3 | Sub-Second Block Period (500 ms QBFT) | Standards Track / Core | Final | aerenew/aips/AIP-3.md |
| 4 | On-Chain Post-Quantum Signature Verification Suite | Standards Track / Interface | Final | aerenew/aips/AIP-4.md |
| 5 | sAERE Receipt Token and AereSink Immutable Flywheel | Standards Track / ARC | Final | aerenew/aips/AIP-5.md |
| 6 | ERC-4337 Passkey and Gasless Onboarding Stack | Standards Track / ARC | Final | aerenew/aips/AIP-6.md |
| 7 | AerePQC Hard-Fork Activation (Native PQC Precompiles and Extended EIP-2935 Lookback) | Standards Track / Core | Final | aerenew/aips/AIP-7.md |
| 8 | Post-Quantum-Authorized Transaction Envelope (EIP-2718 Type 0x2A) | Standards Track / Core | Draft (not live) | aerenew/docs/AIP-PQ-TX-2026-07-18.md |
Notes on real state:
- AIP-1 through AIP-7 are Foundation-ratified (pre-decentralization). AIP-2 through AIP-7 are retro-filed records of changes already live on chain 2800; AIP-1 is the process document itself.
- AIP-8 is a genuine Draft: it specifies a base-layer post-quantum transaction type that requires a coordinated Besu hard fork and is not deployed. It ships with a deploy-today ERC-4337 reference path (
AerePQCTxAccount.sol) that needs no fork. - The mechanism specification behind AIP-7 also exists as
aerenew/research/aip-draft-pqc-precompiles.md(frontmatteraip: TBD, marked SHIPPED); it is the design/gas spec, canonically recorded as AIP-7. It is not a separate AIP number. - A duplicate AIP-1 through AIP-6 set exists under
aere-research-repo/aips/; it is an older copy and is superseded byaerenew/aips/where the two disagree (see 1.6).
2.1 Coverage map: which section-4 decisions already have a record
The engineering rationale in aerenew/docs/AERE-ENGINEERING-SECURITY-SPEC.md Section 4 enumerates the load-bearing design decisions. Several already have a numbered AIP; the rest are drafted in Section 3.
| Section 4 decision | Captured by | New record needed |
|---|---|---|
| 4.1 Consensus: QBFT, not HotStuff | (none) | Yes -> AIP-9 |
| 4.2 Execution client: forked Besu with Nethermind second, not Reth | (none) | Yes -> AIP-10 |
| 4.3 Interoperability: Hyperlane-compatible plus zk light clients, not IBC | (none) | Yes -> AIP-11 |
| 4.6 Virtual machine: extend the EVM, not a new VM | (none) | Yes -> AIP-12 |
| 4.4 Post-quantum signatures: Falcon and ML-DSA together, not one lattice family | AIP-4, AIP-7 (mechanism) | Yes, as a distinct decision record -> AIP-13 |
| 4.5 Account abstraction: ERC-4337 with EIP-7702 bridge, not native AA | AIP-6 (stack) | Yes, as a distinct decision record -> AIP-14 |
| 4.7 The burn: validator-reward cut, not a base-fee burn | AIP-2 (mechanism and rationale) | No; already recorded in AIP-2 |
| PQC precompile activation | AIP-7 | No; already recorded in AIP-7 |
| In-place hybrid PQC consensus activation (R&D, not live) | (none) | Yes -> AIP-15 |
| PQ STARK-verify precompile 0x0AE8 (skeleton, not live) | (none) | Yes -> AIP-16 |
3. Design-decision records drafted here (AIP-9 to AIP-16)
These are the first drafts of the records that continue the real numbering after AIP-8. AIP-9 through AIP-14 document architecture decisions that are already live and settled, so they enter at Final as Informational records (they explain rationale for a shipped choice rather than mandate a new normative change). AIP-15 and AIP-16 document research and blocked work that is not live on chain 2800, so they enter at Draft. Each record is deliberately concise: context, decision, rationale, alternatives rejected, and status. The normative mechanism for a decision that also has a Standards Track AIP (AIP-13 references AIP-4/AIP-7; AIP-14 references AIP-6) stays in that AIP; the record here captures the decision framing.
The post-quantum scope boundary holds throughout: Aere consensus is classical secp256k1 ECDSA QBFT. Post-quantum applies to signatures, accounts, and applications only. No record here claims post-quantum consensus.
AIP-9: Consensus Mechanism: QBFT, not HotStuff
| Field | Value |
|---|---|
| AIP | 9 |
| Title | Consensus Mechanism: QBFT, not HotStuff |
| Author | Aere Network Foundation |
| Type | Informational |
| Status | Final |
| Created | 2026-07-19 |
| Ratification | Foundation-ratified (pre-decentralization) |
Context. Aere is a settlement layer whose core promise is deterministic, single-slot finality at a sub-second cadence. It runs a small, permissioned validator set: seven validators today, with a roadmap target in the 9 to 21 range.
Decision. Use QBFT, the Byzantine-fault-tolerant IBFT-family protocol as implemented in Hyperledger Besu, producing deterministic single-block finality at a target block time of about 0.5 s. At N=7, QBFT tolerates f=2 Byzantine or crashed validators with a commit quorum of 2f+1 = 5-of-7.
Rationale. At Aere's validator-set size, QBFT's O(N^2) message complexity is negligible in absolute terms (a 5-of-7 quorum verify costs on the order of a few milliseconds per block, a small fraction of the 500 ms slot). Against that non-cost, QBFT gives three concrete advantages: deterministic instant single-block finality (the exact settlement guarantee the network sells), maturity and existing integration in Besu (no new-protocol implementation risk), and the fact that Aere's post-quantum consensus research, second-client work, and zk finality proofs are all built against QBFT.
Alternatives rejected. HotStuff and its pipelined variants, whose linear per-round communication complexity is engineered to scale BFT to hundreds of validators. That scaling regime is one Aere does not operate in and does not plan to enter under this design, so HotStuff's headline benefit is unavailable, while adopting it would add the risk and integration cost of a protocol less battle-tested in the chosen client.
Honest limitation. At N=7 the fault tolerance against node outages is real, but all validators are Foundation-operated. Decentralization, not the consensus mechanism, is the binding trust assumption. The block-period choice (500 ms) is documented separately in AIP-3.
Status. Final. Live on chain 2800.
AIP-10: Execution Client: Forked Besu with Nethermind as the Second Client, not Reth
| Field | Value |
|---|---|
| AIP | 10 |
| Title | Execution Client: Forked Besu with Nethermind as the Second Client, not Reth |
| Author | Aere Network Foundation |
| Type | Informational |
| Status | Final |
| Created | 2026-07-19 |
| Ratification | Foundation-ratified (pre-decentralization) |
Context. A production chain needs a producing client and, to retire single-implementation risk, a second independent client. Aere already ships QBFT, which is Besu-specific: no off-the-shelf Geth, Reth, Erigon, or stock Nethermind produces QBFT-compatible blocks.
Decision. A fork of Hyperledger Besu v26.4.0 (Java, base commit d2032017, JDK 21 toolchain) is the sole live mainnet producer. The fork adds the native post-quantum precompiles and extended EIP-2935 lookback (live since block 9,189,161, AIP-7) and the 1-Gwei base-fee floor (live since block 10,141,734). A patched Nethermind 1.39.0 (.NET) is the second, independent client.
Rationale. Besu already carries QBFT and already carries the codebase into which the PQC precompile fork and base-fee changes were integrated. Nethermind was chosen as the second client specifically for implementation diversity: a different codebase in a different language (.NET versus Java), so a consensus-relevant bug in one is unlikely to exist in the other. The patched Nethermind validates the live chain, runs the five PQC precompiles byte-for-byte identically (27 of 27 NIST KAT vectors), and, on an isolated test network, produces byte-identical QBFT blocks that stock Besu accepts through full BFT validation (with a one-byte-tampered seal rejected).
Alternatives rejected. Reth (Rust) as the base client: it has no notion of QBFT, so it would require building QBFT production into a client that lacks it before producing a single block; and the September 2025 Reth halt is the reference case for why depending on one producing implementation is a systemic risk. A second Besu instance instead of Nethermind: that is not client diversity, since it shares every bug with the first.
Honest limitation. Cross-client production is proven on an isolated testnet (offline import and, later, live devp2p between test nodes), and a listen-only Nethermind follower has run against the live network. Nethermind is not yet a live gossiping producer on chain 2800. Besu remains the sole live producer; the second client is a client-diversity cross-check and fail-safe today, not a second live validator. Making Nethermind a live producer is a founder-supervised change, because a producer bug on a live chain can halt or fork it.
Status. Final (as the decision and the current live topology). Live producer: Besu only.
AIP-11: Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC
| Field | Value |
|---|---|
| AIP | 11 |
| Title | Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC |
| Author | Aere Network Foundation |
| Type | Informational |
| Status | Final |
| Created | 2026-07-19 |
| Ratification | Foundation-ratified (pre-decentralization) |
Context. Aere's value proposition is that it is an ordinary EVM chain. Cross-chain interop must serve permissionless, EVM-familiar builders while also offering trust-minimized verification of a counterparty's finality.
Decision. An EVM-native, Hyperlane-compatible messaging layer (a Mailbox-compatible AereMessenger, an interchain gas paymaster AereIGP), an ERC-7683 intent layer, and an Across-v3-compatible spoke pool. Alongside it, a zero-knowledge interop path: on-chain zk light clients that verify a counterparty's consensus finality (inbound Ethereum sync-committee finality, outbound Aere QBFT finality) from inside a contract, via SP1 Groth16 proofs.
Rationale. IBC's design philosophy, verifying the counterparty's consensus rather than trusting a bridge committee, is the right one, and Aere adopts it directly. Aere splits the problem: for permissionless developer-familiar interop it uses the Hyperlane-compatible interfaces the EVM tooling ecosystem already speaks; for the trust-minimization that is IBC's real contribution it built the zk light clients, which capture "verify the counterparty's consensus, do not trust a relayer" without leaving the EVM world.
Alternatives rejected. IBC as a protocol: it is built around Tendermint-style light clients and a non-EVM connection, channel, and packet model. Adopting it natively would import a substantial non-EVM stack and its tooling into a chain whose entire premise is that it is an ordinary EVM.
Honest limitation. The Hyperlane-compatible endpoints are interface-faithful and deployed, but a live decentralized relayer and interchain-security-module network is not yet stood up (the current bridge path runs through a single Foundation signer with a relayer pending). The zk light clients are trust-minimized, not trustless, and not quantum-safe: their committed seals are classical secp256k1 and the proof wrap is Groth16 over BN254 (Shor-breakable).
Status. Final (as the decision). Deployed interfaces; decentralized relayer pending.
AIP-12: The Virtual Machine: Extend the EVM, not a New VM
| Field | Value |
|---|---|
| AIP | 12 |
| Title | The Virtual Machine: Extend the EVM, not a New VM |
| Author | Aere Network Foundation |
| Type | Informational |
| Status | Final |
| Created | 2026-07-19 |
| Ratification | Foundation-ratified (pre-decentralization) |
Context. Aere differentiates on post-quantum verification, parallel execution, and extended block-hash lookback. It must add these without taxing the developer surface it depends on.
Decision. Keep the EVM. Solidity, EVM bytecode, JSON-RPC, and the developer tooling are unchanged. Differentiation is added as precompiles and client-fork rules at otherwise-empty reserved addresses, not as a new instruction set or a new language, and activated by client-only forks in the same manner Ethereum activates its own hard forks.
Rationale. A mature VM has years of implementation hardening, a known cost model, and an operational history; a new VM starts that clock at zero, maximizing technical and adoption risk. The EVM is the single largest smart-contract developer surface in existence, and every deviation (a nonstandard opcode, account model, or RPC) is a tax on every developer and tool. Aere's thesis is settlement, not a novel programming model, so the design keeps the tested execution environment intact and adds differentiation only at the EVM's standard extension points (precompiles at reserved addresses). Nothing about Aere's account, passkey, or post-quantum surface depends on a nonstandard EVM.
Alternatives rejected. Designing a new, purpose-built VM (a new bytecode, language, or non-EVM environment) optimized around Aere's differentiators.
Honest limitation. Some ambitions (base-layer parallel execution, an EVM-in-a-zkVM) must be reached inside the existing model rather than designed in from scratch. Those remain roadmap and are labeled as such.
Status. Final. Live on chain 2800.
AIP-13: Post-Quantum Signatures: Falcon and ML-DSA Together, not a Single Lattice Family
| Field | Value |
|---|---|
| AIP | 13 |
| Title | Post-Quantum Signatures: Falcon and ML-DSA Together, not a Single Lattice Family |
| Author | Aere Network Foundation |
| Type | Informational |
| Status | Final |
| Created | 2026-07-19 |
| Requires | 4, 7 |
| Ratification | Foundation-ratified (pre-decentralization) |
Context. Aere verifies post-quantum signatures on-chain at both the contract layer (AIP-4) and, since block 9,189,161, the native precompile layer (AIP-7). A choice of scheme family is a bet on a mathematical assumption.
Decision. Support multiple post-quantum signature schemes across two distinct lattice families, Falcon (Falcon-512 and Falcon-1024) and ML-DSA (Dilithium2 / ML-DSA-44), alongside hash-based schemes (SLH-DSA, XMSS, WOTS+). The live precompiles for SHAKE256, Falcon-512, Falcon-1024, ML-DSA-44, and SLH-DSA-SHA2-128s occupy the 0x0AE1 to 0x0AE5 band.
Rationale. Cryptographic-risk diversification. Falcon rests on NTRU lattices; ML-DSA rests on module lattices with Fiat-Shamir-with-aborts. Supporting both means a cryptanalytic break or a standardization flaw in one lattice family does not, by itself, remove Aere's ability to verify post-quantum signatures: accounts and settlement authorization can migrate to the surviving family. This mirrors the hybrid AereHybridAuth account, which requires both a classical ECDSA and a Falcon-512 signature so that neither a broken curve nor a broken lattice alone suffices to forge.
Alternatives rejected. Standardizing on a single lattice scheme (ML-DSA alone as the NIST primary, or Falcon alone for its compact signatures). The cost of supporting several schemes is more verifier surface to implement, validate, and eventually audit; that cost is accepted deliberately rather than betting the network's post-quantum future on a single assumption.
Scope boundary (binding). This is post-quantum at the signature, account, and application layer only. Consensus remains classical (validators sign secp256k1 QBFT), and the zk verification is classical (BN254 Groth16, Shor-breakable). Aere never claims post-quantum consensus.
Honest limitation. The verifiers and precompiles carry an internal self-audit only; an external audit is pending before they should secure material value. Their assurance today rests on bit-for-bit agreement with official NIST KAT and ACVP vectors and cross-checks against independent reimplementations.
Status. Final. Precompiles live on chain 2800; the normative mechanism is in AIP-4 (contract suite) and AIP-7 (precompile activation).
AIP-14: Account Abstraction: ERC-4337 with EIP-7702 Bridge, not Native AA
| Field | Value |
|---|---|
| AIP | 14 |
| Title | Account Abstraction: ERC-4337 with EIP-7702 Bridge, not Native AA |
| Author | Aere Network Foundation |
| Type | Informational |
| Status | Final |
| Created | 2026-07-19 |
| Requires | 6 |
| Ratification | Foundation-ratified (pre-decentralization) |
Context. Aere wants programmable accounts (recovery, passkey ownership, post-quantum ownership, gas sponsorship) without breaking EVM and EOA compatibility.
Decision. ERC-4337 (v0.7) smart accounts as the account-abstraction path, with EIP-7702 (live under the Pectra ruleset) as the migration bridge that lets existing externally-owned accounts (EOAs) delegate to smart-account code.
Rationale. ERC-4337 needs no consensus change, is an established standard with an existing bundler and tooling ecosystem, and delivers programmable accounts (including the Falcon-owned post-quantum smart account AerePQCAccountFactory) without touching the protocol, preserving exact EVM and Ethereum compatibility. EIP-7702 is the chosen bridge precisely because it upgrades existing EOAs in place without forcing a disruptive "everything is a contract" change.
Alternatives rejected. Native, protocol-level account abstraction up to an "all accounts are smart accounts by default" end-state: it changes what an account fundamentally is, breaking existing tooling, contracts, and user keys. EIP-3074, an earlier EOA-empowerment proposal: it was superseded by EIP-7702, which is the mechanism Aere carries; Aere does not implement EIP-3074.
Honest limitation. The EntryPoints are Aere's own ERC-4337-compatible implementations, compatible in shape and interface but not byte-identical to Ethereum's canonical audited singleton; integrators should treat them as Aere-specific. Gasless onboarding is subsidized (Foundation-funded, rate-limited), not free. These contracts have not had an external audit.
Status. Final. Live on chain 2800; the normative stack (accounts, factories, paymasters, EntryPoints) is in AIP-6.
AIP-15: In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis
| Field | Value |
|---|---|
| AIP | 15 |
| Title | In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis |
| Author | Aere Network Foundation |
| Type | Standards Track |
| Category | Core |
| Status | Draft (isolated-testnet R&D; not live on chain 2800) |
| Created | 2026-07-19 |
| Ratification | Not ratified; external-audit and founder gated |
Context. Aere's hybrid consensus research (Stage 1 and Stage 2) proved a gossiped, blocking Falcon-512 quorum certificate that runs alongside the ECDSA committed-seal quorum, empirically at N=4 (2 s) and N=7 (0.5 s). Its Falcon registry, however, was bound to chain identity at genesis (folding keccak256(manifest) into the genesis state root). Chain 2800 launched long before any Falcon manifest existed, so blocking activation was previously recorded as "requires a re-genesis," a non-starter for a live chain because re-genesis destroys history and chain identity.
Decision. Bind the Falcon manifest to on-chain state post-genesis, via a minimal, immutable, ownerless anchor contract deployed by one ordinary transaction at an activation height. The contract commits keccak256(manifest) to storage slot 0 (its runtime code is a single STOP byte; it is never callable and has no admin). On every block import the validation rule resolves the manifest from the parent block's world state at the anchor address and activates the pending registry only if the observed hash matches, failing closed on any mismatch. The re-genesis requirement is removed.
Rationale. The late anchor folds keccak256(manifest) into every block hash from the deployment block onward, so two nodes that agree on the chain past that block necessarily agree on the anchored hash: the same integrity guarantee the genesis ceremony gave, minus the re-genesis. The deploy address is deterministic (keccak256(rlp[deployer, nonce])[12:]), so validators can be pre-configured before deployment, and activation is idempotent and retried each block, so deploy-then-configure and configure-then-deploy both converge.
Alternatives rejected. Re-genesis carrying a Falcon anchor in genesis alloc (destroys history and chain identity). A shared per-node manifest file with no on-chain root (a node with a tampered manifest could join silently; the on-chain anchor makes it fail closed instead).
Evidence and honest scope. Proven end-to-end on an isolated N=4 @ 0.5 s testnet (chainId 440855) whose genesis is byte-shape-identical to a classical ECDSA-only chain: classical start, deploy anchor at block 16, activate from the contract at block 17, flip to blocking at fork block 150, with 0 forks, 0.5 s cadence maintained, pre-activation blocks still valid, a post-activation sub-quorum block rejected (chain halts), and recovery in place with no re-genesis. Nothing here is live on chain 2800. Chain 2800 consensus remains classical secp256k1 ECDSA QBFT at N=7, with no Falcon layer of any kind in its headers. The hybrid can only shrink the committable set, so it is never worse than the ECDSA-only chain; ECDSA committed seals remain the decisive safety and liveness seal.
Remaining gates to a live flip. No longer a gate: re-genesis. Still required: an external audit of the Falcon consensus patch (quorum, gossip, assembly, late-anchor Java) and of BouncyCastle Falcon-512 on the consensus path; finalizing the full target validator set (N >= 9 recommended, since N=7 blocking has a zero two-fault margin) with an address-bound manifest re-anchored for the full set; a live isolated N=7 (ideally N=9) soak of the combined activation; and an explicit founder GO. No agent activates blocking consensus on chain 2800.
Status. Draft. Reference patch: aerenew/consensus-pqc/besu-consensus-pqc-fork-activation.patch with evidence under aerenew/consensus-pqc/inplace-activation-evidence/.
AIP-16: PQ STARK-Verify Precompile (0x0AE8)
| Field | Value |
|---|---|
| AIP | 16 |
| Title | PQ STARK-Verify Precompile (0x0AE8) |
| Author | Aere Network Foundation |
| Type | Standards Track |
| Category | Core |
| Status | Draft (reference skeleton; verifies nothing; not live on any Aere network) |
| Created | 2026-07-19 |
| Ratification | Not ratified; prerequisite-gated, external-audit gated, founder gated |
Context. Aere's zk interop and validity paths currently wrap proofs as Groth16 over BN254, which is classical and Shor-breakable. A post-quantum-sound proof system (a FRI-based STARK, hash-commitment only, no pairing) would remove that assumption. A native precompile is the natural home for STARK verification, matching the same reasoning used for the PQC signature precompiles in AIP-7.
Decision. Reserve precompile address 0x0AE8 for a PQ STARK-verify precompile that verifies a hash-based STARK directly on-chain (removing a BN254 pairing check). It is specified to activate under a new, forward-dated milestone (PQ-3), never folded into an already-crossed milestone, so that pre-activation history is byte-identical on old and new binaries and the upgrade itself carries no fork risk.
Scope caveat (2026-07-19 research finding). An earlier draft described this as verifying "an SP1 inner-STARK (FRI over a Poseidon2 commitment)". That is corrected: the verifier skeleton built so far is a BabyBear + FRI STARK verifier, conformance-confirmed against Plonky3 0.4.3-succinct, which targets Aere's OWN Plonky3 circuits, NOT SP1 6.1.0. The pinned SP1 6.1.0 is a Hypercube release (KoalaBear multilinear: BaseFold plus sumcheck-zerocheck plus LogUp-GKR), so FRI does not apply to it and this skeleton does not verify SP1 6.1.0 proofs; retargeting 0x0AE8 to the SP1 Hypercube stack is a separate ~22 to 32 person-week effort. See AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md.
Rationale. A forward-dated, non-retroactive milestone plus a rolling binary upgrade (the same zero-liveness-risk posture proven for the base-fee floor and the in-place activation) means the address stays an empty account, and every consumer adapter fails closed, until the announced activation time. A migrated consumer can keep both the new 0x0AE8 path and the existing BN254 gateway required during a defense-in-depth window before dropping the classical path.
Alternatives rejected. Folding 0x0AE8 into the crossed futureEipsTime milestone (block 9,189,161): every historical block that called the currently-empty address would re-execute with different return data on the upgraded binary, a state divergence and a consensus split. Presenting the current artifact as a working verifier: it is not one.
Honest scope (critical). This is the record's load-bearing honesty statement. 0x0AE8 is not activated on any Aere network. As of this date it is a reference skeleton that fail-closes (returns EMPTY for every input): it is not a working verifier and must not be presented as one. Mainnet 2800 has exactly five PQC precompiles (0x0AE1 to 0x0AE5, block 9,189,161). The sibling ML-KEM-768 (0x0AE6) and Falcon HashToPoint (0x0AE7) precompiles are testnet-only. AerePQStarkVerifier.sol is a fail-closed adapter that denies every proof (safe by construction). Consensus is untouched by all of this; it remains classical ECDSA QBFT.
Prerequisite and gates. Activation cannot begin until the crypto core is ported from maintained references (Plonky3 FRI/Poseidon2/uni-stark, SP1 stark) or a pinned native wrap is built and reproducible; a real SP1 v6.1.0 inner-STARK vector corpus exists and the precompile accepts every valid vector and rejects every tampered or wrong-public-values vector, including cross-agreement with the live BN254 gateway; a soundcalc receipt for the exact pinned FriConfig is recorded (no 128-bit claim without the receipt); and a benchmark confirms a real verify fits under the EIP-7825 2^24 per-transaction gas cap. Beyond the prerequisite: a specialist external STARK/FRI audit of the consensus-critical crypto, a conformance gate green on the frozen artifact, an isolated N=7 soak across a simulated milestone crossing, and an explicit founder GO. Until all hold, 0x0AE8 stays a skeleton.
Status. Draft (blocked on the prerequisite crypto-core port). References: aerenew/docs/PQ-STARK-VERIFIER-PRECOMPILE-2026-07-18.md (design), aerenew/docs/PQ-STARK-VERIFIER-ACTIVATION-2026-07-18.md (gated activation plan), aerenew/contracts/contracts/zkverify/AerePQStarkVerifier.sol (fail-closed adapter).
4. Copyright
Released to the public domain (CC0). No rights reserved.