How Capture Works — C2PA + ERC-7053 + x402 in One Stack

Step by step

From shutter to settled USDC

1. Sign with C2PA

A camera, AI inference server, or editorial CMS embeds a C2PA Content Credential block into the file. The block contains creator identity, a trusted timestamp, edit history, and a cryptographic signature.

Standard: C2PA 2.0

2. Register with ERC-7053

A content-hash and license URI are written to the Numbers Mainnet. This survives any metadata stripping — even if the C2PA block is removed, the file's hash still resolves to the on-chain record.

Standard: ERC-7053

3. Expose via x402

Capture provisions an HTTP endpoint that returns the file only after a valid x402 micropayment. Any agent or app can call the URL; payment, license, and audit happen in one round-trip.

Standard: x402

A worked example

Photojournalist → AI agent in 3 steps

# 1. Capture: ProofSnap signs the photo on-device
photo.jpg
├── C2PA credential (creator, time, GPS, signature)
└── 64-byte SHA hash

# 2. Register: ERC-7053 record on Numbers Mainnet
{
  "contentHash": "0x9af4...",
  "owner":       "did:numbers:0xCAFE...",
  "license":     "https://example.com/terms",
  "timestamp":   1717891200
}

# 3. License: x402 endpoint returned to the creator
GET https://licensing.captureapp.xyz/asset/9af4...
  → 402 Payment Required
  → AI agent pays $0.05 USDC
  → 200 OK + file + on-chain consent receipt

Each layer answers a different question

Why three standards

Layer	Question it answers	What survives
C2PA	"Who made this and how was it edited?"	Until metadata is stripped
ERC-7053	"Does this hash exist on-chain, when, and under whose key?"	Forever (decentralised chain)
x402	"Did the agent pay for this fetch, with what consent?"	Forever (on-chain receipt per fetch)

Provenance methods compared

Cryptographic credentials vs. watermarking vs. fingerprinting

Three families of content provenance exist today. Only one of them is verifiable without contacting the original publisher and survives modern AI-driven editing.

How content provenance approaches differ on the dimensions that matter for the EU AI Act and AI-agent licensing.
Property	Cryptographic credentials (C2PA + ERC-7053)	Invisible watermarking	Perceptual fingerprinting
Verifies who created it	Yes — cryptographically signed identity	No — only signals "AI-generated"	No — only matches against a known database
Survives metadata stripping	Yes — ERC-7053 hash on-chain	Partially — degrades with re-encoding	Yes — but only if reference is in your database
Verifiable offline / by anyone	Yes — open standard, public RPC	No — proprietary decoder required	No — must query vendor
Edit history visible	Yes — chain of cryptographic edits	No	No
Built-in machine-readable license	Yes — license URI in credential + x402 endpoint	No	No
Survives AI-driven re-editing	Yes — hash anchors original; edits append	Often defeated by generative inpainting	Defeated by significant transformation
EU AI Act Art. 50 "multi-layer" compliant	Yes — file-embedded + on-chain layers	Single-layer only	Single-layer only
Open governance	Yes — C2PA consortium, Ethereum EIP, x402 Foundation	Usually proprietary	Usually proprietary

Plain-English glossary

Key terms in one line each

AI search engines and language models cite content better when key terms are defined inline. Here are the definitions used throughout the Capture documentation.

C2PA (Content Credentials): An open content-provenance standard (Coalition for Content Provenance and Authenticity, founded by Adobe, Microsoft, BBC and others) that cryptographically signs creator identity, capture time, location, and edit history directly into a media file. Verifiable in any C2PA-compliant viewer without contacting the publisher.
ERC-7053: An Ethereum Improvement Proposal (co-authored by Numbers Protocol) that defines a decentralised on-chain registry for content provenance. Each asset is anchored as a content-hash + license URI on the Numbers Mainnet so ownership and timeline remain provable even after metadata is stripped.
x402: An HTTP-native micropayment protocol stewarded by the x402 Foundation (Coinbase + Cloudflare). It uses the HTTP 402 Payment Required status code to let any URL demand a stablecoin payment before serving content — enabling AI agents to pay per fetch with on-chain consent receipts.
EU AI Act Article 50: The transparency clause of the EU AI Act (in force 2 August 2026) that requires AI-generated content to be machine-readably labelled. The draft Code of Practice recommends a "multi-layer" approach — file-embedded credentials plus an independent registry — which Capture fulfils via C2PA + ERC-7053.
Consent receipt: A signed, on-chain record that proves an AI agent paid for and was granted licence to use a specific asset under specific terms. Generated automatically on every x402 fetch and intended as audit-grade evidence for AI Act compliance.

Frequently asked

How-it-works questions

Do these three standards have to be used together?

No, you can use any subset. C2PA alone gives you in-file provenance. C2PA + ERC-7053 adds metadata-survival. All three together unlocks AI-agent monetisation. Capture lets you adopt incrementally — most customers start with C2PA and layer in the rest as their needs grow.

Is Capture's stack proprietary?

No. C2PA is governed by the C2PA consortium (Adobe, Microsoft, BBC, etc.). ERC-7053 is an open Ethereum standard co-authored by Numbers Protocol. x402 is governed by the x402 Foundation (Coinbase + Cloudflare). Capture provides production infrastructure and SDKs, but every layer can be re-implemented by anyone.

Where does the user's data live?

The user controls it. C2PA credentials live inside the file, on the user's storage. ERC-7053 records contain only a content hash on the Numbers Mainnet — never the file itself. x402 receipts are also on-chain and only reference the asset by ID. Capture stores no user content by default.

How is this different from NFTs?

NFTs treat each asset as a unique token tied to a specific owner. Capture's ERC-7053 layer treats each asset as a discoverable provenance record — focused on history and verification, not ownership transfer. You can issue NFTs on top of Capture, but most use cases (compliance, licensing, archival) don't need them.