126 lines
6.8 KiB
Markdown
126 lines
6.8 KiB
Markdown
# AIP-19: AIP Process Hardening: Numbering, Status Transitions, Supersession, and Post-Acceptance Immutability
|
|
|
|
## Preamble
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| AIP | 19 |
|
|
| Title | AIP Process Hardening: Numbering, Status Transitions, Supersession, and Post-Acceptance Immutability |
|
|
| Author | Aere Network Foundation |
|
|
| Type | Meta |
|
|
| Category | (none) |
|
|
| Status | Review |
|
|
| Created | 2026-07-20 |
|
|
| Last Call opens | on ratifier acknowledgement |
|
|
| Requires | 1 |
|
|
| Supersedes | None (amends AIP-1, which is Living) |
|
|
| Superseded-By | None |
|
|
| Ratification | **Not yet ratified.** Ratifier is the founder. |
|
|
|
|
## Abstract
|
|
|
|
This AIP records the 2026-07-20 hardening of the Aere Improvement Proposal
|
|
process: permanent non-reusable numbering, an explicit table of permitted status
|
|
transitions, paired `Supersedes` / `Superseded-By` headers, a mandatory template,
|
|
and a rule that a Final AIP is never silently edited (errata and outcome records
|
|
are appended instead). Each mechanism is adopted from an existing standards body
|
|
rather than invented. The amendments are written into AIP-1, which is Living.
|
|
This AIP is the record of why, and is itself in **Review**, not Final.
|
|
|
|
## Motivation
|
|
|
|
Before this change, Aere had a document describing a process rather than a
|
|
process. The evidence for that statement, gathered 2026-07-20:
|
|
|
|
1. **Nothing had moved through the lifecycle.** All eight AIPs that existed
|
|
entered directly at Final, Living, or Draft. Not one had ever occupied Review
|
|
or Last Call. Seven of them were written on two days (2026-07-11 and
|
|
2026-07-16). A lifecycle no document has traversed is a diagram, not a
|
|
process.
|
|
2. **The index referenced files that did not exist.** AIP-9 through AIP-16 were
|
|
published in a numbered index while existing only as sections inside a single
|
|
prose document, `AERE-AIP-PROCESS-AND-INDEX.md`. A number that does not
|
|
resolve to a document is not a record.
|
|
3. **AIP-8 was outside the index**, living at
|
|
`aerenew/docs/AIP-PQ-TX-2026-07-18.md` under a non-conforming filename.
|
|
4. **Two mechanisms that the process depends on did not exist at all:**
|
|
supersession headers and a rule against editing accepted documents. Without
|
|
the first, a reader landing on an old AIP has no way to find the current one.
|
|
Without the second, a citation to an AIP is a citation to whatever the file
|
|
happens to contain today.
|
|
5. **Real decisions had no number.** The 1 Gwei base-fee floor at block
|
|
10,141,734, live since 2026-07-17, appeared in four documents and no AIP. The
|
|
EIP-2935 activation deviation was recorded only in a compatibility matrix.
|
|
|
|
The underlying finding is the one that motivated putting effort here at all:
|
|
formal specifications tend to die (Polkadot's was marked unmaintained on
|
|
2 October 2024; the Ethereum Yellow Paper stops at Shanghai, April 2023; Bitcoin
|
|
never produced one), while numbered proposal processes survive. A process is only
|
|
worth that bet if it has the mechanisms that made the surviving ones survive.
|
|
|
|
## Specification
|
|
|
|
The normative text is AIP-1 revision 2, sections 2 through 6. Summary of what was
|
|
added, with the precedent each mechanism is taken from:
|
|
|
|
| Mechanism | Precedent | Failure it prevents |
|
|
| --- | --- | --- |
|
|
| Numbers assigned at Draft entry, never reused, retained through Withdrawn | IETF RFC 2026; PEP 1; EIP-1 | A citation resolving to a different document than the one cited |
|
|
| Explicit table of permitted status transitions, including that Final has no outbound transition | PEP 1's state diagram; EIP-1's status set | Status becoming an adjective applied by judgment rather than a state with rules |
|
|
| Paired `Supersedes` / `Superseded-By` headers | IETF `Obsoletes` / `Obsoleted by` (RFC 2026, RFC 7322); PEP 1 `Replaces` / `Superseded-By` | A reader landing on outdated text with no path to the current text |
|
|
| Mandatory template with no removable sections | EIP-1 required sections; RFC 3552 mandating Security Considerations | An omission being invisible, since "None" is challengeable and an absent section is not |
|
|
| Post-acceptance immutability, with errata and outcome records appended and dated | RFC Editor immutability plus separate errata; Nygard Architecture Decision Records | Silent revision of accepted decisions, which makes the whole archive uncitable |
|
|
|
|
Alongside the process change, this AIP records the housekeeping that made the
|
|
index true: AIP-8 moved into `aere-research/aips/`; AIP-9 through AIP-16 materialized as
|
|
individual files; AIP-17 (base-fee floor) and AIP-18 (EIP-2935 deviation) filed as
|
|
new retro-filed records; and `CONTRIBUTING.md` added as the outsider path.
|
|
|
|
## Rationale
|
|
|
|
Everything here is borrowed. Aere has one operator, no external contributors, and
|
|
a young archive, so it has not yet encountered the failures these mechanisms
|
|
prevent. That is precisely the argument for adopting them now: the cost of adding
|
|
a `Superseded-By` header to a nineteen-document archive is trivial, and the cost
|
|
of adding it to a two-hundred-document archive that has been edited in place for
|
|
three years is that you cannot, because the history needed to do it correctly is
|
|
gone.
|
|
|
|
**Alternatives rejected.** Designing an Aere-specific process: it would be a
|
|
solution to problems we have not had, while missing the ones already known.
|
|
Deferring until external contributors exist: the mechanisms are cheap now and
|
|
expensive later, and the archive being built today is the one that would need
|
|
retrofitting.
|
|
|
|
## Backwards Compatibility
|
|
|
|
AIP-2 through AIP-16 remain valid and are not rewritten. Missing `Superseded-By`
|
|
headers on older AIPs read correctly as "not superseded". Sections 2 through 6 of
|
|
AIP-1 bind every AIP filed from 2026-07-20 onward and are applied to earlier AIPs
|
|
on their next touch. Post-Acceptance Outcome Records appended to AIP-2, AIP-3 and
|
|
AIP-7 on 2026-07-20 are additions under the new rule and change no existing
|
|
sentence in those documents.
|
|
|
|
## Security Considerations
|
|
|
|
This AIP does not change the fundamental governance weakness: a single party can
|
|
still both author and ratify. Immutability and sourcing rules limit the damage
|
|
that state can do (a false claim becomes dated, attributed, and hard to erase
|
|
quietly) but they do not remove it. Only independent ratifiers do that.
|
|
|
|
There is a specific new risk worth naming: an immutability rule that is not
|
|
enforced by tooling is enforced by discipline, and discipline is not a control. A
|
|
repository-level check that a Final AIP's normative sections have not changed
|
|
between commits would make the rule real. That check does not exist yet and is
|
|
listed here as an open item rather than claimed as shipped.
|
|
|
|
## Reference Implementation and On-Chain Deployment
|
|
|
|
None. This is a process document. Artifacts: `aere-research/aips/AIP-1.md` (revision 2),
|
|
`aere-research/aips/aip-template.md`, `aere-research/aips/README.md`,
|
|
`aere-research/aips/CONTRIBUTING.md`.
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|