# AERE Improvement Proposals (AIPs) An AIP (AERE Improvement Proposal) is a design document that describes 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 any 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. This directory is a local, self-contained scaffold. It is not published anywhere and is not wired into any build or deployment. It is intended to be the seed of a public AIP repository once the process is stable. ## What belongs in an AIP - A protocol or consensus change (block time, fee routing, precompiles). - A new contract standard or interface that other builders are expected to integrate against. - A token-standard or account-standard convention (ARC). - A process or governance change (Meta). Things that do not belong in an AIP: bug-fix redeploys that preserve an existing interface (those are tracked in `sdk-js/src/addresses.ts` deprecation notes), routine parameter tuning inside an already-ratified bound, and pure documentation. ## Lifecycle An AIP moves through a small number of statuses. The happy path is `Draft -> Review -> Last Call -> Final`. Standards that are never "done" (for example a registry that keeps growing) settle in `Living` instead of `Final`. | Status | Meaning | | --- | --- | | Draft | The proposal is written and formatted correctly and has an author. It may still change substantially. | | Review | The author has marked it ready for wider scrutiny. Open questions are being resolved. | | Last Call | Final review window. A fixed review period is stated. If no blocking issue is raised, it advances. | | Final | Accepted and, for already-shipped work, live on chain 2800. The mechanism is now stable and should not change in a breaking way. | | Living | Accepted and expected to keep being updated (for example an index or a registry-style standard). | | Withdrawn | The author or the editors abandoned the proposal. Terminal. | | Stagnant | Inactive in Draft or Review for an extended period. Can be revived. | Retro-filed AIPs (documents written after the change already shipped) enter directly at `Final` or `Living` and carry a note that they are backfilling history. AIP-2 through AIP-7 in this scaffold are retro-filed. ## Categories and types Every Standards Track AIP names one category: - **Core**: consensus, block production, fee/burn accounting, precompiles, and anything that changes how the chain itself behaves. Requires a client or genesis/config change. - **Networking**: peer-to-peer protocol, sync, and node-to-node messaging. - **Interface**: contract-level interfaces, ABIs, RPC conventions, and verification surfaces that builders integrate against. - **ARC (token standards)**: AERE Request for Comment. Application and token standards, for example ERC-20/4626 receipt tokens and ERC-4337 account conventions, as adopted on AERE. - **Meta**: process, governance, and the AIP process itself. Types: Standards Track (Core, Networking, Interface, ARC), Meta, and Informational. Informational AIPs give guidance and do not mandate anything. ## Honest governance note (read this) AERE is not yet trustlessly governed. Today the network runs seven validators under a single operator, one client (Hyperledger Besu QBFT), 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 AERE Foundation account (`0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`, a single-key Foundation-controlled account, not a deployed multisig) 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. As the validator set opens up and a second client and independent stakers come online, the process is expected to migrate to stake-weighted or validator-weighted ratification. That migration will itself be a Meta AIP. Until then, the honest description of AERE governance is: a Foundation publishes proposals, ships them, and records them here for public audit. ## How to file an AIP 1. Copy `aip-template.md` to `AIP-N.md`, where N is the next free integer. 2. Fill in every required section. Do not delete a section header; if a section does not apply, write "None" under it. 3. Cite on-chain addresses verbatim from `sdk-js/src/addresses.ts`. Never invent an address, a transaction hash, or a gas number. If a number has not been measured, write "to be measured" rather than guessing. 4. Add a row to the index below. 5. Open it for editorial review. Until decentralization, the editor is the Foundation. ## Index | AIP | Title | Type / Category | Status | Note | | --- | --- | --- | --- | --- | | [1](./AIP-1.md) | AIP Purpose and Process | Meta | Living | The process itself | | [2](./AIP-2.md) | Coinbase Fee-Burn Routing (37.5%) | Standards Track / Core | Final | Foundation-ratified (pre-decentralization) | | [3](./AIP-3.md) | Sub-Second Block Period (500 ms QBFT) | Standards Track / Core | Final | Foundation-ratified (pre-decentralization) | | [4](./AIP-4.md) | On-Chain Post-Quantum Signature Verification Suite | Standards Track / Interface | Final | Foundation-ratified (pre-decentralization) | | [5](./AIP-5.md) | sAERE Receipt Token and AereSink Immutable Flywheel | Standards Track / ARC | Final | Foundation-ratified (pre-decentralization) | | [6](./AIP-6.md) | ERC-4337 Passkey and Gasless Onboarding Stack | Standards Track / ARC | Final | Foundation-ratified (pre-decentralization) | | [7](./AIP-7.md) | AerePQC Hard-Fork Activation (Native PQC Precompiles and Extended EIP-2935 Lookback) | Standards Track / Core | Final | Foundation-ratified (pre-decentralization) | ## 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. Marketing numbers (for example a design-ceiling throughput) are never presented as measured results.