AIP-8 through AIP-19 and CONTRIBUTING.md published: the index linked twelve documents this package did not carry. Validator counts carry their measurement date (errata on the Final ones, per AIP-1 section 5), the Fusaka activation block corrected to the measured 2,106,597, and the staging rewrites are now a checked table

2026-09-12 09:49:12 +03:00 · 2026-09-12 09:49:12 +03:00 · ec3ca3368f
commit ec3ca3368f
parent 83453d9a79
18 changed files with 1749 additions and 34 deletions
--- a/CITATIONS-UNRESOLVED.md
+++ b/CITATIONS-UNRESOLVED.md
@ -1,7 +1,7 @@
 # Citations in this repository that you cannot open
 This file is generated by the legaturi-repara.cjs script in the Aere working tree and
-enforced by legaturi.cjs. It is the complete list, measured on 2026-09-02, of every
+enforced by legaturi.cjs. It is the complete list, measured on 2026-09-12, of every
 path cited in this repository that does not resolve to a published file.
 A citation is a promise that a claim is checkable. Where the target is not published,
@ -15,15 +15,24 @@ repositories, so they begin with a repository name, for example
 Unresolvable distinct paths in this repository: **104**.
 - `addresses.ts`  cited in: aere-research/research/specs/spec-account-abstraction.md, aere-research/research/specs/spec-antimev-mempool.md, aere-research/research/specs/spec-eip2935-lookback.md, aere-research/research/specs/spec-full-evm-validity.md, aere-research/research/specs/spec-recursive-aggregation-scale.md, aere-research/research/specs/spec-zk-stack.md, aere-research/results/PROVEN-RESULTS-2026-07-11.md
 - `aerenew/basefee-floor-dryrun/basefee-floor.diff`  cited in: aere-research/aips/AIP-10.md, aere-research/aips/AIP-17.md
 - `aerenew/consensus-pqc/besu-consensus-pqc-fork-activation.patch`  cited in: aere-research/aips/AIP-15.md
 - `aerenew/contracts/deployments/falcon-512-verifier.json`  cited in: aere-research/research/pqc-onchain-verification.md
 - `aerenew/contracts/deployments/pqc-account.json`  cited in: aere-research/research/pqc-onchain-verification.md
 - `aerenew/docs/AERE-EIP-COMPATIBILITY-MATRIX.md`  cited in: aere-research/aips/AIP-18.md
 - `aerenew/docs/AERE-PROTOCOL-SPECIFICATION.md`  cited in: aere-research/aips/AIP-17.md, aere-research/aips/AIP-18.md
 - `aerenew/docs/AIP-PQ-TX-2026-07-18.md`  cited in: aere-research/aips/AIP-19.md
 - `aerenew/docs/BASEFEE-FLOOR-FORK-RUNBOOK-2026-07-17.md`  cited in: aere-research/aips/AIP-17.md
 - `aerenew/docs/drafts/PQC-FORK-PAPER-DRAFT.md`  cited in: aere-research/research/aip-draft-pqc-precompiles.md
 - `aerenew/docs/PQ-STARK-VERIFIER-ACTIVATION-2026-07-18.md`  cited in: aere-research/aips/AIP-16.md
 - `aerenew/docs/PQ-STARK-VERIFIER-PRECOMPILE-2026-07-18.md`  cited in: aere-research/aips/AIP-16.md
 - `aerenew/docs/TRANZITIA-QBFT-SETTLED-2026-07-20.md`  cited in: aere-research/aips/AIP-3.md
 - `aerenew/formal-tla/QBFT.tla`  cited in: aere-research/formal-consensus/RULEAZA-TOT.md
 - `aerenew/formal-tla/QBFTPartition.tla`  cited in: aere-research/formal-consensus/RULEAZA-TOT.md
 - `aerenew/scripts/deschise/flaguri-verify.cjs`  cited in: aere-research/VERIFY-POLICY.md
 - `aerenew/strategie/EXECUTION-KERNEL-2026-08-15.md`  cited in: aere-research/execution-kernel/MACHINE-INTERFACE-CONTRACT.md
- `AIP-N.md`  cited in: aere-research/aips/AIP-1.md, aere-research/aips/README.md
+- `AIP-N.md`  cited in: aere-research/aips/AIP-1.md, aere-research/aips/CONTRIBUTING.md, aere-research/aips/README.md
 - `air.rs`  cited in: aere-research/pq-stark/README.md
 - `batch-prover-recovered/bin/aere-prover/Cargo.toml`  cited in: aere-research/pq-stark/export-inner-stark-vector.md
 - `besu-pqc-precompiles-mlkem-hashtopoint.patch`  cited in: aere-research/PQC-FORK-README.md
@ -32,17 +41,12 @@ Unresolvable distinct paths in this repository: **104**.
 - `CLAUDE.md`  cited in: aere-research/execution-kernel/MACHINE-INTERFACE-CONTRACT.md
 - `compression.rs`  cited in: aere-research/pq-stark/spec-mmcs-babybear.md
 - `config.rs`  cited in: aere-research/pq-stark/spec-fri-babybear.md
 - `contracts/contracts/AereCoinbaseSplitter.sol`  cited in: aere-research/aips/AIP-2.md
 - `contracts/contracts/AereCoinbaseSplitterV2.sol`  cited in: aere-research/aips/AIP-2.md
 - `contracts/contracts/AereFeeBurnVault.sol`  cited in: aere-research/aips/AIP-2.md
 - `contracts/contracts/AereIdentity.sol`  cited in: aere-research/research/specs/spec-identity-compliance.md
 - `contracts/contracts/anchor/AereHistoryStateRootAnchor.sol`  cited in: aere-research/research/specs/spec-eip2935-lookback.md
 - `contracts/contracts/parallel/AereBlockSTMRegistry.sol`  cited in: aere-research/research/specs/spec-parallel-execution.md
 - `contracts/contracts/parallel/AereEVMValidity.sol`  cited in: aere-research/research/specs/spec-full-evm-validity.md
 - `contracts/contracts/parallel/AereRollupValidity.sol`  cited in: aere-research/research/specs/spec-full-evm-validity.md, aere-research/research/specs/spec-parallel-execution.md
 - `contracts/contracts/raas/AereRaaSFactory.sol`  cited in: aere-research/parallel-executor/README.md
 - `contracts/contracts/sink/AereSink.sol`  cited in: aere-research/aips/AIP-5.md
 - `contracts/contracts/staking/sAERE.sol`  cited in: aere-research/aips/AIP-5.md
 - `contracts/contracts/zkverify/AereProofAggregator.sol`  cited in: aere-research/research/specs/spec-recursive-aggregation-scale.md
 - `contracts/deploy/deploy-saere-sink-stack.js`  cited in: aere-research/aips/AIP-5.md
 - `contracts/deployments/block-stm-registry.json`  cited in: aere-research/research/specs/spec-parallel-execution.md
@ -58,11 +62,6 @@ Unresolvable distinct paths in this repository: **104**.
 - `contracts/deployments/zkml-mnist-verifier.json`  cited in: aere-research/research/specs/spec-zk-stack.md
 - `contracts/deployments/zkverify-stack.json`  cited in: aere-research/research/specs/spec-zk-stack.md
 - `contracts/test/block-stm-registry.test.js`  cited in: aere-research/research/specs/spec-parallel-execution.md
 - `contracts/test/falcon1024_kat0.json`  cited in: aere-research/aips/AIP-4.md
 - `contracts/test/falcon512_kat0.json`  cited in: aere-research/aips/AIP-4.md
 - `contracts/test/fixtures/mldsa44-acvp-tg8.json`  cited in: aere-research/aips/AIP-4.md
 - `contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json`  cited in: aere-research/aips/AIP-4.md
 - `contracts/test/fixtures/xmss-sha2_10_256-kat.json`  cited in: aere-research/aips/AIP-4.md
 - `crypto/merklesignature/committablePublicKeys.go`  cited in: aere-research/research/pqc-onchain-verification.md
 - `data/transactions/logic/langspec_v12.json`  cited in: aere-research/research/pqc-onchain-verification.md
 - `dense-batch-2026-07-11/NOTE.md`  cited in: aere-research/research/specs/spec-full-evm-validity.md
@ -103,6 +102,7 @@ Unresolvable distinct paths in this repository: **104**.
 - `rollup-sequencer/src/blockstm/BlockSTMExecutor.ts`  cited in: aere-research/research/specs/spec-parallel-execution.md
 - `rollup-sequencer/src/blockstm/example.ts`  cited in: aere-research/research/specs/spec-parallel-execution.md
 - `run-kats.sh`  cited in: aere-research/PQC-FORK-README.md
 - `sdk-js/src/addresses.ts`  cited in: aere-research/aips/AIP-1.md, aere-research/aips/AIP-11.md, aere-research/aips/AIP-2.md, aere-research/aips/AIP-4.md, aere-research/aips/AIP-5.md, aere-research/aips/AIP-6.md, aere-research/aips/AIP-7.md, aere-research/aips/AIP-8.md, aere-research/aips/CONTRIBUTING.md, aere-research/aips/README.md, aere-research/aips/aip-template.md, aere-research/research/pqc-onchain-verification.md, aere-research/research/specs/spec-account-abstraction.md, aere-research/research/specs/spec-antimev-mempool.md, aere-research/research/specs/spec-eip2935-lookback.md, aere-research/research/specs/spec-flywheel-economics.md, aere-research/research/specs/spec-full-evm-validity.md, aere-research/research/specs/spec-identity-compliance.md, aere-research/research/specs/spec-parallel-execution.md, aere-research/research/specs/spec-recursive-aggregation-scale.md, aere-research/research/specs/spec-zk-stack.md, aere-research/results/PROVEN-RESULTS-2026-07-11.md
 - `setup-fork.sh`  cited in: aere-research/PQC-FORK-README.md
 - `shutter-mempool-v2.json`  cited in: aere-research/research/specs/spec-antimev-mempool.md
 - `shutter-mempool-v3.json`  cited in: aere-research/research/specs/spec-antimev-mempool.md
--- a/aips/AIP-10.md
+++ b/aips/AIP-10.md
@ -0,0 +1,86 @@
 # AIP-10: Execution Client: Forked Besu with Nethermind as the Second Client, not Reth
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 10 |
 | Title | Execution Client: Forked Besu with Nethermind as the Second Client, not Reth |
 | Author | Aere Network Foundation |
 | Type | Informational |
 | Category | (none) |
 | Status | Final |
 | Created | 2026-07-19 |
 | Requires | 7, 9 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
 This AIP records the decision to run a fork of Hyperledger Besu as the sole live
 mainnet producer and a patched Nethermind as the second, independent client,
 rather than adopting Reth. It backfills a decision already live on chain 2800.
 ## Motivation
 A production chain needs a producing client and, to retire single-implementation
 risk, a second independent client. Aere already ships QBFT (AIP-9), which is
 Besu-specific: no off-the-shelf Geth, Reth, Erigon, or stock Nethermind produces
 QBFT-compatible blocks.
 ## Specification
 - **Producer:** a fork of Hyperledger Besu v26.4.0 (Java, base commit
  `d2032017`, JDK 21 toolchain), the sole live mainnet producer. The fork carries
  the native post-quantum precompiles and the EIP-2935 write path (live from
  block 9,189,161, AIP-7) and the 1-Gwei base-fee floor (live from block
  10,141,734, AIP-17).
 - **Second client:** a patched Nethermind 1.39.0 (.NET), which validates the live
  chain and runs the five live PQC precompiles byte-for-byte identically (27 of
  27 NIST KAT vectors, **measured**).
 ## Rationale
 Besu already carries QBFT and already carries the codebase into which the PQC
 precompile fork and base-fee changes were integrated. Nethermind was chosen as
 the second client specifically for implementation diversity: a different codebase
 in a different language (.NET versus Java), so a consensus-relevant bug in one is
 unlikely to exist in the other. On an isolated test network the patched
 Nethermind produces byte-identical QBFT blocks that stock Besu accepts through
 full BFT validation, with a one-byte-tampered seal rejected.
 **Alternatives rejected.** Reth (Rust) as the base client: it has no notion of
 QBFT, so it would require building QBFT production into a client that lacks it
 before producing a single block; and the September 2025 Reth halt is the
 reference case for why depending on one producing implementation is a systemic
 risk. A second Besu instance instead of Nethermind: that is not client diversity,
 since it shares every bug with the first.
 ## Backwards Compatibility
 None. This records the existing topology.
 ## Security Considerations
 Cross-client production is proven on an isolated testnet (offline import and,
 later, live devp2p between test nodes), and a listen-only Nethermind follower has
 run against the live network. **Nethermind is not yet a live gossiping producer
 on chain 2800.** Besu remains the sole live producer, so single-implementation
 risk is mitigated as a cross-check and fail-safe, not eliminated. Making
 Nethermind a live producer is a founder-supervised change, because a producer bug
 on a live chain can halt or fork it.
 ## Reference Implementation and On-Chain Deployment
 Chain ID 2800; live producer Besu only. Client fork sources and the Nethermind
 patch live in the consensus and client work trees; the base-fee floor diff is at
 `aerenew/basefee-floor-dryrun/basefee-floor.diff`.
 ## Errata
 None.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-11.md
+++ b/aips/AIP-11.md
@ -0,0 +1,86 @@
 # AIP-11: Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 11 |
 | Title | Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC |
 | Author | Aere Network Foundation |
 | Type | Informational |
 | Category | (none) |
 | Status | Final |
 | Created | 2026-07-19 |
 | Requires | None |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
 This AIP records the decision to build cross-chain interoperability as an
 EVM-native, Hyperlane-compatible messaging layer plus zero-knowledge light
 clients, rather than adopting IBC natively. It backfills a decision already made
 and partly deployed.
 ## Motivation
 Aere's value proposition is that it is an ordinary EVM chain. Cross-chain interop
 must serve permissionless, EVM-familiar builders while also offering
 trust-minimized verification of a counterparty's finality, and those two goals
 pull in different directions.
 ## Specification
 - An EVM-native, Hyperlane-compatible messaging layer: a Mailbox-compatible
  `AereMessenger` and an interchain gas paymaster `AereIGP`.
 - An ERC-7683 intent layer and an Across-v3-compatible spoke pool.
 - A zero-knowledge interop path: on-chain zk light clients verifying a
  counterparty's consensus finality from inside a contract (inbound Ethereum
  sync-committee finality, outbound Aere QBFT finality) via SP1 Groth16 proofs.
 ## Rationale
 IBC's design philosophy, verifying the counterparty's consensus rather than
 trusting a bridge committee, is the right one, and Aere adopts the philosophy
 directly. Aere splits the problem: for permissionless, developer-familiar interop
 it uses the Hyperlane-compatible interfaces the EVM tooling ecosystem already
 speaks; for the trust-minimization that is IBC's real contribution it built the
 zk light clients, which capture "verify the counterparty's consensus, do not
 trust a relayer" without leaving the EVM world.
 **Alternatives rejected.** IBC as a protocol: it is built around Tendermint-style
 light clients and a non-EVM connection, channel, and packet model. Adopting it
 natively would import a substantial non-EVM stack and its tooling into a chain
 whose entire premise is that it is an ordinary EVM.
 ## Backwards Compatibility
 None.
 ## Security Considerations
 The Hyperlane-compatible endpoints are interface-faithful and deployed, but a
 live decentralized relayer and interchain-security-module network is **not** yet
 stood up: the current bridge path runs through a single Foundation signer with a
 relayer pending. Until that changes, the messaging layer's trust assumption is
 the Foundation, not a validator set.
 The zk light clients are trust-minimized, not trustless, and **not quantum-safe**:
 their committed seals are classical secp256k1 and the proof wrap is Groth16 over
 BN254, which is Shor-breakable. A post-quantum-sound replacement is recorded in
 AIP-16 and is not live.
 ## Reference Implementation and On-Chain Deployment
 Deployed messaging and intent interfaces are listed in `sdk-js/src/addresses.ts`.
 The zk light-client and verifier-gateway work is under `aere-contracts` and
 the zk work trees.
 ## Errata
 None.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-12.md
+++ b/aips/AIP-12.md
@ -0,0 +1,88 @@
 # AIP-12: The Virtual Machine: Extend the EVM, not a New VM
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 12 |
 | Title | The Virtual Machine: Extend the EVM, not a New VM |
 | Author | Aere Network Foundation |
 | Type | Informational |
 | Category | (none) |
 | Status | Final |
 | Created | 2026-07-19 |
 | Requires | None |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
 This AIP records the decision to keep the EVM unchanged and to add Aere's
 differentiating capability as precompiles and client-fork rules at reserved
 addresses, rather than designing a new virtual machine. It backfills a decision
 already live on chain 2800.
 ## Motivation
 Aere differentiates on post-quantum verification, parallel execution, and
 extended block-hash lookback. It must add these without taxing the developer
 surface it depends on for adoption.
 ## Specification
 Solidity, EVM bytecode, JSON-RPC, and the developer tooling are unchanged.
 Differentiation is added as:
 - precompiles at otherwise-empty reserved addresses (the `0x0AE1`..`0x0AE5` band,
  live from block 9,189,161, AIP-7), and
 - client-fork rules activated in the same manner Ethereum activates its own hard
  forks.
 No new instruction set, no new language, no nonstandard account model, and no
 nonstandard RPC.
 ## Rationale
 A mature VM has years of implementation hardening, a known cost model, and an
 operational history; a new VM starts that clock at zero, maximizing both
 technical and adoption risk. The EVM is the single largest smart-contract
 developer surface in existence, and every deviation (a nonstandard opcode,
 account model, or RPC) is a tax on every developer and every tool. Aere's thesis
 is settlement, not a novel programming model, so the design keeps the tested
 execution environment intact and adds differentiation only at the EVM's standard
 extension points. Nothing about Aere's account, passkey, or post-quantum surface
 depends on a nonstandard EVM.
 **Alternatives rejected.** Designing a new, purpose-built VM (a new bytecode,
 language, or non-EVM environment) optimized around Aere's differentiators.
 ## Backwards Compatibility
 Full EVM compatibility is the point of the decision. Precompiles at previously
 empty addresses are additive: before activation those addresses were empty
 accounts, so a call to one returned empty rather than reverting. AIP-7 covers the
 activation-boundary consequences.
 ## Security Considerations
 Some ambitions (base-layer parallel execution, an EVM-in-a-zkVM) must be reached
 inside the existing model rather than designed in from scratch. Those remain
 roadmap and are labeled as such wherever they appear. Adding capability at
 reserved addresses means the address band must be treated as consensus-critical:
 activating a precompile at an address that historical transactions already called
 would change their re-execution result, which is why AIP-16 forward-dates its
 milestone rather than folding into a crossed one.
 ## Reference Implementation and On-Chain Deployment
 Chain ID 2800. Live precompiles and their activation block are specified in
 AIP-7.
 ## Errata
 None.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-13.md
+++ b/aips/AIP-13.md
@ -0,0 +1,90 @@
 # AIP-13: Post-Quantum Signatures: Falcon and ML-DSA Together, not a Single Lattice Family
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 13 |
 | Title | Post-Quantum Signatures: Falcon and ML-DSA Together, not a Single Lattice Family |
 | Author | Aere Network Foundation |
 | Type | Informational |
 | Category | (none) |
 | Status | Final |
 | Created | 2026-07-19 |
 | Requires | 4, 7 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
 This AIP records the decision to support multiple post-quantum signature schemes
 across two distinct lattice families (Falcon and ML-DSA) plus hash-based schemes,
 rather than standardizing on one. It backfills a decision already live on chain
 2800. The normative mechanism is in AIP-4 (contract suite) and AIP-7 (precompile
 activation); this record captures the decision framing.
 ## Motivation
 Aere verifies post-quantum signatures on-chain at both the contract layer (AIP-4)
 and, since block 9,189,161, the native precompile layer (AIP-7). A choice of
 scheme family is a bet on a mathematical assumption, and betting on one is a
 single point of cryptographic failure.
 ## Specification
 Supported families:
 - **Falcon** (Falcon-512, Falcon-1024): NTRU lattices.
 - **ML-DSA** (Dilithium2 / ML-DSA-44): module lattices with
  Fiat-Shamir-with-aborts.
 - **Hash-based**: SLH-DSA, XMSS, WOTS+.
 Live mainnet precompiles occupy `0x0AE1`..`0x0AE5`: Falcon-512 `0x0AE1`,
 Falcon-1024 `0x0AE2`, ML-DSA-44 `0x0AE3`, SLH-DSA-SHA2-128s `0x0AE4`, SHAKE256
 `0x0AE5` (**measured**, live from block 9,189,161). `0x0AE6` (ML-KEM-768) and
 `0x0AE7` (Falcon HashToPoint) are **testnet-only and not live on chain 2800**.
 ## Rationale
 Cryptographic-risk diversification. Supporting both lattice families means a
 cryptanalytic break or a standardization flaw in one does not, by itself, remove
 Aere's ability to verify post-quantum signatures: accounts and settlement
 authorization can migrate to the surviving family. This mirrors the hybrid
 `AereHybridAuth` account, which requires both a classical ECDSA and a Falcon-512
 signature, so that neither a broken curve nor a broken lattice alone suffices to
 forge.
 **Alternatives rejected.** Standardizing on a single lattice scheme (ML-DSA alone
 as the NIST primary, or Falcon alone for its compact signatures). The cost of
 supporting several schemes is more verifier surface to implement, validate, and
 eventually audit; that cost is accepted deliberately rather than betting the
 network's post-quantum future on a single assumption.
 ## Backwards Compatibility
 None. Additive.
 ## Security Considerations
 **Scope boundary (binding).** This is post-quantum at the signature, account and
 application layer only. Consensus remains classical: validators sign secp256k1
 QBFT. The zk verification path is also classical (BN254 Groth16, Shor-breakable).
 **Aere never claims post-quantum consensus.**
 The verifiers and precompiles carry an internal self-audit only. An external
 audit is pending before they should secure material value. Their assurance today
 rests on bit-for-bit agreement with official NIST KAT and ACVP vectors and on
 cross-checks against independent reimplementations.
 ## Reference Implementation and On-Chain Deployment
 Contract suite: AIP-4. Precompile activation and addresses: AIP-7. Chain ID 2800.
 ## Errata
 None.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-14.md
+++ b/aips/AIP-14.md
@ -0,0 +1,82 @@
 # AIP-14: Account Abstraction: ERC-4337 with EIP-7702 Bridge, not Native AA
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 14 |
 | Title | Account Abstraction: ERC-4337 with EIP-7702 Bridge, not Native AA |
 | Author | Aere Network Foundation |
 | Type | Informational |
 | Category | (none) |
 | Status | Final |
 | Created | 2026-07-19 |
 | Requires | 6 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
 This AIP records the decision to deliver programmable accounts through ERC-4337
 smart accounts with EIP-7702 as the migration bridge, rather than protocol-level
 native account abstraction. It backfills a decision already live on chain 2800.
 The normative stack is in AIP-6; this record captures the decision framing.
 ## Motivation
 Aere wants programmable accounts (recovery, passkey ownership, post-quantum
 ownership, gas sponsorship) without breaking EVM and externally-owned-account
 compatibility.
 ## Specification
 ERC-4337 (v0.7) smart accounts as the account-abstraction path, with EIP-7702
 (live under the Pectra ruleset) as the migration bridge that lets existing
 externally-owned accounts delegate to smart-account code. EIP-3074 is **not**
 implemented.
 ## Rationale
 ERC-4337 needs no consensus change, is an established standard with an existing
 bundler and tooling ecosystem, and delivers programmable accounts (including the
 Falcon-owned post-quantum smart account `AerePQCAccountFactory`) without touching
 the protocol, preserving exact EVM and Ethereum compatibility. EIP-7702 is the
 chosen bridge precisely because it upgrades existing externally-owned accounts in
 place without forcing a disruptive "everything is a contract" change.
 **Alternatives rejected.** Native, protocol-level account abstraction up to an
 "all accounts are smart accounts by default" end state: it changes what an
 account fundamentally is, breaking existing tooling, contracts, and user keys.
 EIP-3074, an earlier proposal for empowering externally-owned accounts: it was
 superseded upstream by EIP-7702, which is the mechanism Aere carries.
 ## Backwards Compatibility
 Existing externally-owned accounts keep working unchanged. Migration via EIP-7702
 is opt-in per account.
 ## Security Considerations
 The EntryPoints are Aere's own ERC-4337-compatible implementations: compatible in
 shape and interface but **not byte-identical to Ethereum's canonical audited
 singleton**. Integrators should treat them as Aere-specific and should not assume
 the upstream audit applies to them. These contracts have not had an external
 audit.
 Gasless onboarding is subsidized (Foundation-funded, rate-limited), not free. A
 paymaster that runs out of funds stops sponsoring; onboarding degrades rather
 than fails silently.
 ## Reference Implementation and On-Chain Deployment
 The normative stack (accounts, factories, paymasters, EntryPoints) with addresses
 is in AIP-6. Chain ID 2800.
 ## Errata
 None.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-15.md
+++ b/aips/AIP-15.md
@ -0,0 +1,114 @@
 # AIP-15: In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 15 |
 | Title | In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis |
 | Author | Aere Network Foundation |
 | Type | Standards Track |
 | Category | Core |
 | Status | Draft (isolated-testnet R&D; not live on chain 2800) |
 | Created | 2026-07-19 |
 | Requires | 9 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Not ratified; external-audit gated and founder gated |
 ## Abstract
 This AIP specifies a way to bind a Falcon-512 validator manifest to on-chain
 state **after** genesis, via a minimal immutable anchor contract, so that hybrid
 post-quantum consensus could be activated on a live chain without a re-genesis.
 It is **Draft**. Nothing in it is live on chain 2800, whose consensus remains
 classical secp256k1 ECDSA QBFT.
 ## Motivation
 Aere's hybrid consensus research proved, on isolated test networks, a gossiped,
 blocking Falcon-512 quorum certificate running alongside the ECDSA
 committed-seal quorum, empirically at N = 4 (2 s) and N = 7 (0.5 s). Its Falcon
 registry, however, was bound to chain identity at genesis, by folding
 `keccak256(manifest)` into the genesis state root. Chain 2800 launched long
 before any Falcon manifest existed, so blocking activation was previously
 recorded as "requires a re-genesis". That is a non-starter for a live chain:
 re-genesis destroys history and chain identity.
 ## Specification
 Bind the Falcon manifest to on-chain state post-genesis:
 1. Deploy a minimal, immutable, ownerless **anchor contract** by one ordinary
   transaction at an activation height. Its runtime code is a single `STOP` byte,
   so it is never callable and has no admin.
 2. The contract commits `keccak256(manifest)` to storage slot 0.
 3. On every block import, the validation rule resolves the manifest from the
   **parent block's world state** at the anchor address, and activates the
   pending registry only if the observed hash matches. Any mismatch fails closed.
 4. The deploy address is deterministic, `keccak256(rlp[deployer, nonce])[12:]`, so
   validators can be pre-configured before deployment.
 5. Activation is idempotent and retried each block, so deploy-then-configure and
   configure-then-deploy both converge.
 The re-genesis requirement is removed.
 ## Rationale
 The late anchor folds `keccak256(manifest)` into every block hash from the
 deployment block onward, so two nodes that agree on the chain past that block
 necessarily agree on the anchored hash. That is the same integrity guarantee the
 genesis ceremony gave, minus the re-genesis.
 **Alternatives rejected.** Re-genesis carrying a Falcon anchor in the genesis
 alloc: destroys history and chain identity. A shared per-node manifest file with
 no on-chain root: a node with a tampered manifest could join silently, whereas the
 on-chain anchor makes it fail closed.
 ## Backwards Compatibility
 Pre-activation blocks remain valid and are unaffected. The design is
 non-retroactive by construction: the anchor address is an empty account before
 its deploy block.
 ## Security Considerations
 **Evidence and honest scope.** Proven end-to-end on an **isolated N = 4 at 0.5 s
 testnet** (chain ID 440855) whose genesis is byte-shape-identical to a classical
 ECDSA-only chain: classical start, deploy anchor at block 16, activate from the
 contract at block 17, flip to blocking at fork block 150, with 0 forks, 0.5 s
 cadence maintained, pre-activation blocks still valid, a post-activation
 sub-quorum block rejected (the chain halts), and recovery in place with no
 re-genesis. All **measured** on that testnet.
 **Nothing in this AIP is live on chain 2800.** This was written 2026-07-19, when
 the chain ran N = 7 and carried no Falcon material in any header. Measured
 2026-09-12: the set is N = 10, and since block 13,014,000 anchor headers carry a
 post-quantum certificate under the block hash. That anchor is a periodic
 checkpoint, not the per-block blocking quorum specified here, and the design
 below has never been armed on chain 2800.
 The hybrid can only shrink the committable set, so it is never worse than the
 ECDSA-only chain; ECDSA committed seals remain the decisive safety and liveness
 seal. The corresponding risk is liveness: in this design, which is not live, a
 blocking Falcon quorum that cannot be met would halt block production. At N = 7,
 the set size when this was written, the blocking configuration has a zero
 two-fault margin, which is why a larger set is recommended before any live flip.
 **Remaining gates to a live flip.** No longer a gate: re-genesis. Still required:
 an external audit of the Falcon consensus patch (quorum, gossip, assembly,
 late-anchor Java) and of BouncyCastle Falcon-512 on the consensus path;
 finalizing the full target validator set with an address-bound manifest
 re-anchored for the full set; a live isolated soak of the combined activation at
 the full set size (N = 10, measured 2026-09-12); and an explicit founder GO.
 **No agent activates blocking consensus on chain 2800.**
 ## Reference Implementation and On-Chain Deployment
 Not deployed. Reference patch:
 `aerenew/consensus-pqc/besu-consensus-pqc-fork-activation.patch`, with evidence
 under `aerenew/consensus-pqc/inplace-activation-evidence/`.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-16.md
+++ b/aips/AIP-16.md
@ -0,0 +1,110 @@
 # AIP-16: PQ STARK-Verify Precompile (0x0AE8)
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 16 |
 | Title | PQ STARK-Verify Precompile (0x0AE8) |
 | Author | Aere Network Foundation |
 | Type | Standards Track |
 | Category | Core |
 | Status | Draft (reference skeleton; verifies nothing; not live on any Aere network) |
 | Created | 2026-07-19 |
 | Requires | 7, 12 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Not ratified; prerequisite gated, external-audit gated, founder gated |
 ## Abstract
 This AIP reserves precompile address `0x0AE8` for a post-quantum-sound
 STARK-verify precompile that would verify a hash-based STARK on-chain, removing a
 BN254 pairing check from Aere's zk paths. It is **Draft**. As of this date the
 artifact is a reference skeleton that verifies nothing, and `0x0AE8` is not
 activated on any Aere network.
 ## Motivation
 Aere's zk interop and validity paths currently wrap proofs as Groth16 over BN254,
 which is classical and Shor-breakable. A post-quantum-sound proof system (a
 FRI-based STARK, hash commitments only, no pairing) would remove that assumption.
 A native precompile is the natural home for STARK verification, matching the same
 reasoning used for the post-quantum signature precompiles in AIP-7.
 ## Specification
 Reserve precompile address `0x0AE8`. It is specified to activate under a new,
 **forward-dated** milestone (PQ-3), never folded into an already-crossed
 milestone, so that pre-activation history is byte-identical on old and new
 binaries and the upgrade itself carries no fork risk.
 **Scope correction (2026-07-19 research finding).** An earlier draft described
 this as verifying "an SP1 inner-STARK (FRI over a Poseidon2 commitment)". That is
 corrected here: the verifier skeleton built so far is a BabyBear + FRI STARK
 verifier, conformance-confirmed against Plonky3 `0.4.3-succinct`, which targets
 Aere's own Plonky3 circuits and **not** SP1 6.1.0. The pinned SP1 6.1.0 is a
 Hypercube release (KoalaBear multilinear: BaseFold plus sumcheck-zerocheck plus
 LogUp-GKR), so FRI does not apply to it and this skeleton does not verify SP1
 6.1.0 proofs. Retargeting `0x0AE8` to the SP1 Hypercube stack is a separate
 effort **estimated** at 22 to 32 person-weeks. See
 `AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md`.
 ## Rationale
 A forward-dated, non-retroactive milestone plus a rolling binary upgrade (the same
 zero-liveness-risk posture proven for the base-fee floor in AIP-17 and the
 in-place activation in AIP-15) means the address stays an empty account, and every
 consumer adapter fails closed, until the announced activation time. A migrated
 consumer can keep both the new `0x0AE8` path and the existing BN254 gateway during
 a defense-in-depth window before dropping the classical path.
 **Alternatives rejected.** Folding `0x0AE8` into the already-crossed
 `futureEipsTime` milestone (block 9,189,161): every historical block that called
 the currently-empty address would re-execute with different return data on the
 upgraded binary, which is a state divergence and a consensus split. Also
 rejected: presenting the current artifact as a working verifier, because it is
 not one.
 ## Backwards Compatibility
 None, by construction: the address is an empty account until a forward-dated
 activation, so no historical execution changes.
 ## Security Considerations
 **This is the load-bearing honesty statement of this record.** `0x0AE8` is not
 activated on any Aere network. As of this date it is a reference skeleton that
 fail-closes, returning EMPTY for every input. **It is not a working verifier and
 must not be presented as one.** Mainnet 2800 has exactly five PQC precompiles,
 `0x0AE1` to `0x0AE5`, live from block 9,189,161. The sibling ML-KEM-768 (`0x0AE6`)
 and Falcon HashToPoint (`0x0AE7`) precompiles are testnet-only.
 `AerePQStarkVerifier.sol` is a fail-closed adapter that denies every proof, safe
 by construction. Consensus is untouched by all of this and remains classical
 ECDSA QBFT.
 **Prerequisites before activation can even begin.** The crypto core must be
 ported from maintained references (Plonky3 FRI/Poseidon2/uni-stark, SP1 stark) or
 a pinned native wrap must be built and reproducible; a real SP1 v6.1.0
 inner-STARK vector corpus must exist, with the precompile accepting every valid
 vector and rejecting every tampered or wrong-public-values vector, including
 cross-agreement with the live BN254 gateway; a soundcalc receipt for the exact
 pinned `FriConfig` must be recorded (no 128-bit claim without the receipt); and a
 benchmark must confirm a real verify fits under the EIP-7825 2^24 per-transaction
 gas cap.
 **Gates beyond the prerequisites.** A specialist external STARK/FRI audit of the
 consensus-critical crypto, a conformance gate green on the frozen artifact, an
 isolated N = 7 soak across a simulated milestone crossing, and an explicit founder
 GO. Until all hold, `0x0AE8` stays a skeleton.
 ## Reference Implementation and On-Chain Deployment
 Not deployed. Design:
 `aerenew/docs/PQ-STARK-VERIFIER-PRECOMPILE-2026-07-18.md`. Gated activation plan:
 `aerenew/docs/PQ-STARK-VERIFIER-ACTIVATION-2026-07-18.md`. Fail-closed adapter:
 `aere-contracts/contracts/zkverify/AerePQStarkVerifier.sol`.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-17.md
+++ b/aips/AIP-17.md
@ -0,0 +1,161 @@
 # AIP-17: One-Gwei EIP-1559 Base-Fee Floor
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 17 |
 | Title | One-Gwei EIP-1559 Base-Fee Floor |
 | Author | Aere Network Foundation |
 | Type | Standards Track |
 | Category | Core |
 | Status | Final |
 | Created | 2026-07-20 |
 | Requires | 10 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
 This AIP documents the client-flag-gated fork that clamps the EIP-1559 base fee
 on chain 2800 to a minimum of 1 Gwei from block **10,141,734**. Before that block
 the real minimum bottomed out at 7 wei. It is a retro-filed record of a change
 already live on chain 2800: it backfills history and did not go through Draft,
 Review or Last Call.
 ## Motivation
 Aere's public RPC and its documentation reported a 1 Gwei base fee while the
 chain's actual base fee had decayed to 7 wei. That gap was being closed by a
 presentation-layer shim rather than by the chain, which meant a user who queried
 the chain directly and a user who read our documentation got different answers,
 and only one of them was true.
 There were two honest ways to close it: change the documentation to say 7 wei, or
 change the chain so that 1 Gwei is the real value. The second was chosen because
 a base fee of 7 wei is not a meaningful price signal, and because a floor is a
 value the chain can actually enforce and any observer can verify from block data.
 The shim was then retired, which was the point of the exercise: the number
 reported is now the number the chain produces.
 ## Specification
 For every block `B`:
 ```
 baseFee(B) = max( baseFee_1559(parent), 1000000000 )   if number(B) >= 10141734
 baseFee(B) = baseFee_1559(parent)                      otherwise
 ```
 where `baseFee_1559` is the unmodified parent-derived EIP-1559 base fee and
 `1000000000` wei = 1 Gwei.
 - The clamp is applied at the three exits of
  `computeBaseFee(blockNumber, parentBaseFee, parentGasUsed, targetGasUsed)`,
  identically on the produce path and the validate path, so a floored block both
  produces and self-validates the floored value.
 - The two driving values are Besu client **system properties**:
  `AERE_BASEFEE_FLOOR_FORK_BLOCK = 10141734` and
  `AERE_BASEFEE_FLOOR_VALUE = 1000000000`, exposed as
  `aere.basefee.floor.forkBlock`.
 - The defaults are **dormant** (`forkBlock = Long.MAX_VALUE`), so an unflagged
  build never applies the floor and is byte-identical to stock in behavior.
 - The change is deliberately **not** an EIP-2124 fork-id input and is not
  registered as a scheduled fork.
 **Measured activation boundary** (re-confirmed by direct measurement 2026-07-19):
 block 10,141,733 has `baseFeePerGas = 7` wei; block 10,141,734 has
 `baseFeePerGas = 0x3b9aca00 = 1,000,000,000` wei; the value holds at 1 Gwei at
 every later block sampled through head, and `eth_feeHistory` at head reports
 `0x3b9aca00`.
 ## Rationale
 **Why a client flag rather than a chain-config fork.** Base-fee validation is
 absent from the QBFT header ruleset, so a node with a different floor flag does
 not reject a peer's blocks: two clients with different flags share one fork id
 and peer normally. That property is what made the rollout carry no liveness risk,
 because validators could be upgraded one at a time and a lagging node could not
 halt or split the chain. The flag being dormant by default is what keeps every
 historical block below 10,141,734 valid with its original sub-Gwei base fee.
 **Why 1 Gwei.** It is the value the documentation already claimed, so the fork
 made the documentation true rather than choosing a new number and creating a
 second discrepancy.
 **Alternatives rejected.** Keeping the presentation-layer shim: it makes the RPC
 lie, and a hash-verifiable chain that needs a shim to look right has a
 credibility problem worse than a low base fee. Enshrining the floor as a
 consensus fork rule with a fork id: unnecessary given that base fee is not
 header-validated here, and it would have introduced a genuine split risk in
 exchange for nothing.
 ## Backwards Compatibility
 Historical blocks are unaffected and still validate with their original base
 fees. Integrators that hard-coded a sub-Gwei minimum gas price will underprice
 transactions from block 10,141,734 onward and should read the base fee from the
 chain. No contract interface changed.
 ## Security Considerations
 This modification cannot halt or fork QBFT, because base-fee validation is not
 part of the QBFT header ruleset (which is also why a non-upgraded node syncs
 straight past the floor block with no rejection). The corresponding weakness is
 the same fact stated from the other side: because the floor is not
 consensus-enforced, a validator running without the flag would produce blocks
 with a sub-Gwei base fee and no one would reject them. Consistency depends on
 operational rollout to all validators, not on consensus. All seven validators are
 Foundation-operated (AIP-9), so today that is an operational guarantee under one
 operator.
 **Open question, honestly flagged.** Where the EIP-1559 base fee ultimately goes
 on chain 2800 is **not fully resolved**. Measurement on block 10,487,561 (one
 transaction, `gasUsed` 22,474, `effectiveGasPrice` = `baseFeePerGas` = 1 Gwei, so
 zero priority tip) showed a coinbase balance delta of **exactly 0 wei**, which
 rules out the base fee being credited to the coinbase, since crediting would have
 moved 22,474,000,000,000 wei. Because the tip was zero, that measurement cannot by
 itself separate "protocol-burned" from "routed elsewhere". Completing the
 distinction needs a block containing a transaction with a nonzero priority tip and
 unpruned state.
 **This floor is not a burn.** Aere's burn is a separate cut of the validator
 coinbase reward (AIP-2). A base-fee floor sets a minimum price; it does not remove
 supply. These two must not be conflated in any Aere document.
 ## Reference Implementation and On-Chain Deployment
 - Diff: `aerenew/basefee-floor-dryrun/basefee-floor.diff`
 - Runbook: `aerenew/docs/BASEFEE-FLOOR-FORK-RUNBOOK-2026-07-17.md`
 - Specification detail: `aerenew/docs/AERE-PROTOCOL-SPECIFICATION.md` Section 5.1
 - Chain ID 2800, activation block 10,141,734. No contract address: this is a
  client change.
 Verify it yourself: fetch `baseFeePerGas` for blocks 10,141,733 and 10,141,734
 from `https://rpc.aere.network` and from the second public endpoint
 `https://rpc2.aere.network`. Both return 7 wei and 1,000,000,000 wei
 respectively, and the fork-block hash is identical across both endpoints.
 ## Errata
 **Erratum 1 (2026-09-12).** The Security Considerations say "All seven validators
 are Foundation-operated (AIP-9)" without a date, so read on its own it is a claim
 about today. That was a measurement of 2026-07-19. Measured 2026-09-12: the set
 is ten, still all Foundation-operated, so the conclusion of that sentence stands
 and only its count moved. See the erratum on AIP-9. The original text is left
 exactly as published, per AIP-1 section 5.
 ## Post-Acceptance Outcome Record
 **2026-07-20.** Activation was clean and is **measured**: base fee 7 wei at block
 10,141,733 became 1 Gwei at 10,141,734 and has stayed 1 Gwei; the fork-block hash
 was identical across the public RPC and the second RPC, so there was no split;
 N = 7 held with no halt. The presentation-layer shim was retired, and both public
 endpoints now serve an honest, hash-verifiable 1 Gwei. Rollback remains available
 by clearing the flag, which would return the chain to unmodified EIP-1559
 behavior from the next block.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-18.md
+++ b/aips/AIP-18.md
@ -0,0 +1,147 @@
 # AIP-18: EIP-2935 on Chain 2800: Deviation from the Written Activation Schedule
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 18 |
 | Title | EIP-2935 on Chain 2800: Deviation from the Written Activation Schedule |
 | Author | Aere Network Foundation |
 | Type | Standards Track |
 | Category | Core |
 | Status | Final |
 | Created | 2026-07-20 |
 | Requires | 7 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
 Chain 2800 lists EIP-2935 under its Pectra ruleset, but the history-storage
 system contract was not populated and the write path did not run until the
 AerePQC fork at block **9,189,161**. Any client or integrator that assumed
 "Pectra is active, therefore EIP-2935 serves history" was wrong for every block
 between the Pectra ruleset taking effect and block 9,189,161. This AIP records
 that deviation explicitly so it is discoverable, and states exactly what is true
 before and after that block. It is a retro-filed record and backfills history.
 ## Motivation
 A deviation from a written standard that is not written down is a trap. It does
 not cause a problem on the day it is created; it causes one months later, when
 somebody reads the standard, checks that the fork is active, and writes code
 against a guarantee the chain was not providing.
 The deviation was found and confirmed by direct measurement while building the
 EIP compatibility matrix, not by reading our own configuration, which is exactly
 the failure mode this record exists to prevent for the next person.
 ## Specification
 EIP-2935 as written specifies a history-storage system contract at
 `0x0000F90827F1C53a10cb7A02335B175320002935`, a ring buffer serving the last
 `HISTORY_SERVE_WINDOW = 8191` block hashes, written by a consensus system call at
 the start of each block, activated at the fork that adopts it.
 On chain 2800:
 - **Address:** `0x0000F90827F1C53a10cb7A02335B175320002935` (canonical, unchanged).
 - **Window:** 8191 blocks (`0x1fff`), unchanged from the written EIP.
 - **Runtime:** 83 bytes, byte-for-byte the canonical EIP-2935 runtime
  (**measured**). Disassembly confirms the two jump targets: the `JUMPDEST` at
  `0x42` (revert path) and the `JUMPDEST` at `0x46` (the `SSTORE` path taken when
  `caller == SYSTEM_ADDRESS`).
 - **Deviation:** the contract was **not populated at the Pectra ruleset**. It was
  populated, and the consensus write path began running, at the AerePQC milestone
  block **9,189,161** (Besu `futureEipsTime = 1783820272`), the same fork
  documented in AIP-7.
 Therefore, normatively:
 - For `number < 9,189,161`: a call to the history address returns empty, because
  the address was an empty account. EIP-2935 MUST NOT be relied on.
 - For `number >= 9,189,161`: the contract serves the window
  `[number - 8191, number - 1]`. A call passes the 32-byte block number as
  calldata; a query outside the served window reverts.
 At the 500 ms target block period, 8191 blocks is roughly **68 minutes** of
 trustless lookback, against roughly 128 seconds for the 256-block `BLOCKHASH`
 window.
 ## Rationale
 The deviation was not a design choice made in advance; it is the honest
 description of what happened. Pectra parity was configured before the EIP-2935
 write path existed in the Aere Besu fork, so the ruleset listed an EIP whose
 system contract nothing was writing to. When the write path shipped, it was
 bundled into the AerePQC fork rather than given its own activation, because the
 fork was already scheduled and a second coordinated activation would have added
 rollout risk for no benefit (the same bundling rationale as AIP-7).
 **Alternatives rejected.** Silently correcting the compatibility documentation to
 say EIP-2935 was live from Pectra: false. Backfilling the ring buffer at
 activation: impossible without rewriting state, and the fail-empty behavior of an
 unpopulated contract is the safe outcome anyway.
 ## Backwards Compatibility
 This is the whole subject of the AIP. Concretely: a contract deployed before
 block 9,189,161 that called the history address received empty return data, and
 if it treated empty as "hash zero" it computed a wrong answer rather than
 reverting. Any such contract should be re-checked. From block 9,189,161 the same
 call returns real history, so a contract whose behavior depended on the empty
 return changes behavior at that block.
 Note the asymmetry that makes this safe at the consensus layer: the transition is
 from an empty account to a populated one, so no historical block re-executes
 differently on an upgraded binary.
 ## Security Considerations
 The window is 8191 blocks and queries outside it revert. A consumer that assumes
 a longer lookback fails closed, which is correct, but a consumer that assumes any
 lookback before block 9,189,161 silently receives nothing, which is not. That
 asymmetry is the reason this record exists.
 The trustless-lookback guarantee is only as strong as the chain itself: on chain
 2800 that is a seven-validator, single-operator QBFT chain (AIP-9). EIP-2935
 removes a trust assumption on an oracle; it does not remove the trust assumption
 on the validator set.
 ## Reference Implementation and On-Chain Deployment
 Chain ID 2800, activation block 9,189,161, contract
 `0x0000F90827F1C53a10cb7A02335B175320002935`, runtime 83 bytes.
 Verify it yourself against `https://rpc.aere.network`:
 1. `eth_getCode` at the history address returns the canonical 83-byte runtime.
 2. `eth_call` the address with the 32-byte block number of `head - 100` returns
   that block's hash, byte-identical to `eth_getBlockByNumber`. This is the
   stronger check: the ring buffer is not merely populated, it is serving correct
   history.
 Related: AIP-7 (the fork that activated it),
 `aerenew/docs/AERE-EIP-COMPATIBILITY-MATRIX.md` (deviation 7),
 `aerenew/docs/AERE-PROTOCOL-SPECIFICATION.md`.
 ## Errata
 None.
 ## Post-Acceptance Outcome Record
 **2026-07-20.** Both verification paths above were run against the live chain and
 both pass (**measured**). The functional check, returning the correct hash for
 `head - 100`, is recorded as the canonical proof rather than the bytecode check,
 because matching bytes prove deployment while a correct answer proves operation.
 An adjacent claim remains open and is flagged rather than assumed: whether the
 EIP-6110 deposit system contract is populated on mainnet 2800 has **not** been
 checked directly. Given that EIP-2935's contract was listed as active while
 unpopulated, that claim must be measured, not inferred from the ruleset.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-19.md
+++ b/aips/AIP-19.md
@ -0,0 +1,125 @@
 # 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.
--- a/aips/AIP-2.md
+++ b/aips/AIP-2.md
@ -48,7 +48,7 @@ third-party explorer or analyst against the whitepaper.
  anyone, which forwards its native balance to `address(0)` (QBFT Besu permits a
  send to the zero address, after which the value is unreachable). Counters
  `totalBurnedAERE` and `totalSentToZero` make the burn queryable in O(1).
-  Source: `contracts/contracts/AereFeeBurnVault.sol`.
+  Source: `aere-contracts/contracts/AereFeeBurnVault.sol`.
 - **AereCoinbaseSplitter** at `0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec`. The
  routing contract. A validator or its forwarder daemon calls
@ -57,11 +57,11 @@ third-party explorer or analyst against the whitepaper.
  burnBps / 10000`, forwards `burnAmount` to AereFeeBurnVault via its `burn()`
  entrypoint, and returns the remainder to the validator address. It maintains
  lifetime counters `totalBurned` and `totalDistributed` and per-caller
-  attributions. Source: `contracts/contracts/AereCoinbaseSplitter.sol`.
+  attributions. Source: `aere-contracts/contracts/AereCoinbaseSplitter.sol`.
 - **AereCoinbaseSplitterV2** at `0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4`. The
  current canonical splitter. Source:
-  `contracts/contracts/AereCoinbaseSplitterV2.sol`.
+  `aere-contracts/contracts/AereCoinbaseSplitterV2.sol`.
 ### Parameters
@ -116,9 +116,9 @@ reentrancy-guarded, and the burn vault has no withdraw path or admin. The
 ## Reference Implementation and On-Chain Deployment
- `contracts/contracts/AereCoinbaseSplitter.sol` -> `0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec`
+- `aere-contracts/contracts/AereCoinbaseSplitter.sol` -> `0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec`
- `contracts/contracts/AereCoinbaseSplitterV2.sol` -> `0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4`
+- `aere-contracts/contracts/AereCoinbaseSplitterV2.sol` -> `0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4`
- `contracts/contracts/AereFeeBurnVault.sol` -> `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6`
+- `aere-contracts/contracts/AereFeeBurnVault.sol` -> `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6`
 - Related extra-burn bucket: AereSink `0x69581B86A48161b067Ff4E01544780625B231676` (AIP-5)
 All addresses copied verbatim from `sdk-js/src/addresses.ts`. Live cumulative
--- a/aips/AIP-4.md
+++ b/aips/AIP-4.md
@ -14,6 +14,8 @@
 | Status | Final |
 | Created | 2026-07-11 |
 | Requires | None |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
@ -65,12 +67,12 @@ pure Solidity are `view`-only until a native precompile exists (see below).
 Validation vectors used, as repo fixtures:
- Falcon-512: `contracts/test/falcon512_kat0.json` (official NIST KAT).
+- Falcon-512: `aere-contracts/test/falcon512_kat0.json` (official NIST KAT).
- Falcon-1024: `contracts/test/falcon1024_kat0.json` (official round-3 KAT).
+- Falcon-1024: `aere-contracts/test/falcon1024_kat0.json` (official round-3 KAT).
- XMSS: `contracts/test/fixtures/xmss-sha2_10_256-kat.json` (xmss-reference vectors).
+- XMSS: `aere-contracts/test/fixtures/xmss-sha2_10_256-kat.json` (xmss-reference vectors).
- ML-DSA-44: `contracts/test/fixtures/mldsa44-acvp-tg8.json` (NIST ACVP
+- ML-DSA-44: `aere-contracts/test/fixtures/mldsa44-acvp-tg8.json` (NIST ACVP
  ML-DSA-sigVer, 15/15 cases reproduce NIST's expected results).
- SPHINCS+/SLH-DSA: `contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json`
+- SPHINCS+/SLH-DSA: `aere-contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json`
  (NIST ACVP SLH-DSA-sigVer, 14/14 cases reproduce NIST's expected results).
 ### Account-layer primitives (live on chain 2800)
@ -102,6 +104,7 @@ in its stack than AERE does, inside its own state proofs. That prior art, with
 sources and dates, is set out in
 `aere-research/research/pqc-onchain-verification.md`, Section 8.
 ## Rationale
 Pure-Solidity verifiers were built first because they run on the live chain today
@ -188,7 +191,7 @@ Further honest caveats:
 ## Reference Implementation and On-Chain Deployment
-Verifier sources are under `contracts/contracts/` (glob for the PQC, Falcon,
+Verifier sources are under `aere-contracts/contracts/` (glob for the PQC, Falcon,
 XMSS, ML-DSA, and SPHINCS verifiers). All addresses in the tables above are copied
 verbatim from `sdk-js/src/addresses.ts`. Each verifier is live and answerable via
 `eth_call` on `https://rpc.aere.network` (chain ID 2800): official vectors return
@ -199,4 +202,3 @@ under the EIP-7825 cap.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
 </content>
--- a/aips/AIP-5.md
+++ b/aips/AIP-5.md
@ -12,6 +12,8 @@
 | Status | Final |
 | Created | 2026-07-11 |
 | Requires | 2 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
@ -40,7 +42,7 @@ point of trust or a point of failure.
 ### AereSink (immutable three-bucket router)
 Address `0x69581B86A48161b067Ff4E01544780625B231676`. Source
-`contracts/contracts/sink/AereSink.sol`.
+`aere-contracts/contracts/sink/AereSink.sol`.
 Fee-source contracts call `flush(token, amount)` after approving the sink. The
 sink splits the amount into three buckets by immutable basis points that MUST sum
@ -67,7 +69,7 @@ router means redeploying and rewiring fee sources, not mutating this contract.
 ### sAERE (ERC-4626 receipt token)
 Address `0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0`. Source
-`contracts/contracts/staking/sAERE.sol`.
+`aere-contracts/contracts/staking/sAERE.sol`.
 sAERE is a standard ERC-4626 vault: deposit WAERE, receive sAERE shares. The
 WAERE-per-sAERE rate rises as the staker-yield bucket arrives. Two hardening
@ -131,8 +133,8 @@ not change existing contracts. Fee sources opt in by calling `flush`.
 ## Reference Implementation and On-Chain Deployment
- `contracts/contracts/sink/AereSink.sol` -> `0x69581B86A48161b067Ff4E01544780625B231676`
+- `aere-contracts/contracts/sink/AereSink.sol` -> `0x69581B86A48161b067Ff4E01544780625B231676`
- `contracts/contracts/staking/sAERE.sol` -> `0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0`
+- `aere-contracts/contracts/staking/sAERE.sol` -> `0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0`
 - Burn destination: AereFeeBurnVault `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6` (AIP-2)
 - Base token: WAERE `0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8`
 - Deploy script: `contracts/deploy/deploy-saere-sink-stack.js` (splits 1500/4000/4500)
@ -144,4 +146,3 @@ is readable on-chain via `AereSink.BURN_BPS()`, `BUYBACK_BPS()`, and
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
 </content>
--- a/aips/AIP-6.md
+++ b/aips/AIP-6.md
@ -12,6 +12,8 @@
 | Status | Final |
 | Created | 2026-07-11 |
 | Requires | None |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
@ -132,9 +134,9 @@ a paymaster.
 ## Reference Implementation and On-Chain Deployment
-Sources under `contracts/contracts/passkey/` (accounts, factories, MultiOwnable,
+Sources under `aere-contracts/contracts/passkey/` (accounts, factories, MultiOwnable,
-EntryPointV2, WebAuthn, P256Probe) and `contracts/contracts/` plus
+EntryPointV2, WebAuthn, P256Probe) and `aere-contracts/contracts/` plus
-`contracts/contracts/paymaster/` (the paymasters and EntryPoint). Addresses:
+`aere-contracts/contracts/paymaster/` (the paymasters and EntryPoint). Addresses:
 - AereEntryPoint `0x19773ba45287A64B05d0BCBD59D1371BF51Bd5D2`
 - AereEntryPointV2 `0x8D6f40598d552fF0Cb358b6012cF4227B86aF770`
@ -152,4 +154,3 @@ activation (unix 1780220351, block 2,106,597).
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
 </content>
--- a/aips/AIP-8.md
+++ b/aips/AIP-8.md
@ -0,0 +1,390 @@
 # AIP-8: Post-Quantum-Authorized Transaction Envelope (EIP-2718 Type 0x2A)
 > **Note added 2026-08-19.** Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 anchor blocks (every 32nd block, on every one since block 13,889,296) also carry, under the block hash, a certificate of validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md.
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 8 |
 | Title | Post-Quantum-Authorized Transaction Envelope (EIP-2718 Type 0x2A) |
 | Author | Aere Network Foundation |
 | Type | Standards Track |
 | Category | Core |
 | Status | Draft |
 | Created | 2026-07-18 |
 | Requires | 7 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Not ratified; Draft. Ratifier is the founder (pre-decentralization). |
 ## Abstract
 This AIP specifies a new EIP-2718 typed transaction, `TransactionType = 0x2A`, whose
 **sender authorization is a NIST post-quantum signature** (Falcon-512 or ML-DSA-44)
 rather than a secp256k1 ECDSA signature. The transaction carries a scheme selector, a
 raw PQC public key, and a PQC signature; the sender address is derived from the public
 key, and the transaction is valid only if the signature verifies against the exact same
 native precompiles that are already live on AERE mainnet chain 2800 (Falcon-512 `0x0AE1`,
 ML-DSA-44 `0x0AE3`, activated at block 9,189,161 per AIP-7). It makes ordinary value and
 contract-call transactions authorizable by a quantum-resistant key with no smart-account
 indirection. This is a **base-layer execution change requiring a coordinated Besu hard
 fork**; it is NOT yet live. It is explicit that this does not change how AERE blocks are
 proposed, signed, or committed: consensus remains classical secp256k1 ECDSA QBFT and is
 not post-quantum. A deploy-today reference path that needs no fork
 (`AerePQCTxAccount.sol`, an ERC-4337 account) accompanies this AIP.
 ## Motivation
 AERE has live, mainnet-proven post-quantum signature verification at the precompile layer
 (AIP-7) and usable post-quantum authorization at the account layer (AerePQCAccount,
 AereThresholdAccount, AerePQCSocialRecoveryModule). What is still missing is the most
 basic object of all: an ordinary externally-originated transaction whose right to spend an
 account is a post-quantum signature.
 Today every transaction on chain 2800, including one that calls a post-quantum contract,
 is itself authorized by a secp256k1 ECDSA signature. The account's ability to move its
 native balance rests on ECDSA. A cryptographically-relevant quantum computer running
 Shor's algorithm breaks secp256k1: it recovers the private key from the public key, and on
 any account that has ever sent a transaction the public key is already on-chain. Account-
 layer PQC (a 4337 smart account) closes this for smart-contract wallets, but it cannot
 protect a plain externally-owned account (EOA), and it adds a bundler/EntryPoint and a
 deployment step. A base-layer post-quantum transaction type closes the gap for the EOA
 itself: the account is a hash of a PQC public key, and only a PQC signature can spend it.
 The goal is a transaction type that (1) reuses the audited, mainnet-live precompile verify
 paths verbatim (no new cryptography), (2) is a pure function of the transaction bytes for
 validation (like ECDSA sender recovery, so mempool validation reads no state), (3) fits far
 under the Fusaka EIP-7825 per-transaction gas cap, and (4) is a strictly additive,
 client-only hard fork with no re-genesis, exactly like AIP-7.
 ## Specification
 The keywords MUST, SHOULD, and MAY are to be interpreted as in RFC 2119.
 ### Transaction type byte
 The transaction type is `0x2A`.
 EIP-2718 constrains a valid `TransactionType` to the range `[0x00, 0x7f]`: a first byte
 `>= 0xc0` is ambiguous with the RLP list header of a legacy transaction and is excluded,
 and EIP-2718 recommends implementers stay within `0x00`..`0x7f`. Within that range the
 Ethereum L1 assignments are `0x01` (EIP-2930), `0x02` (EIP-1559), `0x03` (EIP-4844), and
 `0x04` (EIP-7702); AERE recognizes all four. `0x2A` is chosen because it is unassigned by
 any Ethereum L1 EIP and sits well below the `0x64`..`0x7f` band that existing L2s have
 informally colonized (Arbitrum `0x64`..`0x6c`, zkSync Era `0x71`+, Optimism deposit
 `0x7e`, Celo `0x7b`..`0x7d`), which minimizes the chance that an imported third-party tool
 misparses an AERE PQ transaction as some other chain's type. `0x2A` is reserved henceforth
 in the AERE chain specification for this purpose. If Ethereum L1 later assigns `0x2A`, AERE
 will re-evaluate to preserve equivalence, as AIP-7 commits to for the precompile band.
 ### Signature-scheme selector
 A one-byte `pq_scheme` selects the NIST scheme and the precompile that validates it. The
 values match AIP-7 and AerePQCAttestation:
 | `pq_scheme` | Scheme | Precompile | Public-key length | Signature envelope |
 | --- | --- | --- | --- | --- |
 | `0x01` | Falcon-512 | `0x0AE1` | 897 bytes (header `0x09`) | `nonce(40) || esig` (esig starts `0x29`) |
 | `0x03` | ML-DSA-44 | `0x0AE3` | 1312 bytes | `sig`, exactly 2420 bytes |
 `pq_scheme` `0x02` (Falcon-1024, `0x0AE2`, 1793-byte pk) and `0x04` (SLH-DSA-128s, `0x0AE4`,
 32-byte pk, 7856-byte sig) MAY be enabled by the same rules; they are omitted from the
 mandatory set because Falcon-512 (NIST level 1, smallest signature) and ML-DSA-44 (FIPS 204,
 fixed-size, conservative) span the practical trade-off between signature size and margin.
 Any other value MUST be rejected as an invalid transaction.
 ### RLP wire format
 A type-`0x2A` transaction is the concatenation of the type byte and the RLP encoding of a
 12-element list:
 ```
 0x2A || rlp([
    chain_id,                 # scalar; MUST equal 2800 for AERE mainnet
    nonce,                    # scalar; the PQC-derived sender's account nonce
    max_priority_fee_per_gas, # scalar (EIP-1559 semantics)
    max_fee_per_gas,          # scalar (EIP-1559 semantics)
    gas_limit,                # scalar
    to,                       # 20-byte address, or empty (0x) for contract creation
    value,                    # scalar
    data,                     # byte string
    access_list,              # EIP-2930 [[address, [storageKey, ...]], ...]
    pq_scheme,                # single byte, 0x01 or 0x03 (see selector table)
    pq_public_key,            # raw NIST public key for pq_scheme
    pq_signature              # signature envelope for pq_scheme (see selector table)
 ])
 ```
 The fee, gas, `to`, `value`, `data`, and `access_list` fields are identical in meaning to
 EIP-1559 (type `0x02`) with an EIP-2930 access list, so existing execution and fee-market
 logic is unchanged. The three trailing fields replace the ECDSA `(y_parity, r, s)` triple.
 The transaction hash is `keccak256(0x2A || rlp([...all 12 fields...]))`, as for any typed
 transaction.
 ### Sender derivation
 The sender is derived from the PQC public key and the scheme, not from signature recovery:
 ```
 sender = keccak256(pq_scheme || pq_public_key)[12:32]   # last 20 bytes
 ```
 Binding the address to `pq_scheme` as well as the key means the same raw key bytes under a
 different scheme selector yield a different account, so there is no cross-scheme aliasing. A
 user migrates to post-quantum custody by moving assets to their `sender` address; from then
 on only a valid PQC signature can spend it. Unlike ECDSA, the public key is transmitted in
 full on every transaction (the verify precompiles are stateless), which is safe: Falcon and
 ML-DSA remain secure with the public key exposed. This is the point of the design, not a
 weakness.
 ### Signing message and verification
 `pq_signature` MUST be a valid signature, under `pq_public_key` and `pq_scheme`, over the
 32-byte digest:
 ```
 sig_hash = keccak256(0x2A || rlp([
    chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,
    to, value, data, access_list, pq_scheme, pq_public_key
 ]))                                     # the 12-field list WITHOUT pq_signature
 ```
 Validation MUST assemble the precompile input for `pq_scheme` exactly as
 AerePQCAttestation / AerePQCKeyRegistry do, with `sig_hash` as the signed message, and
 accept the transaction only if the corresponding precompile returns the 32-byte
 "valid" word `0x…01`:
 - Falcon-512: `input = pk(897) || sm`, where `sm = sigLen(2, big-endian) || nonce(40) ||
  sig_hash(32) || esig` and `sigLen == esig.length`; call `0x0AE1`.
 - ML-DSA-44: `input = pk(1312) || sig(2420) || sig_hash(32)`; call `0x0AE3`.
 The client MUST use the same Bouncy Castle 1.83 verify path the precompile wraps, so
 that transaction validation and an in-EVM `STATICCALL` to the precompile agree bit-for-bit
 on every `(pq_public_key, sig_hash, pq_signature)` triple. A transaction whose signature
 does not verify has no valid sender and is invalid: it MUST be rejected from the mempool and
 MUST NOT be included in a block, exactly as an ECDSA transaction with an unrecoverable
 signature is.
 ### Nonce and replay handling
 - **Cross-chain replay** is prevented by `chain_id` inside both the transaction and
  `sig_hash`: a signature for chain 2800 does not verify for any other chain id.
 - **Intra-chain replay and ordering** are enforced by `nonce`, the account nonce of the
  PQC-derived `sender`, tracked in world state and incremented on inclusion, identical to an
  ECDSA account. A given `(sender, nonce)` can be mined at most once.
 - **Cross-protocol replay** (reusing a PQ tx signature as an AerePQCAttestation,
  AerePQCKeyRegistry, or ERC-4337 authorization, or vice-versa) is prevented because those
  surfaces sign structurally different messages: attestation/registry/account challenges are
  `keccak256(abi.encode(DOMAIN, ...))` or `abi.encodePacked(domain, hash)` byte strings that
  can never equal the `0x2A || rlp(...)` preimage of `sig_hash`. The leading type byte `0x2A`
  in the signed preimage is the domain tag for this transaction type, mirroring how EIP-1559
  signs `keccak256(0x02 || rlp(...))`.
 ### Gas accounting
 Intrinsic gas for a type-`0x2A` transaction is:
 ```
 intrinsic = 21000
          + calldata_gas(entire type-0x2A payload, including pq_public_key + pq_signature)
          + access_list_gas          # EIP-2930: 2400 per address, 1900 per storage key
          + PQ_VERIFY_GAS[pq_scheme]  # fork constant, MUST equal the live precompile verify gas
 ```
 `PQ_VERIFY_GAS` MUST equal the marginal verify-op gas the corresponding precompile charges,
 which AIP-7 measured on the pre-activation scratch fork (chain 28099) and carried to
 mainnet:
 | Scheme | `PQ_VERIFY_GAS` (measured, AIP-7) |
 | --- | --- |
 | Falcon-512 (`0x0AE1`) | 40,000 |
 | ML-DSA-44 (`0x0AE3`) | 55,000 |
 | Falcon-1024 (`0x0AE2`) | 75,000 |
 | SLH-DSA-128s (`0x0AE4`) | 350,000 |
 The dominant *additional* cost versus an EIP-1559 transaction is the calldata for the public
 key and signature. Approximate PQ-material sizes and the resulting calldata component (to be
 measured on the scratch fork; calldata is priced at EIP-2028 rates, subject to the EIP-7623
 floor):
 | Scheme | pk bytes | sig-envelope bytes | PQ material | approx. calldata gas |
 | --- | --- | --- | --- | --- |
 | Falcon-512 | 897 | ~707 (40 + 1 + ~666) | ~1,605 B | ~24,000 (to be measured) |
 | ML-DSA-44 | 1,312 | 2,420 | ~3,732 B | ~56,000 (to be measured) |
 A complete Falcon-512 PQ transaction therefore lands near `21,000 + ~24,000 + 40,000 ≈
 85,000` gas of intrinsic cost before execution, consistent with AIP-7's measured
 end-to-end Falcon-512 verify-and-record transaction of 86,336 gas; a ML-DSA-44 PQ
 transaction lands near `21,000 + ~56,000 + 55,000 ≈ 132,000`. Both are a tiny fraction of
 the EIP-7825 per-transaction cap of 16,777,216 (2^24), leaving the full block-execution
 budget for the call itself.
 `PQ_VERIFY_GAS` is folded into intrinsic gas so the sender pays for the verification work
 that validators perform. Because signature validity is a precondition of transaction
 validity, a transaction with an invalid signature is never included and thus is never
 charged on-chain, exactly as with a bad ECDSA signature; it simply cannot be mined.
 ### Base-layer activation sketch (Besu fork)
 The change is a strictly additive execution-layer fork of the AERE Besu build (base
 `hyperledger/besu:26.4.0`, the same tree that carries the AIP-7 precompiles). No re-genesis,
 no state migration. The implementation touches, at minimum:
 1. **TransactionType.** Add `PQ_AUTHORIZED((byte) 0x2A)` to
   `org.hyperledger.besu.datatypes.TransactionType`.
 2. **Codec.** Add a `PQAuthorizedTransactionDecoder` / `PQAuthorizedTransactionEncoder`
   implementing the 12-field RLP layout above and register them in the `TransactionDecoder` /
   `TransactionEncoder` dispatch. Extend the `Transaction` model to carry `pqScheme`,
   `pqPublicKey`, and `pqSignature`, and override sender computation for this type to
   `keccak256(pqScheme || pqPublicKey)[12:]`, defined only when the PQC signature verifies.
 3. **PQ signature verifier.** A `PQAuthorizedSignatureVerifier` that calls the exact same
   Bouncy Castle 1.83 BCPQC verify path (`AereFalconSupport.verify`, ML-DSA `verifyInternal`)
   the `0x0AE1` / `0x0AE3` precompiles wrap. Zero new cryptography; reuse the precompile
   adapters through the same classloader-isolation boundary AIP-7 established.
 4. **Validation.** In `MainnetTransactionValidator` (via `TransactionValidatorFactory`), for
   type `0x2A`: reconstruct `sig_hash`, verify the PQC signature (reject with an INVALID
   reason on failure), derive the sender, and validate nonce, balance, and intrinsic gas as
   usual.
 5. **Gas.** Extend the `GasCalculator` with `pqAuthorizationIntrinsicGasCost(scheme, payload)`
   returning the calldata component plus `PQ_VERIFY_GAS[scheme]`, wired into
   `transactionIntrinsicGasCost`.
 6. **Mempool and wire.** Teach `TransactionPool` and the eth/68 `Transactions` /
   `PooledTransactions` codecs to carry the larger typed body; expose the type in the JSON-RPC
   transaction serialization (`eth_getTransactionByHash`, receipts).
 7. **Fork gating.** Add an `AerePQTx` milestone to `ProtocolScheduleBuilder` / the chain spec,
   activated at a future block or timestamp distinct from the AIP-7 precompile activation.
   Before activation, a `0x2A` first byte is an unknown type and is rejected; after
   activation it is valid. Because chain 2800 runs seven QBFT validators under one operator on
   one client, activation is a flag-day client upgrade across the validator set, exactly as in
   AIP-7. A non-upgraded validator would reject the type and fork off, so the upgrade is
   mandatory at the fork block.
 8. **Differential testing.** Gate ship on a test that, for the NIST KAT vectors in
   `pqc-fork/kat` and randomized cases, asserts the transaction-validation verify agrees
   bit-for-bit with a `STATICCALL` to the matching precompile over the same
   `(pk, sig_hash, sig)`, plus round-trip encode/decode and a full mine-and-receipt path on an
   isolated testnet.
 Consensus is untouched: QBFT proposal, the committed-seal ECDSA signatures, and block
 structure are unchanged; type `0x2A` is simply another transaction a block may contain, with
 its own receipt type.
 ## Rationale
 **Full public key in every transaction, not a registry keyId.** An alternative shrinks
 calldata by replacing `pq_public_key` with a `keyId` into AerePQCKeyRegistry
 (`0x1eCa…3691`). It is rejected for the base type because it makes transaction validation
 depend on world state (a registry lookup), which breaks the property that a transaction's
 validity is a pure function of its own bytes, the same property ECDSA sender recovery has,
 and which mempool validation relies on. The stateless full-key form keeps validation pure
 and matches how the live precompiles already work. A registry-indexed companion type could be
 specified later once the state-dependency implications for the mempool are worked through.
 **Sender = hash of (scheme, key), reusing the 20-byte address space.** This keeps the PQ
 account indistinguishable from any other address to every downstream contract, tool, and
 explorer: balances, `CALL`, `msg.sender`, and logs all behave normally. The only thing that
 changes is who may originate a transaction from that address.
 **Type `0x2A` over a higher value.** Staying in the low half of the valid range and away
 from the L2-colonized `0x64`..`0x7f` band reduces cross-ecosystem tool confusion, at no cost.
 **A base-layer type at all, given 4337 exists.** ERC-4337 already gives post-quantum
 authorization for smart-contract wallets and is the recommended path today (see the reference
 implementation). But a 4337 account cannot protect a plain EOA, requires a deployed contract
 and a bundler, and pays EVM-execution overhead for validation. The base type is the only way
 to make an *ordinary* account post-quantum, and it prices verification at the native
 precompile cost rather than in-EVM. The trade-off is that it requires a hard fork and touches
 the entire transaction-decoding surface of the ecosystem, which is exactly why it is filed as
 a Draft with a shipping 4337 alternative rather than activated immediately.
 ## Backwards Compatibility
 Additive. Existing legacy, `0x01`, `0x02`, `0x03`, and `0x04` transactions are unaffected.
 Before the `AerePQTx` fork block, a `0x2A` transaction is an unknown type and is rejected by
 all nodes; after it, all nodes accept it. There is no change to existing accounts, contracts,
 receipts of other types, or the genesis state root.
 Ecosystem tooling that decodes raw transactions (wallets, explorers, indexers, the RPC
 transaction serializer, hardware-wallet firmware, signing libraries) MUST learn type `0x2A`
 to build, sign, display, or index these transactions. Tools that only handle types they
 recognize will treat a `0x2A` transaction as opaque or unsupported rather than misdecode it,
 because the type byte is self-describing. This ecosystem surface is the principal cost of the
 change and the reason the ERC-4337 path is preferred for immediate use.
 Because AERE runs all validators under one operator and one client, activation is a
 mandatory flag-day client upgrade across the validator set at the fork block, as in AIP-7. A
 validator that had not upgraded would reject the type and fork.
 ## Security Considerations
 **This change does not make AERE consensus post-quantum.** Validators continue to sign
 classical secp256k1 QBFT committed seals; blocks are proposed and committed exactly as today.
 Type `0x2A` makes an individual transaction's *sender authorization* post-quantum. It does
 not make block production, finality, or the validator set post-quantum, and any claim to that
 effect on the basis of this AIP would be false and must not be made.
 **A valid signature is not authorization beyond spend rights.** A "valid" precompile decision
 establishes only that `pq_signature` is a valid signature by `pq_public_key` over `sig_hash`.
 Freshness and ordering come from `nonce`; scope comes from the tx fields themselves. There is
 no key rotation or recovery at this layer: losing the PQC private key loses the account, the
 same as losing an ECDSA key. Users who need rotation or social recovery should hold assets in
 an ERC-7579 account guarded by AerePQCSocialRecoveryModule instead of, or in addition to, a
 PQ EOA.
 **Single operator, one client (no client-diversity safety net).** Chain 2800's seven QBFT
 validators are one operator on one execution client. A consensus bug in the PQ-transaction
 validation path (for example a decoder edge case, or a divergence between the tx-validation
 verify and the precompile verify) would not be caught by a second live client, because there
 is none. This raises the bar for external audit and for the mandatory bit-for-bit
 differential testing in the activation sketch.
 **Determinism.** Transaction validation, like a precompile, must be deterministic and read no
 node-local state or block context beyond the transaction and the account nonce/balance.
 Falcon verification MUST use the integer-only verify path (never the floating-point signing
 path). Malformed structure MUST be rejected deterministically as an invalid transaction, not
 faulted.
 **Public-key exposure is intended.** The public key is on-chain from the account's first
 transaction. This is safe for Falcon and ML-DSA and is the mechanism by which the account is
 quantum-resistant; it is called out only to preempt the ECDSA-era intuition that an unspent
 address "hides" its key.
 **Not live; external audit pending.** This is a Draft specification and a reference-
 implementation sketch. Nothing here is deployed on chain 2800. The precompiles it reuses
 carry an internal self-audit only (AIP-7). This transaction type MUST NOT secure material
 value until it is implemented, differentially tested against the live precompiles, and
 covered by an external security audit.
 ## Reference Implementation and On-Chain Deployment
 **Not yet live.** The base-layer fork above is a specification and a Besu implementation
 sketch, not a deployed change.
 **Deploy-today reference path (no fork required).** The same user-visible guarantee, "a
 transaction is authorized by a post-quantum signature and nothing else", is delivered today,
 with no base-layer change, by an ERC-4337 v0.7 smart account whose sole owner is a NIST PQC
 key and whose `validateUserOp` verifies via the live precompiles:
 - Contract: `aere-contracts/contracts/pqc/AerePQCTxAccount.sol` (this repository).
 - Tests: `aere-contracts/test/AerePQCTxAccount.test.js` (MockPQCPrecompile across all four schemes
  plus a genuine Falcon-512 path through the NIST-KAT-proven AereFalcon512Verifier).
 - **Verified 2026-07-18:** compiled and tested under the canonical Hardhat toolchain,
  `npx hardhat compile` then `npx hardhat test test/AerePQCTxAccount.test.js`. The contract
  compiles clean and all 20 tests pass: the mock verifier across all four schemes, the
  domain-separation and single-use replay checks, and two genuine Falcon-512 paths through the
  NIST-KAT-proven verifier. This bullet records an actual machine run; it should be read as a
  verified result, not an untested present-tense assertion.
 - It calls the live precompiles (`0x0AE1`..`0x0AE4`) directly with the identical wire
  encoding proven on mainnet by AerePQCAttestation
  (`0x465d9E3b476BF98Aa1393079e240Db5D2a9bEA6A`) and AerePQCKeyRegistry
  (`0x1eCa3c5ADcBD0b22636D8672b00faC6D89363691`), and targets AereEntryPointV2
  (`0x8D6f40598d552fF0Cb358b6012cF4227B86aF770`). Addresses are copied verbatim from
  `sdk-js/src/addresses.ts`.
 The precompile band, its activation block (9,189,161), and the wire encoding are verifiable
 on `https://rpc.aere.network` (chain id 2800) as documented in AIP-7.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/AIP-9.md
+++ b/aips/AIP-9.md
@ -0,0 +1,102 @@
 # AIP-9: Consensus Mechanism: QBFT, not HotStuff
 ## Preamble
 | Field | Value |
 | --- | --- |
 | AIP | 9 |
 | Title | Consensus Mechanism: QBFT, not HotStuff |
 | Author | Aere Network Foundation |
 | Type | Informational |
 | Category | (none) |
 | Status | Final |
 | Created | 2026-07-19 |
 | Requires | 3 |
 | Supersedes | None |
 | Superseded-By | None |
 | Ratification | Foundation-ratified (pre-decentralization) |
 ## Abstract
 This AIP records the decision to run QBFT as Aere's consensus protocol rather
 than HotStuff or a pipelined HotStuff variant. It backfills a decision that is
 already live on chain 2800. It is a decision record: it explains why a shipped
 choice was made and mandates nothing new.
 ## Motivation
 Aere is a settlement layer whose core promise is deterministic, single-slot
 finality at a sub-second cadence, running a small permissioned validator set:
 seven validators today, with a roadmap target in the 9 to 21 range. The consensus
 choice determines whether that promise is deliverable at all, and it was taken
 without being written down anywhere citable.
 ## Specification
 Aere runs QBFT, the Byzantine-fault-tolerant IBFT-family protocol as implemented
 in Hyperledger Besu, producing deterministic single-block finality.
 - Validator count N = 7 (**measured**, all Foundation-operated).
 - Fault tolerance f = 2, commit quorum 2f + 1 = 5-of-7 (**spec**).
 - Target block period 500 ms (**spec**, see AIP-3); measured mean interval
  516.4 ms.
 - Validator seals are classical secp256k1 ECDSA. **Consensus is not
  post-quantum** and no part of this record implies otherwise.
 ## Rationale
 At Aere's validator-set size, QBFT's O(N^2) message complexity is negligible in
 absolute terms: a 5-of-7 quorum verify costs on the order of a few milliseconds
 per block, a small fraction of the 500 ms slot. Against that non-cost, QBFT gives
 three concrete advantages. It provides deterministic instant single-block
 finality, which is the exact settlement guarantee the network sells. It is mature
 and already integrated in Besu, so there is no new-protocol implementation risk.
 And Aere's post-quantum consensus research, second-client work, and zk finality
 proofs are all built against QBFT, so changing it would invalidate that work.
 **Alternatives rejected.** HotStuff and its pipelined variants, whose linear
 per-round communication complexity is engineered to scale BFT to hundreds of
 validators. That scaling regime is one Aere does not operate in and does not plan
 to enter under this design, so HotStuff's headline benefit is unavailable, while
 adopting it would add the risk and integration cost of a protocol less
 battle-tested in the chosen client.
 ## Backwards Compatibility
 None. This records the existing protocol.
 ## Security Considerations
 At N = 7 the fault tolerance against node outages is real, but **all seven
 validators are Foundation-operated**, so the effective Nakamoto coefficient is 1.
 Decentralization, not the consensus mechanism, is the binding trust assumption on
 this chain. A reader should not read "Byzantine fault tolerant" as "trustless".
 Consensus seals are secp256k1 ECDSA and are therefore classically breakable by a
 cryptographically relevant quantum computer. Work on a hybrid post-quantum
 consensus path is recorded in AIP-15 and is **not live**.
 ## Reference Implementation and On-Chain Deployment
 Chain ID 2800. Configuration lives in the Besu QBFT genesis and chain config; the
 block period transition is documented in AIP-3. There is no contract address for
 a consensus choice.
 ## Errata
 **Erratum 1 (2026-09-12).** Every validator count in this document is a
 measurement of 2026-07-19, the day it was written, and none of them carries that
 date in its own sentence, so a sentence quoted on its own reads as a claim about
 today. Read them as dated: "seven validators today" in the Motivation,
 "Validator count N = 7 (**measured**)" and "commit quorum 2f + 1 = 5-of-7" in the
 Specification, and "At N = 7 ... all seven validators are Foundation-operated" in
 the Security Considerations were all true on 2026-07-19. Measured 2026-09-12 on
 the live chain: N = 10, f = 3, commit quorum 7-of-10, and one of the ten runs a
 different client implementation. The decision this AIP records, QBFT rather than
 HotStuff, is unaffected, and so is the Nakamoto argument in the Security
 Considerations: the set grew, the operator count did not. The original text is
 left exactly as published, per AIP-1 section 5.
 ## Copyright
 Released to the public domain (CC0). No rights reserved.
--- a/aips/CONTRIBUTING.md
+++ b/aips/CONTRIBUTING.md
@ -0,0 +1,130 @@
 # Proposing a change to Aere Network
 This document is for someone who is not part of the Aere Foundation and wants to
 change how Aere Network works. It tells you what to do, what happens next, and
 who decides. The last of those three is the one most projects are vague about, so
 it is answered first.
 ## Who decides
 **The founder decides.** Today, ratification of an AIP is one person's decision,
 exercised through the Aere Foundation account
 `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`. That account is a single key. It is
 not a multisig, it is not a timelock, and there is no on-chain vote that binds it.
 There is a governance stack deployed on chain 2800 (a Governor, a Timelock, and a
 governance token). **It controls nothing.** No production contract on chain 2800
 is owned by a timelock, and the governance contracts hold no authority over the
 protocol. They exist as deployed, inert infrastructure for a future in which they
 do. Do not read their existence as a claim that Aere has on-chain governance.
 The network runs seven QBFT validators, all operated by the Foundation, on one
 live client, with no external security audit. The effective Nakamoto coefficient
 is 1.
 This is worth stating plainly rather than implying a governance that does not
 exist. If you are deciding whether to invest engineering effort in an Aere
 proposal, that paragraph is the fact you need, and finding it out later would be
 worse for you and for us.
 **What this means in practice for you:**
 - A good technical argument can win. There is no stake threshold, no token
  requirement, no membership, and no fee. Your proposal is judged on whether it
  is correct and worth doing.
 - There is no appeal. If the founder declines your proposal, that is the end of
  it inside this process. Aere's proposals are CC0, so forking the record and
  implementing your version elsewhere is always available to you, and nobody here
  will treat that as hostile.
 - A rejection will be written down. If your AIP is rejected, it keeps its number,
  moves to Withdrawn, and stays in the repository with the reason recorded. We do
  not delete proposals we disagreed with.
 ## What we will not do
 Two commitments, so you know what you are relying on:
 1. **We will not renumber or reuse your number.** Once your proposal is assigned
   AIP-N it is AIP-N permanently, including if it is withdrawn (AIP-1 section 2).
 2. **We will not silently edit your proposal after it is accepted.** A Final AIP
   is frozen. Corrections are appended as dated errata that leave the original
   text visible (AIP-1 section 5).
 ## How to propose
 ### Step 0: check it belongs in an AIP
 **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; a process or governance change.
 **Out of scope:** bug-fix redeploys that preserve an existing interface, routine
 parameter tuning inside an already-ratified bound, and pure documentation. A
 security vulnerability is **not** an AIP: do not publish it. Report it privately
 first.
 If you are unsure, propose it anyway. The editor will tell you.
 ### Step 1: write it
 Copy `aip-template.md`. Fill in every section. Do not delete a header; write
 "None" if a section does not apply, because "Security Considerations: None" is a
 claim a reviewer can challenge and a missing section is not.
 The rules that get proposals bounced fastest:
 - **Cite addresses verbatim** from `sdk-js/src/addresses.ts`. Do not retype them.
 - **Label every number** as **measured** (reproducible from the chain or a repo
  fixture), **spec** (a configured or standardized value), or **estimate**.
 - **Write "to be measured"** rather than guessing. A guessed gas figure is worse
  than an absent one, because the reader cannot tell it is a guess.
 - **Do not claim post-quantum consensus.** Aere consensus is classical secp256k1
  ECDSA QBFT. Aere's post-quantum work is at the signature, account and
  application layers. A proposal that blurs this will be sent back.
 ### Step 2: submit it
 Open a pull request against `aere-research/aips/` adding `AIP-N.md`, where N is the
 next free integer, plus a row in `README.md`. If you cannot open a pull request,
 send the document by any route that reaches the Foundation; the format matters,
 the transport does not.
 ### Step 3: what happens next
 | Stage | What happens | Who | Typical time |
 | --- | --- | --- | --- |
 | Well-formedness check | The editor checks the template is complete, the number is right, and every cited address, hash and number is real. This is not a merit review. | Editor (the Foundation today) | days |
 | **Draft** | Your number is assigned. You own the document and can keep changing it. | You | as long as you want |
 | **Review** | You declare it ready for scrutiny. Open questions are tracked inside the document itself, not in a side channel. | You, plus anyone who comments | open-ended |
 | **Last Call** | A final review window, 14 days by default, with the end date written into the document. | Editor | 14 days |
 | **Final** | Ratified. Frozen under AIP-1 section 5. | Founder | one decision |
 You can stop at any point by withdrawing. The editor moves a proposal to Stagnant
 after six months of inactivity in Draft or Review; anyone, including you later,
 can revive it.
 ### Step 4: honestly, about "review"
 Aere has **no external technical community commenting on AIPs yet**. This is not
 a modesty statement, it is the current state: decentralization is thin and
 external usage is thin. If you file a proposal today, the review you get is from
 the Foundation, and it may be the only review you get.
 We record that rather than inventing the alternative. There are no fabricated
 comment threads in this repository, no invented "the community debated", and no
 imagined participants. When real external comment arrives it will be recorded as
 it happened. Until then, do not expect a crowd, and do not mistake an empty
 comment section for consensus.
 ## Reporting a vulnerability instead
 If you found a security bug, this is the wrong document. Do not file an AIP, do
 not open a public pull request, and do not include the vulnerability in any
 public issue. Report it privately to the Foundation first. Publishing a live
 vulnerability against a chain with a single operator and no external audit
 endangers users who have no way to react.
 ## Copyright
 Everything you submit here is CC0, released to the public domain. If that is not
 acceptable to you, do not submit it.