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

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)

Browse Source
This commit is contained in:
Aere Network 2026-09-11 22:04:15 +03:00
parent 16ce7e8989
commit 83453d9a79
5 changed files with 461 additions and 233 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

341
aips/AIP-1.md
View File

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

61
aips/AIP-2.md
View File

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

50
aips/AIP-7.md
View File

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

211
aips/README.md
View File

@ -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.
</content>
</invoke>
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.

31
aips/aip-template.md
View File

@ -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: <this number>` 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.
</content>