Single-Use Seals: An Audit Report That Can't Be Shown Twice
This month Tether is relaunching USDT natively on Bitcoin using the RGB protocol — and the primitive doing the heavy lifting is the single-use seal: a cryptographic commitment that can close exactly once. We applied the same primitive to AI-agent audit reports. A sealed attestation can now be presented exactly once, and a second presentation is rejected — with the attempt itself recorded as a proof.
Bitcoin's RGB protocol is having its moment: USDT is returning to Bitcoin through RGB's client-side validation, with settlements flowing privately over Lightning. Underneath the headline is an elegant idea called the single-use seal — a commitment bound to something that can be consumed exactly once (in RGB's case, a Bitcoin UTXO). Once the seal closes, it can never close again. That one property is what makes double-spending impossible without putting the asset data on-chain.
Reading the RGB architecture, we noticed something uncomfortable about our own stack — and, we'd argue, about every attestation system in the AI-agent economy today.
Integrity is not consumption
When BlindOracle audits an agent, the result is cryptographically strong: findings are Merkle-committed, signed as a ProofOfAuditReport, co-signed by independent witnesses, and anchored on public rails. Nobody can alter that report without detection. That's an integrity guarantee, and most of the industry stops there.
Verifiers actually need both guarantees, and they're enforced by different machinery:
| Guarantee | Question it answers | Enforced by |
|---|---|---|
| Integrity | Is this attestation authentic and unaltered? | Hashes, signatures, Merkle commitments, on-chain anchors |
| Freshness | Is this attestation recent? | Timestamps, validity windows |
| Consumption | Is this the first and only time this attestation is being presented to me? | Single-use seals — nothing else in the standard toolkit |
What we shipped
Every BlindOracle attestation can now carry a single-use seal: a signed, one-time consumable bound to the attestation's proof id. The lifecycle mirrors RGB's seals:
issue → seal minted, bound to one attestation, signed with the proof-rail key
present → the seal is redeemed atomically; the credential serves; the seal closes
replay → a second presentation is REJECTED — and the attempt itself is
recorded as a ProofOfSealRedemption (kind 30119, outcome: rejected)Three design choices worth noting:
The consumed-set never forgets. A closed seal stays closed forever. There is no rotation, no expiry of the consumption record — trimming it would silently reopen old seals, which is exactly the failure the primitive exists to prevent.
The rejection is evidence, not just an error. When someone re-presents an already-consumed seal, that attempt is signed into the proof chain. A double-presentation attempt against your audit report becomes something you can point to in a dispute.
Seals bind to one attestation only. A seal minted for audit A can never unlock credential B — the binding is inside the signature, so a mix-and-match presentation fails closed.
Why it matters for agent commerce
Agent-to-agent markets run on presented evidence: audit reports, capability credentials, delegation proofs, receipts. As soon as evidence is portable, it's replayable — an agent can shop the same clean audit to ten counterparties, or a stale credential can circulate long after the agent's behavior changed. Verification-time signature checks catch forgery; they don't catch reuse. Consumption-bound presentation closes that gap the same way RGB closes double-spends: not by trusting the presenter, but by making the second use structurally impossible.
Buyers on the BlindOracle marketplace can request a sealed presentation on any audit deliverable — the single-use seal SKU mints a seal bound to your attestation for $0.05, and the credential endpoint honors it at serve time. If you're evaluating an agent and someone hands you its audit report, the question to ask is no longer just "is this signed?" but "is this sealed — and am I the one consuming it?"
Audit an agent → Get a sealed attestation →
For the full trust architecture — passports, delegation proofs, witness attestation, anchoring, and now seals — read the Verifiable Agent Passport whitepaper.