6cb0140fae
The public history carried kat/__pycache__/mlkem768_reference.cpython-314.pyc, a compiled Python artifact embedding the operator's absolute local path. Text secret scanners do not read compiled binaries, which is exactly how it slipped through, and removing it from the tip would have left it reachable through the old root commits. So this repository is republished from a single clean root. This root also carries, from the previously unpublished line of work: - corrected LICENSE year, LICENSING.md, VERIFY-POLICY.md, and CITATIONS-UNRESOLVED.md remeasured 2026-08-11 (101 paths, README aligned) - O-018: run_consensus_verification.py ran 19 of 29 models and reported PASS; it now runs all 29, and computemarket_smt.py gains resolveByTimeout / reclaimUnsettled cases plus a negative control - O-006: the word 'audited' removed from next to Bouncy Castle, twice, after a concurrent edit resurrected it - O-014: prior art named and dated - Algorand's native falcon_verify shipped about ten months before AERE's precompiles; the primacy claim is withdrawn where it was implied - bench/ scripts parametrized so they actually run for an outsider (the earlier textual sanitization left $STAGING unexpanded inside Python strings) - AIP-2/AIP-3 errata with measured figures, spec remeasurements at 2026-08-01, and the spec-zk-stack retractions (owner is an operational key, not the Foundation; 'maximally sound' withdrawn; aggregator V1 deprecated) The redacted bench-host environment files from the sanitized line are kept exactly as published; the unredacted local variants are not carried.
119 lines
6.5 KiB
Markdown
119 lines
6.5 KiB
Markdown
# 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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
## 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.
|
|
|
|
## Index
|
|
|
|
| AIP | Title | Type / Category | Status | Note |
|
|
| --- | --- | --- | --- | --- |
|
|
| [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) |
|
|
|
|
## 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.
|
|
- 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>
|