aere-network/aere-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Aere Network 2026-09-12 09:49:12 +03:00
parent 83453d9a79
commit ec3ca3368f
18 changed files with 1749 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
CITATIONS-UNRESOLVED.md
View File

@ -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

86
aips/AIP-10.md Normal file
View File

@ -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.

86
aips/AIP-11.md Normal file
View File

@ -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.

88
aips/AIP-12.md Normal file
View File

@ -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.

90
aips/AIP-13.md Normal file
View File

@ -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.

82
aips/AIP-14.md Normal file
View File

@ -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.

114
aips/AIP-15.md Normal file
View File

@ -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.

110
aips/AIP-16.md Normal file
View File

@ -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.

161
aips/AIP-17.md Normal file
View File

@ -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.

147
aips/AIP-18.md Normal file
View File

@ -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.

125
aips/AIP-19.md Normal file
View File

@ -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.

12
aips/AIP-2.md
View File

@ -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`
- `contracts/contracts/AereCoinbaseSplitterV2.sol` -> `0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4`
- `contracts/contracts/AereFeeBurnVault.sol` -> `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6`
- `aere-contracts/contracts/AereCoinbaseSplitter.sol` -> `0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec`
- `aere-contracts/contracts/AereCoinbaseSplitterV2.sol` -> `0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4`
- `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

16
aips/AIP-4.md
View File

@ -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-1024: `contracts/test/falcon1024_kat0.json` (official round-3 KAT).
- XMSS: `contracts/test/fixtures/xmss-sha2_10_256-kat.json` (xmss-reference vectors).
- ML-DSA-44: `contracts/test/fixtures/mldsa44-acvp-tg8.json` (NIST ACVP
- Falcon-512: `aere-contracts/test/falcon512_kat0.json` (official NIST KAT).
- Falcon-1024: `aere-contracts/test/falcon1024_kat0.json` (official round-3 KAT).
- XMSS: `aere-contracts/test/fixtures/xmss-sha2_10_256-kat.json` (xmss-reference vectors).
- 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>

11
aips/AIP-5.md
View File

@ -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`
- `contracts/contracts/staking/sAERE.sol` -> `0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0`
- `aere-contracts/contracts/sink/AereSink.sol` -> `0x69581B86A48161b067Ff4E01544780625B231676`
- `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>

9
aips/AIP-6.md
View File

@ -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,
EntryPointV2, WebAuthn, P256Probe) and `contracts/contracts/` plus
`contracts/contracts/paymaster/` (the paymasters and EntryPoint). Addresses:
Sources under `aere-contracts/contracts/passkey/` (accounts, factories, MultiOwnable,
EntryPointV2, WebAuthn, P256Probe) and `aere-contracts/contracts/` plus
`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>

390
aips/AIP-8.md Normal file
View File

@ -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.

102
aips/AIP-9.md Normal file
View File

@ -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.

130
aips/CONTRIBUTING.md Normal file
View File

@ -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.