dd1410c266
The published line and the local line of this repository had no common ancestor: the public one carried the hygiene pass (no host names, no internal paths), the local one carried a month of corrections that never shipped. This commit ports the local work onto the public line, keeping the public hygiene wording wherever the two touched the same sentence, and keeping the public version of AERE-CROSS-CLIENT-DETERMINISM.md entirely. Carried: LICENSE/LICENSING corrections, VERIFY-POLICY.md, CITATIONS-UNRESOLVED.md remeasured 2026-08-11, the 'audited' adjective removed from next to Bouncy Castle, citation paths rewritten to published form, AIP-8, the QA consolidation report, the second EIP validation pass, fork-height corrections, the AereSink / threshold-factory correction, the forge test floor, and the architecture-map updates.
272 lines
14 KiB
Markdown
272 lines
14 KiB
Markdown
# 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.
|