86 lines
3.3 KiB
Markdown
86 lines
3.3 KiB
Markdown
# 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 |
|
|
| 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. If this document backfills
|
|
a change that already shipped, say so here.
|
|
|
|
## 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.
|
|
|
|
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
|
|
|
|
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. Do not delete this header;
|
|
"None" is a claim a reader can challenge, an absent section is not.
|
|
|
|
## 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.
|
|
|
|
## 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.
|