# Atomicals Improvement Proposals

The AIP register, the complete status model, and implementation evidence that is never assumed from a proposal existing.

Page ID: protocol/aips
Applicability: proposed
Authority: aip
Networks: mainnet
Verified: 2026-08-31
Locale: en
URL: https://bitcoinuniverseio.github.io/atomicals-and-arc-20/protocol/aips/

---
An AIP is a design document. It proposes something. It does not, by existing, change any
implementation.

Nothing here is labelled implemented unless a row in `contracts/aip-implementation-evidence.json`
names the source that establishes it. Where no evidence exists, the register says so plainly.

## The register

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

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

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

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

The register follows the upstream proposals. To correct implementation evidence, open an issue in
the [documentation repository](https://github.com/bitcoinuniverseio/atomicals-and-arc-20/issues)
using the **new AIP** or **source version update** template, and include the source and revision
that establishes the claim.