Elix

Accounts payable for AI agents that pay over x402. Elix checks every payment before it is signed, books it when it settles, and catches vendors who bill the same usage twice.

Comment

Inspiration

AI agents can now buy things on their own. With Coinbase's x402, an API can answer 402 Payment Required and an agent can pay it in USDC a second later. This is great for the agent but a horrible mess for finance. A company ends up with agents paying from a stablecoin wallet, vendors billing the same usage on a monthly invoice, and a bank feed that sees neither. Somebody still has to approve each payment, book it to the right account, and catch the vendor who bills the same usage again. Accounts payable software was built for invoices that people approve one at a time. I wanted to build accounts payable for the payments agents make on their own.

What it does

Elix is accounts payable for AI agents that pay over x402. For every payment, it does three things. Before the payment is signed, it reads the vendor's 402 challenge and checks it against the agent's budget, its per purchase cap, the vendor master and the person who owns that budget. Then it pays, asks the agent a question, routes it to that person, or refuses. When the payment settles, Elix books it as a double entry journal entry with the x402 receipt attached. When the vendor's invoice arrives, Elix matches every line against the usage meter and against what agents already paid over x402. Every attempt, allowed or denied, lands in a hash chained audit log.

The demo is built around a double bill. Kestrel Labs, the fictional customer, has a GPU agent that paid Lumen for 600 spot hours over x402 on October 9. A week later Lumen's invoice bills those same hours again, because its meter counts all usage and its billing system has no idea what the wallet paid. Elix sees both, so it proposes paying $12,234 instead of $13,494, drafts the dispute, and books the $1,260 difference to vendor disputes. When Lumen sends a credit note, Elix checks it against the open dispute and closes it in the ledger.

It also holds a payment when a vendor's wallet changed two hours earlier, even after the budget owner approved the spend. it refuses when an agent tries to approve its own order, and it treats vendor text that says "pre-approved by finance" as data, not an instruction. It catches split purchases, duplicate retries, prices above contract and invoices that bill more than the meter. It reads invoice PDFs too. Claude proposes the fields, and deterministic code checks the vendor, invoice number, every line's arithmetic, the total and the dates before anything posts.

Any agent can use it. Elix ships an MCP server, so Claude Code, Claude Desktop or any MCP client gets a wallet it cannot overspend.

For the Coinbase judges

Elix is a spend control layer for x402 payment agents. An agent, through the Anthropic SDK or the MCP server, asks Elix to buy something. Elix fetches the vendor's real 402 challenge, decodes it, checks it against policy, and only then signs the payment with Coinbase's x402 Python SDK. The vendors in the demo are real x402 resource servers built with the same SDK. Right before paying, Elix fetches a fresh 402 and refuses if the payee or amount changed since a person approved it. In live mode, payments verify and settle in USDC on Base Sepolia through the x402.org facilitator. Here is a real one Elix made this morning, $0.40 for one Signalboard record: https://sepolia.basescan.org/tx/0xd2ff2e9b142d5ed7bf51340ee7b83bed2acc85f0c0480e4020c901597dafd0ad

The part I think is new is what happens after the payment. Every x402 receipt becomes a journal entry, and when the same vendor later sends a normal invoice, Elix uses the receipts to catch usage that was billed twice.

Builder feedback. The biggest blocker was testing without a chain. The exact EVM facilitator needs an RPC connection, so I wrote a local facilitator that implements the SDK's facilitator interface, rebuilds the EIP-712 typed data, recovers the signer, and checks amount, payee, asset, network, time window and nonce reuse. An official offline facilitator in the SDK would make x402 apps testable in CI and at hackathons. Second, the client caps each payment at $1 by default, which fails quietly for anything priced like compute. I raised the cap instead of turning it off. Third, I'd love a documented way to read the decoded requirements before paying and to detect a payee change between two challenges, plus invoice metadata on the 402 so x402 payments can be matched to a vendor's later bill.

Proof

I built a 90 day synthetic company with errors planted at known positions and an answer key the engine never reads. In the latest run Elix caught all 56 planted errors across 14 categories and paid none of them without a person. Every payment it made on its own was clean, for 100% precision. Once the learned policies were approved, the share of clean purchases paid without a person went from 12.0% to 85.3%. The audit chain verified across 3,924 events. Anyone can reproduce this with python -m elix eval.

What is real and what is simulated is labeled everywhere. The policy engine, ledger, audit chain and reconciliation are real code with 542 tests. The x402 messages and payment signatures are real, created with Coinbase's official x402 Python SDK and verified with real signature recovery. The demo runs offline so it cannot fail on venue wifi, with settlement going to a local simulated USDC ledger. Live mode settles on Base Sepolia, and the Coinbase section links a real transaction. The company and its data are synthetic.

How we built it

The engine is Python with FastAPI and SQLite. One facade handles every operation, so the console, CLI, MCP server and tests share a code path. Policy is a table of deterministic rules that each return pass or fail with evidence. A gateway module is the only code allowed to call a payment rail or post to the ledger, and a test enforces that. The audit log is append only, with each row hashing the one before it, written in the same transaction as the change it describes.

The x402 rail uses Coinbase's x402 SDK for both the agent's client and the vendor's server. Agents are Claude tool use loops through the Anthropic SDK, with scripted fallbacks for offline demos. The console is React and TypeScript.

I built it spec first with Claude Code. The specs cover the domain model, the rule table, the state machines and the acceptance checks, and every component was built and tested against them.

Challenges we ran into

The x402 client ships with a one dollar per payment spend cap by default. That is a sensible safety default, but every GPU reservation in the demo is far above it. I raised it instead of turning it off, since Elix is the spend control.

Verifying payments without a chain meant reproducing the exact typed data the client signs and recovering the signer myself.

The hardest product problem was the payee change. Approving a purchase and releasing money to a wallet that just changed are different decisions with different owners, and the state machine had to keep them apart without slowing down the normal case.

Accomplishments that we're proud of

The double bill catch works on real protocol messages, not a mocked flag. A real payment settled on Base Sepolia through the same rail the demo uses. Refused attempts are part of the record, so an auditor can see what an agent tried and why it did not happen. The eval has an answer key the engine never sees, so the numbers are earned. And it was built solo at Cal Hacks.

What we learned

Finance software is mostly about who is allowed to do what, and when. The language model is useful for proposing and explaining, but the product is the controls. I also learned that x402 makes agent payments easy enough that the bookkeeping problem shows up right away.

What's next for Elix

Live settlement on Base mainnet and real bank feeds. Card and API usage rails, so the same reconciliation covers OpenAI, Anthropic and AWS bills. Sync to NetSuite and QuickBooks. A pilot with an AI company whose agents already buy data and compute.

Built With

Share this project:

Updates

Submission history