4a0b48588c
Aere Network public source. Everything here can be checked against the live chain (chain id 2800, https://rpc.aere.network). Scope note, stated up front rather than buried: consensus on chain 2800 is classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at the signature, precompile, account and transport layers. Nothing here makes the consensus post-quantum, and no document in it should be read as claiming so.
163 lines
6.8 KiB
Markdown
163 lines
6.8 KiB
Markdown
# 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.
|
|
</content>
|