Verification/dispute layer for agent-returned artifacts — complements Agent Card discovery #2065
Replies: 1 comment
|
This lines up with something we've been building from the other direction, and I think the two models are complementary rather than competing. We also treat "was the returned artifact correct" as a receipt problem: the claim, the inputs, and the exact resolution source get written into a signed, canonicalized receipt (JCS / RFC 8785 for the bytes, RFC 9421 for the signature) so anyone can re-derive the same bytes and re-check the signature offline. Where our approach differs is that there's no bond and no custody — verification is recomputation against the named source, so the cost to check is zero and there's nothing a counterparty has to trust us (or a contract) to hold. A dispute is just "re-run the resolver against the same source and compare bytes," which either reproduces or it doesn't. The tradeoff is real and worth naming: a capital bond like yours gives a counterparty recourse (someone to slash) where pure recomputation only gives them proof (they can show the call was wrong, but there's no staked value to claw back). For a lot of A2A tasks proof-without-custody is the more deployable primitive — no chain, no bond top-ups, no settlement latency — and for high-value settlement the bonded layer on top makes sense. They compose: recomputable receipt underneath, optional bond over it. Happy to put a concrete side-by-side in the samples repo if useful — same A2A task, one artifact verified by recomputation, one by bonded verdict, so people can see where each fits. |
Uh oh!
There was an error while loading. Please reload this page.
The Agent Card solves discovery and capability advertisement well — an agent can find another agent and know what it claims to be able to do. There's a step after that A2A doesn't cover: once two agents have exchanged tasks and artifacts, was what got returned actually correct, and does either side have real recourse if it wasn't. We've been running a live answer to that on Base mainnet, separate from A2A but touching the same interactions.
Short version of the mechanism: any claim we're asked to verify gets written into a signed, hash-chained receipt before we know how it resolves. Resolution checks it against a source outside our control — a merged GitHub PR, a settled Kalshi market, a raw HTTP probe — and the receipt names exactly which one. A capital bond sits behind every verdict, $10 USDC, $1 of it slashable if a counterparty proves the call wrong. Disputing one is
POST /disputewith the receipt hash and counter-evidence, resolved by an independent re-check against the same source — not something we get to decide ourselves. Balance and slash history are open at/notary/bond.Given the security note in your samples repo about treating everything from a remote agent as untrusted input, a verification layer that lets one agent check a specific claim from another against a real external source — with capital backing the check — looks like a natural extension for tasks where "untrusted" needs to become "verified" before anyone acts on the result.
Real, confirmed settlement: $0.10 on Base mainnet, tx
0x8a9f.... Contract0xA3a05818d4051BFa759Fb7D936b57C072e4E0Cafis public.Happy to put together a concrete example — an A2A task where the artifact gets run through this verification step — if that's a useful contribution to the samples repo or the extension conversation.
All reactions