01
Getting started
AnchorRegistry is a permanent, on-chain provenance registry. Fill in a manifest, pay once, receive an AR-ID, and take custody of your Anchor Key — a permanent, cryptographic record that proves this artifact existed in this exact form at this exact moment, written to Base (Ethereum L2). No expiry. No account. No trust required.
What is an AR-ID?
An AR-ID is a permanent, unique, human and machine-readable identifier for any registered artifact. Format: AR-{YYYY}-{7-char hash}. Every AR-ID resolves to a full provenance record.
# Human anchorregistry.com/verify/AR-2026-K7X9M2P # Machine (AI agents, pipelines, APIs) anchorregistry.ai/AR-2026-K7X9M2P
How to register
Pick from 24 artifact types across 8 groups.
Title, author, descriptor, type-specific fields.
Your private key. Controls your provenance tree. Save it.
$5. Hash computed in browser. Nothing uploaded.
Embed tags
Once anchored, embed your AR-ID in the artifact itself. These tags are the distribution mechanism — every artifact becomes a permanent, distributed proof node that any human or AI can resolve.
# Software artifacts (code, packages, repos) SPDX-Anchor: anchorregistry.ai/AR-2026-K7X9M2P # Everything else (research, data, models, media) DAPX-Anchor: anchorregistry.ai/AR-2026-K7X9M2P
What is stored on-chain vs off-chain?
If all off-chain infrastructure disappears, the complete registry is recoverable from Ethereum events alone using anchorregistry recover. Ethereum is the ground truth.
02
Use cases
Every use case is the same fundamental problem: prove something existed, in this exact form, at this exact moment, and that it has not been altered since. Twenty-four artifact types. Five verticals. One registry.
01
IP Provenance
Developers, researchers, creators, freelancers
In a world where AI generates everything, proving you made something first is increasingly critical. AnchorRegistry gives every digital artifact a permanent, tamper-proof timestamp anchored to Ethereum.
Artifact types
CODE · RESEARCH · DATA · MODEL · AGENT · MEDIA · TEXT · POST
IP Provenance · example tree
02
Audit Trail
Consultants, advisory firms, compliance teams, law firms
Professional deliverables live in email threads and shared drives that can be altered or denied. AnchorRegistry makes the full engagement record — reports, notes, events — permanent and independently verifiable.
Artifact types
REPORT · NOTE · EVENT
Audit Trail · example tree
03
AI Compliance
AI companies, enterprises deploying agents, regulators
When an autonomous system takes an action there is currently no permanent, tamper-proof record of what version of what model was running at that moment. AnchorRegistry is the infrastructure layer for that proof.
Artifact types
MODEL · AGENT · DATA · EVENT (MACHINE · AGENT)
AI Compliance · example tree
04
Scientific Reproducibility
Researchers, clinical trial teams, academic institutions
Pre-registration exists but relies on centralised platforms that can be compromised or defunded. Anchoring a study protocol before results are known creates cryptographic proof the hypothesis predated the data.
Artifact types
RESEARCH · DATA · CODE · EVENT
Scientific Reproducibility · example tree
05
Transaction Records
CFOs, accounting firms, procurement teams, insurance, government
Business transaction records live in systems that can be altered, disputed, and lost. AnchorRegistry makes the financial audit trail permanent and verifiable by any auditor independently — no request to AR required.
Artifact types
RECEIPT · REPORT · NOTE · EVENT
Transaction Records · example tree
03
Artifact types
Twenty-four types across eight logical groups. All non-gated types are active at launch. Gated types (LEGAL, ENTITY, PROOF — IDs 14–16) require verification infrastructure and remain pending until that infrastructure is in place.
EVENT is the only type with a required executor field, making it dual-use: human lifecycle events and machine/agent processes share one type.
executor: HUMAN → conferences, launches, governance votes, milestones executor: MACHINE → training runs, deployments, builds, inference jobs executor: AGENT → agent-initiated tasks, pipeline runs, evaluations
RECEIPT handles all transaction categories via a receiptType field: PURCHASE | MEDICAL | FINANCIAL | GOVERNMENT | EVENT | SERVICE. Amount is stored as a string to preserve decimal precision.
04
The provenance tree
Most registries are flat. AnchorRegistry is not. Every anchor can reference a parent via the parentHash field, creating a directed acyclic graph — a traversable provenance tree. Any registered artifact is a node. The root AR-ID resolves the full tree.
The dual commitment scheme
Every tree carries two cryptographic commitments, both derived from your single Anchor Key K. Together they prove both who owns the tree and who wrote each individual anchor.
The tree identity commitment T proves tree ownership. It is the same for every anchor in your tree:
T = keccak256(K ‖ rootArId) # K — your Anchor Key (32 random bytes, generated in your browser, never sent to AnchorRegistry) # rootArId — the AR-ID of the root anchor in your tree # ‖ — byte-level concatenation
The per-anchor initiation commitment Φᵢ proves authorship of each individual anchor. Every anchor in your tree carries a distinct Φᵢ, but all derive from the same K:
Φᵢ = keccak256(K ‖ arIdᵢ) # K — your Anchor Key (same one used for T) # arIdᵢ — the AR-ID of anchor i
This is the unified property: one credential proves both tree ownership (via T) and per-anchor authorship (via every Φᵢ). AnchorRegistry cannot forge either commitment — K never leaves your browser, and without K, producing a matching commitment is computationally infeasible. This is what makes “not your keys, not your trees” literally true rather than a policy promise. Full proofs in the arXiv paper.
Not your keys, not your trees.
AnchorRegistry never stores, transmits, or has access to your Anchor Key. It is generated in your browser and never leaves it. Because the treeId is derived from your key, AR cannot compute it, cannot read which trees you own, and cannot impersonate you. Self-custody is structural, not a policy.
Tree recovery
Given any single AR-ID as an entry point, the full provenance tree is recoverable in O(n) time. Walk up via parentHash to find the root, then BFS/DFS down using the reverse index. The treeId index makes the whole tree retrievable in one query.
SELECT * FROM anchors_all WHERE tree_id = '<treeId>' ORDER BY block_timestamp ASC
Distinguishing governance from user-initiated anchors
REVIEW, VOID, and AFFIRMED anchors are registered by AnchorRegistry as governance actions. The smart contract hardcodes their token commitment to bytes32(0) — a value that user-initiated content can never carry, since registerContent reverts with MissingTokenCommitment on a zero value. This makes the two classes of anchor cryptographically distinguishable forever: user-initiated anchors carry a non-zero keccak256(K ‖ arId) commitment; governance anchors carry zero. Anyone can filter the Anchored event log for governance actions by scanning for zero commitments, making the dispute chain independently queryable and auditable. This separation is enforced immutably by the deployed bytecode — AnchorRegistry cannot impersonate a user-initiated registration because it cannot produce a valid non-zero commitment without the user's Anchor Key.
05
Security & trust
The governing principle:
Worst case is always time, never data loss.
Access control
Four role tiers govern the contract. No single key can act unilaterally against both owner and recovery address simultaneously.
7-day recovery timelock
The recovery mechanism is a 7-day timelocked ownership transfer initiated by the recovery address. The owner can cancel any in-flight recovery at any time. Every sensitive operation emits an on-chain event visible on Etherscan in real time. A 7-day lockout after cancellation prevents griefing.
Can a record be deleted?
No. The contract is append-only. Records are permanent and cannot be modified or deleted by anyone — including AnchorRegistry. Retraction attaches a new RETRACTION node; the original record remains on-chain permanently.
Can a record be faked?
The manifest hash is SHA-256 of your full manifest fields bound to your Anchor Key — anyone reconstructing it needs the same K, and K never leaves your browser. The contract additionally requires a non-zero token commitment (keccak256(K ‖ arId)) on every user-initiated registration; governance anchors (REVIEW, VOID, AFFIRMED) hardcode this to zero, so AnchorRegistry cannot impersonate a user-initiated registration. The contract also enforces AR-ID uniqueness — AlreadyRegistered() reverts any duplicate. First registration wins permanently.
The dispute system
Every enforcement decision is logged on-chain permanently and carries a zero token commitment, marking it as a governance action that no user could have produced. AnchorRegistry cannot act in secret. The full dispute chain is always public and queryable by anyone — filter the Anchored event log for zero commitments and you have the complete governance record.
The formal model, proofs, and threat analysis are published in Trustless Provenance Trees (Moore, 2026).
06
FAQ
No. There is no token, no coin, no airdrop, and no plans for any. AnchorRegistry is infrastructure — the blockchain is the ledger, not the product. The fee you pay is for permanent on-chain registration, not for a speculative asset. This is a notary service, not a protocol.
No. There is no token, no secondary market, and no speculation. AnchorRegistry is a notary service — you are registering proof that an artifact existed in a specific form at a specific moment. The record lives on Ethereum. Nothing is minted.
There is no file upload. The manifest hash is SHA-256 of your artifact metadata — type, title, author, descriptor, type-specific fields, and your Anchor Key — computed entirely in your browser. The hash is a cryptographic fingerprint of what you declared, bound to your private key. Nothing leaves your browser except the hash itself.
Supabase stores the metadata needed to serve your verify page quickly: AR-ID, artifact type, title, author, descriptor, manifest hash, parent hash, tree ID, type-specific fields, block timestamp, and transaction hash. It also stores your Stripe payment reference (session ID) and, if you provided one, your email address for token recovery. Supabase is a fast-query cache — it is entirely rebuildable from Ethereum events if lost. AnchorRegistry does not store your Anchor Key under any circumstances. It is never sent to our servers.
The Anchor Key is a 32-byte random private credential you generate and hold. Your tree ID — keccak256(K ‖ rootArId) — is derived from it and written to every node in your tree. This means only the holder of K can produce a matching commitment on any future anchor in this tree. AnchorRegistry never has access to your Anchor Key and cannot read which trees you own. Not your keys, not your trees.
Your anchored records are permanent and unaffected — they cannot be deleted. You would lose the ability to prove tree ownership and add new nodes to that tree. Save your Anchor Key. It cannot be recovered. A token recovery flow (V1.5) will allow you to recover your AR-ID ownership token via Stripe email verification.
Yes, and it costs nothing. The manifest hash is fully deterministic — it is SHA-256 of your manifest fields and your Anchor Key. If you have your Anchor Key and remember what you registered, recompute the hash in your browser and look it up via GET /verify/hash/{manifest_hash}. Your AR-ID resolves instantly from the hash. The Anchor Key is the master recovery credential — the AR-ID is just a pointer to the record it unlocks.
Yes. Retraction is a self-service operation ($2) that attaches a RETRACTION anchor to the original record. All blockchain records are permanent and cannot be deleted — that is by design. What retraction does is signal intent: the resolution layer reads the latest state of your provenance tree and renders it accordingly, so a retracted anchor is surfaced as retracted and a replacement AR-ID, if provided, is followed automatically. The tree always reflects your most current preference. The on-chain record of everything that happened remains intact and auditable.
Sealing marks a provenance tree as authentic and complete — no new anchors may be appended. Only the tree root can be sealed, and only by someone holding the original Anchor Key. The contract enforces several conditions at registerSeal(): the anchor must be a tree root, it must not already be sealed, it must not be voided or under review, and a non-zero token commitment is required. Sealing is permanent and cannot be reversed — not by the tree owner and not by AnchorRegistry. AR governance (VOID, REVIEW, AFFIRMED) can still target anchors inside sealed trees, so sealing is not a shield against fraud findings.
Yes. "Trustless Provenance Trees: A Game-Theoretic Framework for Operator-Gated Blockchain Registries" (I. Moore, 2026) — https://arxiv.org/abs/2604.03434. The paper defines the construction formally: tree ID derivation, the keccak256(K ‖ arId) commitment scheme, Theorem 3 (governance separation via hardcoded zero commitments), and the trust model. It is the source of record for the formal guarantees users and agents rely on — everything on this page is downstream of what the paper proves.
AnchorRegistry provides a timestamped, cryptographic, independently verifiable record of what existed and when. It is strong prior art evidence and has been compared to a notary stamp with a blockchain witness. We are not lawyers and this is not legal advice. Consult counsel for your specific jurisdiction.
Base — Ethereum L2 by Coinbase. Fast, cheap, and settled to Ethereum mainnet. The contract is deployed once and cannot be modified. The contract address alone is sufficient to reconstruct the entire registry.
anchorregistry.com is the full human-facing product — registration, verify pages, docs. anchorregistry.ai is the machine-readable endpoint optimised for AI agents and pipelines. Embed anchorregistry.ai/AR-ID in any artifact and any AI or human can resolve it in one request.
Nothing happens to your records. They are on Ethereum permanently. The contract address is the registry — anyone can query it directly via Etherscan or any Ethereum RPC endpoint. The open-source anchorregistry Python package includes a recovery command that reconstructs the full registry from on-chain events alone, with no dependency on our infrastructure.
As long as Ethereum exists, yes. Base settles to Ethereum mainnet. There are no renewals, no subscriptions, and no expiry. One payment. Permanent record.
AI agents query api.anchorregistry.ai/verify/{ar_id} to resolve any AR-ID to a full provenance record. The SPDX-Anchor and DAPX-Anchor tags embedded in artifacts are the resolution triggers. When an agent encounters one of these tags it can resolve the full provenance tree, verify the manifest hash against the artifact it holds, and determine trust level.
Every flag is reviewed by a human and triggers a REVIEW anchor — a soft on-chain flag that marks the anchor as contested and opens a 14-day response window for both parties. If fraud is confirmed, a VOID anchor is attached to the parent of the fraud origin and cascades down the subtree, disabling resolution while leaving the original records permanently visible on-chain. If the finding is overturned on appeal, an AFFIRMED anchor reinstates the tree — a tree that has been challenged, investigated, and vindicated carries the strongest possible trust signal.
Yes. Anyone can register an anchor in their own tree that points at any anchor in yours — like a paper citing another paper, no consent required. The citing anchor lives in the citer's tree, not yours. Your tree is defined by your Anchor Key: only anchors you authored carry your tree's identity commitment. Structural links in the on-chain graph are public; tree ownership is cryptographic. If someone attaches a malicious child to a node in your tree, the dispute process handles it — a VOID anchor targets the fraudulent subtree's root and cascades, removing it from resolution without touching your original anchors.
Yes. Every AnchorRegistry record is stored immutably on Base L2 and can be read directly from the blockchain by anyone, with no dependency on anchorregistry.com, anchorregistry.ai, or the AnchorRegistry orchestrator. This is the core legal-and-compliance property of the system: if you need to demonstrate to a counterparty that a record exists and is authentic, you can do so independently. AR cannot revoke the record, take it offline, or alter it — and a verifier does not need to trust AR in any way.
Technical users can reach the same records programmatically. The open-source anchorregistry Python package (Apache 2.0) connects to Base via any Ethereum RPC, reads the contract's Anchored events, and reconstructs the full registry — trees, lineage, metadata — with no API key, no login, and no call to AR infrastructure.
A holder of an Anchor Key can also cryptographically authenticate a tree they own:
from anchorregistry import authenticate_tree
result = authenticate_tree(
ownership_token = K,
root_ar_id = R,
)
# result["authenticated"] == True iff
# keccak256(K ‖ R) == treeId AND
# keccak256(K ‖ C_i) == tokenCommitment_i for every anchor in the treeFull API and examples in the anchorregistry python docs.
No. The contract enforces uniqueness on manifestHash. AlreadyRegistered() reverts any duplicate. First registration wins — permanently, on-chain.
The contract source is fully open. github.com/anchorregistry/ar-contracts-v1. Or reach us at [email protected].