Glossary

How a running agent finds and understands a service's capabilities. Different from human SEO: an agent wants a structured, immediately callable manifest.

The ability to attribute an agent to a real accountable party. Without it, nobody can be found or held responsible when something goes wrong.

Commerce where an agent, not a person, discovers, compares, orders and pays. The key difference is that the decider is software, so authority and limits must be expressed as machine-enforceable rules.

A forced reversal after a cardholder disputes a charge. On-chain stablecoin payments have no equivalent, which is both the appeal and the risk: a wrong payment does not roll back.

The risk that the other side cannot or will not perform. In agent payments it gains a layer: the other side may not be a real party at all.

The point at which a transaction can no longer be reverted. Time to finality varies widely by chain and is a required parameter when designing a payment flow.

Once confirmed, an on-chain transaction cannot be undone. This is the fundamental reason pre-settlement checks exist: there is no after-the-fact remedy.

Checks that run before money moves: identity, mandate, policy, screening. The difference from after-the-fact auditing is that auditing records the loss; this prevents it.

A payment initiated autonomously by an AI agent, without a human clicking confirm each time.

A third party that verifies payment credentials and settles funds on a merchant's behalf in x402-style protocols, so the merchant doesn't have to run chain infrastructure, custody wallets or handle clearing. It is the role closest to a traditional payment institution in this stack — and therefore the most likely place for regulation to land: whoever facilitates carries the compliance responsibility for the money flow.

The step at which funds actually move and reach finality. It's worth separating two things that get conflated: a payment authorization passing verification (protocol layer) is not the same as money having arrived (settlement layer). Our demos distinguish simulated settlement from real testnet settlement, and the latter always comes with a block-explorer link.

Economic activity in which AI agents act as transacting parties: discovering services, negotiating prices, ordering and paying on behalf of people or companies, and buying and selling data, compute, models and tool capabilities from each other. What separates it from AI-as-efficiency-gain is that the agent isn't only a tool — it's a party on the ledger.

An IETF-registered fixed path for machine-readable site metadata. Agent capability manifests and domain-ownership proofs live here.

An open protocol from OpenAI and Stripe that lets an assistant complete a purchase inside the conversation. It rides existing card rails, not on-chain settlement.

Test vectors runnable against any implementation to check whether it actually meets a standard. The way to validate the suite itself: run it against something obviously non-conformant and expect zero.

A written control list where each item is answerable yes or no. Room to explain is deliberately removed, because a list that allows explanation ends up one everyone claims to meet.

The process before removing a published API element: ship the replacement alongside, mark the old one deprecated with a removal date, only then delete. Skipping it wakes integrators at 3am.

A standard for signing structured data so a wallet can show what is being signed in human-readable form instead of a hex blob.

The standard interface for fungible tokens on Ethereum. USDT and USDC are ERC-20 tokens.

A standard letting smart-contract wallets customise signature and fee logic without protocol changes. It matters for agent payments because spending rules can live in the wallet itself.

Making content more likely to be cited inside AI-generated answers. SEO competes for ranking; GEO competes to be treated as a source of fact.

A status code reserved since 1997 and left unused for three decades. x402 activates it: the server returns 402 with payment requirements, the client pays and retries.

Verifying that two independent implementations actually work together. Conformance asks whether each matches the spec; interoperability asks whether they match each other.

Machine-readable semantic markup embedded in a page, telling machines whether the content is an article, product or Q&A.

A public promise about which fields and identifiers are additive-only and how long a deprecation cycle runs. The useful version is enforced by a build gate, not merely documented.

A runnable example of a standard that removes textual ambiguity. In standards discussions, one running implementation outweighs ten pages of argument.

A root-level file written for large language models, analogous to robots.txt for crawlers: what this site is, what it can do, how to call it.

An extension point in a payment protocol placed before settlement, where a third party can run checks and veto the payment. The technical precondition for a compliance layer to exist at all.

Fixed identifiers returned by a risk API for programs to branch on. Kept separate from human prose because prose gets translated and reworded, and code must not depend on it.

A machine-payment interaction built on the HTTP 402 status code: the server answers an unpaid request with a 402 and a quote (amount, payee, one-time nonce); the client signs a payment authorization and retries the same request carrying that credential; the server verifies and releases the resource. The point is that no account and no API key are required — the payment is the identity. We implement the full round-trip in 200Lab, and you can run it yourself.

A Google-led agent-payment protocol that uses signed mandates to carry user intent into an agent's payment.

Two protocols for safe agent payments: x402 handles 'how to complete a payment in one call'; AP2 handles 'how to prove the user actually authorized it'.

An open protocol that lets AI assistants (like Claude) call external tools and data sources in a standard way.

An Ethereum proposal standard giving AI agents on-chain identity, reputation and validation, so agents can discover and trust each other without a central authority.

An open protocol (started by Google and donated to the Linux Foundation in 2025) for AI agents from different vendors to talk and collaborate; MCP lets an agent use tools, A2A lets agents talk to each other.

An open, protocol-neutral framework proposed by OceanAlt, built on seven pillars: attribution, mandate and limits, firewall, AML screening, auditability, privacy, and interoperability. It is not tied to any particular protocol or settlement rail; the aim is to give the question of how an agent payment should be constrained a citable common vocabulary.

A standard that lets token holders sign off-chain authorization for transfers, with gas paid by another party.

A caller credential. For a public risk API, requiring one blocks the most valuable kind of user: the person who wants to try it right now.

Payments allowed only to listed counterparties. Far more reliable than a blocklist, which can never keep up with new bad actors.

A verifiable statement by one party about a fact. The essential discipline is separating "we verified this" from "they claim this"; conflating them destroys the value.

An identifier specification not dependent on a central registry. Technically workable; the hard parts have always been governance and revocation, not the identifier.

Requiring a person to confirm before a critical action. The design trap is making it a rubber stamp: confirm everything and people click through blind.

Verification for corporate customers: registration, ultimate beneficial owner, ownership structure, scope of business. Harder than individual KYC because it must reach a natural person.

Grant only the authority needed for the task. For an agent that means: who this task may pay, how much at most, until when — and refuse everything else.

Packaging what an agent may do into machine-enforceable rules: per-payment cap, daily cap, payee allowlist, purpose, validity window.

A signature replacing an on-chain approval transaction, saving a fee. Convenient, and also means a phisher only needs one signature to obtain an allowance.

Tying a payment authorisation to a specific purpose, so an off-purpose payment is refused even when the amount is within limits. It stops a hijacked agent spending inside its cap on the wrong thing.

Invalidating an agent's credential in one action. The key test of any agent identity scheme is whether it can stop the agent within a second when something goes wrong.

Information a party states about itself with no third-party verification. It has value — saying it creates accountability — but must never be presented indistinguishably from verified facts.

A cap on a single payment or on spend per period. The most basic and most effective control when handing an agent a key.

In ERC-20, the amount a wallet permits a contract to move on its behalf. Setting it to unlimited is common practice, and the most common origin of a drain.

A credential signed by an issuer, presented by a holder, independently checkable by a verifier. A three-party model whose hard question is always who may issue.

Attributing identity to an AI agent that initiates payments: who it is, which legal entity stands behind it, what it is authorized to do, and whether that authorization can be revoked. The difference from KYC is the subject — KYC identifies a person, KYA identifies the program spending on that person's behalf. Worth stressing: KYA only answers who is behind it. That is not payment security in itself; the real protection is enforcement before the money leaves.

The boundary within which an agent may spend — typically a per-payment cap, a daily cumulative cap, a payee allowlist and a stated purpose. It has to be enforced by a system outside the agent: a limit written into a prompt is not a mandate, because an agent's reasoning can be poisoned. Our gateway checks each of these before settlement and compares the intent of the payment against the original mandate.

The standard checks when onboarding: verify identity, understand the nature of the business, assign a risk rating.

Collect only what the purpose requires. Sound both for compliance and security: data never collected cannot leak.

A deeper level of verification for higher-risk customers, requiring more evidence of source of funds and business background than the standard process.

The intergovernmental body that sets global anti-money-laundering and counter-terrorist-financing standards. The Travel Rule comes from its Recommendation 16.

A rater's published conflict-of-interest rules: payment does not affect the outcome, the rated party gets no preview, self-ratings are labelled. It only counts if written before the first paying customer.

The EU's unified regulatory framework for crypto assets, covering issuance, trading and stablecoins, phased in from 2024.

The EU payments directive that established open banking and strong customer authentication. The question it answered — who authorised this payment — has resurfaced in the agent era.

Someone holding or having held a prominent public function, plus close associates. Not an accusation, but anti-money-laundering rules require enhanced due diligence.

Meeting compliance requirements without centrally collecting personal data. Most approaches remain papers and pilots; few are in production.

Exploiting differences between jurisdictions. For an infrastructure provider it is a warning sign: if that is why a customer chose you, the trouble eventually arrives at your door.

The US Treasury OFAC list of Specially Designated Nationals, whose assets must be blocked and with whom transactions are prohibited. In recent years it includes specific crypto addresses.

Matching a counterparty against official sanctions lists. It is deterministic set membership, so a third party can recompute it exactly — unlike a risk score.

Requiring two or more independent factors at payment time (something you know, have, or are). The agent-era difficulty is that an agent natively has none of the three.

A filing made by a financial institution to its regulator about suspicious transactions. Note the acronym collides with Settlement Attestation Receipt in x402 contexts and means something entirely different.

The natural person who ultimately owns or controls a company. AML rules require piercing layers of ownership to identify them.

FATF's category for crypto asset service providers: exchanges, custodial wallets, some OTC desks. Falling inside the definition brings AML obligations.

The sanctions list maintained by OFAC, a US Treasury agency; paying an address on it can be outright illegal.

An AML rule requiring the institutions on both ends of a transfer above a threshold to pass each other the identity details of sender and receiver.

Checking a counterparty address against sanctions lists, mixers and other risk signals before releasing funds. The boundary matters: we currently run list screening plus on-chain heuristics for Ethereum-family addresses, but for Tron we run list screening only, with no on-chain heuristics yet. We state that on the page rather than glossing over it.

A clean screen means nothing was found in the data held, not that the subject is safe. New addresses and domains always precede any list. Calling clear "safe" is misleading.

Writing a hash of a batch to a public chain, proving the batch existed at that time and has not changed since.

Recording key actions in order of occurrence. Useful only if tamper-evident: a log that can be edited afterwards is worthless in a dispute.

A list of counterparties to refuse. Structurally lagging behind new threats, so it can be a floor but never the only defence.

How long a contract has existed since deployment. A very new contract is not malicious by itself, but it is a signal an agent should surface: most scam contracts do not survive a week.

A provider's item-by-item statement of how deep it screens and where it stops. Its value to a caller is knowing when not to rely on the answer.

Metadata shipped with a verdict: which source, as of when, how many entries. Without it, "not on the list" is indistinguishable from "we did not look".

A list or feed stops updating while queries keep returning answers. A stable row count looks identical to "refreshed daily with no change", so you must record runs, not just results.

A subject removed from an upstream list. The correct handling is to mark it removed and keep the record, not delete it, which would erase point-in-time answerability.

Computing additions and removals only within the sources that actually fetched successfully this run. Otherwise one failed fetch reads as "the whole list was removed".

Checking whether the URL or domain about to be called is a known phishing host. It answers a different question from address screening: a spoofed endpoint hands back a fresh address no list has seen.

A verdict accompanied by checkable grounds: which list, when it was added, where it came from. Unlike a black-box score, it can be challenged.

Reporting clear when the answer should have been risky. In payment screening it is far more dangerous than a false positive: one costs a question, the other costs the money.

Flagging a legitimate subject as risky. The cost is friction and lost trust: too many and users start ignoring every alert.

A stablecoin issuer blacklists an address so it cannot move that token. One of the few mechanisms that can actually stop funds on-chain.

A structure hashing many records into one root, where changing any record changes the root. A common foundation for tamper-evident logs.

Checking only whether an address received funds directly from a known-risky address. One hop is a signal, never a conclusion: legitimate merchants also receive tainted funds.

Answering whether an address was on a list on a specific date. The question compliance actually asks — and deleting history makes it permanently unanswerable.

Whether a third party can fetch the same artifact, apply the published method, and arrive at the same conclusion. List membership qualifies; graph inference usually does not.

Compressing many signals into one number. Useful for ranking, insufficient on its own: the reasons behind the score are the verifiable part.

Treating a payment as complete before it is final. Easy to overlook on fast chains, but reorganisations still happen.

The state to return when screening could not complete: unknown. It must never degrade to clear, which trades a system failure for a possibly bad payment.

Checking whether transaction count or amount per period is abnormal. Critical for agents: a malfunctioning agent rarely makes one wrong payment, it makes many fast.

Addresses that repeatedly misbehave are auto-nominated by an intelligence layer and enter the risk list only after human approval — detection gets smarter, enforcement stays human-controlled.

An attacker generates an address whose first and last characters match the target, sends a zero-value transfer into the victim's history, and waits for them to copy the wrong one.

A victim grants an unlimited token allowance to a malicious contract, which then drains the wallet over time. The funds are not stolen so much as authorised away.

A bridge's mint or verification logic is bypassed and assets are created from nothing. Historically the category with the largest single losses.

A privileged program is tricked into exercising its authority for an attacker. This is the core security problem of agent payments: the agent can spend, the attacker cannot.

Sending tiny amounts to many addresses, then linking them through subsequent consolidation to de-anonymise the owner or set up further phishing.

The attack instruction hides in external content the agent will read — a page, a document, an email — rather than in user input, exploiting the agent's inability to separate data from instructions.

A private key stolen or leaked. It is one of the largest loss categories in real incident data, and it happens entirely outside the payment-screening layer.

A service that pools funds from many parties and redistributes them, severing the on-chain trail. It has legitimate privacy uses and is also the main laundering tool, hence frequent sanctioning.

An attacker manipulates the price feed a contract relies on and arbitrages the wrong price. A contract and market-design problem that pre-payment screening cannot touch.

Impersonating a trusted site or identity to induce a signature, approval or transfer. Especially dangerous on-chain because a signature, once sent, cannot be recalled.

A contract makes an external call before updating state, letting an attacker recurse back in and withdraw repeatedly. The classic smart-contract bug.

An attacker resends a legitimate, already-used request or signature hoping it takes effect again. Defended with a nonce or a time window.

The team disappears with the funds or liquidity. Pre-payment signals usually include a very new contract, no audit, un-renounced admin rights and unlocked liquidity.

Tricking a server into fetching an attacker-chosen internal address. Any feature that fetches a user-supplied URL must defend against it.

Planting malicious instructions in the description of a tool the agent can call. Since tool descriptions enter the model context, it is an often-overlooked injection path.

Hiding malicious instructions inside content an agent will read — a web page, an email, a tool's return value — to make it act against its operator's intent. In payments the classic outcome is a changed payee or amount. We tested this against our own implementation in the Attack Lab: the injected agent did emit the redirected payment, but the request was stopped before settlement by the mandate-intent check. Which is the point: the trust layer has to live outside the agent.

A mechanism to move assets between chains. It is a break in fund tracing: funds enter one side and emerge on the other with no on-chain link.

Operations spanning multiple blockchains. The compliance difficulty is that data availability differs sharply by chain, so "the same check" is not the same depth everywhere.

An ordinary address controlled directly by a private key, with no code. Lose the key and everything is gone, and no spending rules can be embedded.

A third party pays the on-chain fee for the user. It matters for agent payments because an agent should not have to acquire native tokens to send $0.10.

Dedicated hardware where keys are generated, used and never exported. The baseline infrastructure for enterprise key management.

A network built on top of a base chain that batches transactions off-chain and settles back. Low fees make it the main venue for agent micropayments.

Multi-party computation splits the key into shares; signing is a joint protocol and the whole key never exists in one place.

The production network carrying real assets. Switching from testnet is an irreversible decision point requiring explicit authorisation and a small-value trial.

A transaction requires signatures from several keys. The most direct way to stop a single point from deciding to spend.

The secret number that controls an on-chain account. Whoever holds it is the owner — which is why pre-payment screening cannot help at all with key-compromise incidents.

The dominant L2 form: compress many transactions and post them back to the base chain. Optimistic and zero-knowledge variants differ in how they prove the batch is valid.

Third-party review of contract code for vulnerabilities. Audited is not safe: reports have a scope, a date, and do not cover post-deployment changes.

A wallet controlled by contract code rather than a single private key. It can embed multisig, limits, allowlists and social recovery.

A blockchain network using valueless tokens. Everything must work here before mainnet, because mainnet mistakes cost real money.

Circle's dollar stablecoin. The issuer retains the ability to freeze addresses, which is both a compliance tool and a reminder that it is not permissionless.

Tether's dollar stablecoin, the largest by circulation. It also supports freezing, and sees enormous transfer volume on TRON.

Proving a statement true without revealing its content. The compliance appeal: proving "I am not sanctioned" without disclosing who I am.

A price-stable on-chain token pegged to a fiat currency like the US dollar (e.g. USDC), letting machines hold and move 'dollars' directly.

A unique value carried by each payment, consumed once before settlement; a repeat means replay. Without it, a legitimate payment that passed every compliance check can be resent verbatim any number of times — because each instance, viewed on its own, is perfectly compliant. This is the gate we added after breaking our own implementation in Attack Lab episode 5.

The browser mechanism deciding whether a page may read a response from another origin. A public API without CORS cannot be integrated from the front end.

Automatically pausing or degrading when metrics go abnormal, to stop a small fault spreading. Common payment triggers: a spike in failure rate or amount per period.

Layered controls rather than one line of defence, because every layer leaks sometimes and simultaneous bypass of several is far less likely.

Defaulting to deny when a system errors, rather than allow. The alternative means that when the screening service goes down, every risky payment goes through.

Usage available without payment. For infrastructure services its real function is not acquisition but making people willing to take a dependency on you.

When part of a capability is unavailable, honestly reduce service and say so rather than pretending all is well. In risk products this is the floor.

A unique identifier on a request that guarantees the same operation executes only once even if resent. Without it, a network retry becomes a double charge.

The time within which 95% of requests complete. Far more meaningful than an average, which many fast requests flatten, hiding the slow tail.

Capping requests per unit time. Good rate limiting slows rather than cuts off: an allowance that dies mid-month never makes it into production code.

A written commitment on availability and latency, usually with remedies. Without remedies it is a wish, not an agreement.

A test environment isolated from production, running the full flow on fake data. The first step of most financial integrations happens here.

Part of a service breaks while everything still looks fine from outside. More dangerous than an outage, because nobody fixes what appears to be working.

Slowing rather than refusing once an allowance is exceeded. It matters especially for agents, which usually do not degrade gracefully on a hard cut-off but fail the whole flow.

The share of time a service is available. Read the methodology: probing the homepage and probing every critical endpoint give very different numbers.

A server-initiated notification pushed to a URL you supply when an event occurs. The essential requirement is signature verification, or anyone can forge events.