Enma | Devpost

Written for: Devpost project story section (public, read by hackathon judges and the general public).

Enma: Agents Pay Only for Data That Passes QA

The problem

AI agents are starting to transact with each other. One agent buys a market signal from another, calls a paid API, pays for a dataset, all without a human clicking "approve" each time. But the payment model underneath all of this is still borrowed from Web2, and it was never built for autonomous, unsupervised spending.

If an agent pays for an API call today, on-chain, it pays before it has any idea whether the response is good. If the seller sends back an error, stale data, or outright fabricated garbage, the money is already gone. There's no chargeback in crypto. And if the agent is making thousands of calls a day on its own, there's no automatic guardrail stopping it from blowing through a budget because one bad seller kept quoting high, or because a bug kept retrying a failing call.

We kept coming back to the same question: if we're about to hand agents real spending power, what does the payment infrastructure need to guarantee before that's actually safe? Two things, we decided. First, an agent should never pay for a response that fails its own quality bar. Second, an agent should never spend past a limit it set for itself, no matter what a seller quotes or how many times it gets called. Nothing on the market enforces either of those automatically, on-chain, without a human in the loop.

What we built

Enma is a payment and trust layer that sits between an AI buyer agent and a seller, built on the x402 protocol. It's a bridge from the Web2 API world, pay-per-call, request/response, into Web3 payment rails, on-chain settlement, cryptographic vouchers, smart-contract enforcement, without losing the one thing Web2 never had to build: proof that you only pay for what actually worked.

The mechanism has three layers, and we built all three to run without a human watching:

Pay per call, with a receipt that can be clawed back. The buyer opens a pre-funded payment channel with a seller and pays per request with a signed voucher. Every response gets run through the buyer's own QA before the voucher is allowed to settle: a deterministic gate for structure and sanity, and a Claude-powered semantic judge for whether the actual content is real or fabricated. If either gate fails, an error, garbage data, anything that shouldn't have been paid for, the buyer's guardian key revokes that voucher on-chain before the seller's next claim cycle can ever cash it in. The seller genuinely cannot get paid for a bad response. This isn't a refund process; it's baked into the settlement contract itself.

Never spend past your own limit. Before a channel even opens, a spend-limit firewall checks the seller's quoted price against a per-call cap and a rolling budget window. If a seller quotes too high, or this seller has already eaten too much of the buyer's budget recently, the purchase is refused before a single unit of gas is spent. This runs on every call, automatically, so an agent making unsupervised decisions all day can't accidentally overspend.

Bad actors get cut off automatically. A seller's own reputation ledger tracks incidents where a buyer revoked a payment. Cross a threshold, and that seller's payout address gets refused pre-emptively, before any payment round-trip even starts. No admin has to notice a pattern and manually ban anyone. The system polices itself.

All of this runs live: a Cloudflare Worker backed by Durable Objects drives a settlement cycle on its own timer, claiming and settling vouchers, recording incidents, and updating bans without any script triggering it. And the buyer side isn't just a demo script either. We built it as a real MCP server, so Claude itself connects as the buyer, calling Enma's tools and spending real funds on Base Sepolia through the exact same code path a human-run CLI uses.

What we learned

We originally scoped a much bigger vision, a small organization of autonomous agents (procurement, QA judge, treasury, SRE) coordinating over Slack, with Stripe mirroring the on-chain ledger and World ID gating identity. Within the first few hours it was clear that trying to build all of that in one day would leave us with five half-working things instead of one thing that actually works end to end. We cut it down to the core trust mechanism and made sure that part was completely real: real contract, real revocation, real ban logic, real MCP integration, not a mockup of any of it.

We also tried wiring in Brainbase as the orchestration layer for our ops narrator agent, and it worked, we had it posting live to Slack during testing, but its runtime messaging API turned out to be undocumented and task-based rather than a simple push endpoint we could call on every event. Rather than lose hours reverse-engineering it under a hard deadline, we shipped a direct Slack webhook for the same feature and kept moving. That trade-off is documented plainly in our code and README, because we'd rather ship something honest than something that looks more impressive than it is.

I also learned a real lesson from building directly on Base and Coinbase's x402 stack instead of mocking it. Because Coinbase's x402BatchSettlement escrow is live on Base Sepolia and the free x402.org facilitator already speaks the batch-settlement scheme on that network, I chose to build the contract against the real escrow from hour one, and that decision surfaced problems a mock never would have. I found out the hard way that public Base Sepolia RPC endpoints rate-limit aggressively under repeated test traffic, so I moved to a dedicated endpoint early rather than lose a rehearsal to throttling. I also discovered that Coinbase's contract fails an entire claim transaction if even one voucher in a batch is flagged, which is exactly why my seller claims vouchers one at a time instead of batching them, so one revoked payment can never take down a batch of honest ones. And I learned that Base mainnet isn't a flag flip: the free testnet facilitator has no mainnet counterpart, and going live requires a separate signup with Coinbase's own CDP facilitator, so I built Enma to be network-agnostic from the start and proved the same contract logic on both Base Sepolia and Base mainnet in a fork test, even though the live demo itself stays on testnet.

What's next

The reactive enforcement we built, revoke on QA failure, ban on repeated abuse, refuse over budget, is genuinely autonomous once a transaction starts. What's still scripted is the decision to initiate a purchase in the first place. The natural next step is closing that loop: an agent that decides on its own when it needs fresh data, shops across multiple sellers for the best price under its own budget, and only then triggers the payment and QA mechanism we already built. The trust layer is done. The next phase is giving the agent a reason to use it on its own.