Publish and verify an anchor revision.

Portable object identity

The canonical manifest, decoded-content tree, ordered paths, media/layout fields, decoded lengths and SHA-256 values, and address-neutral resource edges produce one portable root.

• Changing one canonical field changes the root.
• A portable root does not itself prove availability, ownership, or source-chain consensus.

Anchor record

An anchor adds chain family, network, registry, revision, anchor root, verifier route, verifier trust class, locator, and chain-specific evidence without changing the portable identity.

• Revisions append; they do not rewrite the portable object.
• Ordinals IDs, CIDs, burn addresses, and operation hashes remain locators unless a verifier checks a stronger statement.

Exact revision, lifetime history, and Grip

isChainAnchored checks one exact object revision. objectChainAnchored reports whether any revision in the object's history was accepted. objectAnchorStamp reports native status/root, a foreign-family bitmask, and frozen state; it is not Grip.

Grip

Unique (family, network) coordinates ever accepted for the object across all revisions

Revision rule

A changed revision requires a new proof; accepted history remains

Native stamp

stampNative checks same-chain registry/store commitment linkage; it does not rehash every stored byte

Settlement and replication state

L2/L3 anchors retain settlement source, hop depth, tier, topology, and data-availability classification. Replication records contributor, carrier, chunk/object binding, and proof result independently of the source anchor.

• Proof can make bytes checkable without making them cheaply readable.
• Replication adds a matching carrier; it does not create authorship or stronger consensus proof.

Read path

A verifier reads the portable root, exact anchor revision, family/verifier registration, proof payload or attested report, settlement topology, and any accepted replication binding before resolving bytes.

• Consumers pin the revision and verifier route.
• Fresh topology or live contract facts require fresh chain reads.

portable root
exact anchor revision
verifier route + trust class
proof payload or attested report
accepted binding or explicit rejection

Write and governance path

Publishers append anchors; proof backends verify family-specific evidence; registry governance adds families and verifier routes append-only; replication contributors submit matching carrier evidence.

• Governance cannot relabel an old attested record as native proof.
• Backend key/version changes require explicit verifier identity and evidence.

Trust class and observation source stay distinct

The verifier trust classes are native, optimistic, attested, and client. CRE, Functions, and threshold reports are attested routes. A pinned RPC response is an observation source, not a trust class; the catalog currently exposes optimistic extensibility without a concrete optimistic adapter.

IPFS proves addressing, not persistence

CID decoding and DAG verification can prove content identity. They do not prove that a gateway or pin remains available tomorrow.

Cross-chain mint is separate

A destination mint authorized by an attestor set is not automatically evidence that the destination contract verified the source chain's consensus.

Ethereum / EVM

The anchors module includes portable and attested registries, L2/state verifiers, settlement registry, Chainlink Functions and CRE routes, IPFS verifier, SP1 and zkVerify backends, Bitcoin-oriented ZK verification, node registry, and replication bridge.

Evidence

keel-contracts/test/modules/keel-anchors/*.t.sol; no module deployment JSON is present.

Tezos / SmartPy

The Tezos lane stores native network bytes, portable/object roots, immutable checkpoints, recursive graph certificates, Bitcoin header state, Ethereum state-proof inputs, and cross-mint attestations.

Evidence

vault-tezos/contracts/keel_artifact_registry.py; keel_immutable_checkpoint.py; keel_btc_header_chain.py; keel_eth_state_proof.py; matching tests and Octez mockup gate

SDK

@keel/protocol defines portable identities, attested anchors, replication records, integrity, and verification presentation. The builder and chain adapters prepare family-specific operations.

Studio

Studio exposes anchor reads, preservation source/chunk/carrier proofs, artifact replication state, and evidence labels. The index accelerates discovery; the viewer rechecks commitments.

Protocol documents

Portable roots, attested anchors, L2 settlement, IPFS encoding, and ZK Bitcoin anchors.

Contract tests

Fourteen focused Foundry suites cover registry, revision, replication, Functions, CRE, IPFS, L2/state, settlement, SP1, ZK, zkVerify, portable anchor, and parity paths.

Tezos tests

Native object/graph, Bitcoin, Ethereum proof, cross-mint, and local browser gates are separately exercised.