# 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.