AIP-1, AIP-2, AIP-7, the template and the index brought to the working generation: the published governance text was missing entire sections, including the rules themselves (D-377)

2026-09-11 22:04:15 +03:00 · 2026-09-11 22:04:15 +03:00 · 83453d9a79
commit 83453d9a79
parent 16ce7e8989
5 changed files with 461 additions and 233 deletions
--- a/aips/AIP-1.md
+++ b/aips/AIP-1.md
@ -6,157 +6,298 @@
 | --- | --- |
 | AIP | 1 |
 | Title | AIP Purpose and Process |
-| Author | AERE Foundation |
+| 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
+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,
+statuses it moves through and the transitions permitted between them, how numbers
-and who ratifies it. It is a Living document because the process will change as
+are assigned and retired, how a later proposal supersedes an earlier one, the
-the network decentralizes.
+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
+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
+memory of the people who shipped it.
 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
+There is a second motivation, established by looking at what actually survives in
-sections before (or, for retro-filed AIPs, immediately after) shipping surfaces
+this industry. Formal specifications tend to die: Polkadot funded a dedicated
-weak assumptions early.
+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
-### Roles
+### 1. What an AIP is
- **Author.** Anyone may author an AIP. The author writes the document, drives it
+An AIP is a design document describing a change to Aere Network (chain ID 2800),
-  through the statuses, and answers review questions.
+its contracts, its consensus parameters, or its processes. It records the
- **Editor.** The editor checks that an AIP is well-formed, correctly numbered,
+motivation, the exact mechanism, the rationale, and, when the change is already
-  correctly categorized, and technically coherent, and that every cited address,
+live, the on-chain addresses and transactions that prove it exists.
  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
+**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).
-The normative lifecycle is `Draft -> Review -> Last Call -> Final`. `Living`
+**Out of scope:** bug-fix redeploys that preserve an existing interface (tracked
-replaces `Final` for standards that keep evolving. `Withdrawn` and `Stagnant` are
+in the SDK address registry's deprecation notes), routine parameter tuning inside
-the off-ramps.
+an already-ratified bound, and pure documentation.
- **Draft.** Well-formed, has an author, may change substantially.
+### 2. Numbering (MUST)
 - **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
+- Numbers are assigned sequentially from 1 by the editor, as integers, with no
-document a change that already shipped.
+  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.
-### Categories and types
+*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.*
-Types are Standards Track, Meta, and Informational. A Standards Track AIP MUST
+### 3. Status values and permitted transitions (MUST)
 name exactly one category:
- **Core**: consensus, block production, fee and burn accounting, precompiles,
+| 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.
+- **Networking:** peer-to-peer protocol and sync.
- **Interface**: contract interfaces, ABIs, RPC conventions, verification
+- **Interface:** contract interfaces, ABIs, RPC conventions, verification
  surfaces.
- **ARC** (AERE Request for Comment): application and token standards (for
+- **ARC** (Aere Request for Comment): application and token standards.
  example ERC-20, ERC-4626, ERC-4337, ERC-6551 conventions as adopted on AERE).
 - **Meta** and **Informational** carry no category.
-### Numbering and format
+Meta and Informational carry no category.
- AIPs are numbered by monotonically increasing integer. AIP-1 is this document.
+### 8. Roles
 - 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)
+- **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.
- Every on-chain address MUST be copied verbatim from `sdk-js/src/addresses.ts`,
+*Precedent: the RFC Editor / IESG split, and EIP-1's separation of editors from
-  the canonical registry. No address may be guessed. If unsure, omit it.
+approval, both of which exist so that the person checking whether a document is
- Every gas figure, transaction hash, and block number MUST be reproducible from
+correctly formed is not the same person deciding whether the idea wins.*
  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
+### 9. Sourcing rules (binding on every AIP)
-Today, ratification is editorial: the Foundation approves an AIP and, for a
+- Every on-chain address is copied verbatim from the canonical SDK registry
-Standards Track change, ships it. This is honest and is labeled as such on every
+  (`sdk-js/src/addresses.ts`). No address is guessed. If unsure, omit it.
-pre-decentralization AIP. It is not stakeholder governance and does not pretend to
+- Every gas figure, transaction hash, and block number is reproducible from the
-be.
+  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.
-The intended migration, each step of which will be its own Meta AIP:
+### 10. Where AIPs live
-1. Open the validator set beyond the current seven Foundation-operated
+`aere-research/aips/` is canonical: `README.md` (the index), `CONTRIBUTING.md` (the
-   validators, and run a second client implementation.
+contribution path), `aip-template.md`, and `AIP-N.md` for every N.
 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
+A stale duplicate of AIP-1 through AIP-6 exists at `aere-research-repo/aips/`
-**"Foundation-ratified (pre-decentralization)"**.
+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 process is deliberately close to Ethereum's EIP/ERC model because AERE is
+The mechanisms above are borrowed, not designed. Every one of them has been load
-EVM-equivalent (Pectra plus Fusaka) and builders already know that model.
+tested for decades by IETF, Python, or Ethereum, and the failure each one
-Copying its status names and section structure lowers the cost of contributing.
+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 one deviation worth calling out is the explicit, up-front honesty about
+The single most important borrowed mechanism is section 5, immutability after
-governance. Rather than dress editorial ratification up as decentralized
+acceptance. A process where accepted documents can be quietly edited produces
-governance, AIP-1 names the current reality and the path off it. Credibility with
+records that cannot be cited, because the thing you cited may not be the thing
-technical readers comes from stating limitations plainly, not from hiding them.
+that is there now. That failure is invisible until the moment it matters, which
 is typically an audit or a dispute.
 ## Backwards Compatibility
-None. This is the first process document.
+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 chief risk in a pre-decentralization process is that a single party can both
+The governance weakness is stated rather than hidden: today a single party can
-author and ratify, so an AIP can be waved through without genuine review. This is
+both author and ratify an AIP. The editor's sourcing rules and the immutability
-mitigated only partially today, by the editor's sourcing rules (every address and
+rule reduce the damage that state can do (a false claim is at least dated,
-number must be real and reproducible) and by keeping the honesty label on every
+attributed, and hard to erase) but they do not remove it. Only independent
-proposal. It is not fully mitigated until independent ratifiers exist. This
+ratifiers do that, and Aere does not have them yet. Every pre-decentralization
-weakness is stated rather than hidden, which is itself part of the mitigation.
+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
-Not applicable. This AIP is the process. The scaffold lives at `aerenew/aips/`
+None. This is a process document.
-and consists of this file, `README.md`, `aip-template.md`, and the retro-filed
+
-AIPs AIP-2 through AIP-7.
+## 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.
 </content>
--- a/aips/AIP-2.md
+++ b/aips/AIP-2.md
@ -12,34 +12,22 @@
 | Status | Final |
 | Created | 2026-07-11 |
 | Requires | None |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
-This AIP documents the on-chain mechanism that makes AERE's burn real and
+This AIP documents the on-chain mechanism that makes AERE's fee-burn real and
 auditable: an atomic splitter that routes a validator's accumulated coinbase
 rewards so that a fixed fraction, 37.5% by default, is sent to a permanent burn
 vault and the remainder is returned to the validator. It is a retro-filed record
 of a change that is already live on chain 2800.
 **Realized burn to date, MEASURED.** The mechanism is live and the vault is
 immutable, and it has burned essentially nothing. `eth_getBalance` on the burn
 vault `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6` returned
 `0x1e7f974e119aaa7` at block 10,571,949 on 2026-07-20, which is
 137,352,594,046,167,719 wei, or 0.1373525940461677 AERE, against a fixed supply
 of 2,800,000,000 AERE. The reason is arithmetic: the burn is a percentage of
 validator coinbase revenue, that revenue is currently zero, and a percentage of
 zero is zero. The 37.5% in this document is a conditional rate on future
 revenue. AERE is not deflationary today. Verify with one RPC call.
 ## Motivation
 The AERE whitepaper (Section 3.3) states that up to 37.5% of transaction fees are
-permanently removed from circulation. That wording predates the implemented
+permanently removed from circulation. On a Hyperledger Besu QBFT chain there is no
 mechanism and is superseded: what this AIP specifies, and what is live, is a cut
 of the VALIDATOR COINBASE REWARD, not of transaction fees. The
 validator-reward-cut description governs everywhere the two conflict. On a
 Hyperledger Besu QBFT chain there is no
 protocol-level base-fee burn of the EIP-1559 kind: QBFT credits fees to the block
 proposer's coinbase rather than burning any part of them at the consensus layer.
 So the whitepaper claim needed an explicit, on-chain mechanism, or it would be
@ -137,7 +125,46 @@ All addresses copied verbatim from `sdk-js/src/addresses.ts`. Live cumulative
 burn statistics are readable via `AereCoinbaseSplitter.burnStats()` and
 `AereFeeBurnVault.totalBurnedAERE()`.
 ## Errata
 None.
 ## Post-Acceptance Outcome Record
 *Appended 2026-07-20 under AIP-1 section 5. Nothing above this heading was
 edited. This record exists because the mechanism works exactly as specified while
 producing an economic outcome that a reader of the sections above would not
 predict.*
 **The burn is real and it is approximately zero.**
 | Quantity | Value | Provenance |
 | --- | --- | --- |
 | Burn rate | 37.5% of the validator coinbase reward | spec (configured) |
 | Hard cap on the rate | 50% (`setBurnBps` reverts above `5000`) | spec |
 | Coinbase revenue to date | zero | measured |
 | Lifetime burned | 0.1374 AERE | measured |
 The splitter routes 37.5% of what it receives, and it has received almost
 nothing, because the chain is quiet and coinbase revenue is effectively zero. A
 percentage of zero is zero. The mechanism is live, immutable at its endpoints,
 and verifiable; the supply effect is negligible.
 **Therefore AERE is not deflationary today, and no Aere document may say that it
 is.** A burn mechanism existing is not the same claim as supply decreasing, and
 the difference between those two claims is 0.1374 AERE against a 2.8 billion
 supply. This will change only if transaction volume changes; it is not a
 parameter anyone can tune, because the rate is already set and the input is what
 is missing.
 **Two related confusions to keep out of Aere copy.** First, this burn is a cut of
 the **validator coinbase reward**, not an EIP-1559 base-fee burn; QBFT credits
 fees to the proposer's coinbase and burns nothing at the consensus layer, which is
 why the mechanism is a contract above consensus. Second, chain 2800 does separately
 run a 1 Gwei base-fee **floor** from block 10,141,734 (AIP-17); a floor sets a
 minimum price and removes no supply. Conflating the floor with the burn produces a
 statement that is wrong twice.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
 </content>
--- a/aips/AIP-7.md
+++ b/aips/AIP-7.md
@ -12,6 +12,8 @@
 | Status | Final |
 | Created | 2026-07-16 |
 | Requires | 4 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
@ -234,10 +236,6 @@ the recorded Falcon-1024 attestation is retrievable at block 9,200,542. The desi
 and gas model are specified in `research/aip-draft-pqc-precompiles.md`; the
 pure-Solidity verifier suite that the precompiles accelerate is documented in AIP-4.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
 ## Errata
 **Erratum 1 (2026-09-11).** The Rationale originally read "a maintained, audited
@ -249,3 +247,47 @@ to us; calling it audited or reviewed asserted more than can be cited. What is c
 is byte-for-byte agreement with the NIST KAT and ACVP vectors in both directions,
 recorded in `AERE-NIST-VALIDATION-STATUS.md` section 3.4. Nothing normative in this
 AIP changed: the precompiles, addresses, encodings and gas constants are untouched.
 The clarification below remains an outcome record rather than an erratum,
 because this AIP specified five precompiles and five is what is live. The record
 exists to close off a misreading that arose elsewhere, not to correct this text.
 ## Post-Acceptance Outcome Record
 *Appended 2026-07-20 under AIP-1 section 5. Nothing above this heading was
 edited.*
 **Mainnet 2800 has exactly five PQC precompiles, and the band ends at
 `0x0AE5`.**
 Two sibling precompiles were built after this fork and are sometimes discussed
 alongside it: ML-KEM-768 at `0x0AE6` and Falcon HashToPoint at `0x0AE7`. Both are
 **testnet-only**. Neither is live on chain 2800.
 This was confirmed on 2026-07-20 by a **gas-differential probe** against a
 no-code control address: a live precompile and an empty account both return empty
 data, so return value alone cannot distinguish them, but they differ in gas
 consumed. `0x0AE6` and `0x0AE7` on mainnet behave as empty accounts.
 | Address | Scheme | Live on 2800 | Provenance |
 | --- | --- | --- | --- |
 | `0x0AE1` | Falcon-512 | yes, from block 9,189,161 | measured |
 | `0x0AE2` | Falcon-1024 | yes, from block 9,189,161 | measured |
 | `0x0AE3` | ML-DSA-44 | yes, from block 9,189,161 | measured |
 | `0x0AE4` | SLH-DSA-SHA2-128s | yes, from block 9,189,161 | measured |
 | `0x0AE5` | SHAKE256 | yes, from block 9,189,161 | measured |
 | `0x0AE6` | ML-KEM-768 | **no, testnet only** | measured (gas-differential probe) |
 | `0x0AE7` | Falcon HashToPoint | **no, testnet only** | measured (gas-differential probe) |
 | `0x0AE8` | PQ STARK verify | **no, skeleton, no network** | AIP-16 |
 The scope boundary this AIP already states is restated because it is the claim
 most likely to be misquoted: this fork changed the execution layer only. **Aere
 consensus is classical secp256k1 ECDSA QBFT and is not post-quantum.**
 The EIP-2935 half of this fork carries a deviation from the written standard,
 namely that the history contract was listed under Pectra but not populated until
 this fork's block. That deviation is now recorded separately as AIP-18.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/README.md
+++ b/aips/README.md
@ -1,118 +1,117 @@
-# AERE Improvement Proposals (AIPs)
+# Aere Improvement Proposals (AIPs)
-An AIP (AERE Improvement Proposal) is a design document that describes a change
+An AIP is a design document describing a change to Aere Network (chain ID 2800),
-to the AERE Network (chain ID 2800), its contracts, its consensus parameters, or
+its contracts, its consensus parameters, or its processes. It records the
-its processes. An AIP records the motivation for a change, the exact mechanism,
+motivation, the exact mechanism, the rationale, and, when the change is already
-the rationale for the design, and, when the change is already live, the on-chain
+live, the on-chain addresses and transactions that prove it exists.
 addresses and transactions that prove it exists.
-AIPs are AERE's equivalent of Ethereum's EIP/ERC process. They exist so that any
+AIPs exist so that a reader, human or machine, can reconstruct why the chain
-reader, human or machine, can reconstruct why the chain works the way it does
+works the way it does from one canonical plain-text source instead of from
-from a single canonical, plain-text source instead of from marketing pages.
+marketing pages or from someone's memory.
-This directory is a local, self-contained scaffold. It is not published anywhere
+**Start here:**
 and is not wired into any build or deployment. It is intended to be the seed of a
 public AIP repository once the process is stable.
-## What belongs in an AIP
+- **[AIP-1](./AIP-1.md)** is the process: numbering, statuses and the transitions
-
+  between them, supersession, and the rule that accepted proposals are not
- A protocol or consensus change (block time, fee routing, precompiles).
+  silently edited.
- A new contract standard or interface that other builders are expected to
+- **[CONTRIBUTING.md](./CONTRIBUTING.md)** is how someone who is not us proposes
-  integrate against.
+  a change, and who actually decides.
- A token-standard or account-standard convention (ARC).
+- **[aip-template.md](./aip-template.md)** is the required template.
 - A process or governance change (Meta).
 Things that do not belong in an AIP: bug-fix redeploys that preserve an existing
 interface (those are tracked in `sdk-js/src/addresses.ts` deprecation notes),
 routine parameter tuning inside an already-ratified bound, and pure documentation.
 ## Lifecycle
 An AIP moves through a small number of statuses. The happy path is
 `Draft -> Review -> Last Call -> Final`. Standards that are never "done" (for
 example a registry that keeps growing) settle in `Living` instead of `Final`.
 | Status | Meaning |
 | --- | --- |
 | Draft | The proposal is written and formatted correctly and has an author. It may still change substantially. |
 | Review | The author has marked it ready for wider scrutiny. Open questions are being resolved. |
 | Last Call | Final review window. A fixed review period is stated. If no blocking issue is raised, it advances. |
 | Final | Accepted and, for already-shipped work, live on chain 2800. The mechanism is now stable and should not change in a breaking way. |
 | Living | Accepted and expected to keep being updated (for example an index or a registry-style standard). |
 | Withdrawn | The author or the editors abandoned the proposal. Terminal. |
 | Stagnant | Inactive in Draft or Review for an extended period. Can be revived. |
 Retro-filed AIPs (documents written after the change already shipped) enter
 directly at `Final` or `Living` and carry a note that they are backfilling
 history. AIP-2 through AIP-7 in this scaffold are retro-filed.
 ## Categories and types
 Every Standards Track AIP names one category:
 - **Core**: consensus, block production, fee/burn accounting, precompiles, and
  anything that changes how the chain itself behaves. Requires a client or
  genesis/config change.
 - **Networking**: peer-to-peer protocol, sync, and node-to-node messaging.
 - **Interface**: contract-level interfaces, ABIs, RPC conventions, and
  verification surfaces that builders integrate against.
 - **ARC (token standards)**: AERE Request for Comment. Application and token
  standards, for example ERC-20/4626 receipt tokens and ERC-4337 account
  conventions, as adopted on AERE.
 - **Meta**: process, governance, and the AIP process itself.
 Types: Standards Track (Core, Networking, Interface, ARC), Meta, and
 Informational. Informational AIPs give guidance and do not mandate anything.
 ## Honest governance note (read this)
 AERE is not yet trustlessly governed. Today the network runs seven validators
 under a single operator, one client (Hyperledger Besu QBFT), no external security
 audit, and thin real usage. In that reality an AIP is not ratified by an on-chain
 vote of independent stakeholders. It is **Foundation-ratified**: the AERE
 Foundation account (`0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`, a single-key
 Foundation-controlled account, not a deployed multisig) is the final editor and
 approver.
 Every AIP that predates validator and client decentralization carries the label
 **"Foundation-ratified (pre-decentralization)"** so no reader mistakes editorial
 ratification for trustless governance. As the validator set opens up and a second
 client and independent stakers come online, the process is expected to migrate to
 stake-weighted or validator-weighted ratification. That migration will itself be a
 Meta AIP. Until then, the honest description of AERE governance is: a Foundation
 publishes proposals, ships them, and records them here for public audit.
 ## How to file an AIP
 1. Copy `aip-template.md` to `AIP-N.md`, where N is the next free integer.
 2. Fill in every required section. Do not delete a section header; if a section
   does not apply, write "None" under it.
 3. Cite on-chain addresses verbatim from `sdk-js/src/addresses.ts`. Never invent
   an address, a transaction hash, or a gas number. If a number has not been
   measured, write "to be measured" rather than guessing.
 4. Add a row to the index below.
 5. Open it for editorial review. Until decentralization, the editor is the
   Foundation.
 ## Index
-| AIP | Title | Type / Category | Status | Note |
+Status values are defined in AIP-1 section 3. A blank Superseded-By means the
 document is current.
 | AIP | Title | Type / Category | Status | Superseded by |
 | --- | --- | --- | --- | --- |
-| [1](./AIP-1.md) | AIP Purpose and Process | Meta | Living | The process itself |
+| [1](./AIP-1.md) | AIP Purpose and Process | Meta | Living (rev 2, 2026-07-20) | |
-| [2](./AIP-2.md) | Coinbase Fee-Burn Routing (37.5%) | Standards Track / Core | Final | Foundation-ratified (pre-decentralization) |
+| [2](./AIP-2.md) | Coinbase Fee-Burn Routing (37.5%) | Standards Track / Core | Final | |
-| [3](./AIP-3.md) | Sub-Second Block Period (500 ms QBFT) | Standards Track / Core | Final | Foundation-ratified (pre-decentralization) |
+| [3](./AIP-3.md) | Sub-Second Block Period (500 ms QBFT) | Standards Track / Core | Final | |
-| [4](./AIP-4.md) | On-Chain Post-Quantum Signature Verification Suite | Standards Track / Interface | Final | Foundation-ratified (pre-decentralization) |
+| [4](./AIP-4.md) | On-Chain Post-Quantum Signature Verification Suite | Standards Track / Interface | Final | |
-| [5](./AIP-5.md) | sAERE Receipt Token and AereSink Immutable Flywheel | Standards Track / ARC | Final | Foundation-ratified (pre-decentralization) |
+| [5](./AIP-5.md) | sAERE Receipt Token and AereSink Immutable Flywheel | Standards Track / ARC | Final | |
-| [6](./AIP-6.md) | ERC-4337 Passkey and Gasless Onboarding Stack | Standards Track / ARC | Final | Foundation-ratified (pre-decentralization) |
+| [6](./AIP-6.md) | ERC-4337 Passkey and Gasless Onboarding Stack | Standards Track / ARC | Final | |
-| [7](./AIP-7.md) | AerePQC Hard-Fork Activation (Native PQC Precompiles and Extended EIP-2935 Lookback) | Standards Track / Core | Final | Foundation-ratified (pre-decentralization) |
+| [7](./AIP-7.md) | AerePQC Hard-Fork Activation (PQC Precompiles and EIP-2935 Lookback) | Standards Track / Core | Final | |
 | [8](./AIP-8.md) | Post-Quantum-Authorized Transaction Envelope (EIP-2718 Type 0x2A) | Standards Track / Core | **Draft, not live** | |
 | [9](./AIP-9.md) | Consensus Mechanism: QBFT, not HotStuff | Informational | Final | |
 | [10](./AIP-10.md) | Execution Client: Forked Besu with Nethermind Second, not Reth | Informational | Final | |
 | [11](./AIP-11.md) | Interoperability: Hyperlane-Compatible plus zk Light Clients, not IBC | Informational | Final | |
 | [12](./AIP-12.md) | The Virtual Machine: Extend the EVM, not a New VM | Informational | Final | |
 | [13](./AIP-13.md) | Post-Quantum Signatures: Falcon and ML-DSA Together | Informational | Final | |
 | [14](./AIP-14.md) | Account Abstraction: ERC-4337 with EIP-7702 Bridge, not Native AA | Informational | Final | |
 | [15](./AIP-15.md) | In-Place Hybrid PQC Consensus Activation, not Re-Genesis | Standards Track / Core | **Draft, testnet R&D only** | |
 | [16](./AIP-16.md) | PQ STARK-Verify Precompile (0x0AE8) | Standards Track / Core | **Draft, skeleton, verifies nothing** | |
 | [17](./AIP-17.md) | One-Gwei EIP-1559 Base-Fee Floor | Standards Track / Core | Final | |
 | [18](./AIP-18.md) | EIP-2935 on Chain 2800: Deviation from the Written Activation Schedule | Standards Track / Core | Final | |
 | [19](./AIP-19.md) | AIP Process Hardening | Meta | **Review, not ratified** | |
 Numbers are permanent and are never reused, including for withdrawn proposals
 (AIP-1 section 2). Numbering is contiguous from 1 to 19 with no gaps. No AIP
 numbered 20 or higher exists in any Aere repository.
 ## Which of these are live on chain 2800
 Read this before citing anything here as a network capability.
 **Live:** AIP-2 (burn routing; see its outcome record for the measured amount),
 AIP-3 (500 ms target, 516.4 ms measured), AIP-4, AIP-5, AIP-6, AIP-7
 (precompiles `0x0AE1`..`0x0AE5` from block 9,189,161), AIP-17 (base-fee floor from
 block 10,141,734), AIP-18 (EIP-2935 from block 9,189,161). AIP-9 through AIP-14
 describe the decisions behind the live system.
 **Not live:** AIP-8 (needs a hard fork), AIP-15 (isolated testnet only), AIP-16
 (a skeleton that verifies nothing), AIP-19 (a process change under review).
 **Never claimed:** post-quantum consensus. Aere consensus is classical secp256k1
 ECDSA QBFT at N = 7. Post-quantum applies to signatures, accounts and
 applications only. The precompiles `0x0AE6` and `0x0AE7` are testnet-only.
 ## Governance, stated plainly
 Aere is not yet trustlessly governed. Seven validators, all Foundation-operated,
 one live client, no external security audit, thin real usage. In that reality an
 AIP is not ratified by a vote of independent stakeholders. **The founder decides**,
 acting through the Foundation account
 `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`, which is a single-key account and
 **not a deployed multisig**. Every proposal that predates decentralization carries
 the label "Foundation-ratified (pre-decentralization)" so nobody mistakes
 editorial ratification for governance. See `CONTRIBUTING.md` for what that means
 if you are not us, and AIP-1 section 8 for the migration path.
 ## Filing an AIP
 See AIP-1 section 6 and `CONTRIBUTING.md`. In short: copy the template, keep
 every section header, cite addresses verbatim from `sdk-js/src/addresses.ts`,
 label every number **measured**, **spec** or **estimate**, write "to be measured"
 rather than guessing, and add a row to this index.
 ## Conventions
- Files are named `AIP-N.md`.
+- Files are named `AIP-N.md`. One AIP per change. If a change has a Core part and
- One AIP per change. If a change has a Core part and an application part, either
+  an application part, either file two AIPs or state clearly which layer each
-  file two AIPs or state clearly which layer each section addresses.
+  section addresses.
 - Addresses, transaction hashes, gas figures, and block numbers must be
-  reproducible from the chain or from a repo fixture. Marketing numbers (for
+  reproducible from the chain or from a repo fixture. Design ceilings (for
-  example a design-ceiling throughput) are never presented as measured results.
+  example a theoretical maximum throughput) are never presented as measured
-</content>
+  results.
-</invoke>
+- A Final AIP is not edited. Corrections go in its Errata section and outcomes go
  in its Post-Acceptance Outcome Record, both dated and appended (AIP-1 section
  5).
 ## Other locations, and one stale copy
 - `aere-research-repo/aips/` holds an older AIP-1 through AIP-6 whose governance
  note says "three validators" and calls the Foundation account a multisig. Both
  statements are false today. **This directory is authoritative** wherever the two
  disagree.
 - the Aere working tree holds drafts (not published in this package) of open, externally-submittable Ethereum standards
  (targeting `ethereum/EIPs`, `ethereum/ERCs`, or the RIP process). Those are not
  AIPs and carry no AIP number: an AIP records why chain 2800 works the way it
  does with its live addresses, while an open EIP draft is the chain-agnostic
  version a third party could implement.
 - `aere-docs/AERE-AIP-PROCESS-AND-INDEX.md` is the published narrative version
  of this index.
 ## Copyright
 All AIPs are released to the public domain (CC0). No rights reserved.
--- a/aips/aip-template.md
+++ b/aips/aip-template.md
@ -12,12 +12,19 @@
 | Status | Draft / Review / Last Call / Final / Living / Withdrawn / Stagnant |
 | Created | YYYY-MM-DD |
 | Requires | Comma-separated AIP numbers, or None |
 | Supersedes | AIP number this replaces, or None |
 | Superseded-By | AIP number that replaces this, or None |
 | Ratification | Foundation-ratified (pre-decentralization), or the governance basis in force |
 `Supersedes` and `Superseded-By` are written as a pair: if this AIP supersedes
 AIP-N, then AIP-N gets `Superseded-By: <this number>` in the same change. A
 reader must be able to follow `Superseded-By` from any AIP to the current text.
 ## Abstract
 Two to four sentences. State what the AIP does in plain language. A reader should
-understand the whole change from this paragraph alone.
+understand the whole change from this paragraph alone. If this document backfills
 a change that already shipped, say so here.
 ## Motivation
@ -33,9 +40,9 @@ with their values. For a consensus change, give the exact configuration keys and
 values and the activation point. Use MUST / SHOULD / MAY where a requirement is
 binding on implementers.
-For anything that touches gas or size, cite only numbers that are measured
+Every quantity carries its provenance: **measured** (reproducible from the chain
-on-chain or sourced from a repo fixture. Label any unmeasured number as
+or a repo fixture), **spec** (a configured or standardized value), or
-"to be measured".
+**estimate**. An unmeasured quantity is written "to be measured", never guessed.
 ## Rationale
@ -51,7 +58,8 @@ breaks.
 Attack surface, trust assumptions, and known weaknesses. This section is required
 and must be honest. If the change depends on a trusted operator, a small
-validator set, or an unaudited contract, say so here.
+validator set, or an unaudited contract, say so here. Do not delete this header;
 "None" is a claim a reader can challenge, an absent section is not.
 ## Reference Implementation and On-Chain Deployment
@ -60,7 +68,18 @@ address(es) copied verbatim from `sdk-js/src/addresses.ts`, and the proving
 transaction hashes and block numbers where available. For a not-yet-live change:
 the branch or spec that implements it and the plan to ship.
 ## Errata
 Corrections to factual errors found after this AIP reached Final. Each entry is
 dated, states what the document said, and states what is correct. The erroneous
 text above is **not** edited away. "None" until there is one.
 ## Post-Acceptance Outcome Record
 What actually happened after the change shipped, including where the outcome
 differs from what this document expected. Appended and dated; never edits the
 original claim. Omit this section entirely while the AIP is pre-Final.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
 </content>