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.
2.3 KiB
AIP-N: Title in Title Case
Preamble
| Field | Value |
|---|---|
| AIP | N |
| Title | Short descriptive title |
| Author | Name or handle |
| Type | Standards Track / Meta / Informational |
| Category | Core / Networking / Interface / ARC / (omit for Meta and Informational) |
| Status | Draft / Review / Last Call / Final / Living / Withdrawn / Stagnant |
| Created | YYYY-MM-DD |
| Requires | Comma-separated AIP numbers, or None |
| Ratification | Foundation-ratified (pre-decentralization), or the governance basis in force |
Abstract
Two to four sentences. State what the AIP does in plain language. A reader should understand the whole change from this paragraph alone.
Motivation
Why this change is worth making. What problem it solves, who it helps, and what goes wrong without it. Be concrete. If the change is already live, say what prompted it.
Specification
The exact, unambiguous mechanism. This is the normative section. For a contract change, describe the interface, the state, the invariants, and the parameters 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".
Rationale
Why the design is the way it is. Alternatives considered and why they were rejected. Trade-offs accepted.
Backwards Compatibility
What breaks, what does not, and how integrators migrate. "None" if nothing breaks.
Security Considerations
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.
Reference Implementation and On-Chain Deployment
For a live change: the contract source path(s) in this repo, the canonical
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.
Copyright
Released to the public domain (CC0). No rights reserved.