# SELAT — Full-Text Corpus > The complete text of SELAT's editorial posts, Manifesto, and FAQ, in one document for answer engines. The link index lives at https://selat.ai/llms.txt. # SELAT vs Skyfire https://selat.ai/insights/selat-vs-skyfire _Published Aug 25, 2026_ Tags: compare, skyfire, agent payments, agent identity --- SELAT and Skyfire both help AI agents transact, but they solve different problems. SELAT is a runtime payment layer: an agent discovers a paid API, data source, or skill mid-task, sees the merchant's live quote, and settles it in USDC from one self-custody treasury over x402 or MPP. Skyfire describes itself as "The Agent Trust Stack": verified agent identity plus a commerce wallet, aimed at getting agents through website access, login, and checkout. Everything below about Skyfire comes from skyfire.xyz as read on August 25, 2026. Where we could not verify a fact, we say so rather than guess. ## What does each product actually do? **SELAT** pays every paid endpoint your agent's task calls — across x402, MPP, or whatever ships next — from one self-custody USDC treasury, in one execution. Discovery is free and federated: any merchant publishing an endpoint behind an HTTP 402 payment protocol is reachable without a signup. Each call is quoted before spend, checked against your hard caps, and lands in one reconciled ledger. **Skyfire** gives agents a verified identity token (they call it KYA — Know Your Agent) intended to unblock website access and logins, and an agentic wallet that completes checkouts. Their site says the wallet supports tokenized card transactions across major card networks (Visa, Mastercard, Discover are named) as well as USDC, plus a "Buy for Me" purchase flow using user mandates. Their listed partners include bot-management and identity vendors such as Akamai, DataDome, f5, HUMAN Security, Okta, and Fastly. ## When is Skyfire the better choice? Be honest about this — for some jobs it clearly is: - **Your agent buys from human storefronts.** If the task is checking out on retail websites with an end user's enrolled card, that is Skyfire's product and not SELAT's. SELAT does not do card checkout on websites. - **Your agent is blocked by bot defenses.** Skyfire's KYA identity token exists to get verified agents through access controls and logins. SELAT has no identity product; if your blocker is a 403 or a login wall rather than a 402 price, SELAT does not remove it. - **You need card rails.** Skyfire names the major card networks as partners. SELAT settles in USDC only. ## When is SELAT the better choice? - **Your agent pays machine-native API endpoints per call.** Search, scraping, enrichment, media generation, on-chain data — priced per request behind HTTP 402, paid at call time with no account, no API key, and no subscription. - **The capability is discovered at runtime.** SELAT's catalog is federated: the agent searches for a capability it didn't know about when you wrote the prompt, inspects the live quote, and pays only after your policy allows it. - **Custody matters to you.** Your treasury is a non-custodial MPC agent wallet — Circle Agent Wallet by default. SELAT never holds your keys and never custodies your balance; hard caps are enforced in the settlement path. - **You want one reconciled record.** Every settled call, every rail, one ledger — each payment mapped 1:1 to the named merchant it paid. ## Can you use both? They sit at different layers, so nothing about one excludes the other: identity and website checkout on one side, per-call API settlement on the other. There is no integration between the two products today. ## How do they differ on custody? SELAT's treasury is self-custody by construction: the MPC key never exists as a file anywhere, and only your wallet can sign a payment — a skill can ask, it can't sign. Skyfire's wallet enrolls user credit cards and manages stablecoins on the agent's behalf; how custody of those balances works beyond that is not stated on their homepage — {{VERIFY: Skyfire custody model}}. ## What does each cost? SELAT's fee is published: 0% on endpoints from the Circle Agent Marketplace, 5% on endpoints from other registries, included in the quote your agent sees before it pays. The merchant's own per-call price is quoted live — simple calls typically run $0.001–$0.05. Skyfire does not publish pricing on its homepage — {{VERIFY: Skyfire fees and pricing}}. ## Side by side | | SELAT | Skyfire | | --- | --- | --- | | Job | Pay per-call API endpoints discovered at runtime | Agent identity, website access, and checkout | | Rails | x402 and MPP (HTTP 402), USDC | Tokenized card networks and USDC (per skyfire.xyz) | | Identity product | None | KYA verified-agent token | | Card checkout on websites | No | Yes — their core use case | | Catalog | Federated — any 402 merchant reachable, no signup | Partner-integrated coverage; their site claims "more than 60% of the Web" | | Custody | Self-custody MPC wallet; SELAT never holds keys or funds | Managed agent wallet; custody model {{VERIFY: Skyfire custody model}} | | Spend controls | Hard caps enforced in the settlement path | User mandates on card transactions (per skyfire.xyz) | | Published fees | 0% Circle Agent Marketplace / 5% other registries | Not published — {{VERIFY: Skyfire fees and pricing}} | ## The short version If your agent needs to *be somebody* — a verified identity that gets it through logins and card checkouts on human websites — look at Skyfire. If your agent needs to *pay for capabilities* — machine-priced API calls it discovers mid-task, settled from a treasury you control — that is what SELAT is for. *Skyfire facts sourced from skyfire.xyz, read August 25, 2026. If anything here is out of date, tell us at hello@selat.ai and we'll correct it.* # Counterparty Risk in Agentic Payments: The Unmeasured Half https://selat.ai/insights/counterparty-risk-agentic-payments _Published Aug 19, 2026_ Tags: counterparty risk in agentic payments, ERC-8004 reputation, agentic payments adoption, x402 reliability, AI agent payments trust --- Ask where the agentic-payments ecosystem is investing its trust work and a pattern emerges: nearly all of it points at the agent as buyer. Authorization frameworks decide what an agent may do. Delegation chains prove who let it. Spend controls bound the damage. Merchant-side verification confirms the agent knocking is legitimate. This work is necessary — we build spending caps and policy into our own product and would not ship without it. But it answers only one question: can we trust the agent as a buyer? The agent's own question — can I trust the seller I'm about to pay? — is **counterparty risk in agentic payments**, and on the open agent-payment rails, where most purchases happen, it goes essentially unmeasured. That asymmetry, more than any missing guardrail, is holding adoption back. ## Where the trust infrastructure points today Inventory the stack being built for AI agent payments and sort each piece by the direction of its trust arrow. Authorization and delegation protocols verify the agent to its operator. Spending caps and session budgets protect the operator from the agent. Agent-verification schemes protect merchants from unwanted bots. Identity registries make the agent legible to everyone else. Every arrow points at the agent as buyer. The buying agent is modeled as the risk to be contained — and in a real purchase on today's stablecoin-based agentic payment rails, the buying agent is the party at risk. ## What does ERC-8004 actually do, and where does it stop? One standard deserves credit for pointing the other way. [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004), "Trustless Agents", defines three registries: identity for portable agent IDs, reputation for client agents rating the server agents they buy from, and validation for third parties attesting that work was done. The reputation flow is literally the buyer rating the seller. Those are the right primitives. But the specification keeps payments explicitly orthogonal: feedback need not be grounded in any real transaction, and attaching proof of payment is optional. Reputation by attestation records claims. The first empirical study of the deployed ecosystem, [arXiv 2606.26028](https://arxiv.org/abs/2606.26028) (data through 13 May 2026), measured the consequence across Ethereum, BNB Smart Chain, and Base: only 3%, 4%, and 15% of registered agents had a valid registration file with at least one declared service endpoint; 73.5%, 59.2%, and 90.6% of reviewers showed coordinated Sybil behavior; and after Sybil-flagged feedback was removed, 15.8%, 77.9%, and 86.8% of *rated* agents were left with no valid feedback. The starkest number: on Base, 93.8% of reviewers had never made an x402 payment, yet they submitted 94.9% of all feedback. Reputation written by reviewers with no x402 payment history. The authors' conclusion: the registry, as currently deployed, "cannot function as a trust signal." A buyer does not need claims. A buyer needs outcomes. ERC-8004 is not entirely alone, and the pattern across its neighbors is instructive. Virtuals' Agent Commerce Protocol holds payment in escrow until an evaluator agent verifies the deliverable against a signed agreement — real outcome verification, but only inside its own marketplace. Open dashboards like x402scan measure endpoint liveness, latency, and usage — genuine observability, but availability is not delivery, and usage counts inherit the ecosystem's wash-trading problem. Competition networks rank agents by verified performance in staged arenas — skill, but not purchases. Each closes part of the gap. None gives an agent, at the moment of purchase on the open rails, an outcome-grounded read on the counterparty it is about to pay. ## Who carries the risk in an agent payment? On stablecoin-based agentic payment rails — x402 and other pay-first HTTP 402 flows — the buyer pays first and discovers the truth second: whether the endpoint answers at all, whether anything is delivered, whether the delivery matches the quote. Settlement is final; there is no in-protocol dispute layer. Independent probes of the raw, open listings — the registries, not curated catalogs — keep finding failure rates that would end any human marketplace: in published crawls, most listed endpoints were unreachable or couldn't return a valid payment request. That is the actual state of agentic payments today: heavily guarded buyers facing effectively unmeasured sellers. ## What card networks teach us about adoption Commerce has run this experiment before. Card networks did not grow by capping what consumers could spend; they grew in large part by capping what consumers could lose. The chargeback regime — protection, not restraint — is much of what made strangers safe to buy from. And buying from strangers is the entire point of a network. Restraint made spending safe for the operator. Protection made it rational for the buyer. Adoption followed the second, not the first. An agent with a funded wallet, tight authorization, and zero counterparty signal is not an equipped buyer — it is a well-guarded gambler, and its operator knows it. ## What sell-side measurement would look like The missing work is unglamorous: measure the sell side, continuously, where purchases happen. Answer rates. Delivery rates. Quote accuracy. Records that join what was paid to what actually arrived. Not a one-off audit or an exposé thread — a study is not a signal a buyer can use at purchase time. Equipping the buyer means pricing the seller. Guardrails tell an agent when to stop; a market only forms when something credible tells it when to go. That is the lens we build with. SELAT is the buy-side of machine-native commerce: discover a paid capability, fund Circle Gateway, and pay USDC from the user's Circle Agent Wallet — self-custody; SELAT never holds keys or funds. The motion is one path — discovery, spending policy, payment, reconciliation of the payment with the returned response — whatever HTTP 402 scheme the merchant chose. A reconciled receipt is not the same as independently verified delivery; that distinction is the gap this essay is about. If you are building an agent that needs to access capabilities across many providers without provisioning API keys or juggling multiple accounts, start with [llms.txt](/llms.txt), or read how [x402 and MPP differ](/insights/x402-vs-mpp). ## FAQ ### What is counterparty risk in agentic payments? The risk the buying agent carries that the seller — an API, service, or another agent — will not answer, will not deliver, or will not deliver what was quoted. On pay-first stablecoin rails with final settlement, this risk sits almost entirely with the buyer. ### Does ERC-8004 solve seller trust? It is the right primitive aimed at the right party, but its reputation is attestation-based and explicitly payment-orthogonal — feedback need not come from a real transaction. The first empirical study of the deployed ecosystem (arXiv 2606.26028) found most feedback Sybil-coordinated and concluded the registry cannot yet function as a trust signal. Adjacent efforts stop short in other ways: marketplace escrow-and-evaluation works only within a single venue, and ecosystem dashboards measure liveness rather than delivery. ### Why is agentic payments adoption slower than the infrastructure suggests? Because nearly all trust work restrains the buyer instead of protecting it. Restraint reduces downside for operators and merchants; it does not give a buyer a reason to transact with an unmeasured counterparty. ### How reliable are x402 endpoints today? Independent community probes have repeatedly found that a majority of publicly listed endpoints fail basic availability or protocol-correctness tests. Reliability varies widely, which is exactly why purchase-time counterparty signals matter more than listings. ### Does SELAT verify that a seller delivered what was quoted? No. SELAT records the payment and the response that came back, from a self-custody Circle Agent Wallet the user controls. That is a reconciled paid run, not an independent proof of delivery or quote accuracy — the measurement this essay argues the ecosystem still lacks. # Why Do AI Agents Break the Moment a Task Needs Payment? https://selat.ai/insights/why-agents-break-at-payment _Published Jun 26, 2026_ Tags: AI agent payment problem, runtime payment surface, agent payment infrastructure, agentic commerce, HTTP 402, payment rails, Circle Agent Wallet --- **AI agents break at payment because API access moved into the runtime and payment didn't.** An agent discovers a paid service mid-task, hits `HTTP 402 Payment Required`, and has nowhere in its runtime to put a payment: no payment surface, no shared credentials, no unified liquidity. Watch an autonomous agent work and it's impressive right up until it isn't. It plans, it reasons, it calls tools, it chains steps. Then the task crosses a paywall — a paid dataset, a metered API, a unit of compute it doesn't already have access to — and the whole thing seizes. The agent that just navigated a ten-step workflow can't get past a single `402`. This isn't a model problem; the reasoning is fine. It's an infrastructure problem. Your agent stops where payment starts. ## Why can't agents just use API keys? For twenty years, accessing an API meant a human did setup work once: sign up, get a key, store it, wire it into the app. Agents inherited that model and it doesn't fit them. An autonomous agent can't sign up for accounts. It can't juggle a pile of API keys without becoming a liability the first time one leaks. It can't enter a credit card or click "subscribe." And critically, it discovers what it needs *at runtime* — it doesn't know in advance which services it'll call, so there's no setup moment to pre-arrange access in. The result is a structural gap. Discovery moved into the agent's runtime; payment didn't. Three things are missing the moment a task needs to pay: - **No runtime payment surface.** Agents spend at runtime, but payment setup still lives outside the agent workflow. - **No shared credential envelope.** Every service wants its own key, stored its own way. That doesn't compose for a thing calling dozens of services it's never seen. - **No unified liquidity path.** Even once an agent *can* pay, it has to fund and reconcile across separate rails that don't know about each other. ![Diagram of the runtime payment gap: the agent runtime holds planning, reasoning, tool calls, and discovery, but payment setup — signups, API keys, cards, per-rail setup — sits outside it, so the task stalls at HTTP 402 Payment Required](/insights/runtime-payment-gap.svg) ## What did HTTP 402 standardize, and what stayed fragmented? The good news of 2026 is that the industry agreed on how to *ask* for payment. `HTTP 402 Payment Required` — reserved since the 1990s — became the spine of machine-native charges. Coinbase has reported 160M+ x402 agentic transactions; treat that as a protocol-volume figure, not a measure of genuine commercial demand. Coinbase, Stripe, Visa, Mastercard, Google, and Circle have all shipped agent-payment schemes. The bad news is that they standardized the *challenge* and fragmented the *settlement*. Credentials, liquidity, and settlement now scatter across Circle Gateway, x402, MPP, and a queue of adjacent commerce protocols (ACP, UCP, AP2) plus agent-to-agent messaging (A2A). So "agents can pay" quietly became "agents can pay, if they re-implement every rail, and re-implement the next one next quarter." For a builder, that's the worst kind of gap: not a wall you can't climb, but a tax that grows every time you ship. ## What does closing the gap actually require? If the problem is "payment doesn't live in the runtime," the fix isn't a better wallet or a faster chain. It's a **payment surface that exists where the agent already is** — one that turns "this task needs to pay" into a single runtime call, and absorbs the rail fragmentation so the agent never sees it. Concretely, that means three things the agent should *not* have to do itself: 1. **Discover and price** a service it didn't know about a second ago. 2. **Translate credentials** so one signature satisfies whatever scheme the merchant uses. 3. **Orchestrate settlement** — choose the rail, move the money, reconcile — across protocols that don't coordinate. This is the job SELAT takes off the agent's plate. Discover, fund Circle Gateway, pay USDC from the user's Circle Agent Wallet. The agent signs one shape; SELAT resolves discovery, authorization, settlement, and reconciliation. SELAT never holds keys or funds. The payment surface moves *into* the runtime, where the gap was. ```bash selat run "search the web for recent papers on agentic payments" ``` `selat run` spends unless you pass `--dry-run`. That's the whole point: the agent expresses intent, and getting from intent to a paid result stops being the step where everything breaks. ## Why is this the interesting problem in agentic commerce? It's tempting to treat payments as plumbing — necessary, unglamorous, solved-enough. But the agents people actually want don't just answer questions; they *do* things, and doing things in the real world almost always costs money somewhere in the chain. An agent that can't reliably cross a paywall is an agent that can only ever operate in the free tier of the world. Closing the runtime payment gap is what turns autonomy from a demo into a workflow. The reasoning was never the bottleneck. Payment was. ## What's the real unit of work: the payment or the skill? There's a reframe hiding at the end of this. When an agent does real work, it rarely crosses a single paywall — it runs a *skill*: a multi-step workflow that might hit a search API on one rail, a scraper on another, a model behind a third. Solving payment per call is necessary, but it's not the destination. What the runtime actually needs is cross-rail composition: **every endpoint a multi-step skill calls paid — across whatever rails they live on — from a single self-custody balance, in one execution**. Each merchant is paid directly, at its live quote, on its own rail, per call, with every call drawing on one Circle Agent Wallet, under one set of spending caps, reconciling into one ledger. That's a bigger idea than a payment surface. Registries solved how skills get *listed* — distribution is free and it works. Nothing underneath them solved how a skill gets *settled*. Closing the runtime payment gap is step one; the rest is where this is all headed. If you're building agents that need to transact, the builder's-eye view of the same territory is [how AI agents pay for APIs](/insights/how-ai-agents-pay-for-apis). Start with [llms.txt](/llms.txt), or compare the protocols in [x402 vs MPP](/docs/primers/x402-vs-mpp). ## FAQ ### Why do AI agents break at payment? Because they discover services at runtime but still lack a payment surface in that same runtime. `HTTP 402 Payment Required` is a well-specified challenge; funding, credentials, and settlement are not one path. ### What is a runtime payment surface? A way to turn "this task needs to pay" into a single in-workflow call: discover, quote, apply spending caps, pay, return the resource. Without it, the agent has to leave the task and wait for a human to provision a key or a card. ### How does SELAT close that gap? Discover → fund Circle Gateway → pay USDC from the user's Circle Agent Wallet. `selat run` does that path and spends unless you pass `--dry-run`. SELAT never holds keys or funds. Hosted discovery at `https://catalog.selat.ai/mcp` is search and quotes only. ### Is HTTP 402 enough by itself? No. HTTP 402 standardizes the ask. Merchants still settle on different rails. The agent still needs one wallet, one policy, and one way to pay whoever answered the 402. # How to Let AI Agents Pay for APIs and Get Past Paywalls Automatically https://selat.ai/insights/how-ai-agents-pay-for-apis _Published Jun 5, 2026_ Tags: how agents pay for APIs, agentic payments, paywalls, autonomous agents, HTTP 402, Circle Agent Wallet, USDC payments, spending caps, x402 --- Your agent is mid-task. It needs a piece of paid data, a model call, or an API it doesn't already have a key for. A year ago that's where it stopped: a paywall, and a human asked to go sign up, grab a key, and paste it back in. In 2026 you can let an autonomous agent handle that moment itself. **AI agents pay for APIs** by answering an `HTTP 402 Payment Required` challenge and settling in USDC from a wallet the operator controls — no checkout page, no human approving each charge. That capability is **agentic payments**. The protocols are live. This is a builder's guide to how it actually works: what "getting past a paywall" really means for an agent, the HTTP 402 challenge, how an agent holds money in a Circle Agent Wallet, how a single call turns into a settled payment, and how you keep an autonomous spender inside hard spending caps. ## Can an autonomous agent bypass a paywall? Not by sneaking around it. The honest answer is better: it pays the paywall, automatically. There are two kinds of paywall on today's internet, and the distinction is the first thing to internalize: - **Human paywalls** — subscription and login walls in front of content, built for people with accounts and browsers. Agents should not circumvent these, and SELAT does not. - **Machine-payable paywalls** — `HTTP 402 Payment Required` challenges in front of APIs, data, and services, designed from the start to be paid by software at request time. For the second kind, "bypassing the paywall" just means paying it in-flight: the agent hits the wall, reads the price, pays it, and retries with proof of payment. Nothing is circumvented. The merchant gets paid, the agent gets the resource, and the task keeps moving with no human in the loop. The rest of this guide is how to set that up. ## What are agentic payments? 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. That breaks every assumption built into human payments: - **Machine-to-machine.** No browser, no human in the loop per transaction. - **High-frequency, low-value.** Many micropayments, not occasional big ones. Published x402 catalogs often quote well under a dollar per call; treat live `402` quotes as the price, not a blog range. - **Policy-bounded.** Spending caps and per-call budgets stand in for human judgment. - **Identity is a wallet.** The agent authenticates and pays with a wallet and signer, not an account password. Cards, invoices, and monthly billing simply don't fit a thing that wants to make dozens of small payments to many different merchants in one task. ## How does an HTTP 402 paywall work? The whole system rests on a status code reserved since HTTP/1.1 and left unused for decades: `HTTP 402 Payment Required`. The flow is simple: 1. Your agent requests a resource. 2. The server replies `402` with a payment instruction instead of the data. 3. The agent pays. 4. The agent retries with proof of payment, and the server returns the resource. No subscription, no account, no prior relationship. Pay-per-call. Settlement time depends on the rail (on-chain USDC versus a session or card method); the important property is that payment is part of the HTTP exchange, not a separate checkout. ## How does an agent hold and spend money? An agent pays from a **wallet**, not a credit card. In practice that means a self-custody **Circle Agent Wallet** funded with USDC. The operator funds **Circle Gateway**; the agent's signer authorizes payments; you stay in control of the funds. SELAT never holds keys or funds. The important part for anyone nervous about handing money to an autonomous process: **spending limits are enforced, not suggested.** A well-built setup writes hard caps — per-transaction, daily, weekly, monthly — that the agent literally cannot exceed, plus a per-call price cap so any quote above your ceiling is rejected before it's ever signed. The agent operates freely *inside* the box; it can't spend its way out of it. ## Why isn't there one payment rail? Here's where it gets messy. `HTTP 402` standardized the *challenge* — "you must pay" — but not what happens below it. Different merchants settle over different rails: - **x402** — the open standard from Coinbase, now stewarded by the x402 Foundation under the Linux Foundation. Primarily USDC on-chain (Base and Solana are the two most-used settlement networks; other chains exist). - **MPP** — the Machine Payments Protocol, co-authored by Stripe and Tempo. Multi-rail: Tempo stablecoins, Stripe cards, and extensible custom methods. See [x402 vs MPP](/docs/primers/x402-vs-mpp). - **Circle Gateway** — batched, gas-free USDC settlement used for high-frequency nanopayments, often with x402-compatible services. It is a settlement layer, not a third HTTP-402 dialect. - Adjacent commerce protocols (ACP, UCP, AP2) and agent-to-agent messaging (A2A) keep shipping around the same problem. Each payment rail has its own signing shape, its own credentials, its own liquidity. An agent that wants to pay *any* merchant has to re-implement all of them — and re-implement the next one when it lands. That's the integration tax, and it's the real reason "agents can pay" hasn't yet meant "agents can pay *anywhere*." ## How does SELAT make it one call? SELAT collapses that mess into a single runtime path. Discover a paid capability, fund Circle Gateway, and pay USDC from the user's Circle Agent Wallet. You sign one shape; SELAT handles discovery, rail detection, and settlement. SELAT never holds keys or funds. A full intent-to-result run looks like this from the terminal: ```bash selat run "search the web for recent papers on agentic payments" ``` `selat run` spends unless you pass `--dry-run`. Under the hood, SELAT: 1. **Discovers** candidate services across federated catalogs and ranks them by how well they match your intent. 2. **Prices** the chosen service and probes its `402` challenge. 3. **Detects the rail** and pays — from the Circle Agent Wallet, directly when it can, or routed when it must. 4. **Returns** the upstream response, ready to pipe back into the agent's reasoning loop. You never branch on protocol. You never hold a key per merchant. Hosted discovery at `https://catalog.selat.ai/mcp` is search and quotes only — it cannot spend. Spend stays on the local runner. ## How do you get started? If you're building a skill that needs to transact, the fastest path is the CLI: `selat init` (Circle Agent Wallet), `selat fund` (Circle Gateway), set spending policy, then `selat run` — or `selat run --dry-run` to quote without paying. Plugins install into Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, and Hermes; start from [llms.txt](/llms.txt). One thing worth internalizing early: a single paid call is the unit of the *protocol*, not of the *work*. Real agent tasks run as skills — multi-step workflows that chain several paid endpoints, often across different rails, in one execution. That is cross-rail composition: every endpoint the skill calls is paid merchant-direct, at its live quote, on its own rail, and every one of those calls draws on the same self-custody balance, under the same caps, reconciling into the same ledger. Agentic payments are the verb; this — every call in a run settled from one balance — is what you're actually building toward. The takeaway for builders: agentic payments aren't a someday feature — they're a thing your agent can do today, as long as you don't make it learn every rail by hand. Let it sign once, cap it hard, and route the rest. For the problem-side view of the same territory, see [why AI agents break the moment a task needs payment](/insights/why-agents-break-at-payment). ## FAQ ### How do AI agents pay for APIs? They request the resource, receive `HTTP 402 Payment Required` with a payment instruction, settle (commonly USDC), and retry with proof of payment. No API key, no checkout page, no human per charge. ### Can AI agents bypass paywalls automatically? They pay them automatically, which is the version that actually works. An `HTTP 402` paywall is machine-payable by design: challenge, pay, retry, data. Human subscription and login paywalls are a different thing, and SELAT does not circumvent them. ### How do I let an agent spend autonomously without losing control? Set hard caps before the first paid call: per-transaction, per-session, daily, weekly, and monthly limits, enforced in the settlement path rather than in a prompt. Quote first with `selat run --dry-run`, and treat the caps and each live quote as the approval boundary. ### What is HTTP 402 Payment Required? A status code reserved in HTTP for "payment required" and unused for decades. x402 and MPP both use it as the challenge: the server withholds the resource until the client pays. ### What is a Circle Agent Wallet in this flow? The self-custody wallet the operator funds. USDC is deposited into Circle Gateway; payments are signed from that wallet. SELAT never holds the keys or the funds. ### Does `selat run` spend money? Yes. `selat run` discovers, quotes, then pays. Pass `--dry-run` to quote without paying. The hosted discovery MCP cannot move funds. # Pay Exa from Your Agent — No API Key, One Install https://selat.ai/tutorials/pay-exa-from-your-agent _Published Aug 21, 2026_ Tags: exa api no api key, pay exa with usdc, exa x402, exa agent, exa web search api pricing, exa mpp tempo, exa pay per call, exa api without signup, ai agent web search api, exa contents endpoint --- **Exa** is an AI-native web search API: neural and keyword search over live web pages, plus content extraction that returns clean page text, highlights, and AI-generated summaries. Your agent can call it **per request, with no API key and no signup** — the endpoint answers `402`, the agent pays USDC from the user's Circle Agent Wallet, and the result comes back in the same run. SELAT never holds keys or funds. ## What Exa does Exa searches the web by meaning rather than keyword match and returns results already shaped for a model to read: ranked URLs, titles, published dates, authors, full page text, highlights, and summaries. It exists to ground LLMs and agents on live web data. - **Semantic web search** — find relevant pages by meaning, not exact-match terms. - **Clean content retrieval** — pull readable page text from a URL or an Exa document ID. - **Highlights and AI summaries** — condensed page content for grounding a model. - **News, company research, and fact-checking** — recent dated results, sourced pages for a named entity, and the page a claim actually came from. Full API reference: [docs.exa.ai](https://docs.exa.ai/). ## What it costs Exa lists **2 endpoints** in the catalog, both of them priced, and both payable on every chain Exa quotes. | Endpoint | What it returns | Price | Rail | |---|---|---|---| | `POST /search` | Ranked web results optimized for AI agents | $0.007 | all 3 rails | | `POST /contents` | Clean page content from URLs or Exa document IDs | $0.001 | all 3 rails | Catalog prices run from **$0.001 to $0.007** per call. `/contents` costs a seventh of `/search`, so a retrieval-heavy loop stays cheap per page. ## Where Exa is payable Exa is payable on Base, Solana, and Tempo; the agent does not pick. ## Install SELAT in your agent SELAT installs **once per agent runtime** — no per-service setup, no API key. Quickest path (Claude Code): ```bash claude plugin marketplace add SELAT-AI/selat-plugins claude plugin install selat@selat-plugins ``` Using Codex, Cursor, Gemini CLI, OpenClaw, Hermes, or a plain terminal? Follow the canonical, always-current install guide: **[Install SELAT →](https://selat.ai/docs/selat-plugins)**. ## Pay Exa from your agent `selat search` is free: hosted discovery returns ranked, live-priced candidates and does not spend. `selat run` spends — it discovers, quotes, and pays USDC from the user's Circle Agent Wallet. `selat run --dry-run` quotes without paying. SELAT never holds keys or funds. ```bash selat search "search the web for recent papers on agentic payments" # free — ranked, live-priced selat run "search the web for recent papers on agentic payments" --dry-run # quotes without paying selat run "search the web for recent papers on agentic payments" # spends: discover → quote → pay USDC ``` Fund path: `init → fund → run`. Fund Circle Gateway, then pay USDC from the user's Circle Agent Wallet. See the [SELAT CLI / docs](https://www.selat.ai/docs) for `init → fund → run`. ## When to use Exa vs alternatives - **Use `/search` when you need to *find* pages.** $0.007 buys ranked, meaning-matched results when your agent doesn't yet know which URL matters. - **Use `/contents` when you already have the URL.** At $0.001, extraction costs a seventh of search — don't pay search prices to read a page you already found. - **Use Exa when the answer has to be current.** A model's weights are stale by definition; Exa's job is live web grounding. - **Skip Exa when the model already knows.** A paid call for something answerable from context is money spent on nothing. ## FAQ ### Do I need an Exa API key to use Exa from an agent? No. The endpoint answers `HTTP 402` with a payment instruction, your agent pays USDC from the user's Circle Agent Wallet, and the retry returns the data. No signup, no dashboard, no key to rotate. SELAT never holds keys or funds. ### How much does one Exa API call cost? `POST /search` quotes **$0.007** per call and `POST /contents` quotes **$0.001**. A loop that searches once and reads five pages runs about **$0.012**. ### Which chain does Exa settle on? Exa is payable on Base, Solana, and Tempo; the agent does not pick. ### What's the difference between Exa `/search` and `/contents`? `/search` finds pages by meaning and returns ranked results. `/contents` takes URLs or Exa document IDs you already have and returns clean text, highlights, and summaries. Most loops call `/search` once and `/contents` several times. ### Is Exa's `/contents` endpoint free? Not as a documented tier — budget **$0.001** per call. One `/contents` listing does carry a `$0` quote with no amount attached. ### Can my agent pay Exa in USDC? Yes. Pay USDC from the user's Circle Agent Wallet. Your agent pays whatever asset the quote names, without choosing. ### Can I cap what my agent spends on Exa in one run? Yes. You set a per-call ceiling and a session budget, and you can freeze the wallet. With a $0.001–$0.007 spread the ceiling matters less here than the session budget — the risk on Exa is call volume, not any single call. ### How do I call Exa from my agent? Install the SELAT plugin in Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, or Hermes, then ask for the web context you need — the agent finds Exa in the catalog and `selat run` pays for the call in the same session. You write the intent; the agent does not pick the chain. ## Related - [Pay Tavily from your agent](/tutorials/pay-tavily-from-your-agent) - [Pay Nansen from your agent](/tutorials/pay-nansen-from-your-agent) - [Capability tutorials](/tutorials) - [SELAT CLI / docs](https://www.selat.ai/docs) # Pay Nansen from Your Agent — No API Key, One Install https://selat.ai/tutorials/pay-nansen-from-your-agent _Published Aug 21, 2026_ Tags: nansen api no api key, pay nansen with usdc, nansen x402, nansen agent, nansen api pricing per call, smart money api for agents, on-chain analytics api pay per call, nansen mpp tempo, wallet profiler api agent, nansen api x layer --- **Nansen** is an on-chain analytics API — smart money flows, wallet profiling and PnL, token holder and flow analytics, Nansen Score rankings, perpetual and prediction market data, and token screening across multiple chains. Your agent can call any of its **72 endpoints per request, with no Nansen account and no API key** — the endpoint answers `402`, the agent pays USDC from the user's Circle Agent Wallet, and the rows come back in the same run. SELAT never holds keys or funds. Nansen is the deep-surface case: one merchant and a 750x price spread between its cheapest and most expensive call. ## What Nansen does Nansen turns raw chain activity into labelled intelligence: which wallets are moving, what they hold, what they made or lost, and how flow looks around a given token. The surface is genuinely long-tail — each product area is its own set of separately priced calls, not one omnibus query. - **Smart money** — netflow, holdings, DEX trades, perp trades, DCAs. - **Wallet profiler** — current and historical balances, transactions, counterparties, related wallets, PnL and PnL summary. - **Token God Mode (TGM)** — flows, flow intelligence, holders, transfers, DEX trades, OHLCV, PnL leaderboard. - **Perps** — contract screener, trading leaderboard, Hyperliquid perp PnL summary. - **Prediction markets** — market and event screeners, categories, OHLCV, PnL by market, top holders. - **Screening and scoring** — token screener, Nansen Score top tokens, chain growth rankings. - **Research agent** — Nansen's own research agent in "fast" and "expert" modes. Full API reference: [nansen.ai](https://nansen.ai/). ## What it costs Nansen lists **72 endpoints** in the catalog, 65 of them priced. A representative spread: | Endpoint | What it returns | Price | Rail | |---|---|---|---| | `POST /api/v1/profiler/address/pnl` | Address PnL | $0.01 | all 4 rails | | `POST /api/v1/perp-screener` | Perpetual contract screening | $0.01 | all 4 rails | | `POST /api/v1/prediction-market/market-screener` | Prediction market screener | $0.01 | all 4 rails | | `POST /api/v1/smart-money/netflow` | Smart money netflow | $0.05 | all 4 rails | | `POST /api/v1/tgm/holders` | Token God Mode holders | $0.05 | all 4 rails | | `POST /api/v1beta1/tgm/historical-pnl-leaderboard` | Historical TGM PnL leaderboard (beta) | $0.25 | x402 · exact · Solana, Base, X Layer | | `POST /api/v1/agent/fast` | Nansen Research Agent, fast mode | $2.00 | x402 · exact · Solana, Base, X Layer | | `POST /api/v1/agent/expert` | Nansen Research Agent, expert mode | $7.50 | x402 · exact · Solana | Catalog prices run from **$0.01 to $7.50** per call. Most of the profiler, TGM, perp and prediction-market endpoints sit at $0.01 or $0.05; the top of the range is 750x the floor, and it belongs to two endpoints. ## Where Nansen is payable Nansen is payable on Solana, Base, X Layer, and Tempo; the agent does not pick. ## Install SELAT in your agent SELAT installs **once per agent runtime** — no per-service setup, no API key. Quickest path (Claude Code): ```bash claude plugin marketplace add SELAT-AI/selat-plugins claude plugin install selat@selat-plugins ``` Using Codex, Cursor, Gemini CLI, OpenClaw, Hermes, or a plain terminal? Follow the canonical, always-current install guide: **[Install SELAT →](https://selat.ai/docs/selat-plugins)**. ## Pay Nansen from your agent `selat search` is free: hosted discovery returns ranked, live-priced candidates and does not spend. `selat run` spends — it discovers, quotes, and pays USDC from the user's Circle Agent Wallet. `selat run --dry-run` quotes without paying. SELAT never holds keys or funds. ```bash selat search "smart money netflow for a token on Base" # free — ranked, live-priced selat run "smart money netflow for a token on Base" --dry-run # quotes without paying selat run "smart money netflow for a token on Base" # spends: discover → quote → pay USDC ``` Fund path: `init → fund → run`. Fund Circle Gateway, then pay USDC from the user's Circle Agent Wallet. See the [SELAT CLI / docs](https://www.selat.ai/docs) for `init → fund → run`. ## When to use Nansen vs alternatives - **Use Nansen when the question is about *who*, or spans products.** Labelled wallets, smart money positioning, counterparties and related addresses, plus token flows, perps and prediction markets in one run against one merchant. ## FAQ ### Do I need a Nansen API key to use Nansen from an agent? No. Your agent pays per call from the user's Circle Agent Wallet and gets the response back — there is no Nansen account to create and no key to store or rotate. SELAT never holds keys or funds. ### How much does one Nansen API call cost? It depends on the endpoint. Catalog prices run from **$0.01 to $7.50**; most of the profiler, TGM, perp and prediction-market endpoints sit at $0.01 or $0.05, and the top of the range is the Nansen Research Agent — $2.00 in fast mode, $7.50 in expert mode. ### Which chain does Nansen settle on? Nansen is payable on Solana, Base, X Layer, and Tempo; the agent does not pick. ### Can one agent run combine Nansen smart money data with a wallet profiler lookup? Yes. Each endpoint is priced and paid on its own, so a single skill can chain `smart-money/netflow` into `profiler/address/pnl` and settle both from the same Circle Agent Wallet under the same caps. ### Does Nansen cover perps and prediction markets, or just tokens and wallets? Both. There is perp screening, a perp trading leaderboard, and Hyperliquid perp PnL summary, plus prediction-market screeners, categories, OHLCV, PnL by market, and top holders. ### Can I cap what my agent spends on Nansen in one run? Yes. You set a per-call ceiling and a session budget, and you can freeze the wallet. With a $0.01–$7.50 spread on this merchant, the per-call ceiling is the control worth setting first — a quote above it does not get paid. `selat run --dry-run` quotes without paying. ### How do I call Nansen from my agent? Install the SELAT plugin in Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, or Hermes, then ask the on-chain question you actually have — the agent finds the matching Nansen endpoint in the catalog and `selat run` pays for the call in the same session. You write the intent; the agent does not pick the chain. ## Related - [Pay Tavily from your agent](/tutorials/pay-tavily-from-your-agent) - [Pay Exa from your agent](/tutorials/pay-exa-from-your-agent) - [Capability tutorials](/tutorials) - [SELAT CLI / docs](https://www.selat.ai/docs) # Pay Tavily from Your Agent — No API Key, One Install https://selat.ai/tutorials/pay-tavily-from-your-agent _Published Aug 21, 2026_ Tags: tavily api no api key, pay tavily with usdc, tavily x402, tavily mpp tempo, tavily agent, tavily pay per call, tavily search api pricing, tavily crawl endpoint, ai web search for agents, agentic web search api --- **Tavily** is an AI-optimized web search, content extraction, site mapping, and crawling API. Your agent can call it **per request, with no API key and no signup** — the endpoint answers `402`, the agent pays USDC from the user's Circle Agent Wallet, and the content comes back in the same run. SELAT never holds keys or funds. Tavily is the budgeting case: price shape follows task shape, so what a research skill costs depends less on how many calls it makes than on which kind it makes. ## What Tavily does Tavily returns web content shaped for a model to read rather than for a person to click. The listing spans several task shapes, and the spread matters when you budget a run: a query is cheap, a whole-site traversal is not. - **Search** — ranked web results with content, built for retrieval rather than a SERP page. - **Extract** — page content from one or more specified URLs. - **Map** — site structure traversed as a graph, many paths in parallel. - **Crawl** — graph-based traversal that walks a site and returns what it finds. - **Research** — multi-search investigation of a topic with source analysis. Full API reference: [tavily.com](https://tavily.com/). ## What it costs Tavily lists **10 endpoints** in the catalog, 3 of them priced. Six representative rows: | Endpoint | What it returns | Price | Rail | |---|---|---|---| | `POST /search` | Tavily Search, advanced mode | $0.01 | x402 · exact · Base | | `POST /tavily/map` | Site structure traversed as a graph | $0.09 | MPP · exact · Tempo | | `POST /research` | Multi-search topic research with source analysis | $0.50 | MPP · exact · Tempo | | `POST /tavily/search` | Search results | no catalog price | MPP · exact · Tempo | | `POST /tavily/extract` | Page content from specified URLs | no catalog price | MPP · exact · Tempo | | `POST /tavily/crawl` | Crawled site content | no catalog price | MPP · exact · Tempo | Catalog prices run from **$0.01 to $0.50** per call on the endpoints that carry one. **Price shape follows task shape** — a query at $0.01, a site map at $0.09, a research pass at $0.50 — so a plan that maps three domains before it searches costs an order of magnitude more than one that searches first. ## Where Tavily is payable Tavily is payable on Base and Tempo; the agent does not pick. ## Install SELAT in your agent SELAT installs **once per agent runtime** — no per-service setup, no API key. Quickest path (Claude Code): ```bash claude plugin marketplace add SELAT-AI/selat-plugins claude plugin install selat@selat-plugins ``` Using Codex, Cursor, Gemini CLI, OpenClaw, Hermes, or a plain terminal? Follow the canonical, always-current install guide: **[Install SELAT →](https://selat.ai/docs/selat-plugins)**. ## Pay Tavily from your agent `selat search` is free: hosted discovery returns ranked, live-priced candidates and does not spend. `selat run` spends — it discovers, quotes, and pays USDC from the user's Circle Agent Wallet. `selat run --dry-run` quotes without paying. SELAT never holds keys or funds. ```bash selat search "ai-optimized web search with page extraction" # free — ranked, live-priced selat run "ai-optimized web search with page extraction" --dry-run # quotes without paying selat run "ai-optimized web search with page extraction" # spends: discover → quote → pay USDC ``` Fund path: `init → fund → run`. Fund Circle Gateway, then pay USDC from the user's Circle Agent Wallet. See the [SELAT CLI / docs](https://www.selat.ai/docs) for `init → fund → run`. ## When to use Tavily vs alternatives - **Use Tavily when the agent needs web content already shaped for a model.** Search, extract, map, and crawl sit behind one merchant, so a research skill does not stitch four vendors together. - **Use `/search` on x402/Base at $0.01 for high fan-out.** Cheap enough to issue many queries inside one task. - **Think twice before fanning out on `map` or `crawl`.** At $0.09 a map call, breadth gets expensive fast; `crawl` carries no listed price, so check the quote before you fan out. Search first, then map the one domain that matters. - **Weigh `/research` at $0.50 against composing it yourself** from several $0.01 searches plus extracts, when you need one deep topic pass. ## FAQ ### Do I need a Tavily API key to use Tavily from an agent? No. Tavily is listed as a pay-per-call merchant, so your agent pays per request from the user's Circle Agent Wallet instead of authenticating with a key. There is no signup step in the loop. SELAT never holds keys or funds. ### How much does one Tavily API call cost? The listed `POST /search` endpoint on x402/Base is **$0.01** per call. Of the ten listed Tavily endpoints, three carry a listed price: $0.01 for search, $0.09 for map, and $0.50 for research. ### Which chain does Tavily settle on? Tavily is payable on Base and Tempo; the agent does not pick. ### Why does Tavily's map endpoint cost more than search? Map traverses a site as a graph and explores many paths in parallel, so it does far more work per call than one query. It is listed at $0.09 against $0.01 for search. ### Can my agent use Tavily's crawl and extract endpoints pay-per-call? Yes — both are listed. Neither carries a listed price in the catalog, so the price comes back in the quote before your agent commits. `selat run --dry-run` quotes without paying. ### Can I cap what my agent spends on Tavily in one run? Yes. You set a per-call ceiling and a session budget, and you can freeze the wallet. On this merchant the per-call ceiling is what keeps a $0.01 plan from silently becoming a $0.50 one. ### How do I call Tavily from my agent? Install the SELAT plugin in Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, or Hermes, then ask for the web research you need — the agent finds the matching Tavily endpoint in the catalog and `selat run` pays for the call in the same session. You write the intent; the agent does not pick the chain. ## Related - [Pay Exa from your agent](/tutorials/pay-exa-from-your-agent) - [Pay Nansen from your agent](/tutorials/pay-nansen-from-your-agent) - [Capability tutorials](/tutorials) - [SELAT CLI / docs](https://www.selat.ai/docs) # The SELAT Manifesto https://selat.ai/manifesto Markets are built by exchange. Exchange happens when friction disappears. Throughout history, civilizations did not flourish around oceans. They flourished around straits: the passages where trade, capital, and ideas moved freely. A strait makes commerce possible without creating demand or owning the ports. We believe machine economies will emerge the same way. Autonomous agents have evolved from tools into economic actors. They can create value, monetize services, and hold assets. Yet when they need to buy services themselves, they hit fragmented merchants, disconnected payment systems, manual funding, API keys, and incompatible workflows. > The bottleneck isn't intelligence or payments. It's commerce. The missing piece is a connective layer that lets autonomous agents discover, procure, and settle value across fragmented systems, not another payment rail, wallet, or protocol. We built SELAT as a passage, not a destination. A digital strait for machine-native commerce. We believe the best infrastructure is invisible. It doesn't demand attention; it enables every transaction, every exchange, and every new market built on top of it. We aspire to remove the friction that stops commerce, not to own it. # Frequently Asked Questions https://selat.ai/faq > Cost, custody, caps, and the treasury model behind runtime agent payments — without a dashboard or account layer. ## What does SELAT actually do? SELAT pays every paid endpoint your agent's skill calls — across x402, MPP, or whatever ships next — from one self-custody treasury, in one execution. Every call is mapped 1:1 to the named merchant it paid, visible in your history — nothing pooled, nothing redistributed. ## What does it cost? Your agent pays each merchant's live quote per call — the merchant prices the request the moment your agent probes the endpoint, and you see the quote before the agent pays. Simple calls — search, scraping, enrichment — run $0.001–$0.05; heavier endpoints like media generation or deep research run tens of cents to a few dollars. SELAT's fee: 0% on endpoints from the Circle Agent Marketplace (agents.circle.com), 5% on endpoints from other registries (pay.sh, MPP services, Apify) — included in the quote you see. ## How is this different from an API key? An API key is something you sign up for, store, and can leak. A settled call is a payment your agent makes at the moment it's needed — mapped to the merchant it paid, no stored secrets. ## Is this crypto? Do I need to buy tokens? Your agent's treasury holds USDC — that's it. No native ETH, no gas to hold, no exchange account. Fund once via Circle Gateway and every paid call draws from that balance. ## Who holds my funds? You do. You hold the treasury through a non-custodial agent wallet — Circle Agent Wallet by default today. It's MPC: the private key never exists as a file anywhere, on your machine or ours. SELAT never holds your keys and never custodies your balance — your USDC stays yours until your wallet signs a per-call payment. Skills are declarative: a skill can ask for a payment, but only your wallet can sign one, and your caps are checked before it does. A skill can ask; it can't sign. ## What stops a bad skill from draining my treasury? Hard caps — per-transaction, per-session, daily, weekly, monthly limits you set, enforced in the settlement path, not in the skill's prose. A compromised skill can request settlement, but can't exceed your caps or reach your keys. ## How do I see what my agent spent? One ledger. Every settled call — every skill, every rail — lands in a single reconciled view: selat history. ## Do I need a wallet for every chain or every rail? No — one balance, one deposit. Deposit USDC into Circle Gateway from any one of the 7 EVM chains SELAT supports — Base, Optimism, Arbitrum, Polygon, Ethereum, Avalanche, or Unichain — and SELAT settles every merchant from that one balance, whatever chain or rail they're on. A chain is where your treasury lives; a rail is how a merchant gets paid (x402 or MPP). ## Which agent harnesses does this work with? Any harness that reads install.md — Claude Code, Codex, Cursor, OpenClaw, Hermes, and more. ## Do I need to store API keys to compose a skill? No — none in the source, and none demanded at runtime. Payment is the auth: each endpoint is paid at the moment it's called — no signups, no secrets to provision, nothing redistributed. Some merchants issue a prepaid access token at runtime; that's a receipt, not a key — proof of a payment already made, bounded by its remaining balance, governed by your caps. ## Does this replace OAuth integrations like Gmail or Slack? No. SELAT's catalog covers commercial paid endpoints — it doesn't replace OAuth access to your own SaaS accounts. ## How is this different from an API aggregator or proxy? Aggregators and proxies remove key sprawl by pooling accounts for you — and they gatekeep the catalog: your agent reaches only the merchants they've chosen to integrate. SELAT removes accounts entirely and federates the catalog: any merchant that publishes an endpoint behind an HTTP 402 payment protocol is already reachable. Payment is the access. Protocol is the integration.