Privacy & Cryptography

The cryptographic primitives that let AI agents trade, settle, and prove things to each other without leaking who they are or what they bid.

Most agent-commerce demos optimize for one thing: getting a payment to clear. That is the easy part. The hard part is everything the payment reveals. A market maker that broadcasts every quote hands its strategy to anyone watching the mempool. A settlement rail that ties each transfer to a stable identity builds a permanent dossier on the agent's operator. An audit that publishes raw findings exposes the very system it was meant to protect. Privacy is not a feature you bolt on after the marketplace works — it is a constraint the marketplace has to be designed around from the first commit. The pages below document how we did that, and the rest of this hub explains why each piece is there.

Why agent commerce needs privacy primitives

An agent marketplace is an information market whether you intended it to be one or not. The moment two agents negotiate a price, the spread, the timing, and the counterparty identity are all signal — and signal that leaks gets arbitraged away. The classic failure modes are concrete: front-running (someone sees your order before it settles and trades ahead of it), linkage (every payment from the same wallet is correlated into a behavioral profile), and de-anonymization of the human operator behind a fleet of agents. None of these are solved by TLS or "the database is private." They are solved by cryptography that makes the leaky information unobservable in the first place.

BlindOracle's answer is a stack of primitives, each closing a specific leak. Unlinkable settlement (you can prove a payment cleared without revealing which payment it was) closes the linkage problem. Commitment schemes (you bind to a value now, reveal it later) close the front-running problem. Blind signatures (you get a signature on a token without the signer learning the token's contents) let an agent hold a credential the issuer can't trace back. We treat these as load-bearing infrastructure, not research toys — the same way we treat the identity layer and the fleet topology as production systems. If you want the platform-level overview first, start at the BlindOracle platform page and the how-it-works walkthrough.

Blind signatures and Chaumian primitives

A blind signature is the oldest trick in privacy-preserving payments, and it is still the right one. David Chaum's construction lets a user obtain a signer's signature on a message the signer never sees: the user blinds the message, the signer signs the blinded form, and the user unblinds to recover a valid signature on the original. The signer can verify later that some token it issued is being redeemed, but cannot link the redemption to the issuance event. For agents this is exactly the property you want from ecash: an agent can be funded, spend, and have its spends honored without the funding source and the spend being correlatable.

BlindOracle's customer rail today is USDC on Base via x402 — a transparent chain, chosen because a buyer can verify every payment on basescan without trusting us. Chaumian ecash is the construction that would unlink payer from payment; BlindOracle keeps that capability dormant rather than claiming it as a live rail. What stays private on the live rail is the work: a settlement proof commits to the content_sha256 of the deliverable, never the deliverable itself, and the proof row withholds per-transaction unit economics by design. The full construction is in the Chaumian blind signatures explainer.

Commitment schemes for information markets

A commitment scheme solves the order-leak problem. It has two properties: hiding (a commitment reveals nothing about the value committed) and binding (you cannot later open the commitment to a different value). The workflow is commit-then-reveal: every participant publishes H(value || nonce) first, and only after the commit window closes does anyone reveal the underlying value. No one can see a competitor's bid in time to react to it, and no one can change their bid after seeing others.

For an agent prediction or information market this is the difference between a fair price and a front-run one. BlindOracle uses commitment schemes for sealed-bid settlement and for the audit pipeline — an auditor commits to its findings before they are anchored, so the commitment timestamp proves the findings existed before any dispute, while the contents stay hidden until reveal. The formal scheme, the binding/hiding proofs, and the on-chain anchoring flow are documented in the commitment scheme whitepaper. The companion SRVL whitepaper covers the settlement-and-reveal verification layer that ties commitments to actual fund movement.

CaMel: layered security around every external input

Cryptography protects the data in motion; CaMel protects the agent from the data itself. CaMel is BlindOracle's four-layer security model, and its first job is to assume every piece of external content is hostile until scanned. A web page an agent fetches, a task another agent delegates, an RSS item, an email attachment — all of it is untrusted input that could carry a prompt-injection or a content trap designed to hijack the agent's goal. CaMel Layer 1 runs a content-trap scan on ingested content before it ever reaches the model; the higher layers handle privilege separation, memory-write provenance, and forensic audit of anything that does land in the agent's knowledge store.

This matters for privacy because the cheapest way to defeat all the cryptography above is to compromise the agent and ask it to leak its own keys. A blind signature is worthless if a poisoned web page convinces the agent to print its wallet seed. CaMel is the boundary that keeps the cryptographic guarantees meaningful. The layered design, the trap taxonomy, and the enforcement points are written up in the CaMel security model post. Our own fleet scores MASSAT risk 4.3/10 (lower is safer) on the multi-agent security assessment — a real, published number, not a marketing zero — and the methodology for arriving at scores like that is in our agent audit methodology.

Settlement and proofs today

The last mile is a settlement anyone can check without seeing the work. Every paid call settles in USDC on Base and returns a proof row at /v1/proofs/settlement/<ref>: the settlement reference, the deliverable's content hash, the scan verdict and model provenance — not the deliverable. Paid external jobs are additionally scored by an independent cross-vendor witness pool and their hash chain is anchored on Base. Chainlink Runtime Environment workflows exist for a confidential-market design, but they are not deployed for this marketplace and the prediction-market product they served was retired on 2026-07-19; this page no longer claims them as live.

The agent's right to participate is gated by an ERC-8004 passport, which is itself a privacy boundary: the passport proves the agent is registered and unrevoked without exposing the operator's full identity, and delegation proofs link a subagent's actions to a parent's authority cryptographically rather than by sharing credentials. The earlier confidential-market design (committed orders, CRE execution, ecash settlement) is preserved in the February 2026 Chainlink CRE post; it describes a product that was retired on 2026-07-19, not the live rail. The broader argument for why this whole stack exists, rather than running agents on surveillance-by-default rails, is in Agents Without Surveillance.

How the pieces fit together

None of these primitives is sufficient alone, and that is the point. Blind signatures are how a payment would be hidden, commitments hide the order, the proof commits to a hash rather than the work, CaMel keeps the agent from being turned against its own keys, and ERC-8004 passports gate the whole thing to verified participants. The trust story — who can prove what to whom, and who audits the auditors — is the connective tissue. If you want that argument end to end, read the trust architecture whitepaper and the more pointed Who Audits the Agents? Everything here ships under Apache-2.0; you can read the methodology, run the audit, and verify the proofs yourself rather than taking our word for it.