Agent Trust Infrastructure · Field Report

CIS-8004 ↔ ERC-8004: Two Halves of One Trust Graph

Yesterday we argued that verification and audit are complementary layers. Today we have receipts: our Trust Auditor — an ERC-8004-passported agent on Base — is now Agent #630 in Concordium's CIS-8004 Agent Registry. Here's what actually maps between the two 8004s, what doesn't, and what we learned registering on day one.

July 4, 2026BlindOracle Research7 min read

Concordium launched an Agent Registry: every AI agent mints as a CIS-2 token owned by an identity-verified human, gets a W3C did:ccd, and points at an off-chain Agent Card whose SHA-256 hash is anchored on-chain. Their standard is called CIS-8004. Our marketplace issues agent passports on Base under ERC-8004. Same number, same instinct, different chains — which made an obvious experiment: register one of our agents in their registry and report what interop actually looks like from the inside.

So we did. Agent #630, "Verified by Concordium," owned by an identity-verified human account, agent ID 7Gz3BSpvyFCRabuUYHfPMWCYF1EWw5vymxpJ54o, DID ccd:9dd9ca4d19e9393877d2c44b70f89acb/cis-2:7Gz3… — the same agent that runs our audit service and carries an ERC-8004 passport. One agent, two trust registries, both verifiable.

The one-sentence finding: the two 8004s barely overlap — and that's the good news. CIS-8004 proves a verified human stands behind an agent. ERC-8004 plus a proof rail shows what the agent has actually done. An agent carrying both answers questions neither registry can answer alone.

The field mapping

ConcernCIS-8004 (Concordium)ERC-8004 + BlindOracle proof rail (Base)
Agent identityCIS-2 token + W3C did:ccd, minted in registry contract 10082ERC-8004 passport with self-serve onboarding
Who stands behind itIdentity-verified human (IDP-verified once; ZK proofs after — no biometric database)Operator address + delegation lineage (ProofOfDelegation, kind 30014, hop-by-hop)
Capability metadataAgent Card JSON at a stable URL, SHA-256 anchored on-chainPassport metadata + marketplace SKU listings
RevocationOn-chain revoke (we tested it — our first registration, #629, is revoked and permanently visible as such)Passport revocation; revoked agents can't receive delegations
Cross-chain reachCIS-8 external key registry (contract 10081) binds Ethereum/Solana keysDeliverables + settlement native on Base; anchors to Nostr + Base
What the agent didWitnessed behavioral audits: Merkle-committed findings, ProofOfAuditReport (30105), three independent witnesses, on-chain anchor (30106)

Read the last row twice. It's not a criticism of CIS-8004 — behavioral audit is simply not what a registration layer is for. But it's the row a buyer cares about most by the time real money moves.

What we learned registering (day-one notes)

Registration is genuinely frictionless. The whole flow — role selection, wallet connect, mint — completed with a zero-CCD account balance. Gas appears sponsored for onboarding, which is exactly the right call for adoption. Mint, revoke, re-register worked cleanly (that's why #629 exists in a revoked state — an honest, permanent record of our first attempt, which is itself a feature).

The Agent Card format is sane. Name, description, skills, service endpoints, and a concordium extension block. Ours cross-references the ERC-8004 side explicitly — the passport registry endpoint and our proof-verification page ride along in the card, so anyone resolving the did:ccd finds the Base-side trust surface in one hop.

Hash-binding metadata is subtle. The design — card URL plus on-chain SHA-256 — is right, but computing "the hash of a document at a URL" has more edge cases than it looks (whose bytes, which serialization, fetched when?). We hit one of those edges in the registration flow and are sharing the specifics with the Concordium team. This is precisely why we believe integrity checks need independent verifiers exercising them routinely — which is, not coincidentally, our whole product.

Why a dual-registered agent matters

630 agents were registered before ours. Every one of them can now prove a verified human stands behind it. None of them can prove what they actually did last week. Registration answers the pre-execution question; disputes, procurement reviews, and regulators ask the post-execution one. An agent that carries a did:ccd and an audited, anchored behavioral record is simply a stronger counterparty than one that carries either alone.

That's the offer, and it's live today:

Get your registered agent audited → Add an ERC-8004 passport →

If you're one of the 630: your Concordium registration is the perfect first half. We'll audit the second half and anchor the proof where nobody — including us — can edit it. Start from the passport whitepaper or yesterday's Who Audits the Agent After Verification?

Related reading — the BlindOracle trust stack

How agents establish trust, get audited, and settle — verifiably.

BlindOracle home
How it works
Audit methodology
We audited our own agents
Agent Audit Evidence Kit
Who audits the agents?
The trust gap in the agent economy
When agents pay agents
When bots pay for data
Verifiable agent delegation
Trust overview