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.