Overflow

Overflow started with a conversation we had at a Berkeley event with Mr. Nemil Dalal, who helped launch x402 at Coinbase. We were already interested in blockchain, but hearing about the idea of software being able to make payments over the internet without going through the usual checkout process got us thinking about what that could actually look like.

The idea of an AI agent being able to purchase something on its own is pretty exciting. It opens up a lot of possibilities, especially as agents become more capable of completing complicated tasks without constant human involvement. But we kept coming back to one question: just because an AI can spend money, does that mean we should trust it to?

That became the starting point for Overflow.

Initially, we were focused almost entirely on securing an agent's wallet. If an agent has access to a private key, there's a lot that can go wrong. It could misunderstand an instruction, fall for a prompt injection, or accidentally send money to an address it shouldn't. We wanted to give agents the ability to make purchases without handing them unrestricted control over someone's funds.

As we worked through that problem, we realized security was only one part of it. Even if an agent makes a perfectly authorized payment, how does it know whether the thing it's buying is worth the money? What if two agents need the same dataset and both end up paying for it? And what happens if the seller takes the payment and never sends anything back?

We ended up expanding our original idea quite a bit. Instead of building just a safer wallet, we started building a system that could handle the entire purchasing process.

That's what Overflow does. You give it a goal, a budget, and some constraints, and it figures out what resources it needs to complete the task. Our Oracle component helps find and compare relevant resources, while Fusion looks for opportunities to combine purchases when multiple agents need similar things. On the financial side, we built a treasury that lets agents operate with their own budgets, spending limits, approved recipients, and expiration times.

One thing we really wanted to avoid was relying on an LLM prompt to enforce any of those restrictions. You can tell an agent not to spend more than $10, but that doesn't actually stop a transaction from going through. We wanted the restrictions to exist outside the model, where the agent couldn't simply ignore them or be manipulated into overriding them.

That's where the blockchain became useful. We wrote Solidity smart contracts that enforce those spending rules at the transaction level. We integrated USDC payments, x402 payment flows, and Coinbase Developer Platform wallets so agents could sign payment authorizations without needing unrestricted access to a wallet's funds.

Then we started thinking more about the seller's side of the transaction, which honestly turned into one of the most interesting parts of the project.

Paying someone for a digital resource is a little strange because there's no guarantee they'll actually deliver what they advertised. For example, an AI agent could purchase a dataset, only to discover that the seller provided corrupted records or never delivered the data at all.

We built Recourse to deal with that. Each protected purchase gets its own escrow contract, and sellers make cryptographic commitments about the data they're delivering. The buyer can verify samples, and the seller has to reveal the information needed to access the complete purchase. If the seller disappears, the buyer can recover its payment after the deadline. If the seller provides data that demonstrably doesn't match its commitment, the buyer can submit cryptographic evidence and trigger a refund.

Getting that to work was considerably harder than we expected.

We spent a lot of time understanding EIP-712 signatures, contract wallet verification, USDC authorization flows, and how all of those pieces fit together. We also had to figure out how to generate and verify Merkle proofs, structure the encrypted data, and make sure our escrow contracts handled all the different ways a transaction could fail.

And once the contracts were working, we still had to connect everything to the backend and frontend.

We built the application using TypeScript, Next.js, Solidity, and a set of backend services responsible for mission execution, purchasing, event tracking, and accounting. The dashboard lets users see what their agents are doing, how much they're spending, which transactions were blocked, and what happened to each purchase.

Some of our most frustrating bugs only showed up when we started running everything together. During our local Anvil testing on a fork of Base Sepolia, we found issues with how payments were recorded in the ledger and how escrow deposits were reconciled. They weren't particularly glamorous problems, but fixing them made us realize how much more there is to a payment system than successfully sending money from one address to another.

We eventually got three different seller scenarios working against the actual smart contracts. An honest seller delivered the data and received payment. Another seller never revealed the required information, so the escrow refunded the buyer. In the third case, a seller deliberately provided data that didn't match its cryptographic commitment, and the contract verified the mismatch, refunded the buyer, and recorded the violation.

We also tested unauthorized purchases. In one scenario, an attempted payment to an unapproved address was rejected by the treasury. In another, a direct attempt to bypass the treasury was rejected by USDC's signature verification. Seeing those transactions fail for the exact reasons we designed the contracts around was probably one of the most satisfying parts of building Overflow.

The biggest thing we learned was that blockchain payments are both more powerful and more limited than we initially understood. x402 makes it possible for software to pay for things in a way that feels much more natural for automated systems. But just because a transaction succeeds doesn't mean it was a smart purchase, that it followed the right permissions, or that the seller fulfilled its side of the deal.

We also realized that putting everything onchain isn't necessarily the answer. A lot of what Overflow does, like researching available resources, comparing datasets, and coordinating purchases, makes more sense offchain. The blockchain becomes most valuable when we need to enforce financial rules or settle disagreements without trusting either side to do the right thing voluntarily.

That's really what kept us interested throughout the hackathon. We started out wanting to understand how AI agents could make blockchain payments, and somewhere along the way we became much more interested in what it

Built With

• anthropic-claude
• anvil
• base
• coinbase-developer-platform
• drizzle-orm
• eip-712
• ethereum
• foundry
• hono
• model-context-protocol
• next.js
• node.js
• playwright
• pnpm
• postgresql
• react
• solidity
• tailwind-css
• typescript
• usdc
• viem
• vitest
• x402
• zod