aere-docs/AERE-AIP-PROCESS-AND-INDEX.md

spec-25: The Aere Improvement Proposal (AIP) Process and Index

Field	Value
Spec	25
Title	The Aere Improvement Proposal (AIP) Process and Index
Author	Aere Network Foundation
Status	For publication
Created	2026-07-19
Last revised	2026-07-20
Chain	Aere Network, chain ID 2800

0. Purpose of this document

This is the published narrative view of the AIP process and its index. The canonical artifacts are in aerenew/aips/:

Artifact	Path
The process, normatively	aere-research/aips/AIP-1.md
The index	aere-research/aips/README.md
The outsider contribution path	aerenew/aips/CONTRIBUTING.md
The required template	aere-research/aips/aip-template.md
Every proposal	aerenew/aips/AIP-N.md

Where this document and AIP-1 disagree, AIP-1 wins. This one exists to explain the process to a reader who is not going to read nineteen files.

0.1 What changed on 2026-07-20, and why it mattered

The revision of 2026-07-19 of this document described a process and published an index. An honest review on 2026-07-20 found that what existed was a document describing a process rather than a process, on five specific counts:

1. Nothing had ever moved through the lifecycle. All eight proposals entered directly at Final, Living or Draft; none had occupied Review or Last Call.
2. AIP-9 through AIP-16 were published in the index while existing only as sections inside this document. A number that does not resolve to a document is not a record.
3. AIP-8 lived outside the AIP directory under a non-conforming filename.
4. Two mechanisms the process depends on did not exist: supersession headers, and a rule against editing accepted documents.
5. Real, consequential decisions had no number at all: the 1 Gwei base-fee floor live since block 10,141,734, and the EIP-2935 activation deviation.

All five are now addressed. The process change is recorded as AIP-19, which is itself in Review and not ratified. AIP-1 revision 2 carries the normative text.

0.2 Honesty note on community review (read this first)

An AIP process is worth running from day one, even before an external technical community exists, because its first job is transparent decision documentation: a stable, plain-text home for the motivation, mechanism, on-chain proof, and honest limitations of each change. That value does not depend on anyone commenting.

The comment and review mechanism is open: anyone may author an AIP, raise an issue on one, or fork the record. But Aere has essentially no external technical community commenting yet. Decentralization is thin (an effective Nakamoto coefficient of about 1, since all validators are Foundation-operated on a single live client) and real external usage is thin.

Therefore this document and the AIPs it indexes contain no fabricated community discussion: no invented debate, no fake review threads, no imagined participants, no comment counts. Where an AIP records a decision, it records who actually decided (today, the founder) and on what evidence.

---

1. The process in brief

Full normative text: aere-research/aips/AIP-1.md. Summary:

What an AIP is. A design document describing a change to chain 2800, its contracts, its consensus parameters, or its processes, recording motivation, mechanism, rationale, and, when live, the addresses and transactions that prove it exists.

Lifecycle. Draft -> Review -> Last Call -> Final, with Living replacing Final for documents that keep evolving, and Withdrawn and Stagnant as off-ramps. AIP-1 section 3 publishes the full table of permitted transitions. There is no transition out of Final: a Final AIP changes only by being superseded.

Retro-filing. A document written after the change shipped enters directly at Final or Living and must say so in its Abstract. This is the one sanctioned bypass, and it exists because pretending a shipped change went through review would be a lie.

Numbering. Sequential from 1, assigned at Draft entry, never reused, retained through Withdrawn.

Supersession. Paired Supersedes and Superseded-By headers, so a reader who lands on any AIP can follow Superseded-By to the current text. A superseded AIP is never deleted or rewritten: its historical claim stays true.

Immutability. A Final AIP's normative sections are frozen. Corrections are dated Errata appended below the original text; results are dated Post-Acceptance Outcome Records. Nothing above those headings is edited.

Precedent for each mechanism. Numbering permanence from IETF RFC 2026; transition table from PEP 1's state diagram; supersession from the IETF Obsoletes / Obsoleted by pair; mandatory sections from EIP-1 and RFC 3552; immutability plus separate errata from the RFC Editor model and from Nygard's Architecture Decision Records. None of it is invented here.

Types. Standards Track (categories Core, Networking, Interface, ARC), Meta, Informational.

Roles. Author (anyone), Editor (checks well-formedness and that every cited number is real; does not judge merit), Ratifier (the founder, today).

Sourcing rules. Addresses verbatim from sdk-js/src/addresses.ts; every number labeled measured, spec or estimate; "to be measured" rather than a guess; design ceilings never presented as measured results; and no document claims post-quantum consensus.

---

2. Index

The canonical index with status and supersession columns is aere-research/aips/README.md. Numbering is contiguous from 1 to 19 with no gaps; no AIP numbered 20 or higher exists in any Aere repository.

AIP	Title	Type / Category	Status
1	AIP Purpose and Process	Meta	Living (rev 2)
2	Coinbase Fee-Burn Routing (37.5%)	Standards Track / Core	Final
3	Sub-Second Block Period (500 ms QBFT)	Standards Track / Core	Final
4	On-Chain Post-Quantum Signature Verification Suite	Standards Track / Interface	Final
5	sAERE Receipt Token and AereSink Immutable Flywheel	Standards Track / ARC	Final
6	ERC-4337 Passkey and Gasless Onboarding Stack	Standards Track / ARC	Final
7	AerePQC Hard-Fork Activation	Standards Track / Core	Final
8	Post-Quantum-Authorized Transaction Envelope (Type 0x2A)	Standards Track / Core	Draft, not live
9	Consensus Mechanism: QBFT, not HotStuff	Informational	Final
10	Execution Client: Forked Besu, Nethermind second, not Reth	Informational	Final
11	Interoperability: Hyperlane-compatible plus zk light clients, not IBC	Informational	Final
12	The Virtual Machine: Extend the EVM, not a New VM	Informational	Final
13	Post-Quantum Signatures: Falcon and ML-DSA Together	Informational	Final
14	Account Abstraction: ERC-4337 with EIP-7702 Bridge	Informational	Final
15	In-Place Hybrid PQC Consensus Activation, not Re-Genesis	Standards Track / Core	Draft, testnet R&D
16	PQ STARK-Verify Precompile (0x0AE8)	Standards Track / Core	Draft, skeleton
17	One-Gwei EIP-1559 Base-Fee Floor	Standards Track / Core	Final
18	EIP-2935 on Chain 2800: Deviation from the Written Activation Schedule	Standards Track / Core	Final
19	AIP Process Hardening	Meta	Review, not ratified

Every one of these is a file at aerenew/aips/AIP-N.md.

2.1 What is actually live on chain 2800

Live: AIP-2, AIP-3, AIP-4, AIP-5, AIP-6, AIP-7, AIP-17, AIP-18. AIP-9 through AIP-14 record the decisions behind the live system.

Not live: AIP-8 (requires a coordinated hard fork), AIP-15 (isolated testnet only, chain ID 440855), AIP-16 (a fail-closed skeleton that verifies nothing), AIP-19 (a process change in Review).

Boundaries that must not be blurred in any Aere document:

• Consensus on chain 2800 is classical secp256k1 ECDSA QBFT at N = 7. Aere never claims post-quantum consensus. Post-quantum applies to signatures, accounts and applications.
• Mainnet has exactly five PQC precompiles, 0x0AE1 to 0x0AE5, from block 9,189,161. 0x0AE6 and 0x0AE7 are testnet-only (confirmed 2026-07-20 by a gas-differential probe against a no-code control). 0x0AE8 is not activated anywhere.
• The Aere burn is a cut of the validator coinbase reward, not a base-fee burn. Coinbase revenue is zero and lifetime burn is 0.1374 AERE, so AERE is not deflationary today (AIP-2 outcome record). The separate 1 Gwei base-fee floor (AIP-17) sets a minimum price and removes no supply.
• The block period is a 500 ms target; the measured mean interval is 516.4 ms (AIP-3 outcome record).

2.2 Coverage of the engineering-spec design decisions

aerenew/docs/AERE-ENGINEERING-SECURITY-SPEC.md Section 4 enumerates the load-bearing design decisions. All now have a numbered record.

Section 4 decision	Record
4.1 Consensus: QBFT, not HotStuff	AIP-9
4.2 Execution client: forked Besu with Nethermind second, not Reth	AIP-10
4.3 Interoperability: Hyperlane-compatible plus zk light clients, not IBC	AIP-11
4.4 Post-quantum signatures: Falcon and ML-DSA together	AIP-13 (mechanism in AIP-4, AIP-7)
4.5 Account abstraction: ERC-4337 with EIP-7702 bridge	AIP-14 (stack in AIP-6)
4.6 Virtual machine: extend the EVM, not a new VM	AIP-12
4.7 The burn: validator-reward cut, not a base-fee burn	AIP-2
PQC precompile activation	AIP-7
Base-fee floor	AIP-17
EIP-2935 activation deviation	AIP-18
In-place hybrid PQC consensus activation (R&D, not live)	AIP-15
PQ STARK-verify precompile 0x0AE8 (skeleton, not live)	AIP-16

2.3 Open EIP/ERC drafts (external standards, not AIPs)

Separately from the internal AIP numbering, Aere maintains drafts of open, externally-submittable Ethereum standards for the primitives judged genuinely novel and worth standardizing beyond Aere. The strategy is to conform to existing open standards wherever they exist and to propose only the genuinely new primitives, as open (CC0) standards, never as a closed Aere-only standard. These live in aerenew/eips/ (index: aerenew/eips/README.md) and target the upstream ethereum/EIPs, ethereum/ERCs, or the RIP (RollCall) process. Each is Status: Draft: formatted as submittable, but not yet submitted to or accepted by the upstream editors, and carrying no assigned EIP number.

They are distinct from AIPs: an AIP records why chain 2800 works the way it does with its live addresses; an open EIP draft is the chain-agnostic version a third party could implement.

Open draft	File	Type / Category	Status	Maps to AIP
Native NIST PQC signature-verification precompiles	aerenew/eips/eip-draft-pqc-signature-precompiles.md	Standards Track / Core (filable as RIP)	Draft	AIP-4, AIP-7
SHAKE256 extendable-output-function precompile	aerenew/eips/eip-draft-shake256-precompile.md	Standards Track / Core (filable as RIP)	Draft	AIP-7
Post-quantum account and mandate authorization	aerenew/eips/eip-draft-pqc-account-authorization.md	Standards Track / ERC	Draft	AIP-4, AIP-14

The precompile drafts generalize the primitive shipped on chain 2800 at 0x0AE1 to 0x0AE5 (block 9,189,161, recorded as AIP-7); the account and mandate ERC draft generalizes the account primitives recorded in AIP-4. Gas figures in all three are cited from aerenew/docs/AERE-BENCHMARK-REPORT.md. None of these drafts touches consensus.

---

3. Governance, stated plainly

Aere is not yet trustlessly governed. Seven QBFT validators (f = 2, commit quorum 5-of-7) under a single operator, one live client (Hyperledger Besu), no external security audit, thin real usage. In that reality an AIP is not ratified by an on-chain vote of independent stakeholders. The founder decides, acting through the Foundation account 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3, which is a single-key account and not a deployed multisig.

A Governor, Timelock and governance token are deployed on chain 2800 and control nothing: no production contract is owned by a timelock. They are inert infrastructure for a future in which they hold authority. Their existence is not a claim that Aere has on-chain governance.

Every AIP that predates validator and client decentralization carries the label "Foundation-ratified (pre-decentralization)" so 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.

The chief risk of a pre-decentralization process, that a single party can both author and ratify, is mitigated only partially today, by the editor's sourcing rules and by the immutability rule that makes a false claim dated, attributed and hard to erase quietly. It is fully mitigated only when independent ratifiers exist. This weakness is stated rather than hidden.

For what this means to an outside contributor, see aerenew/aips/CONTRIBUTING.md.

---

4. Relationship to the whitepaper

Every substantive change to the whitepaper should cite the AIP that authorized it, so the version history explains itself rather than recording only that something moved. The rule and its mechanics are specified in aerenew/docs/AERE-WHITEPAPER-AIP-LINKAGE.md.

---

5. Copyright

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