Cardano
label 2222.
AI anchoring.

Short version.

Cardano transactions can carry arbitrary metadata under numerically-keyed labels. CIP-10 establishes the labels registry so labels do not collide between protocols. Label 2222 is the label used by Orynq for anchoring AI-inference Merkle roots (and the wider Materios partner-chain pattern). The label was chosen for visual mnemonic (four 2s, like “to two” — sender + receiver, system + auditor) and is registered with the protocol's schema in the Materios documentation set.

The schema fields are minimal: a Merkle root hash, a manifest hash, a trace identifier, a version tag, and an optional payer. Cost is ~0.2–0.3 ADA per anchor at protocol-parameter levels as of 2026; throughput is bounded by Cardano block production (~20-second slot, with practical bundling letting throughput scale well above one anchor per block).

This guide unpacks the schema, the cost arithmetic, the verifier flow, and how the same label composes with the Materios partner-chain Merkle-root pattern.

Cardano transaction metadata.

Every Cardano transaction can carry an auxiliary data structure of metadata. The shape is a map from 64-bit unsigned integer labels to arbitrary CBOR-encoded values (strings, integers, byte strings, lists, maps). Constraints: any single metadatum string is limited to 64 bytes; nested structures are allowed; total size is bounded by the protocol max-transaction-size parameter.

Two important properties of Cardano transaction metadata:

• Metadata is part of the transaction body (via the auxiliary data hash committed inside the transaction body). It is signed by the transaction's witnesses and becomes immutable once the transaction is on-chain. It cannot be edited after the fact.
• Labels are coordinated via CIP-10. The CIP-10 registry maintains a list of in-use labels (e.g. 721 for CIP-25 NFTs, 674 for Cardano message signing). Protocols register their chosen label there to avoid collision.

The reason this matters for AI auditing: Cardano metadata is the smallest, cheapest, most chain-native way to commit a hash to the ledger. No smart contract, no token, no UTxO bookkeeping — just a labelled blob signed by the submitter, anchored by consensus.

The 2222 schema.

Under label 2222, Orynq writes a small map with the following fields. Field names are chosen to be self-describing in a Blockfrost or Cardanoscan UI that shows the raw decoded metadata.

• v — schema version. Integer. Current value is 1. Reserved for forward compatibility; a 2222-v2 schema would carry additional fields without breaking existing verifiers.
• root — Merkle root. 32-byte hex string (66 chars with the “0x” prefix elided). SHA-256 of the trace's Merkle tree. This is the substance of the anchor — the cryptographic commitment to the bundle of inference events.
• man — manifest hash. 32-byte hex string. Hash of the model manifest (model checkpoint + tokenizer + system prompt + training-data fingerprint). Pins model state to the trace at anchor time.
• tid — trace identifier. UTF-8 string up to 64 bytes (Cardano metadatum limit). The operator's internal trace ID. Allows cross-reference to observability and storage layers without leaking trace contents on-chain.
• ts — operator timestamp. Unix epoch integer (seconds). The operator's asserted time of trace close. The chain's block timestamp is the authoritative time; ts is for cross-referencing the operator's clock.
• pay — payer ID (optional). For managed Anchor-as-a-Service: which customer the anchor was paid for. Omitted in self-hosted mode.

The schema is intentionally minimal. Anything richer (inputs, outputs, intermediate events) stays in the off-chain bundle that hashes to root. This is consistent with the Cardano on-chain philosophy: only what must be on-chain goes on-chain.

How label 2222 composes with other CIPs:

• CIP-25 (NFT metadata, label 721). No interaction. A single transaction can carry both label 721 NFT metadata and label 2222 anchor metadata — the labels are independent.
• CIP-68 (datum-based NFTs). Orthogonal. CIP-68 stores reference metadata in a datum; label 2222 stores an anchor in transaction metadata. A datum-based NFT could carry an anchor reference; the patterns do not conflict.
• CIP-30 (wallet connector). Used at the submission layer. Wallet signs the metadata-bearing transaction like any other.

Cost & throughput.

Cardano transaction fees are deterministic: a base fee plus per-byte size component, plus an additional cost if the transaction includes scripts. Anchor transactions carry only metadata — no scripts — so the fee is the floor.

For a minimal one-input, one-output, no-script anchor transaction with the 2222 metadata blob (~250–300 bytes encoded), the fee as of 2026 protocol parameters sits in the range of 0.17 to 0.20 ADA. The output must satisfy the min-ADA requirement (currently approximately 1.0–1.5 ADA depending on output size), but that ADA is returned to the submitter — it is not burned. The net cost is the fee, not the full transaction value.

Practical round numbers we cite on the rest of the site: ~0.2–0.3 ADA per anchor end-to-end. At ADA prices in the $0.30–$0.70 range, that is roughly $0.06–$0.21 per anchor — the cheapest credible on-chain audit primitive available on a mainstream public chain.

On throughput: Cardano produces a block roughly every 20 seconds on average, with a max-block-body-size of 90 KB. An anchor transaction is on the order of 500 bytes including the witness set; theoretical ceiling is ~180 anchors per block, or ~9 anchors per second. In practice anchors share blocks with all other Cardano transaction types, so realistic sustained throughput from a single submitter is well below the ceiling. For workloads that need higher rates, anchor a Merkle root of many traces (batching) — each anchor commits to N inferences with the same per-block overhead.

Comparison points: Ethereum L1 calldata anchoring costs $0.50–$5 depending on gas; Bitcoin OP_RETURN anchoring is ~$1–$10 depending on mempool. The closest equivalents on Cardano-adjacent infrastructure — Hydra heads, Mithril certificates — are different primitives; the direct comparison is L1 metadata.

Verifying an anchor.

An anchor is useless if a third party cannot verify it independently. Three verification paths are supported, in order of integration depth.

1. 01

   Cardanoscan UI.

   Paste the anchor transaction hash into cardanoscan.io . The metadata section shows label 2222 decoded with the schema fields. Block timestamp gives the authoritative anchor time. No login.

2. 02

   Blockfrost API.

   A single REST call: GET /txs/{hash}/metadata. Returns the metadata as JSON. Filter by label 2222 to extract the anchor fields. Programmatic verification path.

3. 03

   Orynq open verifier.

   Given a bundle and a transaction hash, the open verifier computes the Merkle root from the bundle, fetches the anchored root from Cardano via Blockfrost, and confirms they match — proving inclusion. Open-source; runs locally; no Orynq service required.

The verifier flow specifically does not require trust in Flux Point Studios or any Orynq-operated service. Any party with the bundle and the transaction hash can verify against a Cardano node of their choosing.

Composing with Materios.

Direct L1 anchoring at 0.2–0.3 ADA per anchor is plenty cheap for most workloads. For two cases it is not enough: very high per-trace volumes (millions of inferences per day per operator), and use cases that need an extra layer of governance certification beyond a single anchor signature.

The Materios partner chain addresses both. It is a Cardano-aligned chain optimized for AI agent settlements that aggregates many Orynq traces, lets a witness committee certify the aggregate, and anchors the Materios block root back into Cardano L1 under the same label 2222. From a verifier's perspective:

• A single Cardano L1 transaction carries the Materios block root under label 2222.
• The Materios block carries a Merkle aggregate of many trace roots.
• Each trace root commits to the full Merkle tree of its inference events.

Three layers of Merkle inclusion, one L1 transaction. Cost amortizes across all anchored traces in the Materios block; throughput rises with Materios block production rate. The verifier path is the same label-2222 read on Cardano, plus a two-level inclusion proof against the Materios block and the trace bundle.

Read the longer story at /materios (partner chain overview) and proof-of-inference: anchoring deep dive.

Common questions.

• Why label 2222 specifically? It was an unused label at the time we adopted it (verified against CIP-10), short enough to be memorable, and visually mnemonic (four 2s — “to two,” system speaking to auditor). Any unused label would work technically. The point is registration and stability, not the numerology.
• Is label 2222 registered in CIP-10? The schema and label are documented in the Materios documentation set; we are coordinating the registration process in the CIP-10 registry. Label uniqueness in practice is established by published schema + production usage; the registry update follows.
• Can other protocols use label 2222 too? They could technically — Cardano does not enforce label ownership at the protocol level — but CIP-10 exists exactly to prevent overlap. We expect 2222 to remain the AI-anchor label by convention.
• What if I want to use a different chain? The schema is chain-agnostic. The same Merkle root can be anchored to Ethereum (more expensive), Bitcoin via OP_RETURN (more expensive, smaller payload), or another chain. The economics of Cardano L1 metadata happen to be very favourable for this workload; nothing prevents multi-chain anchoring as a belt-and-suspenders pattern.
• Does this require an ADA wallet? Self-hosted yes — the submitter pays the fee in ADA from its own wallet. Managed Anchor-as-a-Service abstracts this via x402 / Flux payments; the customer pays in stablecoin or Flux credits and the AaaS service submits the Cardano transaction.
• Can I read all anchors written by a specific operator? Yes — Blockfrost lets you query metadata by label across the chain, filter by the submitter address, and reconstruct the operator's anchor history. This is a feature, not a leak — public auditability is the point.