I built an x402-paid, agent-callable API on Base — solo. Here's the architecture.
You might be here if: you shipped an AI agent, your users want it to actually transact, and now you're staring at signing keys, usage metering, a kill-switch, and calldata you're not sure is safe to hand a bot. That's the gap between a demo and production — and it's the part nobody puts in the launch tweet.
I run PaladinFi. The stack below is live on Base right now, built and operated by one person. This walks through how it's wired — starting with the part that almost bit me.
The hard part first: handing an agent calldata that moves funds
An agent asks my swap API for a route. What comes back is ready-to-execute calldata — the agent's own wallet signs and submits it (it keeps its keys; I sign nothing on anyone's behalf). That's the right design for autonomy, and it's also a loaded gun: if the calldata I return is malformed or points somewhere it shouldn't, an autonomous caller submits it with no human in the loop.
So the router doesn't blindly trust its upstream aggregators (0x's AllowanceHolder, Velora's Augustus). Before any calldata leaves the service:
- the function selector must be on a per-aggregator allowlist;
- for 0x's dispatch path, the inner
targetis validated against the known Settler address — becauseAllowanceHolder.execis atarget.call(data)dispatcher: check the selector but not the target, and an attacker-supplied "valid" selector just calls whatever address you hand it. The selector check is cosmetic without pinning the target; - a hard deny-list of token-approval and transfer selectors never passes, even in warn mode.
/health reports the enforcement state, so it's auditable from the
outside. None of this shows up in a demo. It's the difference between a swap route
and a swap route you'd let an agent execute unattended.
The shape: MCP in front, x402 at the door, Base underneath
- MCP is the discovery/call surface for MCP clients like Claude: two servers are published in the registry (swap + trust) and handshake live; a client lists the tools and calls them with typed arguments. The same HTTP API is also wrapped as ElizaOS and Coinbase AgentKit plugins — separate integrations, not MCP — so the tools are consumable from all three without pretending AgentKit speaks a protocol it doesn't.
- x402 is how a caller pays, inline. A paid call returns
HTTP 402with payment requirements; the client signs a USDC payment authorization (EIP-3009transferWithAuthorization, schemeexact, networkeip155:8453) and returns it; the server verifies it through a facilitator, settles on-chain, and serves the result. The caller signs, it doesn't pre-settle — no account, no invoice, no gas paid just to make the call. - Base is the settlement layer: cheap, fast, and where the counterparties already are.
Two fees, kept separate because they're separate products: access to a paid endpoint is a flat $0.001 in USDC over x402; the swap router separately bakes a 10-bps fee into the calldata it returns. The OFAC screen leg is free and anonymous (rate-limited), so you can validate request shape before wiring up payment.
Fail-loud, never a silent allow
The trust gate returns allow / warn / block.
The failure mode that matters isn't a wrong answer — it's a source going down and the
gate quietly returning allow. A check that fails open silently is worse
than no check, because the caller thinks it ran.
By contract: every unreachable source becomes a flagged, zero-weight
factor, and if all sources are unreachable the recommendation is forced to
warn — never a silent allow. An OFAC hit is a hard
block. The caller can always tell "this looks fine" from "I couldn't
check." (I've written before about the
silent-allow bugs I caught in my own gate — this is the contract that prevents them.)
Verifiable responses
The free OFAC endpoint signs each response: an Ed25519 signature and the public key travel in the payload, and the signing contract — canonical JSON per JCS / RFC 8785, signature fields stripped before signing — is published, so a caller can verify a verdict came from this service and wasn't altered in transit. It's scoped to that one endpoint today (the paid and swap endpoints aren't signed yet), and the key is pinned on a docs page, not only in-band — an in-band-only key gives you integrity, not authenticity.
The unglamorous half: auth, metering, kill-switch
The accountless free + x402 path needs no signup. For keyed, metered use there's a parallel account tier: signup + email verification, API-key issuance and rotation, per-key usage counters, an audit log, and a kill-switch — FastAPI on Postgres, with RDS IAM auth: no long-lived DB credential on disk, the app mints a short-lived SigV4 token via the EC2 instance role. Anything that signs or moves funds goes through an adversarial self-review before it ships.
This is the part that takes the longest and wins no attention — and it's usually the exact piece a team without an infra hire is missing.
Why solo is the point, not the caveat
Everything above was designed, built, and is operated by one person. Hire that person and you get the whole mental model, no handoff to a junior, and — the part that matters for a bus-factor worry — code and infra that are yours, in your repo, with runbooks written for handoff, not job security. Solo means accountable, not single-point-of-failure.
Honest proof-of-life, because a trust-adjacent post shouldn't fake it: the MCP servers have been live in the registry since spring 2026 (swap since April, trust since May), the stack runs in production on Base, and there's been no funds-loss incident. It's early — this is the infrastructure, presented straight, not a traction story.
I build the production layer between an AI agent and money moving on-chain — agent-callable surfaces, x402/paid access, safe on-chain execution, signed responses, and the auth + metering underneath. If that's your gap, fractional or contract, tell me the piece you're stuck on and I'll send back how I'd approach it: paladinfi.com/build.
Published: 2026-07-05 · Live: swap.paladinfi.com/health · Build: paladinfi.com/build