The pieces, explained.

Five concepts you'll encounter constantly: CLOB · MCP · x402 · EIP-712 · EIP-3009. Each gets a one-paragraph definition, why we use it, and what changes if you swap it out.

CLOB — Central Limit Order Book

A CLOB is an order book where makers post limit orders (price + size, no market impact) and takers cross them. Trade price is exactly the limit price — no slippage curve, no constant-product math, no impermanent loss for liquidity providers.

Why we use one

FX needs price discipline. AMMs (Uniswap-style) work for volatile pairs because LPs accept inventory risk for swap fees, but stablecoin FX has tiny spreads and high notional — AMM impermanent loss eats the entire margin. CLOBs let market-makers quote the same spread they'd quote at any prime broker, on-chain.

Implications for your code

• Quoted price = executed price. No slippage parameter to set.
• If a quote returns "no liquidity," that's real — there's no maker at that level. Use scan_markets to find what is tradeable now.
• Spreads tighten with notional density, not pool depth. A pair can be tight at $10K and loose at $100K, or vice versa.

MCP — Model Context Protocol

An open protocol from Anthropic for letting AI hosts (Claude, Cursor, ChatGPT, OpenAI Agents SDK, custom hosts) talk to external tools. Every host implements the same JSON-RPC over stdio interface; every tool is a server. Stewarded by the Linux Foundation as of 2026.

Why Sera ships an MCP

It's the most portable shape. One sera-mcp server reaches every modern agent host — no per-host SDK, no OAuth dance, no proprietary plugin format. "claude mcp add sera ..." and you have 32 FX tools.

What MCP gives you for free

• Tools — typed function calls (sera.get_quote, etc.)
• Resources — browseable static catalogs (sera://help/tools)
• Prompts — slash commands the host surfaces in its UI (/deal_scan)

What it doesn't give you

• Authentication. Each tool decides its own auth model (we use env-based API keys + EIP-712 signatures).
• State persistence between calls. The MCP server's process is the only state.

x402 — HTTP 402 Payment Required

An open agent-payment standard layered on top of HTTP. The server returns 402 Payment Required with payment instructions. The client pays (USDC, on-chain). The client retries with an X-PAYMENT header. The server verifies and returns 200 OK with the goods. Idempotent, stateless, cache-friendly.

Why we expose one

Some agents don't speak MCP — they speak HTTP. The x402 endpoint lets any agent that knows the standard pay USDC and get an FX-converted payout in any of 40+ stablecoins, no Sera SDK required.

Why this is interesting beyond Sera

x402 is the closest thing the agent ecosystem has to "Stripe for agents" without the Stripe. Wrapping any API in the same pattern means agents can pay you per call without contract negotiations, OAuth flows, or pre-funded API keys. See the x402-paid API tutorial.

EIP-712 — Typed structured-data signing

An Ethereum standard for hashing and signing structured data (instead of opaque hex strings). Wallets show humans "You are signing an Order: maker=0x...; price=1.41; expiry=...," not "Signature data 0xa3f7...8b2c."

Why we use it

Quote signing. Every Sera trade is a maker/taker order encoded as a typed-data struct (Maker · Market · isBid · BaseAmount · Price · Expiry · Nonce). The wallet signs that — never raw bytes. The sera-mcp never sees the private key; it just gets the signature back.

What you get

• Phishing resistance. The wallet can show a humane summary.
• Replay protection. The struct includes a nonce + chain_id.
• Off-chain signing, on-chain settlement. No gas to ask for a quote.

EIP-3009 — transferWithAuthorization

An ERC-20 extension that lets a token holder pre-sign an authorization to transfer X tokens to address Y by time T, and a third party submits that authorization on-chain. USDC implements it.

Why x402 needs it

Without EIP-3009, an agent paying for an API call would need to (a) approve the API server's contract for an allowance, (b) call a transfer function — two on-chain transactions, two gas fees. With EIP-3009, the agent signs an authorization off-chain, posts it in the X-PAYMENT header, the server submits it. One transaction; the server pays gas (or batches many).

Putting them together

Two end-to-end flows show how the concepts compose:

FX swap via MCP (uses CLOB + MCP + EIP-712)

1. Agent → sera.get_quote → MCP returns Order struct
2. Agent's wallet → signs Order via EIP-712 typed-data
3. Agent → sera.execute_swap with signature → MCP submits to Sera CLOB
4. Sera Protocol → fills against a maker → settles atomically on-chain
5. Agent → sera.settlement_status → confirms trade_id

FX swap via x402 (uses CLOB + x402 + EIP-3009)

1. Agent → POST /x402/swap → server returns 402 + payment_id
2. Agent → signs USDC transferWithAuthorization (EIP-3009) off-chain
3. Agent → retries POST with X-PAYMENT: id:auth header
4. Server → verifies USDC payment + executes Sera swap from vault
5. Server → returns 200 OK with delivered + trade_id

Next: Pick a tutorial · API reference · Recipes.