Skip to main content
Just want the copy-paste path? The Agent Quickstart is the fastest way in: fund one wallet with USDC on Base, run one verified script, get your first paid result.
The Empire Access Layer (EAL) lets your own AI agent — Claude Code, Cursor, Codex CLI, or any agent runtime — call Otto AI’s intelligence and tooling directly, paid per use in USDC. Instead of clicking through the /app dashboard, you wire Otto’s x402 service catalog straight into the agent you already work in. How you pay: The rest of this page covers the live BYO-x402 path with working steps. Your payer key stays on your machine; you pay per call.

What EAL is for

Otto runs a swarm of agents exposing 80 paid HTTP endpoints over the x402 protocol — market intelligence, KOL sentiment, token security, yield discovery, AI research, image/video generation, and more. x402 is a pay-per-request standard: there are no API keys. Your agent makes a request, gets a 402 Payment Required, pays a few fractions of a cent in USDC on-chain, retries with proof, and gets the data. EAL is the on-ramp for builders and power users who want that catalog inside their own agent, not behind the dApp.
EAL vs. the dApp: the /app Mission Control dashboard is for human users clicking through guided mini-agents. EAL is for your agent calling Otto’s services programmatically. Same underlying catalog, different front door.

Connect your agent

Start with the hosted read lane to confirm the loop end-to-end. Its policy is first call free, then pay per call in USDC (x402) — your agent brings its wallet. The same wallet can then pay those ten intelligence tools through the hosted MCP or call the wider catalog through a direct x402 client.

Lane 1 — hosted Otto Intel MCP (one free call, then x402)

No signup or API key. The first successful intelligence-tool invocation is free. Every later intelligence call requires a signed Base-USDC x402 payment from the calling agent’s wallet; otto_catalog remains free and returns the complete live menu. Full detail, tool list and prices: Otto Intel MCP.
After the taste, an unpaid tool result contains the route’s machine-actionable x402 requirement. The agent signs it with its own wallet and retries the same tool with x_payment. The hosted service verifies and settles through the existing paid endpoint; it never receives the wallet’s signing key.

Lane 2 — pay-per-call (BYO-x402)

Two ways to pay, both from a wallet you fund and control.
  • Same ten tools through local stdio. The local MCP server exposes the same ten intelligence definitions and signs each bounded Base-USDC payment from the dedicated wallet configured in that local process. Config below.
  • The wider catalog. To call other routes, wire an x402 library into your own code (the @x402/fetch snippet below). Routes that execute rather than read additionally require that route’s own account and authorization setup — paying the x402 fee alone does not authorize an underlying trade.
Use a fresh, disposable wallet funded only with the Base USDC you intend to spend, and expose its key only to the local MCP process. The key signs bounded Base-USDC payment authorizations locally and is never sent to Otto. Env-var syntax differs by client — Cursor expects ${env:X402_PRIVATE_KEY} where the block above uses ${X402_PRIVATE_KEY}.

What a connected agent can and cannot do

What your agent can reach depends on which lane you connected, so the table says so explicitly. On all three paying paths, Otto receives your payer address and the signed payment authorization — that is what settles the call on-chain — along with the request itself. Your key is what never leaves your machine. True on every lane, without exception:
  • No Otto Intel MCP tool can place an order, move principal, or sign an arbitrary wallet message.
  • Reference prices and scanner output are data — not executable quotes, not recommendations.
  • Nothing here can pull from a funded Safe; you sign and settle each call yourself.
The catalog is not read-only in its entirety — alongside the intelligence routes it exposes execution routes for Otto’s own trading surfaces. What the table pins down is that reaching those is a separate, deliberate setup step, never a side effect of paying for a read.
Once provisioned, a client can sign without asking you each time. That is the point of an agent, but it means the payer wallet — not a per-call prompt — is your real spending limit. Fund it with only what you intend to spend, keep it separate from any wallet holding principal, and rotate it if the machine is shared.

BYO-x402 (live today)

In the “bring your own x402” model, your agent pays each call from an x402 wallet you fund and control. Your payer key never leaves your machine — you sign each micropayment yourself, or your agent runtime signs it with the key you provide. Otto serves the catalog and the 402 paywall, and receives your payer address plus the signed payment authorization, which is what settles the call on-chain. This is the standard x402 flow, and it works against the live catalog right now.

What you need

  • An x402-capable agent or client. This includes Claude Code / Cursor with an x402 payment tool (for example via Base MCP), or any client built with an x402 library (@x402/fetch, @x402/axios).
  • A funded wallet with USDC on Base (Polygon and Solana are also supported). Prices vary by route, so read the live 402 challenge or catalog before paying. Use a dedicated, lightly funded wallet — never your main treasury.

1. Discover the catalog

Everything is discoverable live — no signup, no key request:

2. See the paywall

Hit any paid endpoint without payment and you’ll get a 402 describing exactly what to pay:

3. Pay per call

Your x402 client handles this automatically: it reads the 402, signs a USDC payment from your wallet on-chain, retries the request with the payment proof, and returns the data. With a library it’s a single call:
In Claude Code / Cursor with an interactive x402 payment tool, the agent does the same thing through the tool’s initiate / complete payment calls, and that tool prompts you to approve each spend. A client you provision with a key directly — the local MCP server above, or your own @x402/fetch code — signs without prompting.
The BYO-x402 payment flow is non-custodial: Otto holds no keys and signs nothing on your behalf — your wallet signs each payment, and what reaches Otto is your request plus the payer address and signed authorization that settle it. The catalog itself carries both read/query routes and execution routes; execution requires that route’s own account setup and authorization, so paying a fee never authorizes an underlying action by itself. Start with the cheap intelligence reads (/crypto-news, /kol-sentiment, /token-alpha) to confirm the loop end-to-end before scaling usage.

Where to look next

  • The full endpoint list, prices, and capability tags live on the x402 Storefront page.
  • Prefer on-chain USDC escrow with receipts and reputation for higher-stakes jobs? Use acp-cli instead.

Things to ask once connected

These are direct BYO-x402 examples — they name catalog routes, most of which are outside the hosted MCP’s ten tools. Each route is live on the catalog right now. They are written to read, compare and check — never to place an order.
Pull /crypto-news and /news-recaps, then /base-ecosystem-news. Give me what actually changed since yesterday, separate reporting from interpretation, and flag anything you could not corroborate across all three.
For this Base token, use its contract address with /token-security, /holder-analytics and /token-top-holders, and its symbol with /token-details. Tell me the concentration risk and what the security scan could NOT verify. Do not tell me whether to buy.
Compare /kol-sentiment and /tweet-search for this symbol against /token-alpha's price, news and futures data. Where does the social signal disagree with the market data? Call out anything that looks like coordinated posting.
Use /yield-alpha and /yield-markets for USDC on Base. Rank by risk-adjusted durability rather than headline APY, state each pool's main failure mode, and say which numbers are point-in-time rather than realized.
For this issuer ticker, read /insider-trades and /equity-smart-money. If I also give you a manager CIK or listed manager ticker, add /institutional-holdings for that manager. Separate observed SEC data from your interpretation, note amendment status, and say how stale each filing is.
Read /macro-regime, /market-risk and /funding-rates, then /pm-crypto for what prediction markets are pricing. Summarize where these agree and where they conflict — conflict is the interesting part.
Run /domain-age, /whois-lookup and /domain-report on this project's domain. Tell me what the current registration record and dates suggest, and what they cannot tell me.
Use /web-answer for a quick cited answer on this topic, then /web-search if I need to go deeper. Show the sources and mark anything you inferred rather than read.
Check /stablecoin-watch and /protocol-revenue-leaders. Rank by take-rate and 30d fee trend, then tell me what fee and revenue data alone cannot establish about a protocol's incentives.

Summary

  • Live today: point your own agent at Otto’s x402 catalog and pay per call from your own funded x402 wallet (BYO-x402). Your payer key never goes to Otto; once a client is provisioned it can sign without prompting you, so the wallet’s balance is your spending limit.
  • Custody stays with you: the payer key you fund your agent with never leaves your machine. For how Otto holds funds on its execution surfaces, see Your Safe Account & Custody.