Agent payments, explained
The vocabulary here is new and messy. This page explains the basics in plain language: no jargon, no assumption you're technical. Read it and you can hold a conversation about agent payments.
What is Agent payment?
Every online payment used to have a person behind it: a person clicks confirm, enters a password, takes responsibility. An agent payment lets an AI program do all of that itself — it decides to buy some data, call an API, hire another agent, and then sends the money, with no human clicking confirm.
Why now? Two pieces just clicked together. Stablecoins (dollars on a blockchain) let machines directly hold and move "money"; protocols like x402 let a single API call carry a payment. Put them together and a machine can spend like a person.
It usually has three traits: small amounts (often cents to a few dollars), high frequency, high speed. That's its value — efficient machine-to-machine collaboration — and its risk: by the time a human reacts, hundreds of payments may already be out the door.
So the real question isn't "can machines pay?" (they already can) but "who is this paid to, was it tricked, is the money clean?" — answered before the money actually leaves, at machine speed. That's exactly what OceanAlt does.
What is x402?
x402 is an open protocol that lets an AI agent pay for a single API call straight from its wallet. The name comes from an old HTTP status code — 402 Payment Required — which sat unused for decades; x402 picked it up.
How it works is simple: an agent calls an endpoint, the server says "this costs money" (returns a 402 with the amount, payee, and a one-time number). The agent signs and pays from its wallet, retries the request with proof of payment, and the server hands over the result.
What makes it special: no account, no API key. The payment is the identity — whoever paid gets access. That suits agents, which can't register, fill forms, and wait for approval the way people do.
x402 is driven by Coinbase and has run real volume on mainnet since 2025. It's one of the main foundations for machines spending on their own.
What is AP2 (Agent Payments Protocol)?
AP2 (Agent Payments Protocol) is a payments protocol led by Google. It's after the same big thing as x402 — letting AI agents pay safely — but from a different angle.
x402 focuses on completing a payment inside a single API call; AP2 focuses on proving the payment was actually authorized by the user. Its core is the "mandate": the user signs an authorization first (say, "may spend up to $50 on a flight"), and the agent carries that signature when it pays, so the merchant can confirm this isn't the agent spending on a whim but the user's real intent.
Why does that matter? Because agents can be tricked (see "prompt injection"). Without a verifiable mandate, a merchant can't tell "the user wanted this" from "the agent was manipulated into it." AP2 uses cryptographic signatures to pin down user intent so it can't be tampered with in transit.
Think of it as another main road for agent payments. The field is young — x402, AP2 and others coexist and are still competing and converging; no clear winner yet. OceanAlt's compliance layer is built to not depend on any single protocol, so it plugs into whichever road takes off.
What is the difference between x402 and AP2?
In short: both x402 and AP2 aim to let AI agents pay safely, but they cover different parts.
x402 (driven by Coinbase) is about the payment action itself: an agent calls an endpoint, the endpoint says "this costs money," and the agent signs and pays from its wallet on the spot — no account, no key; the payment is the pass. It solves "how to turn one call into one charge."
AP2 (driven by Google) is about the source of authorization: the user signs a mandate first (e.g. "may spend up to $50 on a flight"), and the agent carries that signature when it pays, so the merchant can confirm it's the user's real intent, not the agent freelancing. It solves "how to prove the payment was authorized."
So they aren't either/or — more like different links in one chain: one governs "how to pay," the other "on what authority." The field is young; no clear winner. OceanAlt's compliance layer is deliberately protocol-neutral: whether you use x402, AP2 or something else, the pre-settlement compliance check plugs in.
What is Stablecoin?
A stablecoin is a price-stable cryptocurrency, usually pegged one-to-one to a US dollar (USDC and USDT are common). It runs on a blockchain, but its value doesn't swing like Bitcoin's, because it's backed by equivalent dollars or Treasuries in reserve.
To a person it's like "dollars on-chain." To a machine it's essential — an agent can't open a bank account or send a SWIFT wire, but it can hold and move stablecoins directly. Stablecoins made "a machine holding and paying dollars" possible for the first time, which is the precondition for agent payments.
They also suit cross-border and micro-payments naturally: settled in seconds, near-zero fees, always on. A few-cent agent payment wouldn't even cover a bank's fee, but works fine in stablecoins.
One distinction to keep clear: stablecoins solve how money moves, not whether it should move or whether the counterparty is clean. That's the compliance layer's job — which is what OceanAlt does.
What is KYA (Know Your Agent)?
We know KYC (Know Your Customer): opening a bank account requires proving "you are you." KYA applies the same idea to AI agents — Know Your Agent, giving a spending agent an "ID card."
It answers four questions: who is this agent? Which accountable entity (company, person) stands behind it? What is it authorized to do? And can it be revoked in one click if something goes wrong? KYC identifies a person; KYA identifies the program spending on that person's behalf.
Why is it needed? An agent's ID isn't secret, and an ID alone can't prove "you are that agent" — like knowing a name isn't being the person. If a system checks the ID but not a credential, anyone with your agent's ID could spend against your budget (a hole we actually broke on our own gateway once, now fixed).
One emphasis: KYA only answers who's behind it — it isn't payment security by itself. The real protection is the sequence of enforced gates before the money leaves. KYA is the first, not the whole.
What is Mandate?
A mandate is the boundary within which an agent may spend. It usually has four parts: the most it can spend in one payment, the most per day, which addresses it may pay (an allowlist), and what purpose is allowed. Think of it as an allowance's rules — but for an agent.
The key: these rules must be enforced by a system outside the agent. A limit written only into the agent's prompt isn't a real mandate, because an agent's "mind" can be poisoned by text and talked into going around it (see "prompt injection"). Letting an agent enforce its own limit is letting a possibly-hijacked guard watch itself.
Before every settlement, OceanAlt's gateway checks the mandate line by line: over the cap? Blocked. Paying an off-allowlist address? Blocked. Purpose doesn't match? Blocked. It also compares this payment's intent against the original mandate — even if the agent insists "this is fine," a mismatch doesn't pass.
In one line: a mandate turns "how much, to whom" from a sentence in a prompt into a hard constraint the money can't get past.
What is OFAC sanctions list?
OFAC is an agency under the US Treasury (the Office of Foreign Assets Control). It maintains a sanctions list (often called the SDN list) of sanctioned individuals, entities, countries — and, increasingly, crypto wallet addresses.
Paying an address on the list can break the law outright, whether you meant to or were tricked. A famous case is the mixer Tornado Cash being sanctioned by OFAC: afterward, anyone interacting with its contracts risks crossing the line.
For agent payments this is a hard constraint: an agent won't check whether a payee is on the sanctions list, but once the money's out, the liability has landed. So "check against OFAC before paying" is the most basic, least-skippable step in AML screening. OceanAlt's free address check does this first — and the list must be kept current, which is one reason our data source must keep growing.
What is Facilitator?
In protocols like x402, a facilitator is a third-party service that verifies signatures and settles the money on-chain on a merchant's behalf. The merchant doesn't have to touch the blockchain, manage wallet keys, or handle clearing — it hands that grunt work to the facilitator.
An analogy: when you swipe a card, the shop doesn't go clear it at a bank itself — an "acquirer" in the middle does. The facilitator is that role in agent payments. It can front the gas (on-chain fees) and usually doesn't custody your funds — it just brokers the settlement.
Why does it matter? It's the role closest to a traditional payment institution on this path, and therefore the most likely target for regulation — whoever is the facilitator takes on some of the compliance responsibility for the money flow.
A key distinction for OceanAlt: our live settlement of real money goes through Coinbase's public facilitator (it fronts gas, doesn't custody). We are the compliance-screener and payee, not the party moving the funds — which keeps our compliance position clean.
What is MCP (Model Context Protocol)?
MCP (Model Context Protocol) is a universal interface that lets AI assistants use external tools. Think of it as a "USB port" for AI: instead of custom-wiring every new tool, a tool implements MCP once and any MCP-capable AI (Claude, Cursor, and others) can call it plug-and-play.
Example: you want Claude to be able to check whether an address is clean. Add OceanAlt's MCP tool to the config and Claude can call it natively inside a chat — no copying results back and forth.
Why does it matter for agent payments? MCP is one of the main ways an agent "grows hands" — it's through tools like these that an agent can actually do things (fetch data, send requests, even initiate payments). Whoever's tool gets called by more agents via MCP sits at the distribution gateway.
OceanAlt's compliance screening is published as an MCP tool, so any MCP-capable agent can install it free and check a counterparty before paying.
What is ERC-8004?
ERC-8004 is a draft standard proposed in the Ethereum community (ERC means "Ethereum Request for Comments") aimed at AI agents. It tackles one problem: when thousands of agents deal with — and pay — each other, how does one agent know who another is and whether it's trustworthy?
Its approach puts three things on-chain as public registries: identity (who the agent is, which entity it belongs to), reputation (its track record, any complaints), and validation (whether its claimed capabilities have been verified). Because it's on-chain, anyone can check and no one can quietly edit the record.
Why it matters to us: it's the same broad direction as KYA (giving an agent an ID) — both answer "can this agent be trusted?" ERC-8004 leans "decentralized on-chain registry," we lean "enforced compliance check before settlement"; the two can complement. It's still evolving, not final, but worth watching.
What is A2A (Agent2Agent)?
A2A (Agent2Agent) is an open protocol, led by Google, that lets "AI agents built by different companies talk to each other." In reality agents come from all sorts of vendors and frameworks that don't interoperate; A2A defines a common language so one agent can discover another, delegate a task, and get results back.
It's often mentioned alongside MCP, but they split the work: MCP lets one agent "use tools and data" (agent → tool); A2A lets "agents talk and collaborate with each other" (agent ↔ agent). One is hands, the other is social.
Why does it relate to payments? Once agents delegate to and hire each other, they naturally pay each other. Agents that can talk (A2A) + pay (x402/AP2) + trust each other (ERC-8004/KYA) — put together, that's the seed of an "agent economy." And every time an agent pays an agent, someone has to ask, before settlement, whether the money is clean.
What is RAP (Responsible Agentic Payments)?
RAP is a framework proposed by OceanAlt: Responsible Agentic Payments. It answers one question: what makes an agent payment "responsible" — the kind institutions and regulators can take seriously?
It organizes the answer into seven pillars: (1) attribution (every agent traces to an accountable entity), (2) mandate and limits (spending has boundaries), (3) a pre-settlement firewall (gates before money leaves), (4) AML screening (filter sanctions, mixers, dirty money), (5) auditability (every verdict leaves verifiable evidence), (6) privacy (compliance isn't handing over all your data), (7) interoperability (not tied to one protocol, works across chains).
Why build a "standard" rather than just a product? In a brand-new field, whoever defines the rules holds more sway than whoever builds a single tool. A neutral standard others cite is the strongest proof of "we define this space" — and the hardest moat to copy.
RAP is published and citable, and it's used to rate agent-payment protocols for compliance — with the method published before the rankings: explain how you score, then score.
What is Travel Rule?
The Travel Rule is a rule set by the international AML body FATF, and its core is simple: when a transfer exceeds a threshold, the sending institution must pass identity details of "who sent it and to whom" to the receiving institution — the information must "travel" with the money, hence the name.
It originally governed banks and wire transfers, then extended to crypto-asset service providers (exchanges, custodians, etc.). The point is to keep identity from "breaking" mid-chain, so laundering can be traced.
Why is it hard for agent payments? Agent payments are often between anonymous wallets, at machine speed, small and frequent — the "who's the sender, who's the receiver" simply doesn't exist in the traditional sense. Whoever settles on this path (the facilitator) may be required to meet this rule. It's one of the problems a compliance layer has to solve ahead of time, and an unavoidable checkpoint when regulation lands.
What is AML screening?
AML stands for Anti-Money Laundering. AML screening means checking, before money goes out, whether the payee is "a problem" — on a sanctions list, a mixer, stolen-hacker-funds, or connected on-chain to any of those.
Why do agents especially need it? A payee address is just a string of hex — you can't tell if it's clean by looking. A person might get suspicious from experience; an agent won't — it won't go research an address's history. And paying a sanctioned address can be outright illegal; by the time compliance notices, the money and the liability have landed.
Good AML screening has two points. One is "multi-hop tracing": if the money didn't come straight from a sanctioned address but through a few hops, it should still be traceable. The other is verifiable evidence rather than a black-box score — telling you why it's risky and letting you click through to check, not just handing you "87/100."
OceanAlt's free address-screening tool does exactly this: paste an address, get a clean/risky answer in 30 seconds, with evidence you can open.
What is Self-evolving risk list?
This is one of OceanAlt's own mechanisms, and our answer to "how the moat keeps deepening."
The idea: every time the gateway blocks a bad address, that information shouldn't be wasted. Repeatedly suspicious addresses get auto-"nominated" by an intelligence layer — but it's only a nomination, not automatic. It must pass human review and approval before it truly enters the risk list and gets used by all later queries.
The key principle in one line: evolve the eyes, never the hands. Detection can get smarter with use (automatically surfacing new bad addresses), but enforcement stays a deterministic, auditable, human-approved rule. The system is never allowed to be both detective and judge.
Why it matters: it lets the product strengthen itself without going out of control — every block makes the whole network a little safer; the more it's used, the thicker the data and the sharper the judgment — while a human always holds the last gate. This is what "the data source must keep growing" looks like in practice.
What is EIP-3009?
Imagine you have a check, but you don't want to go to the bank yourself (pay the fee). EIP-3009 lets you sign the check offline, then a friend takes it to the bank and pays the gas. That's 'off-chain signature, someone else pays gas.'
In USDC transfers, you don't need to send a transaction. You just sign a proof saying 'allow this amount to be moved.' Anyone can submit that proof to the blockchain, and they pay the gas fee. So you can transfer money for free, but the other party might charge a service fee.
This standard is the foundation for x402 gasless payments. x402 lets AI agents or websites request a user's signature, then the service provider pays the gas, making the payment invisible to the user. Like clicking 'agree' online, money is deducted, but you don't pay transaction fees.
Note that signatures have expiry and limits to prevent abuse. But details are still evolving, and implementations may vary.