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 | `aere-research/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
`aere-research/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.