From 83453d9a79d1f8c87283003f88ccbc88d378d65f Mon Sep 17 00:00:00 2001 From: Aere Network Date: Fri, 11 Sep 2026 22:04:15 +0300 Subject: [PATCH] AIP-1, AIP-2, AIP-7, the template and the index brought to the working generation: the published governance text was missing entire sections, including the rules themselves (D-377) --- aips/AIP-1.md | 341 ++++++++++++++++++++++++++++++------------- aips/AIP-2.md | 61 +++++--- aips/AIP-7.md | 50 ++++++- aips/README.md | 211 +++++++++++++------------- aips/aip-template.md | 31 +++- 5 files changed, 461 insertions(+), 233 deletions(-) diff --git a/aips/AIP-1.md b/aips/AIP-1.md index f6e9dc7..1409acc 100644 --- a/aips/AIP-1.md +++ b/aips/AIP-1.md @@ -6,157 +6,298 @@ | --- | --- | | AIP | 1 | | Title | AIP Purpose and Process | -| Author | AERE Foundation | +| Author | Aere Network Foundation | | Type | Meta | | Category | (none) | | Status | Living | | Created | 2026-07-11 | +| Last substantive revision | 2026-07-20 (revision 2, recorded in AIP-19) | | Requires | None | +| Superseded-By | None | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract -This AIP defines the AERE Improvement Proposal process: what an AIP is, the -statuses it moves through, the categories it can carry, the required sections, -and who ratifies it. It is a Living document because the process will change as -the network decentralizes. +This AIP defines the Aere Improvement Proposal process: what an AIP is, the +statuses it moves through and the transitions permitted between them, how numbers +are assigned and retired, how a later proposal supersedes an earlier one, the +required document template, and the rule that an accepted proposal is not +silently edited. It is a Living document because the process will change as the +network decentralizes. ## Motivation -AERE ships changes to a live chain (chain ID 2800) and to a growing set of +Aere ships changes to a live chain (chain ID 2800) and to a growing set of contracts. Without a single canonical record of why each change was made, that history lives only in commit messages, in the SDK address registry, and in the -memory of the people who shipped it. An AIP process fixes that. It gives every -change a stable, plain-text home that states the motivation, the exact mechanism, -the on-chain proof, and the honest limitations. It lets an outside auditor, -integrator, or automated agent reconstruct the design of the chain without asking -anyone. +memory of the people who shipped it. -It also forces discipline. Writing the Specification and Security Considerations -sections before (or, for retro-filed AIPs, immediately after) shipping surfaces -weak assumptions early. +There is a second motivation, established by looking at what actually survives in +this industry. Formal specifications tend to die: Polkadot funded a dedicated +specification with a committee and marked it unmaintained on 2 October 2024; +the Ethereum Yellow Paper states on its face that it stops at Shanghai (April +2023); Bitcoin never produced one at all. In each case the numbered proposal +process is what absorbed the work and kept running. A proposal series survives +because each document is small, dated, owned by one author, and finished, so it +never needs a maintainer to keep it true. A monolithic specification needs a +maintainer forever and eventually does not get one. + +Aere therefore puts its documentation weight on this numbered series rather than +on a single living specification document. ## Specification -### Roles +### 1. What an AIP is -- **Author.** Anyone may author an AIP. The author writes the document, drives it - through the statuses, and answers review questions. -- **Editor.** The editor checks that an AIP is well-formed, correctly numbered, - correctly categorized, and technically coherent, and that every cited address, - transaction, and number is real. The editor does not judge whether a proposal - is a good idea; that is the ratifier's job. Until decentralization the editor - role is held by the AERE Foundation. -- **Ratifier.** The party whose approval moves an AIP to Final. Until - decentralization this is the Foundation account - `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3` (a single-key, - Foundation-controlled account, not a deployed multisig). See the governance note - below. +An AIP is a design document describing a change to Aere Network (chain ID 2800), +its contracts, its consensus parameters, or its processes. It records the +motivation, the exact mechanism, the rationale, and, when the change is already +live, the on-chain addresses and transactions that prove it exists. -### Statuses +**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 (ARC); a process or governance change +(Meta). -The normative lifecycle is `Draft -> Review -> Last Call -> Final`. `Living` -replaces `Final` for standards that keep evolving. `Withdrawn` and `Stagnant` are -the off-ramps. +**Out of scope:** bug-fix redeploys that preserve an existing interface (tracked +in the SDK address registry's deprecation notes), routine parameter tuning inside +an already-ratified bound, and pure documentation. -- **Draft.** Well-formed, has an author, may change substantially. -- **Review.** Author has requested wider scrutiny; open questions are tracked in - the AIP. -- **Last Call.** A stated final-review window (default 14 days). If no blocking - issue is raised, it advances to Final or Living. -- **Final.** Accepted. For shipped work, live on chain 2800. Breaking changes - after Final require a new AIP that supersedes this one. -- **Living.** Accepted and expected to keep being updated. -- **Withdrawn.** Abandoned. Terminal, but the number is retired, not reused. -- **Stagnant.** Inactive in Draft or Review beyond 6 months. Revivable by any - author. +### 2. Numbering (MUST) -Retro-filed AIPs enter at Final or Living and state in their Abstract that they -document a change that already shipped. +- Numbers are assigned sequentially from 1 by the editor, as integers, with no + gaps and no sub-numbers. +- **A number is never reused.** Once assigned it belongs to that proposal + permanently, including if the proposal is Withdrawn, Stagnant, or superseded. A + withdrawn AIP-N stays AIP-N and its file stays in the repository. +- A number is assigned when the document is first accepted as well-formed by the + editor (that is, at entry to Draft), not when it is ratified. Assigning at + ratification would leave dangling references in review discussion. +- References to an AIP are by number, not by title or path. Titles may be + corrected; numbers may not. -### Categories and types +*Precedent: IETF RFCs (RFC 2026), where a published number is permanent and is +never recycled even after the document is obsoleted; and PEP 1 and EIP-1, which +both assign a number at entry rather than at acceptance.* -Types are Standards Track, Meta, and Informational. A Standards Track AIP MUST -name exactly one category: +### 3. Status values and permitted transitions (MUST) -- **Core**: consensus, block production, fee and burn accounting, precompiles, +| Status | Meaning | +| --- | --- | +| Draft | Well-formed, has a named author, may still change substantially. | +| Review | The author has requested wider scrutiny. Open questions are tracked inside the document. | +| Last Call | A stated final-review window, default 14 days, with an end date written into the document. | +| Final | Accepted. For shipped work, live on chain 2800. Immutable under section 5. | +| Living | Accepted and expected to keep being updated (a process document, an index, a registry). | +| Withdrawn | Abandoned by the author or the editor. Terminal. | +| Stagnant | Inactive in Draft or Review beyond six months. Revivable. | + +Permitted transitions, and no others: + +| From | May move to | Who moves it | +| --- | --- | --- | +| (new) | Draft | Editor, on a well-formedness check | +| Draft | Review, Withdrawn, Stagnant | Author (Review, Withdrawn); editor (Stagnant) | +| Review | Last Call, Draft, Withdrawn, Stagnant | Author (all but Stagnant); editor (Stagnant) | +| Last Call | Final, Living, Review, Withdrawn | Ratifier (Final, Living); author or editor (back to Review on a blocking issue) | +| Final | (none) | Nobody. Change requires a new AIP that supersedes it. | +| Living | Living (revised), Final, Withdrawn | Editor, with a Change Log entry | +| Stagnant | Draft | Any author reviving it | +| Withdrawn | (none) | Terminal | + +A transition that is not in this table is invalid. In particular there is no path +out of Final: a Final AIP is changed only by being superseded. + +**Retro-filing.** A document written after the change already shipped enters +directly at Final or Living, skipping Draft, Review and Last Call, and MUST say +in its Abstract that it backfills history. This is the one sanctioned bypass and +it exists because pretending a shipped change went through review would be a lie. +Retro-filed AIPs carry the same immutability rule from the moment they are filed. + +*Precedent: PEP 1, which publishes an explicit state diagram rather than a list of +adjectives, so that "what may happen next" is answerable without a judgment call; +and EIP-1's Draft / Review / Last Call / Final / Living / Withdrawn / Stagnant +vocabulary, adopted here rather than invented.* + +### 4. Supersession (MUST) + +Two headers express the relationship, and both sides MUST be written: + +- `Supersedes: N` on the new document. +- `Superseded-By: M` on the old document. + +Adding a `Superseded-By` header to a Final AIP is the **only** edit permitted to +that document (section 5), and it is a pure addition: no existing text is +changed, so a reader who has the old bytes and the new bytes sees exactly one +added line. + +The reading rule this creates: **a reader who lands on any AIP can reach the +current text by following `Superseded-By` until there is none.** That is the +whole point of the mechanism. A superseded AIP is not deleted, not hidden, and +not rewritten, because its historical claim ("this is what we did and why, on +this date") stays true forever even after the decision changes. + +Partial supersession is expressed by naming the sections: `Supersedes: 3 +(Section 4 only)`. If a new AIP replaces a decision but not the mechanism, it +says so in its Abstract. + +*Precedent: the IETF `Obsoletes` and `Obsoleted by` header pair (RFC 2026, +RFC 7322), which is the reason a thirty-year-old RFC still resolves to current +practice; and PEP 1's `Replaces` and `Superseded-By` fields.* + +### 5. Post-acceptance immutability (MUST) + +Once an AIP is Final, its normative content is frozen. Specifically: + +1. **No silent edits.** The Abstract, Motivation, Specification, Rationale, + Backwards Compatibility and Security Considerations sections of a Final AIP + MUST NOT be modified. +2. **Permitted edits, exhaustively:** adding a `Superseded-By` header; adding an + entry to the document's own **Errata** section; adding a + **Post-Acceptance Outcome Record** section; and typographical corrections that + cannot change meaning (spelling, broken link targets, table formatting). +3. **Errata** correct a factual error in a Final AIP. An erratum is appended, is + dated, states what was wrong and what is correct, and never edits the wrong + text away. A reader must be able to see both what was published and what was + corrected. +4. **A Post-Acceptance Outcome Record** reports what actually happened after the + change shipped, including when the outcome contradicts the expectation stated + in the original text. It is appended and dated. It never edits the original + claim. +5. If a change is large enough that errata would distort the document, file a new + AIP that supersedes it instead. +6. A Living AIP is exempt from (1) but MUST carry a **Change Log** section, and + every substantive revision MUST cite the AIP that authorized it. + +*Precedent: the RFC Editor model, where a published RFC is immutable and +corrections are published as separate errata against it rather than as edits to +it, so a citation to a document is a citation to fixed bytes; and Michael +Nygard's Architecture Decision Records, in which an accepted record is never +rewritten and a changed decision is a new record that supersedes it.* + +### 6. Required template (MUST) + +Every AIP uses `aip-template.md`. Every section header is present. A section that +does not apply keeps its header with the body "None". The required sections are +Preamble, Abstract, Motivation, Specification, Rationale, Backwards +Compatibility, Security Considerations, Reference Implementation and On-Chain +Deployment, and Copyright. + +A fixed section list is not bureaucracy; it is what makes an omission visible. +"Security Considerations: None" is a claim someone can challenge. A missing +Security Considerations section is a claim nobody notices. + +*Precedent: EIP-1's required-section list, and RFC 3552, which made a Security +Considerations section mandatory in every RFC precisely so that its absence could +not pass unremarked.* + +### 7. Types and categories + +Types are **Standards Track**, **Meta**, and **Informational**. Informational +AIPs give guidance and mandate nothing. A Standards Track AIP names exactly one +category: + +- **Core:** consensus, block production, fee and burn accounting, precompiles, genesis and client configuration. -- **Networking**: peer-to-peer protocol and sync. -- **Interface**: contract interfaces, ABIs, RPC conventions, verification +- **Networking:** peer-to-peer protocol and sync. +- **Interface:** contract interfaces, ABIs, RPC conventions, verification surfaces. -- **ARC** (AERE Request for Comment): application and token standards (for - example ERC-20, ERC-4626, ERC-4337, ERC-6551 conventions as adopted on AERE). -- **Meta** and **Informational** carry no category. +- **ARC** (Aere Request for Comment): application and token standards. -### Numbering and format +Meta and Informational carry no category. -- AIPs are numbered by monotonically increasing integer. AIP-1 is this document. -- Each AIP is a single Markdown file named `AIP-N.md`. -- Each AIP MUST contain the sections in `aip-template.md`: Preamble, Abstract, - Motivation, Specification, Rationale, Backwards Compatibility, Security - Considerations, Reference Implementation and On-Chain Deployment, Copyright. A - section that does not apply is kept with the body "None". +### 8. Roles -### Sourcing rules (binding on all AIPs) +- **Author.** Anyone. Writes the document, drives it through the statuses, + answers review questions. +- **Editor.** Checks that a proposal is well-formed, correctly numbered and + categorized, technically coherent, and that every cited address, transaction, + and number is real. The editor explicitly does **not** judge whether a proposal + is a good idea. Today the editor is the Foundation. +- **Ratifier.** The party whose approval moves a proposal to Final. Today this is + the founder, acting through the Foundation account + `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`, a single-key + Foundation-controlled account and **not** a deployed multisig. See + `CONTRIBUTING.md` for the honest description of what that means for an outside + contributor. -- Every on-chain address MUST be copied verbatim from `sdk-js/src/addresses.ts`, - the canonical registry. No address may be guessed. If unsure, omit it. -- Every gas figure, transaction hash, and block number MUST be reproducible from - the chain or from a repo fixture. Unmeasured quantities MUST be written as "to - be measured", never invented. -- Design ceilings (for example a theoretical maximum throughput) MUST NOT be - presented as measured throughput. +*Precedent: the RFC Editor / IESG split, and EIP-1's separation of editors from +approval, both of which exist so that the person checking whether a document is +correctly formed is not the same person deciding whether the idea wins.* -### Ratification and the decentralization path +### 9. Sourcing rules (binding on every AIP) -Today, ratification is editorial: the Foundation approves an AIP and, for a -Standards Track change, ships it. This is honest and is labeled as such on every -pre-decentralization AIP. It is not stakeholder governance and does not pretend to -be. +- Every on-chain address is copied verbatim from the canonical SDK registry + (`sdk-js/src/addresses.ts`). No address is guessed. If unsure, omit it. +- Every gas figure, transaction hash, and block number is reproducible from the + chain or a repo fixture. Unmeasured quantities are written "to be measured", + never invented. +- Every number carries its provenance: **measured**, **spec**, or **estimate**. +- Design ceilings (a theoretical maximum throughput) are never presented as + measured throughput. +- Aere consensus is classical secp256k1 ECDSA QBFT. No AIP claims or implies + post-quantum consensus. Post-quantum applies to signatures, accounts and + applications only. -The intended migration, each step of which will be its own Meta AIP: +### 10. Where AIPs live -1. Open the validator set beyond the current seven Foundation-operated - validators, and run a second client implementation. -2. Introduce a public review period with standing that the Foundation cannot - unilaterally shorten. -3. Move ratification to stake-weighted or validator-weighted approval once an - independent staker and validator base exists. +`aere-research/aips/` is canonical: `README.md` (the index), `CONTRIBUTING.md` (the +contribution path), `aip-template.md`, and `AIP-N.md` for every N. -Until step 3, all Standards Track AIPs carry -**"Foundation-ratified (pre-decentralization)"**. +A stale duplicate of AIP-1 through AIP-6 exists at `aere-research-repo/aips/` +with an older governance note that says "three validators" and calls the +Foundation account a multisig. Both statements are false today. That copy is +superseded by this directory wherever the two disagree. ## Rationale -The process is deliberately close to Ethereum's EIP/ERC model because AERE is -EVM-equivalent (Pectra plus Fusaka) and builders already know that model. -Copying its status names and section structure lowers the cost of contributing. +The mechanisms above are borrowed, not designed. Every one of them has been load +tested for decades by IETF, Python, or Ethereum, and the failure each one +prevents is a failure those bodies actually hit. Inventing a new process for a +chain with one operator and no external contributors would be inventing a +solution to a problem we have not yet had, while missing the problems that are +already known. -The one deviation worth calling out is the explicit, up-front honesty about -governance. Rather than dress editorial ratification up as decentralized -governance, AIP-1 names the current reality and the path off it. Credibility with -technical readers comes from stating limitations plainly, not from hiding them. +The single most important borrowed mechanism is section 5, immutability after +acceptance. A process where accepted documents can be quietly edited produces +records that cannot be cited, because the thing you cited may not be the thing +that is there now. That failure is invisible until the moment it matters, which +is typically an audit or a dispute. ## Backwards Compatibility -None. This is the first process document. +AIP-2 through AIP-16 were filed before this revision. They remain valid. Where +one of them lacks a `Superseded-By` header, its absence means "not superseded", +which is the correct reading. Sections 2 through 6 bind every AIP filed from +2026-07-20 onward and are applied to earlier AIPs on their next touch. ## Security Considerations -The chief risk in a pre-decentralization process is that a single party can both -author and ratify, so an AIP can be waved through without genuine review. This is -mitigated only partially today, by the editor's sourcing rules (every address and -number must be real and reproducible) and by keeping the honesty label on every -proposal. It is not fully mitigated until independent ratifiers exist. This -weakness is stated rather than hidden, which is itself part of the mitigation. +The governance weakness is stated rather than hidden: today a single party can +both author and ratify an AIP. The editor's sourcing rules and the immutability +rule reduce the damage that state can do (a false claim is at least dated, +attributed, and hard to erase) but they do not remove it. Only independent +ratifiers do that, and Aere does not have them yet. Every pre-decentralization +AIP carries the label **"Foundation-ratified (pre-decentralization)"** so that no +reader mistakes editorial ratification for trustless governance. + +The intended migration, each step its own Meta AIP: (1) open the validator set +beyond the current seven Foundation-operated validators and run a second client +as a live producer; (2) introduce a public review period the Foundation cannot +unilaterally shorten; (3) move ratification to stake-weighted or +validator-weighted approval once an independent staker and validator base exists. ## Reference Implementation and On-Chain Deployment -Not applicable. This AIP is the process. The scaffold lives at `aerenew/aips/` -and consists of this file, `README.md`, `aip-template.md`, and the retro-filed -AIPs AIP-2 through AIP-7. +None. This is a process document. + +## Change Log + +| Revision | Date | Change | Authorized by | +| --- | --- | --- | --- | +| 1 | 2026-07-11 | Initial process definition: statuses, categories, roles, sourcing rules. | Foundation | +| 2 | 2026-07-20 | Added numbering permanence (section 2), the transition table (section 3), supersession headers (section 4), post-acceptance immutability with errata and outcome records (section 5), provenance labels, and named precedent for each mechanism. | AIP-19 (Review) | ## Copyright Released to the public domain (CC0). No rights reserved. - diff --git a/aips/AIP-2.md b/aips/AIP-2.md index e9cbf3d..d3acf0a 100644 --- a/aips/AIP-2.md +++ b/aips/AIP-2.md @@ -12,34 +12,22 @@ | Status | Final | | Created | 2026-07-11 | | Requires | None | +| Supersedes | None | +| Superseded-By | None | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract -This AIP documents the on-chain mechanism that makes AERE's burn real and +This AIP documents the on-chain mechanism that makes AERE's fee-burn real and auditable: an atomic splitter that routes a validator's accumulated coinbase rewards so that a fixed fraction, 37.5% by default, is sent to a permanent burn vault and the remainder is returned to the validator. It is a retro-filed record of a change that is already live on chain 2800. -**Realized burn to date, MEASURED.** The mechanism is live and the vault is -immutable, and it has burned essentially nothing. `eth_getBalance` on the burn -vault `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6` returned -`0x1e7f974e119aaa7` at block 10,571,949 on 2026-07-20, which is -137,352,594,046,167,719 wei, or 0.1373525940461677 AERE, against a fixed supply -of 2,800,000,000 AERE. The reason is arithmetic: the burn is a percentage of -validator coinbase revenue, that revenue is currently zero, and a percentage of -zero is zero. The 37.5% in this document is a conditional rate on future -revenue. AERE is not deflationary today. Verify with one RPC call. - ## Motivation The AERE whitepaper (Section 3.3) states that up to 37.5% of transaction fees are -permanently removed from circulation. That wording predates the implemented -mechanism and is superseded: what this AIP specifies, and what is live, is a cut -of the VALIDATOR COINBASE REWARD, not of transaction fees. The -validator-reward-cut description governs everywhere the two conflict. On a -Hyperledger Besu QBFT chain there is no +permanently removed from circulation. On a Hyperledger Besu QBFT chain there is no protocol-level base-fee burn of the EIP-1559 kind: QBFT credits fees to the block proposer's coinbase rather than burning any part of them at the consensus layer. So the whitepaper claim needed an explicit, on-chain mechanism, or it would be @@ -137,7 +125,46 @@ All addresses copied verbatim from `sdk-js/src/addresses.ts`. Live cumulative burn statistics are readable via `AereCoinbaseSplitter.burnStats()` and `AereFeeBurnVault.totalBurnedAERE()`. +## Errata + +None. + +## Post-Acceptance Outcome Record + +*Appended 2026-07-20 under AIP-1 section 5. Nothing above this heading was +edited. This record exists because the mechanism works exactly as specified while +producing an economic outcome that a reader of the sections above would not +predict.* + +**The burn is real and it is approximately zero.** + +| Quantity | Value | Provenance | +| --- | --- | --- | +| Burn rate | 37.5% of the validator coinbase reward | spec (configured) | +| Hard cap on the rate | 50% (`setBurnBps` reverts above `5000`) | spec | +| Coinbase revenue to date | zero | measured | +| Lifetime burned | 0.1374 AERE | measured | + +The splitter routes 37.5% of what it receives, and it has received almost +nothing, because the chain is quiet and coinbase revenue is effectively zero. A +percentage of zero is zero. The mechanism is live, immutable at its endpoints, +and verifiable; the supply effect is negligible. + +**Therefore AERE is not deflationary today, and no Aere document may say that it +is.** A burn mechanism existing is not the same claim as supply decreasing, and +the difference between those two claims is 0.1374 AERE against a 2.8 billion +supply. This will change only if transaction volume changes; it is not a +parameter anyone can tune, because the rate is already set and the input is what +is missing. + +**Two related confusions to keep out of Aere copy.** First, this burn is a cut of +the **validator coinbase reward**, not an EIP-1559 base-fee burn; QBFT credits +fees to the proposer's coinbase and burns nothing at the consensus layer, which is +why the mechanism is a contract above consensus. Second, chain 2800 does separately +run a 1 Gwei base-fee **floor** from block 10,141,734 (AIP-17); a floor sets a +minimum price and removes no supply. Conflating the floor with the burn produces a +statement that is wrong twice. + ## Copyright Released to the public domain (CC0). No rights reserved. - diff --git a/aips/AIP-7.md b/aips/AIP-7.md index 71e07d1..6abb249 100644 --- a/aips/AIP-7.md +++ b/aips/AIP-7.md @@ -12,6 +12,8 @@ | Status | Final | | Created | 2026-07-16 | | Requires | 4 | +| Supersedes | None | +| Superseded-By | None | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract @@ -234,10 +236,6 @@ the recorded Falcon-1024 attestation is retrievable at block 9,200,542. The desi and gas model are specified in `research/aip-draft-pqc-precompiles.md`; the pure-Solidity verifier suite that the precompiles accelerate is documented in AIP-4. -## Copyright - -Released to the public domain (CC0). No rights reserved. - ## Errata **Erratum 1 (2026-09-11).** The Rationale originally read "a maintained, audited @@ -249,3 +247,47 @@ to us; calling it audited or reviewed asserted more than can be cited. What is c is byte-for-byte agreement with the NIST KAT and ACVP vectors in both directions, recorded in `AERE-NIST-VALIDATION-STATUS.md` section 3.4. Nothing normative in this AIP changed: the precompiles, addresses, encodings and gas constants are untouched. + +The clarification below remains an outcome record rather than an erratum, +because this AIP specified five precompiles and five is what is live. The record +exists to close off a misreading that arose elsewhere, not to correct this text. + +## Post-Acceptance Outcome Record + +*Appended 2026-07-20 under AIP-1 section 5. Nothing above this heading was +edited.* + +**Mainnet 2800 has exactly five PQC precompiles, and the band ends at +`0x0AE5`.** + +Two sibling precompiles were built after this fork and are sometimes discussed +alongside it: ML-KEM-768 at `0x0AE6` and Falcon HashToPoint at `0x0AE7`. Both are +**testnet-only**. Neither is live on chain 2800. + +This was confirmed on 2026-07-20 by a **gas-differential probe** against a +no-code control address: a live precompile and an empty account both return empty +data, so return value alone cannot distinguish them, but they differ in gas +consumed. `0x0AE6` and `0x0AE7` on mainnet behave as empty accounts. + +| Address | Scheme | Live on 2800 | Provenance | +| --- | --- | --- | --- | +| `0x0AE1` | Falcon-512 | yes, from block 9,189,161 | measured | +| `0x0AE2` | Falcon-1024 | yes, from block 9,189,161 | measured | +| `0x0AE3` | ML-DSA-44 | yes, from block 9,189,161 | measured | +| `0x0AE4` | SLH-DSA-SHA2-128s | yes, from block 9,189,161 | measured | +| `0x0AE5` | SHAKE256 | yes, from block 9,189,161 | measured | +| `0x0AE6` | ML-KEM-768 | **no, testnet only** | measured (gas-differential probe) | +| `0x0AE7` | Falcon HashToPoint | **no, testnet only** | measured (gas-differential probe) | +| `0x0AE8` | PQ STARK verify | **no, skeleton, no network** | AIP-16 | + +The scope boundary this AIP already states is restated because it is the claim +most likely to be misquoted: this fork changed the execution layer only. **Aere +consensus is classical secp256k1 ECDSA QBFT and is not post-quantum.** + +The EIP-2935 half of this fork carries a deviation from the written standard, +namely that the history contract was listed under Pectra but not populated until +this fork's block. That deviation is now recorded separately as AIP-18. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/README.md b/aips/README.md index d406284..7fa1a5b 100644 --- a/aips/README.md +++ b/aips/README.md @@ -1,118 +1,117 @@ -# AERE Improvement Proposals (AIPs) +# Aere Improvement Proposals (AIPs) -An AIP (AERE Improvement Proposal) is a design document that describes a change -to the AERE Network (chain ID 2800), its contracts, its consensus parameters, or -its processes. An AIP records the motivation for a change, the exact mechanism, -the rationale for the design, and, when the change is already live, the on-chain -addresses and transactions that prove it exists. +An AIP is a design document describing a change to Aere Network (chain ID 2800), +its contracts, its consensus parameters, or its processes. It records the +motivation, the exact mechanism, the rationale, and, when the change is already +live, the on-chain addresses and transactions that prove it exists. -AIPs are AERE's equivalent of Ethereum's EIP/ERC process. They exist so that any -reader, human or machine, can reconstruct why the chain works the way it does -from a single canonical, plain-text source instead of from marketing pages. +AIPs exist so that a reader, human or machine, can reconstruct why the chain +works the way it does from one canonical plain-text source instead of from +marketing pages or from someone's memory. -This directory is a local, self-contained scaffold. It is not published anywhere -and is not wired into any build or deployment. It is intended to be the seed of a -public AIP repository once the process is stable. +**Start here:** -## What belongs in an AIP - -- A protocol or consensus change (block time, fee routing, precompiles). -- A new contract standard or interface that other builders are expected to - integrate against. -- A token-standard or account-standard convention (ARC). -- A process or governance change (Meta). - -Things that do not belong in an AIP: bug-fix redeploys that preserve an existing -interface (those are tracked in `sdk-js/src/addresses.ts` deprecation notes), -routine parameter tuning inside an already-ratified bound, and pure documentation. - -## Lifecycle - -An AIP moves through a small number of statuses. The happy path is -`Draft -> Review -> Last Call -> Final`. Standards that are never "done" (for -example a registry that keeps growing) settle in `Living` instead of `Final`. - -| Status | Meaning | -| --- | --- | -| Draft | The proposal is written and formatted correctly and has an author. It may still change substantially. | -| Review | The author has marked it ready for wider scrutiny. Open questions are being resolved. | -| Last Call | Final review window. A fixed review period is stated. If no blocking issue is raised, it advances. | -| Final | Accepted and, for already-shipped work, live on chain 2800. The mechanism is now stable and should not change in a breaking way. | -| Living | Accepted and expected to keep being updated (for example an index or a registry-style standard). | -| Withdrawn | The author or the editors abandoned the proposal. Terminal. | -| Stagnant | Inactive in Draft or Review for an extended period. Can be revived. | - -Retro-filed AIPs (documents written after the change already shipped) enter -directly at `Final` or `Living` and carry a note that they are backfilling -history. AIP-2 through AIP-7 in this scaffold are retro-filed. - -## Categories and types - -Every Standards Track AIP names one category: - -- **Core**: consensus, block production, fee/burn accounting, precompiles, and - anything that changes how the chain itself behaves. Requires a client or - genesis/config change. -- **Networking**: peer-to-peer protocol, sync, and node-to-node messaging. -- **Interface**: contract-level interfaces, ABIs, RPC conventions, and - verification surfaces that builders integrate against. -- **ARC (token standards)**: AERE Request for Comment. Application and token - standards, for example ERC-20/4626 receipt tokens and ERC-4337 account - conventions, as adopted on AERE. -- **Meta**: process, governance, and the AIP process itself. - -Types: Standards Track (Core, Networking, Interface, ARC), Meta, and -Informational. Informational AIPs give guidance and do not mandate anything. - -## Honest governance note (read this) - -AERE is not yet trustlessly governed. Today the network runs seven validators -under a single operator, one client (Hyperledger Besu QBFT), no external security -audit, and thin real usage. In that reality an AIP is not ratified by an on-chain -vote of independent stakeholders. It is **Foundation-ratified**: the AERE -Foundation account (`0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`, a single-key -Foundation-controlled account, not a deployed multisig) is the final editor and -approver. - -Every AIP that predates validator and client decentralization carries the label -**"Foundation-ratified (pre-decentralization)"** so no reader mistakes editorial -ratification for trustless governance. As the validator set opens up and a second -client and independent stakers come online, the process is expected to migrate to -stake-weighted or validator-weighted ratification. That migration will itself be a -Meta AIP. Until then, the honest description of AERE governance is: a Foundation -publishes proposals, ships them, and records them here for public audit. - -## How to file an AIP - -1. Copy `aip-template.md` to `AIP-N.md`, where N is the next free integer. -2. Fill in every required section. Do not delete a section header; if a section - does not apply, write "None" under it. -3. Cite on-chain addresses verbatim from `sdk-js/src/addresses.ts`. Never invent - an address, a transaction hash, or a gas number. If a number has not been - measured, write "to be measured" rather than guessing. -4. Add a row to the index below. -5. Open it for editorial review. Until decentralization, the editor is the - Foundation. +- **[AIP-1](./AIP-1.md)** is the process: numbering, statuses and the transitions + between them, supersession, and the rule that accepted proposals are not + silently edited. +- **[CONTRIBUTING.md](./CONTRIBUTING.md)** is how someone who is not us proposes + a change, and who actually decides. +- **[aip-template.md](./aip-template.md)** is the required template. ## Index -| AIP | Title | Type / Category | Status | Note | +Status values are defined in AIP-1 section 3. A blank Superseded-By means the +document is current. + +| AIP | Title | Type / Category | Status | Superseded by | | --- | --- | --- | --- | --- | -| [1](./AIP-1.md) | AIP Purpose and Process | Meta | Living | The process itself | -| [2](./AIP-2.md) | Coinbase Fee-Burn Routing (37.5%) | Standards Track / Core | Final | Foundation-ratified (pre-decentralization) | -| [3](./AIP-3.md) | Sub-Second Block Period (500 ms QBFT) | Standards Track / Core | Final | Foundation-ratified (pre-decentralization) | -| [4](./AIP-4.md) | On-Chain Post-Quantum Signature Verification Suite | Standards Track / Interface | Final | Foundation-ratified (pre-decentralization) | -| [5](./AIP-5.md) | sAERE Receipt Token and AereSink Immutable Flywheel | Standards Track / ARC | Final | Foundation-ratified (pre-decentralization) | -| [6](./AIP-6.md) | ERC-4337 Passkey and Gasless Onboarding Stack | Standards Track / ARC | Final | Foundation-ratified (pre-decentralization) | -| [7](./AIP-7.md) | AerePQC Hard-Fork Activation (Native PQC Precompiles and Extended EIP-2935 Lookback) | Standards Track / Core | Final | Foundation-ratified (pre-decentralization) | +| [1](./AIP-1.md) | AIP Purpose and Process | Meta | Living (rev 2, 2026-07-20) | | +| [2](./AIP-2.md) | Coinbase Fee-Burn Routing (37.5%) | Standards Track / Core | Final | | +| [3](./AIP-3.md) | Sub-Second Block Period (500 ms QBFT) | Standards Track / Core | Final | | +| [4](./AIP-4.md) | On-Chain Post-Quantum Signature Verification Suite | Standards Track / Interface | Final | | +| [5](./AIP-5.md) | sAERE Receipt Token and AereSink Immutable Flywheel | Standards Track / ARC | Final | | +| [6](./AIP-6.md) | ERC-4337 Passkey and Gasless Onboarding Stack | Standards Track / ARC | Final | | +| [7](./AIP-7.md) | AerePQC Hard-Fork Activation (PQC Precompiles and EIP-2935 Lookback) | Standards Track / Core | Final | | +| [8](./AIP-8.md) | Post-Quantum-Authorized Transaction Envelope (EIP-2718 Type 0x2A) | Standards Track / Core | **Draft, not live** | | +| [9](./AIP-9.md) | Consensus Mechanism: QBFT, not HotStuff | Informational | Final | | +| [10](./AIP-10.md) | Execution Client: Forked Besu with Nethermind Second, not Reth | Informational | Final | | +| [11](./AIP-11.md) | Interoperability: Hyperlane-Compatible plus zk Light Clients, not IBC | Informational | Final | | +| [12](./AIP-12.md) | The Virtual Machine: Extend the EVM, not a New VM | Informational | Final | | +| [13](./AIP-13.md) | Post-Quantum Signatures: Falcon and ML-DSA Together | Informational | Final | | +| [14](./AIP-14.md) | Account Abstraction: ERC-4337 with EIP-7702 Bridge, not Native AA | Informational | Final | | +| [15](./AIP-15.md) | In-Place Hybrid PQC Consensus Activation, not Re-Genesis | Standards Track / Core | **Draft, testnet R&D only** | | +| [16](./AIP-16.md) | PQ STARK-Verify Precompile (0x0AE8) | Standards Track / Core | **Draft, skeleton, verifies nothing** | | +| [17](./AIP-17.md) | One-Gwei EIP-1559 Base-Fee Floor | Standards Track / Core | Final | | +| [18](./AIP-18.md) | EIP-2935 on Chain 2800: Deviation from the Written Activation Schedule | Standards Track / Core | Final | | +| [19](./AIP-19.md) | AIP Process Hardening | Meta | **Review, not ratified** | | + +Numbers are permanent and are never reused, including for withdrawn proposals +(AIP-1 section 2). Numbering is contiguous from 1 to 19 with no gaps. No AIP +numbered 20 or higher exists in any Aere repository. + +## Which of these are live on chain 2800 + +Read this before citing anything here as a network capability. + +**Live:** AIP-2 (burn routing; see its outcome record for the measured amount), +AIP-3 (500 ms target, 516.4 ms measured), AIP-4, AIP-5, AIP-6, AIP-7 +(precompiles `0x0AE1`..`0x0AE5` from block 9,189,161), AIP-17 (base-fee floor from +block 10,141,734), AIP-18 (EIP-2935 from block 9,189,161). AIP-9 through AIP-14 +describe the decisions behind the live system. + +**Not live:** AIP-8 (needs a hard fork), AIP-15 (isolated testnet only), AIP-16 +(a skeleton that verifies nothing), AIP-19 (a process change under review). + +**Never claimed:** post-quantum consensus. Aere consensus is classical secp256k1 +ECDSA QBFT at N = 7. Post-quantum applies to signatures, accounts and +applications only. The precompiles `0x0AE6` and `0x0AE7` are testnet-only. + +## Governance, stated plainly + +Aere is not yet trustlessly governed. Seven validators, all Foundation-operated, +one live client, no external security audit, thin real usage. In that reality an +AIP is not ratified by a vote of independent stakeholders. **The founder decides**, +acting through the Foundation account +`0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`, which is a single-key account and +**not a deployed multisig**. Every proposal that predates decentralization carries +the label "Foundation-ratified (pre-decentralization)" so nobody mistakes +editorial ratification for governance. See `CONTRIBUTING.md` for what that means +if you are not us, and AIP-1 section 8 for the migration path. + +## Filing an AIP + +See AIP-1 section 6 and `CONTRIBUTING.md`. In short: copy the template, keep +every section header, cite addresses verbatim from `sdk-js/src/addresses.ts`, +label every number **measured**, **spec** or **estimate**, write "to be measured" +rather than guessing, and add a row to this index. ## Conventions -- Files are named `AIP-N.md`. -- One AIP per change. If a change has a Core part and an application part, either - file two AIPs or state clearly which layer each section addresses. +- Files are named `AIP-N.md`. One AIP per change. If a change has a Core part and + an application part, either file two AIPs or state clearly which layer each + section addresses. - Addresses, transaction hashes, gas figures, and block numbers must be - reproducible from the chain or from a repo fixture. Marketing numbers (for - example a design-ceiling throughput) are never presented as measured results. - - + reproducible from the chain or from a repo fixture. Design ceilings (for + example a theoretical maximum throughput) are never presented as measured + results. +- A Final AIP is not edited. Corrections go in its Errata section and outcomes go + in its Post-Acceptance Outcome Record, both dated and appended (AIP-1 section + 5). + +## Other locations, and one stale copy + +- `aere-research-repo/aips/` holds an older AIP-1 through AIP-6 whose governance + note says "three validators" and calls the Foundation account a multisig. Both + statements are false today. **This directory is authoritative** wherever the two + disagree. +- the Aere working tree holds drafts (not published in this package) of open, externally-submittable Ethereum standards + (targeting `ethereum/EIPs`, `ethereum/ERCs`, or the RIP process). Those are not + AIPs and carry no AIP number: an AIP records why chain 2800 works the way it + does with its live addresses, while an open EIP draft is the chain-agnostic + version a third party could implement. +- `aere-docs/AERE-AIP-PROCESS-AND-INDEX.md` is the published narrative version + of this index. + +## Copyright + +All AIPs are released to the public domain (CC0). No rights reserved. diff --git a/aips/aip-template.md b/aips/aip-template.md index 8f90dc3..c774d2d 100644 --- a/aips/aip-template.md +++ b/aips/aip-template.md @@ -12,12 +12,19 @@ | Status | Draft / Review / Last Call / Final / Living / Withdrawn / Stagnant | | Created | YYYY-MM-DD | | Requires | Comma-separated AIP numbers, or None | +| Supersedes | AIP number this replaces, or None | +| Superseded-By | AIP number that replaces this, or None | | Ratification | Foundation-ratified (pre-decentralization), or the governance basis in force | +`Supersedes` and `Superseded-By` are written as a pair: if this AIP supersedes +AIP-N, then AIP-N gets `Superseded-By: ` in the same change. A +reader must be able to follow `Superseded-By` from any AIP to the current text. + ## Abstract Two to four sentences. State what the AIP does in plain language. A reader should -understand the whole change from this paragraph alone. +understand the whole change from this paragraph alone. If this document backfills +a change that already shipped, say so here. ## Motivation @@ -33,9 +40,9 @@ with their values. For a consensus change, give the exact configuration keys and values and the activation point. Use MUST / SHOULD / MAY where a requirement is binding on implementers. -For anything that touches gas or size, cite only numbers that are measured -on-chain or sourced from a repo fixture. Label any unmeasured number as -"to be measured". +Every quantity carries its provenance: **measured** (reproducible from the chain +or a repo fixture), **spec** (a configured or standardized value), or +**estimate**. An unmeasured quantity is written "to be measured", never guessed. ## Rationale @@ -51,7 +58,8 @@ breaks. Attack surface, trust assumptions, and known weaknesses. This section is required and must be honest. If the change depends on a trusted operator, a small -validator set, or an unaudited contract, say so here. +validator set, or an unaudited contract, say so here. Do not delete this header; +"None" is a claim a reader can challenge, an absent section is not. ## Reference Implementation and On-Chain Deployment @@ -60,7 +68,18 @@ address(es) copied verbatim from `sdk-js/src/addresses.ts`, and the proving transaction hashes and block numbers where available. For a not-yet-live change: the branch or spec that implements it and the plan to ship. +## Errata + +Corrections to factual errors found after this AIP reached Final. Each entry is +dated, states what the document said, and states what is correct. The erroneous +text above is **not** edited away. "None" until there is one. + +## Post-Acceptance Outcome Record + +What actually happened after the change shipped, including where the outcome +differs from what this document expected. Appended and dated; never edits the +original claim. Omit this section entirely while the AIP is pre-Final. + ## Copyright Released to the public domain (CC0). No rights reserved. -