# AIP-1: AIP Purpose and Process ## Preamble | Field | Value | | --- | --- | | AIP | 1 | | Title | AIP Purpose and Process | | Author | AERE Foundation | | Type | Meta | | Category | (none) | | Status | Living | | Created | 2026-07-11 | | Requires | None | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract This AIP defines the AERE Improvement Proposal process: what an AIP is, the statuses it moves through, the categories it can carry, the required sections, and who ratifies it. It is a Living document because the process will change as the network decentralizes. ## Motivation AERE ships changes to a live chain (chain ID 2800) and to a growing set of contracts. Without a single canonical record of why each change was made, that history lives only in commit messages, in the SDK address registry, and in the memory of the people who shipped it. An AIP process fixes that. It gives every change a stable, plain-text home that states the motivation, the exact mechanism, the on-chain proof, and the honest limitations. It lets an outside auditor, integrator, or automated agent reconstruct the design of the chain without asking anyone. It also forces discipline. Writing the Specification and Security Considerations sections before (or, for retro-filed AIPs, immediately after) shipping surfaces weak assumptions early. ## Specification ### Roles - **Author.** Anyone may author an AIP. The author writes the document, drives it through the statuses, and answers review questions. - **Editor.** The editor checks that an AIP is well-formed, correctly numbered, correctly 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 role is held by the AERE 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). See the governance note below. ### Statuses The normative lifecycle is `Draft -> Review -> Last Call -> Final`. `Living` replaces `Final` for standards that keep evolving. `Withdrawn` and `Stagnant` are the off-ramps. - **Draft.** Well-formed, has an author, may 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 to Final or Living. - **Final.** Accepted. For shipped work, live on chain 2800. Breaking changes after Final require a new AIP that supersedes this one. - **Living.** Accepted and expected to keep being updated. - **Withdrawn.** Abandoned. Terminal, but the number is retired, not reused. - **Stagnant.** Inactive in Draft or Review beyond 6 months. Revivable by any author. Retro-filed AIPs enter at Final or Living and state in their Abstract that they document a change that already shipped. ### Categories and types Types are Standards Track, Meta, and Informational. A Standards Track AIP MUST name 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 (for example ERC-20, ERC-4626, ERC-4337, ERC-6551 conventions as adopted on AERE). - **Meta** and **Informational** carry no category. ### Numbering and format - AIPs are numbered by monotonically increasing integer. AIP-1 is this document. - Each AIP is a single Markdown file named `AIP-N.md`. - Each AIP MUST contain the sections in `aip-template.md`: Preamble, Abstract, Motivation, Specification, Rationale, Backwards Compatibility, Security Considerations, Reference Implementation and On-Chain Deployment, Copyright. A section that does not apply is kept with the body "None". ### Sourcing rules (binding on all AIPs) - Every on-chain address MUST be copied verbatim from `sdk-js/src/addresses.ts`, the canonical registry. No address may be guessed. If unsure, omit it. - Every gas figure, transaction hash, and block number MUST be reproducible from the chain or from a repo fixture. Unmeasured quantities MUST be written as "to be measured", never invented. - Design ceilings (for example a theoretical maximum throughput) MUST NOT be presented as measured throughput. ### Ratification and the decentralization path Today, ratification is editorial: the Foundation approves an AIP and, for a Standards Track change, ships it. This is honest and is labeled as such on every pre-decentralization AIP. It is not stakeholder governance and does not pretend to be. 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 implementation. 2. Introduce a public review period with standing that 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 **"Foundation-ratified (pre-decentralization)"**. ## Rationale The process is deliberately close to Ethereum's EIP/ERC model because AERE is EVM-equivalent (Pectra plus Fusaka) and builders already know that model. Copying its status names and section structure lowers the cost of contributing. The one deviation worth calling out is the explicit, up-front honesty about governance. Rather than dress editorial ratification up as decentralized governance, AIP-1 names the current reality and the path off it. Credibility with technical readers comes from stating limitations plainly, not from hiding them. ## Backwards Compatibility None. This is the first process document. ## Security Considerations The chief risk in a pre-decentralization process is that a single party can both author and ratify, so an AIP can be waved through without genuine review. This is mitigated only partially today, by the editor's sourcing rules (every address and number must be real and reproducible) and by keeping the honesty label on every proposal. It is not fully mitigated until independent ratifiers exist. This weakness is stated rather than hidden, which is itself part of the mitigation. ## Reference Implementation and On-Chain Deployment Not applicable. This AIP is the process. The scaffold lives at `aerenew/aips/` and consists of this file, `README.md`, `aip-template.md`, and the retro-filed AIPs AIP-2 through AIP-7. ## Copyright Released to the public domain (CC0). No rights reserved.