How it works

AAC-1 rests on one idea: a manifest's hash is simultaneously its integrity proof, its address, and its pointer. Everything else follows from that.

The entry

Every change to an agent — a release or a checkpoint — is a canonical-JSON manifest. Its 32-byte SHA-256 hash is three things at once:

1. Integrity proof — recompute the hash, and you've verified the exact bytes.

2. Content address — the hash is the IPFS location (raw-block CIDv1, f01551220…), so the manifest is fetchable by its own hash from anywhere.

3. Pointer — the next entry embeds it as lineage.parent, hash-linking the chain.

Because proof, address, and pointer are the same value, given nothing but a lane's head hash you can fetch the entry, verify it with vanilla SHA-256, read its parent, and walk the agent's entire history backward — with zero trust in the registry, Orbofi, or any RPC.

head ──parent──▶ entry_n ──parent──▶ … ──parent──▶ genesis
  │                │                                  │
 fetch by hash   verify SHA-256                    the AAC token
 from IPFS       read parent, repeat               (mint block)

Checkpoint entries also carry under — the release they were accumulated under — cross-linking the two lanes into a DAG. Any behavioral diff then cleanly partitions into a design diff (release lane) and an experience diff (checkpoint lane).

The registry: a notary, not a curator

The on-chain registry (AACRegistry) anchors only the two lane heads per token, and enforces exactly the three things an EVM can verify:

• Append-only ordering — a new head's parent must equal the current head; dense sequence numbers.

• Authorship — releases require controller authority; checkpoints require the agent wallet.

• Time — block timestamps bound when each head existed.

Everything else is self-authenticating off-chain. Per-token on-chain state is deliberately tiny — two addresses (controller, agent wallet), a mode byte, a liveness heartbeat, and the two lane heads — so the whole thing stays auditable in a minute.

Two independent ways to recover history

Neither path trusts the other:

Path	Recovers	Needs	Survives
Walk the hash links	Content genealogy (which manifest derived from which)	IPFS availability	Registry/RPC loss
Replay registry events	Anchoring order (what was accepted, and when)	An RPC	IPFS loss of intermediate entries

This is per-agent Certificate Transparency: the registry is the signed tree-head, the lineage is the log.

Creation stays one transaction

None of this adds friction to launch. Minting an AAC is still one wallet transaction — the launcher writes the genesis release atomically at creation. The immutable tokenURI (the token's face) is set once and never changes; the brain versions live in the lineage, not the token metadata.