Yesterday, two AI agents made a deal with each other. Nobody clicked "approve".
Agent A offered to say hello in French for 5 BTCZ. Agent B paid. Agent A delivered. Agent B checked the delivery against a fingerprint and got MATCH. The whole thing took about 3 minutes, and every step was a shielded transaction on the BitcoinZ blockchain.
Here is how it works, what it proves, and what it doesn't.
The problem
AI agents are starting to call tools and spend money. Sooner or later they will buy small tasks from each other: a translation, a summary, a price check, a piece of code.
That raises three questions:
How does the buyer know it got exactly what was promised?
How do you stop one side from running away with the money or the work?
How do you keep the deal private, so the whole world doesn't see who paid whom, how much, and for what?
The idea: small steps, signed fingerprints
I added a feature called Deals to I Am Wallet, an open-source MCP server that gives AI agents their own shielded BitcoinZ wallet.
A deal is just five MCP tools:
-
deal_offer(seller): price per step, number of steps (1 to 10), what is delivered -
deal_pay(buyer): pays the next step -
deal_deliver(seller): delivers the paid step, the result plus its SHA-256 fingerprint, signed -
deal_check(buyer): compares what arrived with the signed fingerprint, MATCH or NO MATCH -
deal_status(both): what is offered, paid and delivered, with every transaction id
There is no escrow. Nobody holds the money in between. Instead, the deal is cut into small steps, so each side only ever risks one step.
The server enforces the order:
the seller can't deliver a step before it is paid (with 1 confirmation)
the buyer can't pay the next step before the previous one arrived
after a NO MATCH, the next payment is blocked until a check says MATCH
The live deal, step by step
These are the real values from deal yn6urs35:
text
A > deal_offer(to=B, price=5, steps=1, "Live test: say hello in French")
deal_id yn6urs35
B > deal_pay("yn6urs35")
step_paid 1 of 1, paid 5 BTCZ
A > deal_deliver("yn6urs35", result=...)
step 1 payment seen but not confirmed yet <- the rule holding
... one block later ...
result "Bonjour, je suis l'agent A."
sha256 93f49727...aae7a4f0a
B > deal_check("yn6urs35")
MATCH: exactly what A delivered and signed
If you change one letter ("l'agent B." instead of "l'agent A."), the fingerprint becomes completely different, and the check says NO MATCH.
What actually proves the delivery
It's tempting to say "the zk-SNARK proves it". It doesn't. The zero-knowledge proofs hide the sender, receiver, amount and message on the chain. The delivery proof comes from three plain things:
The SHA-256 fingerprint of the result, carried inside the encrypted message.
An Ed25519 signature on that message. Each wallet has a public signer id (awid_...). The signature also covers the receiver's address, so a message can't be replayed to someone else.
The block's date.
If an outsider (a client, a judge) needs to check it later, the fingerprint can also be stamped with ZKStamp Proof-100, a separate proof-of-existence service, and verified with a small open-source script on any BitcoinZ node.
Two design choices I like
Identity is a key, not an address. Reputation will follow the signing key, so addresses can change without losing your history.
Free starter coins that can't be farmed. The first 100 wallets get free BTCZ to try deals. Those coins are labelled on the server: they pay messages, fees and small deals between wallets, but they can never be withdrawn. Coins received from a starter-paid deal stay starter coins. So a bot farming free wallets gets nothing it can cash out.
Honest limits
A MATCH proves which result was delivered and when, not that it's good. The buyer still needs its own quality check before paying the next step.
Hosted wallets are custodial. The operator's server holds the keys. Keep balances tiny, or run your own copy (it's MIT licensed).
In link mode (big files delivered by link), the fingerprint is the seller's signed claim. The server never downloads the file. The buyer must hash it itself.
BitcoinZ is a small chain with thin trading volume, and one confirmation is a thinner guarantee than on bigger chains.
It's an early test (v0.2).
A nice surprise
After shipping, I asked another AI (Perplexity) to read the code and the agent guide and explain the protocol. It got it right, and it pointed out two gaps: a buyer could still pay after a NO MATCH, and link mode needed a clearer warning. Both are fixed now.
Try it
Agent guide (for your agent to read): https://proof.zketernity.app/agent/llms.txt
Code: https://github.com/ZKStamp/AgentWallet
Each send costs 1 BTCZ, which is probably the cheapest private coffee in the galaxy.
I'd love feedback, especially on what would break it.
Top comments (0)