Verify a credential

Paste a credential ID or receipt. We show the result and the raw materials, so you can re-check it yourself — no DCS account needed.

Tip: append /verify.html?cid=sha256:… to deep-link straight to a result.
How to use

What can I enter, and what comes back?

Three kinds of input — no account needed. Everything here is public and independently re-checkable.

1 · Session ID — verify a whole build
1e477d1d-abed-4248-86d6-bff63c41aa04

A build's ID (a UUID). Returns the full receipt chain for that build — “verified · N in chain · signed · anchored” — with every run linked together. Find it in your dashboard history under the Project / build column, or on the build's certificate.

2 · Receipt CID — verify one receipt
bafkreigdygiu7qgglx6qi6c3izcqkgyxwimft446utcvvg5n75ivy3fzau

An IPFS address for a single receipt (starts with bafk/bafy). Returns “content verified — these bytes hash to this CID” plus the receipt's kind, runs, signature, and chain links. This check runs in your browser, so it works even when our servers are down. Find CIDs on the certificate PDF, the Explorer feed, or any “View on IPFS” link.

3 · Receipt JSON — paste the raw record
{ "kind": "build_complete", "session_id": "…", "signature": { … } }

Paste the whole receipt object to re-check its hash and signature. Optionally paste the original document too, to confirm it still matches the stored hash.

What the result means

✓ Content-address match — the bytes are exactly what the CID commits to (tamper-evident).
✓ Signature valid — signed by the issuer's Ed25519 key.
✓ Anchored on Base — the chain's root is written to Base mainnet.
N in chain — how many linked receipts that build produced (one per run, plus lifecycle receipts like build_complete).

If you see an error

“Could not reach the verification service” → the credential API is briefly down. Use a Receipt CID instead — it verifies in-browser with no server — or retry shortly.

“Couldn't load that CID from the gateway” → check the CID for typos, or open the raw JSON link directly. A brand-new receipt can take ~1 minute to propagate to IPFS.

“Content hash does NOT match this CID” → those bytes were altered — don't trust that copy. Re-fetch from the official source.

“That's a receipt CID, not an issuer” → you're on the Registry. A receipt belongs on Verify or the Explorer; the Registry is for issuer profiles (e.g. ?issuer=dcslabs).

FAQ

Frequently asked questions

Receipts, chains, IDs, and how independent verification works.

What is a DCS receipt?
A receipt is a cryptographic record of one AI action — what happened, when, which system did it, and a fingerprint of the result. Unlike a log, it's signed and content-addressed, so anyone can verify it later without trusting us.
Session ID vs Receipt CID vs hash — what's the difference?
A Session ID (a UUID) identifies one build, which contains many receipts. A Receipt CID (bafk…) is the IPFS address of a single receipt. A sha256:… value is a content fingerprint. Rule of thumb: paste a Session ID to verify a whole build, a CID to verify one receipt.
How many receipts does a build create?
One per recorded action (run), plus a few lifecycle receipts (build_complete, memory_write). So 10 runs ≈ 11–12 in chain, and 50 runs ≈ 52–53 in chain. The count tracks actions, not agents — one agent can take several actions.
What does “N in chain” mean?
The number of receipts linked together for that build. Each receipt carries the hash of the one before it (prev_receipt_cid), forming a tamper-evident chain — change any receipt and every later link breaks.
Do I need an account to verify?
No. The Verify, Explorer, and Registry pages are fully public. Anyone can paste an ID and re-check the result — that's the whole point: trust you can't inspect isn't trust.
What does “anchored on Base” mean?
The chain's Merkle root is written to Base mainnet (an Ethereum L2) in a single transaction. That timestamps the receipts on a public blockchain and proves they existed at that moment and haven't changed since.
Can I verify a receipt without DCS at all?
Yes. Fetch the JSON from IPFS (gateway.lighthouse.storage/ipfs/<cid>), recompute its SHA-256 to confirm it matches the CID, and check the Ed25519 signature against the issuer's published key. The reference verifier is open — our servers are a convenience, not a dependency.
What happens if someone edits a receipt?
Its content hash changes, so it no longer matches its CID, and the chain link from the next receipt breaks. Verification fails immediately and visibly. Tampering can't be hidden.
Where do I find my Session ID or CID?
In your dashboard's transaction history (the Project / build column links each build), on the build's certificate PDF, or in the Explorer network feed. Any “View on IPFS” link is a CID.
Why does something say “temporarily unavailable”?
The issuer registry/credential API may be redeploying. Receipt verification by CID still works independently, because it's content-addressed and checked in your browser. Issuer trust scores return once that service is back.
Is my private content exposed in a receipt?
No. A receipt holds action metadata — kind, timestamp, hashes, cost, energy — not the underlying private data. It carries only what's needed to prove the action happened, nothing more.
Which standards does this use?
The open R-Series: R+2 signed receipts (Ed25519 + RFC 8785 JCS canonicalization + SHA-256), R+3 post-quantum hybrid co-signatures, and R+4 zero-knowledge proofs. See the R-Series standard on dcslabs.ai.