How Condu.ID works

Condu.ID is a public, opinion-free name service for AI agents and the MCP servers that host them. It maps a stable decentralized identifier back to its DID document, surfaces the receipts that identifier has signed, and gives you the cryptographic evidence to verify both without trusting our infrastructure.

The identity layer

Every server registered on Condu.ID has a did:web identifier — a URL-anchored DID whose document lives at a well-known path on the server's own domain. Every agent operating under that server gets a child did:web, with the parent DID listed as its controller in the DID document.

Receipts themselves are signed with did:key — a self-contained DID method where the public key is recoverable directly from the identifier. That's deliberate: it means the signature on a receipt can be verified even if Condu.ID, the server's domain, and every DNS provider on Earth simultaneously go offline. The key travels with the receipt.

The receipt format

Receipts conform to RCPT Protocol — an open spec for verifiable AI agent action receipts. Each receipt declares an action type, a signer, the canonical bytes of the action's input and output, and an Ed25519 signature over the whole envelope.

The canonicalization is RFC 8785 (JCS — JSON Canonicalization Scheme). That's the only safe way to canonicalize JSON for signature: stable key order, stable number formatting, stable string escaping. Two implementations following RFC 8785 produce byte-identical output, which is a non-negotiable for cross-language signature verification.

The signature itself is Ed25519 per RFC 8032 — over the canonical bytes directly, with no SHA-256 pre-hash. Pre-hashing breaks interoperability with the standard library Ed25519 verifiers, and it breaks the non-repudiation claim. RCPT receipts must be verifiable by `crypto/ed25519` in Go, `cryptography` in Python, and `@noble/ed25519` in TypeScript without special configuration.

The anchor

Receipts are batched into a Merkle tree and the root is written to Solana. Solana isn't load-bearing — the receipt and its Ed25519 signature stand on their own. The anchor adds two properties: a public timestamp (the slot the merkle root landed in) and tamper-evidence (you can prove a receipt was part of a batch recorded before some later event).

We chose Solana for cost and confirmation latency. Devnet is fine for development; production batches go to mainnet. The merkle proof shipped with each receipt lets you reconstruct the leaf hash, walk up to the stored root, and check on-chain confirmation yourself.

The verifier

Condu.ID's API has a /v1/receipts/:id/verify endpoint, but it carries an authoritative=false flag and a notice: client-must-verify field. That isn't decoration — it's the architecture. The server will tell you what it thinks, but the answer that counts is the one your browser computes.

Every receipt page on this site re-runs five checks locally:

1. JCS canonicalization. Re-encode the receipt body via RFC 8785 and confirm it matches what the server returned.
2. Ed25519 signature. Recover the signer's public key from did:key, verify the 64-byte signature over the canonical bytes.
3. Delegation chain. If a delegation block is present, structurally validate it. (Full chain validation lands in v1.1.)
4. Merkle inclusion. Hash the canonical body, walk the proof's siblings, confirm the computed root matches the stored root.
5. Solana confirmation. Open a connection to a public Solana RPC directly from your tab and require a finalized confirmation for the anchor signature.

Step five is the one the server cannot do for you in a trustworthy way. If our resolver tells you a transaction is confirmed, you have to trust our resolver. If your browser asks a public Solana RPC and gets back a finalized status, you have to trust the Solana validator set. The latter is a much bigger trust set, and that matters.

Why neutral matters

Condu.ID is intentionally separate from any commercial layer. The same infrastructure that powers a marketplace would discourage a competing marketplace from adopting the identity layer. By keeping resolution and verification neutral, we make it easier for ecosystems that don't trust each other to share the same identity substrate.

The protocol is open. The code is public. The verification is done in your browser. If we disappear tomorrow, the receipts you've already collected are still verifiable on someone else's resolver — or with no resolver at all.