aere-research/aips

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

Numbers are permanent and are never reused, including for withdrawn proposals (AIP-1 section 2). Numbering is contiguous from 1 to 19 with no gaps. No AIP numbered 20 or higher exists in any Aere repository.

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.

Not live: AIP-8 (needs a hard fork), AIP-15 (isolated testnet only), AIP-16 (a skeleton that verifies nothing), AIP-19 (a process change under review).

Never claimed: post-quantum consensus. Aere consensus is classical secp256k1 ECDSA QBFT at N = 7. Post-quantum applies to signatures, accounts and applications only. The precompiles 0x0AE6 and 0x0AE7 are testnet-only.

Governance, stated plainly

Aere is not yet trustlessly governed. Seven validators, all Foundation-operated, one live client, 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.