Prototype v1 · Open Source
Fivefield Protocol
An open protocol for delegated purchases. By Kurt Traxl and Michael Brinkmann.
An open protocol for delegated purchases. By Kurt Traxl and Michael Brinkmann.
AI agents purchase on behalf of humans. But who is liable when the agent orders wrong? Who checks the budget? Who stops a manipulated order? Today there is no standard for this.
No protocol defines who is responsible when an agent makes erroneous transactions.
Agents can act beyond the authorized budget — no check before the charge.
A manipulated merchant can lure the agent into unauthorized purchases.
A signed mandate defines exactly what the agent may do: what (categories), where (merchants), how much (per-order and total limit), until when (validity), which agent (agent key). Before every charge, a verifier checks automatically — no transaction without valid authorization.
The user signs the five fields on a surface the agent does not control — banking app, card app, EUDI wallet, crypto wallet, or OS passkey (our approval page is a placeholder). The agent proposes the fields; only the user can sign them.
Whoever releases the payment (PSP, issuer, large merchant, or the on-chain program) runs five comparisons: signature valid (includes agent key match), merchant allowed, category allowed, amount within limit, not expired. Deterministic, no LLM.
A consumer is liable only for payments approved via strong customer authentication, bound to a payee and an amount. Merchant list = payee, amount limits = amount, passkey signature = SCA. Precedent: UK Open Banking Variable Recurring Payments.
The agent controls what is bought inside the five fields, and nothing else.
| Situation | Decision | Liability |
|---|---|---|
| Mandate signature invalid | REJECT | None (never charge) |
| Agent not authorized / Attestation invalid / Replay | REJECT | Agent provider |
| Order outside constraints (budget, merchant, category) | REJECT | Agent provider |
| Order within constraints | APPROVE | Principal (normal purchase) |
| Goods wrong, faulty or not delivered | — | Merchant, consumer law unchanged |
From SDK to blockchain — the same verifier runs everywhere.
Create, sign, verify mandates. Pure functions, no I/O. Runs in Node.js, Deno, browser and edge workers.
Escrow, Ed25519 introspection, reputation tracking. PDA-based; upgrade authority to be burned after security audit.
Card via issuer/PSP (mandate in Verifiable Intent). SEPA / Wero Request-to-Pay (planned). x402 (HTTP-native). Google AP2. Mastercard VI. Visa TAP (planned). Same verifier, every rail.
Principal, agent and merchant sign cryptographically. Forgery computationally infeasible.
On-chain CPI attacks blocked. The verifier checks the signature directly in the Ed25519 precompile.
Attestation hash prevents replay of intercepted transactions.
No plaintext on chain or at the merchant. Only a SHA-256 hash as evidence.
Cumulative budget across multiple orders. On-chain state, tamper-proof.
Mandates expire. No transaction possible outside the signed time window.
The prompt contains personal intentions, preferences and context; sending it to the merchant or the blockchain would expose purchase behaviour permanently. And a sentence is not a rule: constraints can be checked deterministically, a prompt cannot.
Only a SHA-256 hash of the prompt is transmitted — as cryptographic evidence for disputes. The verifier checks constraints, not intentions. Privacy by design.
Click one of the commands to test the verifier live.
{ "version": "1", "mandateId": "mnd_7f3a9c2b", "principal": { "scheme": "ed25519", "pubkey": "4mXp...kR9z" }, "agent": { "scheme": "ed25519", "pubkey": "9nQr...mL2w" }, "constraints": { "merchants": ["merchant.kaffeeshop.at"], "categories": ["food_beverage", "grocery"], "maxTotal": 5000, "currency": "EUR", "maxOrders": 3 }, "validFrom": 1729382400, "validUntil": 1729987199, "nonce": "a3f7c2e1b8d4", "signature": "7xKm...4pNq" }
{ "orderId": "ord_3a8f1c", "mandateId": "mnd_7f3a9c2b", "merchant": "merchant.kaffeeshop.at", "category": "food_beverage", "amount": 1850, "currency": "EUR", "items": [{ "name": "Kaffee Speciality 250g", "qty": 1, "price": 1850 }], "totalSpent": 0, "timestamp": 1729424520, "attestation": "3zRt...8kWx" }
"constraints": { "type": "object", "required": ["currency", "maxTotal"], "properties": { "merchants": { "type": "array", "items": { "type": "string" } }, "categories": { "type": "array", "items": { "type": "string" } }, "maxTotal": { "type": "integer", "minimum": 0, "description": "Max cumulative spend in minor units (cents)" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$" }, "maxOrders": { "type": "integer", "minimum": 1 } } }
Eight weeks. Weeks 1–2: mandate signing in your app sandbox. Weeks 3–6: verifier in shadow mode next to your authorization, every agent transaction gets a verdict, nothing is declined. Weeks 7–8: measure out-of-scope rate, false declines, dispute time. Fivefield delivers integration, attack scenarios and reporting. The protocol stays open.