Skip to main content
Agentic payments are payments initiated and settled by software agents rather than people. When an AI agent needs data, compute, or an API call mid-task, it pays for that resource autonomously — no checkout page, no human approving each charge. This breaks the assumptions of human-centric payments (cards, invoices, monthly billing) and calls for rails that are programmatic, low-value-friendly, and policy-bounded.

​
Why it’s different

  • Machine-to-machine. No browser, no human in the loop per transaction.
  • High-frequency, low-value. Many sub-cent to few-cent payments, not occasional large ones. Typical SELAT calls run roughly 0.001–0.001–0.05 in USDC.
  • Policy-bounded. Spending caps and per-call budgets stand in for human judgment.
  • Identity is a wallet. An agent authenticates and pays with a wallet/signer, not an account password.
The deeper problem is that existing API access assumes per-user API keys, per-service signup, and bespoke credential storage. That doesn’t compose for an autonomous agent: it can’t sign up for accounts, juggle fifty keys, or contain the fallout when one leaks. Open 402-based payment protocols replace that with pay-per-call settlement — but several rails exist, each with its own signing shape, so a naive agent would have to re-implement all of them.

​
How SELAT fits

SELAT gives agents a single path to discover, price, and pay for services over open payment protocols, so the agent says “find me a thing that does X” and gets a runnable, paid result.

​
Discover and price

SELAT’s discovery is federated across three catalogs — Circle’s x402 catalog, the Agentic Market, and the MPP catalog. An intent ranker scores candidate services by semantic keyword match, price relative to the cohort (log-scaled), and source-count credibility, with default weights of 0.65 / 0.25 / 0.10.
Payment rails are not scored by default. Discovery surfaces every payment option on the chosen endpoint and lets the payer decide direct vs. routed — so ranking stays about what the service does, not how it gets paid.

​
Pay over open rails

A 402 Payment Required challenge can be satisfied by two paid-rail protocols, and SELAT pays them two ways:
  • Direct — when the chosen Circle-supported chain matches the upstream’s offer, the payer settles a Gateway-batched payment directly, skipping the router.
  • Routed — for erc-3009 or tempo-native upstreams, the request goes through the SELAT Router, which verifies the inbound payment and translates rails on the outbound leg so the agent only ever signs one shape.
The two protocols are x402 (the open 402 standard, settled in USDC) and MPP (settled tempo-native). The SDK’s preferProtocol defaults to mpp, with x402 opt-in; among routed alternatives MPP wins by default. See x402 and MPP on Tempo for the rail details.

​
End-to-end: intent to result

A single command takes a plain-language intent through discovery, ranking, payment, and response.
1

Express an intent

The agent (or operator) describes what it needs in natural language.
selat run "search the web for recent papers on agentic payments"
2

Discover and pick

selat run invokes the discovery ranker, picks the top match, and validates that the selected execution hint is a selat-pay command.
3

Detect the rail and pay

selat-pay probes the upstream, auto-detects the protocol, and pays — choosing direct or routed mode without any branching in the agent.
[selat-pay] probing upstream directly to detect scheme
[selat-pay] mode=routed (upstream not Gateway-batched on eip155:8453; using router)
[selat-pay] quoteId=911f6e4b-8919-4536-bd48-fe5cbeded3ac
[selat-pay] price=$0.031500 on eip155:8453
[selat-pay] payTo=0x1E5Be7e87A876C04AF0ffd725adccf02e998c5C2
[selat-pay] signed; submitting paid request
[selat-pay] status=200
4

Return the response

The upstream’s response body prints on its own (JSON when applicable), ready to pipe into jq, a file, or back into the agent’s reasoning loop.
The same flow is available programmatically — RouterClient.fetch(url, { preferProtocol }) returns the final upstream Response. See RouterClient.

​
Identity, policy, and budgets

Wallet-as-identity in practice. Wallet creation, typed-data signing, and spending limits are delegated to Circle Agent Wallets (user-controlled 2-of-2 MPC) via the Circle CLI. Agents pay without API keys or local private keys — the skill never sees mnemonics or private keys. The SDK also supports a private-key signer or a remote signer object when in-process key handling or custom custody is preferred. USDC settlement runs over Circle Gateway. Confirmed SDK chain keys are base, optimism, arbitrum, and arc. Arc is a private-access mainnet (eip155:5042) that needs raw-key signing — Circle’s MPC signer can’t sign Arc yet — and has no gasless funding. Gateway supports additional EVM mainnets; for the authoritative set your runtime accepts, run npx @selat-ai/selat-pay --list-chains. Funding the budget. selat fund makes a direct deposit that settles on the source chain; selat fund --method eco is a gasless deposit from Base, Optimism, or Arbitrum that always settles into Gateway on Polygon (Eco is not supported on Arc). Hard spending caps. selat setup-policy writes Circle Agent Wallet spending limits — per-transaction, daily, weekly, and monthly (default prompts: 5 / 50 / 200 / 500 USDC). The write is gated by an email OTP, and the code describes it as “the only hard ceiling the agent literally cannot bypass.” Set caps with setup-policy before depositing more than about $20.
The Circle policy is the outer ceiling no payment can exceed. Inside it, every paid call also needs its own per-call price cap: pass --max-amount <usd> to selat skill run (the SDK requires an equivalent cap). The payer enforces it fail-closed — any quote where price <= cap is false is rejected before signing — so the two caps stack rather than override each other.

​
Next