Atomicals Improvement Proposals
The AIP register, the complete status model, and implementation evidence that is never assumed from a proposal existing.
Proposed Verified 2026-08-31
A proposal exists. Nothing here is implemented or activated by that fact alone.
- Page ID
-
protocol/aips - Normative authority
- Atomicals Improvement Proposal
- Networks
- mainnet
- Documentation version
- 2026.08
- Audience
- developer, integrator
- Owner
- bitcoin-universe-docs
- Sources
-
- Atomicals Improvement Proposals
at
be08d7856db7 - Universe Atomicals NFT, Realm, and Subrealm index
at
1d9109c68d95private repository provider AIP handshake
- Atomicals Improvement Proposals
at
- Known limitations
-
- The register reflects the vendored snapshot at the pinned revision. A proposal added upstream since then is not shown until the snapshot is refreshed by CI.
- An AIP is never marked implemented because it exists. Only the evidence file can establish that.
此内容尚不支持你的语言。
An AIP is a design document. It proposes something. It does not, by existing, change any implementation.
The register
Section titled “The register”| AIP | Type | Status | Created | Implementation evidence |
|---|---|---|---|---|
|
AIP-1 AIP Purpose and Guidelines | Meta | Draft | 2024-1-4 | none AIP-1 is a Meta proposal describing the AIP process itself. There is nothing for an implementation to implement, so no implementation evidence is expected or recorded.
Last checked 2026-08-31 |
|
AIP-3 Remove duplicate bytes field `$d` for Atomicals This proposal is targeting to remove the duplicate bytes field (`$d`) from Atomicals queries. | Standards Track Application | Draft | 2024-1-11 | proven The Universe NFT and Realm index requires its Atomicals provider to report the exact AIP set [1, 3] on server.info before it will accept the provider, and fails closed otherwise. That runtime check is the evidence, and it proves the provider reports the set, not that the serialisation change itself was independently re-verified here.
Last checked 2026-08-31 |
The register is generated by scripts/generate-aip-registry.mjs from a vendored snapshot of the
proposals plus the evidence file. Neither the table nor the evidence is hand maintained on this
page.
The status model
Section titled “The status model”An AIP sits in exactly one status. The generator rejects any value outside this set.
| Status | Meaning |
|---|---|
| Idea | Not yet submitted as a formal draft |
| Draft | Formally submitted and under development |
| Review | Ready for peer review |
| Last Call | Final review window before acceptance |
| Final | Accepted as a standard |
| Stagnant | Inactive for an extended period |
| Withdrawn | Withdrawn by the authors |
| Living | Continually updated, never final |
Conformance levels
Section titled “Conformance levels”Separate from AIP status, and about implementations rather than the proposal.
| Level | Meaning |
|---|---|
proven |
An executed test or a runtime contract check establishes the behavior at a pinned revision |
claimed |
An implementation reports it. Nothing here executes a check against that claim |
none |
No implementation evidence was located |
A Draft AIP can have proven conformance, and a Final AIP can have none. The two axes are
independent, and collapsing them is how a proposal ends up described as a shipped feature.
What the Universe index actually checks
Section titled “What the Universe index actually checks”The Universe NFT and Realm index requires its Atomicals provider to report the exact AIP set
[1, 3] during the provider handshake, and refuses the provider otherwise. That is a real runtime
contract check, and it is the evidence recorded for AIP-3.
It proves the provider reports that set. It is not an independent re-verification of the serialisation change the proposal describes.
Proposing a change to the register
Section titled “Proposing a change to the register”The register follows the upstream proposals. To correct implementation evidence, open an issue in the documentation repository using the new AIP or source version update template, and include the source and revision that establishes the claim.