I built an x402-paid, agent-callable API on Base — solo. Here's the architecture.

2026-07-05 · Engineering x402 mcp agent-infra base

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:

/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

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.

What a first engagement looks like. A paid, fixed-fee one-week audit of your agent-execution surface — I map your calldata paths, flag where funds can leak, and hand back a fix plan and a fixed quote. You keep the plan whether or not we keep working together.

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