aere-network/aere-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
4739d4206b
aere-research/aips/README.md

10 KiB
Raw Blame History

Aere Improvement Proposals (AIPs)

An AIP is a design document describing a change to Aere Network (chain ID 2800), its contracts, its consensus parameters, or its processes. It records the motivation, the exact mechanism, the rationale, and, when the change is already live, the on-chain addresses and transactions that prove it exists.

AIPs exist so that a reader, human or machine, can reconstruct why the chain works the way it does from one canonical plain-text source instead of from marketing pages or from someone's memory.

Start here:

  • AIP-1 is the process: numbering, statuses and the transitions between them, supersession, and the rule that accepted proposals are not silently edited.
  • CONTRIBUTING.md is how someone who is not us proposes a change, and who actually decides.
  • aip-template.md is the required template.

Index

Status values are defined in AIP-1 section 3. A blank Superseded-By means the document is current.

AIP Title Type / Category Status Superseded by
1 AIP Purpose and Process Meta Living (rev 2, 2026-07-20)
2 Coinbase Fee-Burn Routing (37.5%) Standards Track / Core Final
3 Sub-Second Block Period (500 ms QBFT) Standards Track / Core Final
4 On-Chain Post-Quantum Signature Verification Suite Standards Track / Interface Final
5 sAERE Receipt Token and AereSink Immutable Flywheel Standards Track / ARC Final
6 ERC-4337 Passkey and Gasless Onboarding Stack Standards Track / ARC Final
7 AerePQC Hard-Fork Activation (PQC Precompiles and EIP-2935 Lookback) Standards Track / Core Final
8 Post-Quantum-Authorized Transaction Envelope (EIP-2718 Type 0x2A) Standards Track / Core Draft, not live
9 Consensus Mechanism: QBFT, not HotStuff Informational Final
10 Execution Client: Forked Besu with Nethermind Second, not Reth Informational Final
11 Interoperability: Hyperlane-Compatible plus zk Light Clients, not IBC Informational Final
12 The Virtual Machine: Extend the EVM, not a New VM Informational Final
13 Post-Quantum Signatures: Falcon and ML-DSA Together Informational Final
14 Account Abstraction: ERC-4337 with EIP-7702 Bridge, not Native AA Informational Final
15 In-Place Hybrid PQC Consensus Activation, not Re-Genesis Standards Track / Core Draft, testnet R&D only
16 PQ STARK-Verify Precompile (0x0AE8) Standards Track / Core Draft, skeleton, verifies nothing
17 One-Gwei EIP-1559 Base-Fee Floor Standards Track / Core Final
18 EIP-2935 on Chain 2800: Deviation from the Written Activation Schedule Standards Track / Core Final
19 AIP Process Hardening Meta Review, not ratified
20 Native Post-Quantum Transactions (Type 0x50, ML-DSA Authorization) Standards Track / Core Draft, not ratified; implemented in both clients and proven conformant on shared vectors (2026-09-17); live on testnet 28001 from block 2,212,000 (first type-0x50 transaction at 2,212,032, both clients); on chain 2800 the implementation runs on every node since 2026-09-22 and is armed, uniformly, for block 19,900,000 (per-node property, not a genesis change); no type-0x50 transaction on chain 2800 before that height
21 Verifiable Post-Quantum Finality per Block (Side Store, Proof RPC, Anchor as Permanent Record) Standards Track / Interface (non-consensus) Draft, not ratified; first half (retention window + aere_getPqFinality) implemented in the Besu-derived client with 7 tests and deployed on testnet 28001 (5 nodes, public door testnet-rpc.aere.network/finality) on 2026-09-18; Nethermind port the same day (10 tests) and deployed on the testnet Nethermind validator with its own public door; two-client conformance proven live (aip21-conformitate/DOVEDESTE.sh, CONFORM on block 2,250,809); second half (the window on disk, same journal format in both clients) deployed on all six testnet nodes the same day: the window survives a restart in both (1,284 and 1,255 seals re-verified, 0 failed), and a round-1 block is post-quantum in both on the same hash (CONFORM 08:49Z, block 2,285,481 and round-1 block 2,285,333); on chain 2800 since 2026-09-22 on all ten validators and both clients (aere_getPqFinality answers post-quantum with 10 of 10 seals re-verified; dated record at the end of AIP-21)
22 Post-Quantum-Only Finality (Chained Quorum Certificates, PQ Validator Identity, ECDSA Demoted to Compatibility) Standards Track / Core Draft, not ratified; a design only on 2026-09-23; stages 1 to 6 then proven on testnet 28001 in both clients (2026-09-23 to 2026-09-25, stage records in the AIP); conformance corpus of all nine kinds published 2026-09-27 (aip22-conformance/); on chain 2800 stages 1 to 3 active from blocks 20,715,632, 20,746,736 and 20,836,228 (2026-09-29 and 2026-09-30), stages 4 and 5 not armed (their activation heights are the founder's)
23 AERE Proof Protocol (Portable Verifiable-Statement Envelope with Optional Post-Quantum On-Chain Finality) Standards Track / Interface Draft, not ratified (2026-09-26); reference verifier and conformance vectors published 2026-09-27; finality proven end to end on testnet 28001

Numbers are permanent and are never reused, including for withdrawn proposals (AIP-1 section 2). Numbering is contiguous from 1 to 23 with no gaps (corrected 2026-10-01: until then this sentence still said 22, and that no AIP numbered 23 or higher existed).

Which of these are live on chain 2800

Read this before citing anything here as a network capability.

Live: AIP-2 (burn routing; see its outcome record for the measured amount), AIP-3 (500 ms target, 516.4 ms measured), AIP-4, AIP-5, AIP-6, AIP-7 (precompiles 0x0AE1..0x0AE5 from block 9,189,161), AIP-17 (base-fee floor from block 10,141,734), AIP-18 (EIP-2935 from block 9,189,161). AIP-9 through AIP-14 describe the decisions behind the live system.

Post-quantum layers live on top of QBFT (see SPEC.md of the public node package for the exact rules and heights): the anchor certificate under the block hash (every 32nd block from 13,014,000, every 128th from 17,225,968 to 20,746,736, every 32nd again since, with SLH-DSA every 128th; hybrid Falcon-512 + SLH-DSA since 17,047,600; at least seven valid seals per scheme of the ten validators, as many as the quorum, since 20,715,632 (the seals prove those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01), six from 14,961,456), post-quantum validator ids in consensus since 20,836,228 (AIP-22 stages 1 to 3, 2026-09-29 and 2026-09-30), and the per-message Falcon-512 enforcement on every QBFT message (heights 17,250,000 to 17,700,000, September 2026). AIP-21's record is live on chain 2800 since 2026-09-22; AIP-20 is deployed and armed for 19,900,000.

Not live: AIP-8 (needs a hard fork), AIP-15 as written (its testnet R&D form; what is live is the dated list above), AIP-16 (a skeleton that verifies nothing), AIP-19 (a process change under review), AIP-22 (design only).

Not claimed: consensus whose safety does not depend on ECDSA. Aere consensus is QBFT in which classical secp256k1 ECDSA is still a validity criterion on every block and every message, with the post-quantum layers above added to it (hybrid, never "post-quantum only"); AIP-22 is the design for removing that dependence and nothing in it is implemented. The precompiles 0x0AE6 and 0x0AE7 are testnet-only.

Governance, stated plainly

Aere is not yet trustlessly governed. Ten validators (since 2026-09-11), all Foundation-operated, two client implementations (one of each since 2026-09-11) but one operator, no external security audit, thin real usage. In that reality an AIP is not ratified by a vote of independent stakeholders. The founder decides, acting through the Foundation account 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3, which is a single-key account and not a deployed multisig. Every proposal that predates decentralization carries the label "Foundation-ratified (pre-decentralization)" so nobody mistakes editorial ratification for governance. See CONTRIBUTING.md for what that means if you are not us, and AIP-1 section 8 for the migration path.

Filing an AIP

See AIP-1 section 6 and CONTRIBUTING.md. In short: copy the template, keep every section header, cite addresses verbatim from sdk-js/src/addresses.ts, label every number measured, spec or estimate, write "to be measured" rather than guessing, and add a row to this index.

Conventions

  • Files are named AIP-N.md. One AIP per change. If a change has a Core part and an application part, either file two AIPs or state clearly which layer each section addresses.
  • Addresses, transaction hashes, gas figures, and block numbers must be reproducible from the chain or from a repo fixture. Design ceilings (for example a theoretical maximum throughput) are never presented as measured results.
  • A Final AIP is not edited. Corrections go in its Errata section and outcomes go in its Post-Acceptance Outcome Record, both dated and appended (AIP-1 section 5).

Other locations, and one stale copy

  • aere-research-repo/aips/ holds an older AIP-1 through AIP-6 whose governance note says "three validators" and calls the Foundation account a multisig. Both statements are false today. This directory is authoritative wherever the two disagree.
  • the Aere working tree holds drafts (not published in this package) of open, externally-submittable Ethereum standards (targeting ethereum/EIPs, ethereum/ERCs, or the RIP process). Those are not AIPs and carry no AIP number: an AIP records why chain 2800 works the way it does with its live addresses, while an open EIP draft is the chain-agnostic version a third party could implement.
  • aere-docs/AERE-AIP-PROCESS-AND-INDEX.md is the published narrative version of this index.

Copyright

All AIPs are released to the public domain (CC0). No rights reserved.