Booking Layer

An agent native booking system with x402 payments.

Comment

Social Media Post: link

Booking Layer

Theme A · AI Operating Layer — Trust, Commerce & Fraud: “How might we make online transactions safer, detect scams earlier, and help users decide who or what to trust?”

A non‑custodial rail that lets AI agents pay for and book services (hotels now with flights, tours and restaurants next) — but only for what a human has signed off on, with the money held in escrow that can never reach anyone but the real merchant. No account, no API keys, no cards. The agent's crypto wallet is the account.

Team

  • Ian Buxton Sia

The Problem

AI agents can plan a whole trip in seconds, and then one of two things happens: they freeze at checkout, or they get scammed. This year alone, agentic browsers have bought from fake look‑alike shops (Guardio · Perplexity “Comet”), been hijacked by a hidden prompt inside a fake CAPTCHA (“PromptFix”), or had a sneaky line‑item added to a checkout so the money goes to an attacker (Palo Alto Unit 42). The honest truth is there’s nothing sitting between an agent’s wallet and the real world to keep it safe — card rails want a human and booking APIs want an account with KYC.

The Solution

Booking Layer is neutral infrastructure — the “Stripe + Plaid” for agent bookings. An agent talks to it over the Model Context Protocol (MCP) and pays in x402 / USDC, and trust is built into three places:

  • Reputable supply only — bookings come from vetted suppliers, never a fake or hallucinated merchant.
  • One human‑signed intent — a budget cap plus where/when/what rules, so prompt‑injection can’t spend past what was approved.
  • Non‑custodial escrow — the money can only ever reach the real merchant or return to the agent, and every booking ends in a signed receipt.

Who it’s for: AI‑native builders and the people who use their agents — anyone who wants to go agent‑first and needs a hard guarantee that the agent can only ever do what its owner approved.

How it Fights Fraud

  • Safer transactions — the budget sits in an audited third‑party escrow (Coinbase Commerce Payments). It can only capture to the merchant on a confirmed booking or refund to the agent — there’s no “send it somewhere else,” so an attacker has nowhere to point the money. And funds only move after the supplier confirms.
  • Stops scams before they land — the human signs one EIP‑712 intent with a hard budget cap and scope. A prompt‑injected attempt to inflate the total, slip in a gift‑card, or book off‑scope is simply refused at capture — and the traveler is committed as a hash, so an injection can’t even change who the booking is for.
  • Helps people know what to trust — every booking ends in a layer‑signed receipt you can verify, it’s userless (no password to phish — the agent proves itself by signing the payment), and everything’s open and on‑chain.

How it Works

  1. verify — the agent escrows its budget (x402/USDC) and solves a quick proof‑of‑work. The human gets a one‑click link, reviews the terms, and signs a single intent in their wallet. The agent then gets back a 24‑hour search token.
  2. search — one tool for every service, token‑gated and scoped to exactly what the human approved, returning real supplier inventory.
  3. book — the real price is captured from the escrow (no new payment), the supplier is booked, the leftover budget auto‑refunds, and a signed receipt comes back.

The human signs exactly one thing; the agent runs autonomously inside it.

Technical Architecture

            ┌──────────── Human ────────────┐
            │  signs ONE EIP-712 intent (off-chain, gasless)
            │  budget cap · constraints · traveler-details hash
            ▼
 Agent ──MCP / JSON-RPC──▶  BOOKING LAYER (orchestration only)
 (wallet)        │            │
   │  x402/USDC  │            ├─▶ Escrow ── non-custodial, third-party (Coinbase, on Base)
   │  (EIP-3009) │            │   authorize ▸ capture→merchant ▸ refund→agent
   │             │            ├─▶ Supplier ── LiteAPI (hotels) · Duffel (flights)
   │             │            └─▶ State ── Upstash Redis (hot) · Supabase (durable, encrypted PII)
   ▼             ▼
 verify ──────▶ search ──────▶ book ──────▶ EIP-712 signed receipt   (money moves once)
  • Surfaces — an MCP server (JSON‑RPC over stdio), a REST API (OpenAPI 3.1), and a stateless TypeScript SDK that holds nothing but the base URL, the agent wallet, and the token.
  • Authorization — the human signs an EIP‑712 IntentMandate: delegated agent, per‑item budget caps, graduated constraints (kinds; where region→city→venue; when; party size), and a hash commitment of the traveler details. Delivered as a click‑to‑sign link whose whole payload lives in the URL fragment, so the layer stores nothing.
  • Payment — x402 (HTTP 402 + an X‑PAYMENT header carrying an EIP‑3009 authorization), USDC on Base, gasless for the agent. It can self‑fund or pull from the human’s wallet within a one‑time spend permission.
  • Escrow — funds settle into the third‑party AuthCaptureEscrow contract, never our wallet. The “confirmed → capture / failed → refund” check is also the regulator’s validation procedure, which (plus a seller‑of‑record model) keeps us clear of money‑transmitter status. A mock mode runs the same lifecycle in memory for $0.

Tools Used

  • Language / runtime — TypeScript, Node.js
  • Agent interface — Model Context Protocol (MCP); LLM‑agnostic (works with Claude, GPT, or any MCP agent)
  • Web — Express, Hono, Cloudflare Workers
  • Crypto / chain — viem, EIP‑712 & EIP‑3009, x402, USDC on Base
  • Escrow — Coinbase Commerce Payments (AuthCaptureEscrow) + Spend Permissions
  • Suppliers — LiteAPI (hotels / flights), Viator (experiences)
  • Data — Supabase, Upstash Redis
  • Standards — AP2, x402, UCP, OpenAPI 3.1

Challenges

  • No budget — everything had to prove itself at $0, so the whole system runs end‑to‑end in mock mode and flips to prod with a few env vars.
  • Making the agent unable to pull its money back once committed — there’s a whole test suite just for that one guarantee.
  • Staying out of money‑transmitter status — which shaped the design: non‑custodial escrow + seller‑of‑record + a booking‑confirmation validation procedure.
  • Real supplier quirks — LiteAPI’s two‑step hotel search and strict flight passenger schema took a while to get right.

What I’m Proud of

  • A working MVP — MCP server, REST API, SDK, and human signing flow — with 80+ tests green, all at $0.
  • Real on‑chain settlement on Base Sepolia — agent → escrow → merchant, gasless, including partial capture.
  • Real hotel bookings through LiteAPI, finished with signed receipts.
  • A complete, honest trust model that maps straight onto the challenge.

What I Learned

Trust in agent commerce isn’t a feature you add — it has to be the shape of the rail. And designing for the regulator and designing for the attacker turned out to be the same job.

Guide

Website: link

Built With

Share this project:

Updates