aere-research/aips/AIP-1.md

AIP-1: AIP Purpose and Process

Preamble

Field	Value
AIP	1
Title	AIP Purpose and Process
Author	Aere Network Foundation
Type	Meta
Category	(none)
Status	Living
Created	2026-07-11
Last substantive revision	2026-07-20 (revision 2, recorded in AIP-19)
Requires	None
Superseded-By	None
Ratification	Foundation-ratified (pre-decentralization)

Abstract

This AIP defines the Aere Improvement Proposal process: what an AIP is, the statuses it moves through and the transitions permitted between them, how numbers are assigned and retired, how a later proposal supersedes an earlier one, the required document template, and the rule that an accepted proposal is not silently edited. 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.

There is a second motivation, established by looking at what actually survives in this industry. Formal specifications tend to die: Polkadot funded a dedicated specification with a committee and marked it unmaintained on 2 October 2024; the Ethereum Yellow Paper states on its face that it stops at Shanghai (April 2023); Bitcoin never produced one at all. In each case the numbered proposal process is what absorbed the work and kept running. A proposal series survives because each document is small, dated, owned by one author, and finished, so it never needs a maintainer to keep it true. A monolithic specification needs a maintainer forever and eventually does not get one.

Aere therefore puts its documentation weight on this numbered series rather than on a single living specification document.

Specification

1. What an AIP is

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.

In scope: a protocol or consensus change (block time, fee routing, precompiles); a new contract standard or interface others integrate against; a token or account standard convention (ARC); a process or governance change (Meta).

Out of scope: bug-fix redeploys that preserve an existing interface (tracked in the SDK address registry's deprecation notes), routine parameter tuning inside an already-ratified bound, and pure documentation.

2. Numbering (MUST)

• Numbers are assigned sequentially from 1 by the editor, as integers, with no gaps and no sub-numbers.
• A number is never reused. Once assigned it belongs to that proposal permanently, including if the proposal is Withdrawn, Stagnant, or superseded. A withdrawn AIP-N stays AIP-N and its file stays in the repository.
• A number is assigned when the document is first accepted as well-formed by the editor (that is, at entry to Draft), not when it is ratified. Assigning at ratification would leave dangling references in review discussion.
• References to an AIP are by number, not by title or path. Titles may be corrected; numbers may not.

Precedent: IETF RFCs (RFC 2026), where a published number is permanent and is never recycled even after the document is obsoleted; and PEP 1 and EIP-1, which both assign a number at entry rather than at acceptance.

3. Status values and permitted transitions (MUST)

Status	Meaning
Draft	Well-formed, has a named author, may still change substantially.
Review	The author has requested wider scrutiny. Open questions are tracked inside the document.
Last Call	A stated final-review window, default 14 days, with an end date written into the document.
Final	Accepted. For shipped work, live on chain 2800. Immutable under section 5.
Living	Accepted and expected to keep being updated (a process document, an index, a registry).
Withdrawn	Abandoned by the author or the editor. Terminal.
Stagnant	Inactive in Draft or Review beyond six months. Revivable.

Permitted transitions, and no others:

From	May move to	Who moves it
(new)	Draft	Editor, on a well-formedness check
Draft	Review, Withdrawn, Stagnant	Author (Review, Withdrawn); editor (Stagnant)
Review	Last Call, Draft, Withdrawn, Stagnant	Author (all but Stagnant); editor (Stagnant)
Last Call	Final, Living, Review, Withdrawn	Ratifier (Final, Living); author or editor (back to Review on a blocking issue)
Final	(none)	Nobody. Change requires a new AIP that supersedes it.
Living	Living (revised), Final, Withdrawn	Editor, with a Change Log entry
Stagnant	Draft	Any author reviving it
Withdrawn	(none)	Terminal

A transition that is not in this table is invalid. In particular there is no path out of Final: a Final AIP is changed only by being superseded.

Retro-filing. A document written after the change already shipped enters directly at Final or Living, skipping Draft, Review and Last Call, and MUST say in its Abstract that it backfills history. This is the one sanctioned bypass and it exists because pretending a shipped change went through review would be a lie. Retro-filed AIPs carry the same immutability rule from the moment they are filed.

Precedent: PEP 1, which publishes an explicit state diagram rather than a list of adjectives, so that "what may happen next" is answerable without a judgment call; and EIP-1's Draft / Review / Last Call / Final / Living / Withdrawn / Stagnant vocabulary, adopted here rather than invented.

4. Supersession (MUST)

Two headers express the relationship, and both sides MUST be written:

• Supersedes: N on the new document.
• Superseded-By: M on the old document.

Adding a Superseded-By header to a Final AIP is the only edit permitted to that document (section 5), and it is a pure addition: no existing text is changed, so a reader who has the old bytes and the new bytes sees exactly one added line.

The reading rule this creates: a reader who lands on any AIP can reach the current text by following Superseded-By until there is none. That is the whole point of the mechanism. A superseded AIP is not deleted, not hidden, and not rewritten, because its historical claim ("this is what we did and why, on this date") stays true forever even after the decision changes.

Partial supersession is expressed by naming the sections: Supersedes: 3 (Section 4 only). If a new AIP replaces a decision but not the mechanism, it says so in its Abstract.

Precedent: the IETF Obsoletes and Obsoleted by header pair (RFC 2026, RFC 7322), which is the reason a thirty-year-old RFC still resolves to current practice; and PEP 1's Replaces and Superseded-By fields.

5. Post-acceptance immutability (MUST)

Once an AIP is Final, its normative content is frozen. Specifically:

1. No silent edits. The Abstract, Motivation, Specification, Rationale, Backwards Compatibility and Security Considerations sections of a Final AIP MUST NOT be modified.
2. Permitted edits, exhaustively: adding a Superseded-By header; adding an entry to the document's own Errata section; adding a Post-Acceptance Outcome Record section; and typographical corrections that cannot change meaning (spelling, broken link targets, table formatting).
3. Errata correct a factual error in a Final AIP. An erratum is appended, is dated, states what was wrong and what is correct, and never edits the wrong text away. A reader must be able to see both what was published and what was corrected.
4. A Post-Acceptance Outcome Record reports what actually happened after the change shipped, including when the outcome contradicts the expectation stated in the original text. It is appended and dated. It never edits the original claim.
5. If a change is large enough that errata would distort the document, file a new AIP that supersedes it instead.
6. A Living AIP is exempt from (1) but MUST carry a Change Log section, and every substantive revision MUST cite the AIP that authorized it.

Precedent: the RFC Editor model, where a published RFC is immutable and corrections are published as separate errata against it rather than as edits to it, so a citation to a document is a citation to fixed bytes; and Michael Nygard's Architecture Decision Records, in which an accepted record is never rewritten and a changed decision is a new record that supersedes it.

6. Required template (MUST)

Every AIP uses aip-template.md. Every section header is present. A section that does not apply keeps its header with the body "None". The required sections are Preamble, Abstract, Motivation, Specification, Rationale, Backwards Compatibility, Security Considerations, Reference Implementation and On-Chain Deployment, and Copyright.

A fixed section list is not bureaucracy; it is what makes an omission visible. "Security Considerations: None" is a claim someone can challenge. A missing Security Considerations section is a claim nobody notices.

Precedent: EIP-1's required-section list, and RFC 3552, which made a Security Considerations section mandatory in every RFC precisely so that its absence could not pass unremarked.

7. Types and categories

Types are Standards Track, Meta, and Informational. Informational AIPs give guidance and mandate nothing. A Standards Track AIP names 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.

Meta and Informational carry no category.

8. Roles

• Author. Anyone. Writes the document, drives it through the statuses, answers review questions.
• Editor. Checks that a proposal is well-formed, correctly numbered and categorized, technically coherent, and that every cited address, transaction, and number is real. The editor explicitly does not judge whether a proposal is a good idea. Today the editor is the Foundation.
• Ratifier. The party whose approval moves a proposal to Final. Today this is the founder, acting through the Foundation account 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3, a single-key Foundation-controlled account and not a deployed multisig. See CONTRIBUTING.md for the honest description of what that means for an outside contributor.

Precedent: the RFC Editor / IESG split, and EIP-1's separation of editors from approval, both of which exist so that the person checking whether a document is correctly formed is not the same person deciding whether the idea wins.

9. Sourcing rules (binding on every AIP)

• Every on-chain address is copied verbatim from the canonical SDK registry (sdk-js/src/addresses.ts). No address is guessed. If unsure, omit it.
• Every gas figure, transaction hash, and block number is reproducible from the chain or a repo fixture. Unmeasured quantities are written "to be measured", never invented.
• Every number carries its provenance: measured, spec, or estimate.
• Design ceilings (a theoretical maximum throughput) are never presented as measured throughput.
• Aere consensus is classical secp256k1 ECDSA QBFT. No AIP claims or implies post-quantum consensus. Post-quantum applies to signatures, accounts and applications only.

10. Where AIPs live

aere-research/aips/ is canonical: README.md (the index), CONTRIBUTING.md (the contribution path), aip-template.md, and AIP-N.md for every N.

A stale duplicate of AIP-1 through AIP-6 exists at aere-research-repo/aips/ with an older governance note that says "three validators" and calls the Foundation account a multisig. Both statements are false today. That copy is superseded by this directory wherever the two disagree.

Rationale

The mechanisms above are borrowed, not designed. Every one of them has been load tested for decades by IETF, Python, or Ethereum, and the failure each one prevents is a failure those bodies actually hit. Inventing a new process for a chain with one operator and no external contributors would be inventing a solution to a problem we have not yet had, while missing the problems that are already known.

The single most important borrowed mechanism is section 5, immutability after acceptance. A process where accepted documents can be quietly edited produces records that cannot be cited, because the thing you cited may not be the thing that is there now. That failure is invisible until the moment it matters, which is typically an audit or a dispute.

Backwards Compatibility

AIP-2 through AIP-16 were filed before this revision. They remain valid. Where one of them lacks a Superseded-By header, its absence means "not superseded", which is the correct reading. Sections 2 through 6 bind every AIP filed from 2026-07-20 onward and are applied to earlier AIPs on their next touch.

Security Considerations

The governance weakness is stated rather than hidden: today a single party can both author and ratify an AIP. The editor's sourcing rules and the immutability rule reduce the damage that state can do (a false claim is at least dated, attributed, and hard to erase) but they do not remove it. Only independent ratifiers do that, and Aere does not have them yet. Every pre-decentralization AIP carries the label "Foundation-ratified (pre-decentralization)" so that no reader mistakes editorial ratification for trustless governance.

The intended migration, each step its own Meta AIP: (1) open the validator set beyond the current seven Foundation-operated validators and run a second client as a live producer; (2) introduce a public review period the Foundation cannot unilaterally shorten; (3) move ratification to stake-weighted or validator-weighted approval once an independent staker and validator base exists.

Reference Implementation and On-Chain Deployment

None. This is a process document.

Change Log

Revision	Date	Change	Authorized by
1	2026-07-11	Initial process definition: statuses, categories, roles, sourcing rules.	Foundation
2	2026-07-20	Added numbering permanence (section 2), the transition table (section 3), supersession headers (section 4), post-acceptance immutability with errata and outcome records (section 5), provenance labels, and named precedent for each mechanism.	AIP-19 (Review)

Copyright

Released to the public domain (CC0). No rights reserved.