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.
163 lines
6.8 KiB
Markdown
163 lines
6.8 KiB
Markdown
# AIP-1: AIP Purpose and Process
|
|
|
|
## Preamble
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| AIP | 1 |
|
|
| Title | AIP Purpose and Process |
|
|
| Author | AERE Foundation |
|
|
| Type | Meta |
|
|
| Category | (none) |
|
|
| Status | Living |
|
|
| Created | 2026-07-11 |
|
|
| Requires | 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.
|
|
|
|
## Motivation
|
|
|
|
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.
|
|
|
|
It also forces discipline. Writing the Specification and Security Considerations
|
|
sections before (or, for retro-filed AIPs, immediately after) shipping surfaces
|
|
weak assumptions early.
|
|
|
|
## Specification
|
|
|
|
### Roles
|
|
|
|
- **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.
|
|
|
|
### Statuses
|
|
|
|
The normative lifecycle is `Draft -> Review -> Last Call -> Final`. `Living`
|
|
replaces `Final` for standards that keep evolving. `Withdrawn` and `Stagnant` are
|
|
the off-ramps.
|
|
|
|
- **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.
|
|
|
|
Retro-filed AIPs enter at Final or Living and state in their Abstract that they
|
|
document a change that already shipped.
|
|
|
|
### Categories and types
|
|
|
|
Types are Standards Track, Meta, and Informational. A Standards Track AIP MUST
|
|
name 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
|
|
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.
|
|
|
|
### Numbering and format
|
|
|
|
- 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".
|
|
|
|
### Sourcing rules (binding on all AIPs)
|
|
|
|
- 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.
|
|
|
|
### Ratification and the decentralization path
|
|
|
|
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.
|
|
|
|
The intended migration, each step of which will be its own Meta AIP:
|
|
|
|
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.
|
|
|
|
Until step 3, all Standards Track AIPs carry
|
|
**"Foundation-ratified (pre-decentralization)"**.
|
|
|
|
## 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 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.
|
|
|
|
## Backwards Compatibility
|
|
|
|
None. This is the first process document.
|
|
|
|
## 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.
|
|
|
|
## 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.
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|
|
</content>
|