An advertiser agent posts a campaign. Publisher agents bid in a live auction. Budget is escrowed per impression batch on Masumi — and when one publisher serves bot traffic, the fraud judge fires and the money comes back. Automatically. With evidence.
A simulated run of the full 2-minute submission flow — campaign brief → live auction → escrow → impression serving → fraud alert → auto-refund → receipt. Play it end-to-end, or step through phase by phase.
Track rule, verbatim: “An agent completes a transaction scenario with a visible outcome. A sandbox transaction counts; a simulated payment must be labelled.” — every money movement in this console is a simulation, labelled as such.
Spider AF (H1 2026): $25.3 billion lost to invalid traffic, a 5.58% fraud rate — roughly $1 of every $18 in ad spend. Bot farms, datacenter click loops, spoofed impressions. Humans built dashboards for this. Agents won't read dashboards — they need the refund to be automatic.
AI agents will negotiate placements, budgets and audiences at machine speed — overnight, unsupervised. Nobody hands an agent a credit card without proof the impressions were human. The missing piece isn't the auction. It's the trust layer: every batch escrowed, verified, and refundable by policy, not by support ticket.
The clean division we enforced all night: Masumi provides identity, discovery, escrow, payment states and audit anchors. We never rebuilt any of it. Our entry is the auction engine, the fraud evaluator, and the wrapper UI.
| Masumi primitive | How this scenario uses it | Why it's essential |
|---|---|---|
| Agent identity (DIDs) | did:masumi:techblog-07, did:masumi:devnews-02, … | Reputation attaches to someone — repeat fraud is visible |
| Service discovery (registry) | Find publishers by audience / vertical before the auction | No auction without bidders you can find |
| Escrow | €18 locked in 9 per-batch slices (3 per winner) | Advertiser doesn't trust publishers; publishers don't trust advertiser |
| Payment state machine | FundsLocked → ResultSubmitted → Settled | RefundRequested | The visible money lifecycle the demo narrates |
| Dispute states | Fraud flag → RefundRequested / Disputed path fires | Invalid traffic is a first-class state, not an exception |
| Decision logging | Immutable bid log; sha256 of impression reports + fraud verdicts | Audit anchor for “who won, and why that batch was refunded” |
| Explorer | Raw chain view linked from the receipt | We build the ticker and receipt on top |
In plain UI language: Draft → Bids in → Winners picked → Budget reserved → Serving → Report in → Fraud check → Paid / Refunded. The demo animates all 9 slices through this machine in the settlement phase.
Five criteria, 0–5 each. A 3 on end-to-end = “one complete core scenario works.” A 5 = “works convincingly and handles an important failure case.” Our failure case IS the demo's main event.
The track rule says a simulated payment must be labelled — so here's the boundary, in writing, exactly as we'd show the jury.