aere-research/aips

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 Purpose and Process	Meta	Living	The process itself
2	Coinbase Fee-Burn Routing (37.5%)	Standards Track / Core	Final	Foundation-ratified (pre-decentralization)
3	Sub-Second Block Period (500 ms QBFT)	Standards Track / Core	Final	Foundation-ratified (pre-decentralization)
4	On-Chain Post-Quantum Signature Verification Suite	Standards Track / Interface	Final	Foundation-ratified (pre-decentralization)
5	sAERE Receipt Token and AereSink Immutable Flywheel	Standards Track / ARC	Final	Foundation-ratified (pre-decentralization)
6	ERC-4337 Passkey and Gasless Onboarding Stack	Standards Track / ARC	Final	Foundation-ratified (pre-decentralization)
7	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.