4a0b48588c
Aere Network public source. Everything here can be checked against the live chain (chain id 2800, https://rpc.aere.network). Scope note, stated up front rather than buried: consensus on chain 2800 is classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at the signature, precompile, account and transport layers. Nothing here makes the consensus post-quantum, and no document in it should be read as claiming so.
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>
|