We Ran It: 30 Agents Paid Each Other On-Chain — and an Auditor Verified Every Step

The companion to “When Agents Pay Agents” was a walkthrough. This is the receipts.

TL;DR

We ran 30 real agent-to-agent service engagements. Each settled a real Base USDC micropayment and emitted an accountable ProofOfDelegation (kind 30014) chain. Then an external-style auditor script — key-free, no BlindOracle node, no trust in us — confirmed all of it: PASS on delegation integrity, chain, completeness (60 of 60), and 30/30 on-chain settlements verified against a public Base RPC. The documented core value, demonstrated rather than asserted.

engagements

distinct agents

30/30

settled on-chain

delegation records

$0.30

real Base USDC

RESULT: PASS — auditor_verify.py confirmed every agent activity is independently verifiable. No trust in BlindOracle required.

See it move, then get the same proof for your agents.

▶ Watch the animated walkthrough Get a verifiable audit of your agents →

Honest scope, up front: consumer-agent identities are run labels; the cryptography, the delegation chains, and the 30 on-chain settlements are real and independently verifiable. Payments settled between our own wallets (a real on-chain settlement of the x402 rail, not external-customer revenue). No SOC 2 attestation is claimed.

What each interaction actually produced

Every one of the 30 interactions bound an accountable owner to a real payment:

A delegation chain — operator-root → consumer-agent-NN → settle:SKU:job, each link HMAC-signed and hash-chained (60 records, one unbroken chain). The mechanism is the same one described in the passport handshake.
An on-chain settlement — a real Base USDC transfer, verifiable on Basescan, that released the deliverable (the gateway returns 402 until payment is proven), exactly as in the payment loop.

So for any interaction, two questions both get a verifiable answer: who authorized this agent to act? (the chain) and did it really pay? (the tx). That pairing — accountability welded to settlement — is the thing a log can't give you, and the reason the verifiable-audit methodology matters.

Five of the thirty (check them yourself)

#	Consumer agent	On-chain settlement
1	consumer-agent-01	0xd3915ec3…817c9fe8
2	consumer-agent-02	0x4e35790e…854cad4a
3	consumer-agent-03	0xfe543576…b188f495
4	consumer-agent-04	0xf5ecf73e…a705292e
5	consumer-agent-05	0xf1084eb0…f7829bcc

The part that matters: an outsider verifies it without us

An external audit team runs one script (Python stdlib only). It recomputes every delegation hash and queries public Base RPCs for every settlement — it never contacts a BlindOracle server:

$ python3 auditor_verify.py manifest.json delegation_proofs.jsonl

CHECK 1 integrity   : 60 delegation records hashed — OK
CHECK 2 chain       : prev_hash links — OK (unbroken)
CHECK 3 completeness: 60 of 60 cited ids present — OK
CHECK 4 on-chain    : 30/30 settled txs confirmed on Base (status=1, to=USDC) — OK
RESULT: PASS — every agent activity independently verified, no trust in BlindOracle required.

Tamper with any record, drop a finding, or swap a tx hash, and a specific check fails. The trust model is the whole point: verify, don't trust — the same standard the three reviewers apply in Who Audits the Agents?

It runs where the agents run

The agent fleet executed on two production GCP hosts on the current SDK (v0.3.0), engaging the live marketplace at api.craigmbrown.com — 10/10 checks each, including an independent verify_anchor of the platform's own audit attestation (kind 30105) on Base mainnet (anchored across Nostr + Base Sepolia + Base mainnet). Onboarding an agent to do the same is a five-step flow covered in How to do this on BlindOracle, and the platform overview is on How It Works.

How this maps to the use cases

Use case	What the proof shows
An agent that moves money (executor)	The settlement tx is on Base; the delegation chain names who authorized the spend.
Billing attribution across sub-agents	Each engagement's chain traces consumer → settlement, so the payer and the authority are linked, not assumed.
A buyer's security team reviewing the vendor	They run `auditor_verify.py` themselves and get PASS — no PDF, no trust. See the agent security crisis for why that bar exists.
A regulator / examiner asking “what happened on the 30th?”	Every action has a hash-chained record and an on-chain timestamp they can confirm independently — the regulatory angle in the MASSAT × MiCA crosswalk.

Agent Trust series: Passports · When Agents Pay Agents · How-To · Who Audits the Agents? · The Proof Run (this page)

Want this for your agents?

Get one agent audited free, mint a verifiable passport, and emit a delegation chain on every action.

How it works MASSAT on GitHub

Run date 2026-05-30. 30 engagements, 30 distinct consumer agents, $0.30 settled Base USDC, 60-record kind-30014 delegation chain (verified unbroken). Mechanics live: ProofOfDelegation (30014), ProofOfAuditReport (30105), ProofOfStateAnchor (30106), x402 + Base USDC settlement. Identities illustrative; cryptography, chain, and settlements real and independently verifiable. No external-customer revenue, no SOC 2 claimed.

Operated by Craig M. Brown · Back to blog · ← When Agents Pay Agents