# OceanAlt

> Should this payment go to this address? That is the one question OceanAlt answers — before the money moves.
> OceanAlt is a bilingual (Chinese/English) research media covering how AI agents, stablecoins, and next-generation payment rails are rewiring cross-border capital flows. Brand line: "OceanAlt — Bringing AI agents safely into the real financial world." (Chinese: OceanAlt，让 Agent 安全进入真实金融世界) Operator-grade analysis rooted in Asia, written for the world.

## What we cover
- Agent Economy (Agent经济): https://oceanalt.com/en/channel/agent-economy
- Stablecoins (稳定币): https://oceanalt.com/en/channel/stablecoins
- Cross-Border (跨境资金): https://oceanalt.com/en/channel/cross-border
- Policy (政策与监管): https://oceanalt.com/en/channel/policy
- Trust & Safety (合规与安全): https://oceanalt.com/en/channel/trust

## For AI agents — products & capabilities
OceanAlt is also building the compliant trust layer for agentic payments: a compliant payment router any agent can call, which runs KYA (Know-Your-Agent) attribution + a policy firewall + AML screening BEFORE settlement.
- AI Security Lab — live demos: a real x402 round-trip (402→sign→200) + a compliance-gate demo (KYA + firewall blocking bad agents), plus five reproducible attack cases: https://oceanalt.com/en/lab
- Live on Base mainnet — the paid x402 endpoints settle real USDC via Coinbase's CDP facilitator (first real payment received, on-chain verifiable). Endpoints & prices: https://oceanalt.com/api/x402
- Responsible Agentic Payments (RAP) Framework v1.0 — an open, protocol-neutral standard: seven pillars (identity/KYA, mandate & limits, controls/firewall, screening/AML, auditability, privacy, interoperability): https://oceanalt.com/en/rap
- Agent Control Baseline (ACB) v1.0 — the verifiable answer to prompt injection. We do NOT judge whether an agent's reasoning was poisoned (not achievable, not verifiable); we put the boundary outside its reasoning and make it third-party verifiable. Three layers, modelled on SWIFT's Customer Security Programme: ① a published control list (https://oceanalt.com/api/baseline) ② per-control self-attestation (POST https://oceanalt.com/api/baseline/attest) ③ counterparty lookup before settlement (GET https://oceanalt.com/api/baseline/lookup?entity=…). Every control is labelled gateway-enforced / on-chain verifiable / self-attested — a claim is never presented as a verification. Human page: https://oceanalt.com/en/baseline
- RAP governance — who may change the standard, how, and how to object. Four-step change process (public issue → objection window → vectors first → semver with the old version's vectors kept runnable) plus three commitments: no retroactive changes, no rule only we can pass, and our own results published before anyone else is measured. It also states plainly what is NOT done: ownership is not yet neutral, and neutralising it waits on real adoption because a governing body for an unused standard is an empty shell. https://oceanalt.com/en/rap/governance
- RAP Conformance Vectors v1.0 — RAP as executable assertions rather than prose. Fetch the vectors (https://oceanalt.com/api/rap/conformance), point the runner at YOUR base URL, and run them against your own implementation; non-zero exit on any critical failure makes it a CI gate. "Conformant with RAP v1.0" has exactly one definition: every critical vector passes. Our own daily results are published including the ones we fail: https://oceanalt.com/en/rap/conformance
- RAP Compliance Rating — an open rating (L0–L3) of how well an agent/service satisfies RAP; the trust signal buyer agents filter on: https://oceanalt.com/en/rap/rating
- Agent Payment Observatory — narrative density index computed only from OceanAlt's own corpus (hits per 1,000 items per ISO week, base 2026-W28 = 100), every point with numerator/denominator, frozen history, CSV export. GET https://oceanalt.com/api/observatory/index?term=x402 · https://oceanalt.com/api/observatory/bubbles · https://oceanalt.com/api/observatory/emerging · method https://oceanalt.com/en/observatory/method
- Agent Identity Registry — resolves a chain of accountability rather than an address risk score: agent → principal → mandate → credential → wallet. GET https://oceanalt.com/api/registry/agent?agentId=… returns which links hold and where accountability stops. Publication is opt-in (the credential holder calls set-discoverable), and only posture is exposed — whether a ceiling exists, never its value. Directory: https://oceanalt.com/api/registry/agents
- Trusted Agent Service Registry — a directory of agent-purchasable services, each with a RAP rating. Machine-readable manifest for buyer agents: https://oceanalt.com/registry.json (human view: https://oceanalt.com/en/registry)
- OpenAPI 3.1 spec (machine-readable, the standard way to discover and call these endpoints): https://oceanalt.com/openapi.json — every public endpoint with its parameters, response schema and error codes. Human view: https://oceanalt.com/en/api-docs
- Output language: human-readable fields (signals, note, advice) default to **English**; pass `lang=zh` for Chinese. Every response also carries `signal_keys` — language-independent keys (e.g. `list.mixer`, `taint.onehop`) that agents should branch on instead of parsing prose.
- Compliant payment gateway (HTTP): POST https://oceanalt.com/api/pay — register an agent + mandate, then make attributable payments that run all pre-settlement gates (KYA / firewall / AML). Docs: https://oceanalt.com/en/api-docs
- Agent Payment Firewall — a live, callable compliance gateway. 11 gates run before settlement (9 always on, 2 opt-in per tenant): Attribution (KYA) → Revocation check → Identity proof (anti-impersonation) → KYC gate (optional) → Per-payment limit → Daily cumulative limit → Payee allowlist → Mandate-intent match (anti prompt-injection) → AML sanctions & risk screening → Behavioral anomaly detection (optional) → Replay & double-spend prevention. Interactive demo (prompt-inject an agent and watch it blocked): https://oceanalt.com/en/firewall · Integrate in 5 min: https://oceanalt.com/en/firewall/integrate · Gateway API: https://oceanalt.com/api/pay
- Payee decision (the other half) — before settling, ask whether the payee accepts: POST https://oceanalt.com/api/payee/decide { payee, payer?, amountUsdc?, purpose? } → { status: "accept"|"decline"|"hold_request_info"|"not_ready", reasons[], requested_fields[], evidence[], signature }. Rules, not model judgement; payee readiness comes from the registry ladder (https://oceanalt.com/en/registry/rules). GET the same URL for the reason-code table.
- Signed payment requirements (x402) — a 402 response is plaintext, so any hop between seller and agent (proxy, CDN, a compromised SDK, a malicious tool) can swap the payTo address. OceanAlt's own 402s carry extensions.signedRequirements inside the PAYMENT-REQUIRED header payload (x402 v2; mirrored in the JSON body) — Ed25519 over resource + accepts[].scheme/network/payTo/amount/asset/extra; key at https://oceanalt.com/.well-known/oceanalt-keys.json. Verify offline, or POST https://oceanalt.com/api/x402/verify-requirements { body: <decoded PAYMENT-REQUIRED JSON or its raw base64>, expect?: { payTo, amount } } → { verified, reason_code: ok|no_signature|digest_mismatch|signature_invalid|key_unavailable|payto_mismatch|amount_mismatch, detail }. Defends against tampering in transit; cannot defend against a compromised seller origin (pin the key_id for that). Spec: https://oceanalt.com/en/api-docs#signed-requirements
- Fulfillment receipts (no custody) — after an x402 / stablecoin payment, the payer files "I paid this tx (verified on-chain) and did / did not receive", the payee files "delivered / disputed"; both statements are stored and shown side by side, OceanAlt adjudicates nothing and never touches funds; per-payee rates are withheld until 10 verified receipts: POST https://oceanalt.com/api/fulfillment { role: "payer"|"payee", txHash, chain, payee, claim } · GET https://oceanalt.com/api/fulfillment?payee=0x… · human page https://oceanalt.com/en/fulfillment
- Intent check (anti blind-signing) — decode what calldata will ACTUALLY do and compare with the payment the agent believes it is making: POST https://oceanalt.com/api/intent/check { intent: { action: "pay", to, amount? }, contract, data, value? } → { decision: "match"|"mismatch"|"unknown", reason_code, decoded: { kind, to?, spender?, amount?, unlimited?, en, zh } }. Covers ERC-20 transfer/transferFrom/approve/increaseAllowance/permit, setApprovalForAll, safeTransferFrom, transferOwnership, native transfers; multicall and unknown selectors return "unknown" — undecodable is not the same as safe. Free, no key. Solana: POST the same endpoint with { network: "solana", transaction: "<base64 transaction or message>", intent: { action: "pay", to: <wallet or token account>, amount?, asset?: <mint> } } — decodes SPL Token / Token-2022 Transfer, TransferChecked, Approve, SetAuthority, CloseAccount, Burn, System Transfer / Assign and ATA creation (used to link a token account to its wallet); address-lookup-table accounts and unknown programs return "unknown", never guessed.
- Evidence bundle (witness, not plaintiff) — GET https://oceanalt.com/api/evidence/bundle?address=…&network=… → { bundle: { screening (verdict + evidence + freshness), profile, profile_signals, one_hop_relations, fulfillment, coverage }, signature, verify: { keys_url, key } }. Everything inside is already public on oceanalt.com; no user data; no conclusions or attribution of persons; anyone may request one, there is no privileged channel. Ed25519-signed so it can be verified offline. 10 requests/min.
- Decide (for any paying agent) — "Before your agent pays, call OceanAlt once." Free machine-executable payment decision: POST https://oceanalt.com/api/decide { to, amountUsdc?, purpose?, network? } (or GET https://oceanalt.com/api/decide?to=0x…) → { decision: "allow"|"review"|"decline", allow (bool), evidence[], retry, reason_code }. No signup, no key. Paid upgrade that also settles the payment: POST https://oceanalt.com/api/x402/decision.
- Watch an address (free, zero integration, for humans) — paste a wallet or payee address and OceanAlt emails you if its risk changes or it sends money out: https://oceanalt.com/en/watch
- Give a spending AI a limited key (free, for humans) — set per-payment / daily caps, an allowlist of payees and a purpose; OceanAlt issues a key, and any payment beyond those rules is blocked at the gateway. Revocable in one click: https://oceanalt.com/en/keys
- Risk Query (for buyer agents) — ask before you pay whether a counterparty address is known-risky, built from real blocked attacks and human-reviewed: https://oceanalt.com/api/risk?addr=0x… · Aggregate threat stats: https://oceanalt.com/api/threats
- Endpoint Risk Query (the half address screening cannot answer) — in x402 the agent finds a URL first and only then learns where to pay; a spoofed endpoint returns a freshly generated address that appears on no sanctions list. Screens a URL or domain against public phishing databases plus hostname shape signals: https://oceanalt.com/api/endpoint?url=https://pay.example.com/x402
- AML SDK "oceanalt-aml" (npm) — one-line integration for any agent/script. Free `decide()` (allow/review/decline before paying) + `screen()`/`recent()` (zero-dependency); paid `decision()`/`trace()`/`batch()` over x402 (adds settlement). Docs: https://oceanalt.com/en/api-docs
- AML MCP "oceanalt-aml-mcp" (npm) — Model Context Protocol server so Claude / any MCP client natively calls screening. Free tools: `screen_address` (is this payee risky?), `screen_endpoint` (is this payment URL a known phishing host?), `payee_decide` (accept / decline / hold-and-request-info, from the payee's side), `payment_decision` (should this agent make this payment?), `counterparty_control_baseline` (what controls does this counterparty actually run?), `resolve_agent_identity` (who is behind this agent?), `recent_flagged`, `check_calldata_intent` (decode what a transaction will ACTUALLY do and compare it with what the agent believes it is doing — an unlimited approval dressed up as a payment comes back as a mismatch), `verify_payment_requirements` (was this x402 402 response's payTo/amount/asset/network signed by the seller and left untouched in transit?), `baseline_controls`, `attest_control_baseline`, `evidence_bundle` (everything OceanAlt can say about one address in a single Ed25519-signed bundle you can verify offline: verdict, evidence, freshness, profile signals, one-hop relations to listed addresses, fulfillment receipt stats — a witness, not a plaintiff: no conclusions and no attribution of persons, every item carries its source and coverage date). Paid x402 tools: `compliance_decision`, `deep_trace`, `batch_screen`. Install: `npx oceanalt-aml-mcp`, or add it to an MCP client config — no API key for the free tools.
- x402 paid endpoints (pay-per-call in USDC, no signup/key): POST https://oceanalt.com/api/x402/decision ($0.30 gateway verdict) · GET https://oceanalt.com/api/x402/trace?addr=T… ($0.20 deep taint trace) · POST https://oceanalt.com/api/x402/batch ($0.10 batch). Machine-readable manifest: https://oceanalt.com/api/x402

## Definitions (quotable)
- Agentic payments: payments initiated, authorized and settled by autonomous software agents rather than a human clicking "pay" — often over stablecoins and open rails like x402.
- KYA — Know-Your-Agent: the agent-era counterpart to KYC. Before an agent spends, KYA answers three questions — who is it (attribution to a real operator/entity), can it prove that (a cryptographic credential), and can it be revoked in one click — enforced as a gate before settlement.
- RAP — Responsible Agentic Payments Framework (v1.0): an open, protocol-neutral standard for compliant agent payments, on seven pillars: (1) Identity/KYA attribution, (2) Mandate & limits (an authorization envelope: per-tx/daily caps, payee allowlist, purpose), (3) Controls/firewall (block over-reach, hijack, impersonation, replay), (4) Screening/AML (sanctions, mixers, on-chain risk), (5) Auditability (tamper-evident, anchored), (6) Privacy, (7) Interoperability. Canonical: https://oceanalt.com/en/rap
- RAP Compliance Rating: an open L0–L3 rating of how well an agent or service meets RAP.
- Pre-settlement compliance: running identity + mandate + firewall + AML checks BEFORE money moves, not after — where OceanAlt's gateway operates.
- Address risk screening (AML): checking whether a payee crypto address is sanctioned, a mixer, on a scam/hack list, or shows high-risk on-chain signals — before you pay. OceanAlt covers 7 EVM chains (Ethereum, Base, BSC, Polygon, Arbitrum, Optimism, Avalanche), Tron (USDT-TRC20), Solana and Bitcoin. Depth varies by chain and we say so: list matching (sanctions / mixer / scam / hack) runs on every chain; full depth — issuer freeze lists, address age and activity and one-hop taint in the verdict, with fund flow and multi-hop deep trace on request — on Ethereum, Polygon, Arbitrum, Base, Optimism and Tron; BSC and Avalanche add address activity (Avalanche also the USDC freeze list) but have no free transaction-history source, so no taint, fund flow or deep trace; Bitcoin and Solana verdicts use list matching, with multi-hop deep trace on request. Verdicts use one-hop relations only; a deep trace result is returned separately and does not change the verdict. Batch screening skips the EVM issuer-freeze lookup and Tron one-hop taint. Per-chain table: https://oceanalt.com/en/coverage (machine-readable: coverage.chains in https://oceanalt.com/.well-known/agent-capabilities). A "clear" verdict means no match in the data held, not that the address is safe. Shows verifiable evidence, not a black-box score: https://oceanalt.com/en/check

- Endpoint risk screening: checking whether the payment ENDPOINT itself (a URL or domain) is a known phishing host, before the agent ever calls it. Distinct from address screening and not substitutable for it: when a frontend or domain is hijacked, the payee address handed back is newly generated and matches no list, so only the endpoint layer can catch it. OceanAlt screens the hostname and its parent domains against public phishing databases (MetaMask eth-phishing-detect, ScamSniffer) plus hostname shape signals (bare IP, punycode homograph, deep subdomain nesting, free hosting): https://oceanalt.com/api/endpoint
- Coverage declaration: a public, chain-by-chain statement of how deep a screening service actually goes and where it stops. OceanAlt publishes one because a caller who does not know the boundary eventually takes the fall exactly where the provider was least sure: https://oceanalt.com/en/coverage — machine-readable as coverage.chains (verdict_steps, issuer_freeze_tokens, on_request) in https://oceanalt.com/.well-known/agent-capabilities
- Incident archive: a public, classified record of real crypto incidents (DefiLlama hacks dataset), each class marked with whether pre-payment screening applies. Screening applies to part of three classes — frontend/domain hijacks, social engineering and rugpulls — which are a minority of incidents by count and by amount; key compromise, contract bugs, oracle manipulation and bridge flaws need other controls and screening does not stop them. Published because a compliance product that only states what it catches should not be trusted at settlement time. Live figures by count and by amount, plus the per-class split: GET https://oceanalt.com/api/incidents/stats · human page: https://oceanalt.com/en/incidents

- Output contract: a published, versioned list of every identifier an integrator may branch on, with a guarantee that identifiers are only added, never renamed or removed without a 90-day deprecation cycle — and a build gate that enforces it. Published because the thing that breaks an agent integration is not a missing feature but a field that quietly changed shape: https://oceanalt.com/en/contract

## API (for agents & developers)
- Access levels (all opt-in; nothing you use today stops working). **anonymous** — send nothing: 60 requests/min and 2,000 calls a month free (metered per source, by a salted hash of the IP — we never store the raw address), no signup, no key. **registered** — POST https://oceanalt.com/api/access-keys { email }, click the link in the email, then send `Authorization: Bearer <key>` (or `x-api-key`): 180/min and 5,000 calls a month free, counted per key. **kya** — already have an agent in the registry? Send `x-agent-id` + `x-agent-secret`, no second key to apply for: 300/min and 50,000 a month free, aggregated per owner rather than multiplied per agent. All three levels have the same capabilities (including batch, point-in-time lookups and signed evidence bundles); they differ only in limits and attribution. Every level is metered, including anonymous — otherwise the level with no identity attached would always be the cheapest one to use, and we would be paying people to bypass the identity layer. Past the free allowance every level is throttled, never cut off (abuse, security incidents and policy violations excepted), and every level's throttled rate is at or above the anonymous normal rate — an allowance that dies mid-month cannot be put in a production path. Where an answer would otherwise be about something else, the response carries `requires_information` (fields, why, how) alongside the decision — most often a missing `network` on an EVM address, which exists independently on 7 chains while the on-chain heuristics default to Ethereum; every response states the `screened_network` actually used. `decision` stays three-valued (allow/review/decline) on purpose: a fourth value would fall through existing callers' else branch, which is usually "pay". Optionally tell us what the payment is for — `task`, `reasoning`, `maxAmountUsdc` (or `intent: { task, reasoning, max_amount_usdc }` in a POST body) — and /api/decide and the MCP `payment_decision` tool also run a deterministic intent check: an empty intent returns `requires_information`, instruction-override phrases route to review, an amount above your declared cap is declined, and an amount more than 10x what the task mentions routes to review. It only ever makes a decision stricter, and callers that send none of these keys get exactly the same response as before. Decisions are reproducible: at the same moment and against the same lists, the same address returns the same decision, reason_code and evidence; an answer changes only when lists update, on-chain facts change, or rules are revised — `evaluated_at` and `evidence_as_of` on every response let you reconstruct why a payment was decided. When fulfillment receipts exist for the payee, /api/decide and MCP `payment_decision` also return `payee_fulfillment` (payer- and payee-reported figures kept separate, rates withheld below 10 verified receipts) as reference only — it never changes the decision. A credential we do not recognise is never silently downgraded: the response carries `key_rejected` and the reason, and every response carries an `access` block stating your level and what the next one adds. A registered key can also be locked down by whoever holds it (2026-09-16), and a key with none of this set behaves exactly as before: **scopes** — limit it to any subset of screen_address, screen_endpoint, decide, payee_decide, batch_screen, trace_funds, evidence_bundle, intent_check, baseline_lookup, with a call outside them refused 403 `key_scope_denied`; **a source-IP allowlist** — up to 20 IPv4/IPv6 addresses or CIDR ranges, with anything else refused 403 `key_ip_denied` (we use the address the connection actually came from, not an X-Forwarded-For header the caller sets); and **an expiry** — past it the key is treated exactly like a revoked one, served at the anonymous level with `key_rejected: expired` rather than silently downgraded. Only the endpoints named in those scopes read a key at all — as of 2026-09-16 that includes batch screening, deep trace, fund flow, evidence bundles, intent checks and control-baseline lookups, which used to ignore a key. What still ignores one: the x402 paid endpoints (paid per call, no key was ever needed), the point-in-time lookup GET https://oceanalt.com/api/risk?on=, and the remaining utility endpoints (/api/pay, /api/fulfillment, /api/baseline, /api/registry, the RAP endpoints) — all rate limited per source IP. Scopes govern what a key may do, not how much: on those six newly covered endpoints a call is still rate limited per source IP and still counts towards no monthly allowance, so calling them without a key behaves exactly as it did before. Read and change the limits at `GET|POST https://oceanalt.com/api/access-keys/settings` with the key itself: tightening applies immediately, while loosening (more scopes, a wider or removed allowlist, a later or removed expiry) only takes effect after confirming a link emailed to the address the key was issued to — otherwise anyone who stole the key could simply remove its limits. The MCP endpoint POST https://oceanalt.com/api/mcp takes a key optionally (Authorization: Bearer or x-api-key): without one every tool works as before; with one, tool calls are rate limited per key, the holder's scopes and IP allowlist apply per tool (screen_address, screen_endpoint, payment_decision -> decide, check_calldata_intent -> intent_check, counterparty_control_baseline -> baseline_lookup), and verdicts can be written to the decision log; a revoked or expired key is still served at the anonymous level and the result says key_rejected. This is OceanAlt's own API key, not the OAuth 2.1 authorization in the MCP specification. Decision log: off by default and records nothing until the key holder switches it on (decision_log: true on the settings endpoint); each verdict issued to that key is stored with its list source and data freshness, Ed25519-signed per row, with no IP, user agent or request body; export with GET https://oceanalt.com/api/access-keys/decisions (JSON, or ?format=csv); retention 30-730 days, default 180; turning it off never deletes rows already written. Human page: https://oceanalt.com/en/api-keys
- GET https://oceanalt.com/api/risk?addr=<0x… or T…>&network=<chain> — free, CORS-enabled, no signup. Returns JSON: { address, verdict ("clear"|"caution"|"risky"|"uncertain"), risk (0–100), blocked, lang, signals[] (prose, in the requested language), signal_keys[] (language-independent — branch on these), evidence[] (each {label, detail, source, url} — click through to verify), note, advice }. Add `lang=zh` for Chinese output; default is English. `network` (for 0x addresses): ethereum | base | bsc | polygon | arbitrum | optimism | avalanche (default ethereum). Tron/Solana auto-detected. Sanctions/mixer/scam checks are chain-agnostic.
- Control-baseline attestation (publish what YOUR side runs, so payers can see it before settling) — POST https://oceanalt.com/api/baseline/attest with { entity, answers: {controlId: bool}, gapPlan }. Control ids from GET https://oceanalt.com/api/baseline. Gaps are allowed and expected: answer false and say how you will close it — a filing with declared gaps beats no filing, because a payer can act on a known shape but not on a blank. No account, no key. Human form: https://oceanalt.com/en/baseline/attest · MCP tools: `baseline_controls`, `attest_control_baseline`
- Public conformance scoreboard — anyone can enter their gateway at POST https://oceanalt.com/api/rap/conformance/submit with { name, baseUrl }. Scores are NOT self-reported: OceanAlt runs the published vectors against the submitted URL and publishes the result including the vectors that did not pass. OceanAlt's own implementation sits in the same table, scored the same way. Board: https://oceanalt.com/en/rap/conformance
- Status page — real availability and per-endpoint P50/P95 latency, with the probe methodology stated and the date measurement began. What is not measured is listed explicitly, and there is no SLA claim (an SLA without remedies is a wish): https://oceanalt.com/en/status
- Discord bot — same verdicts as the web and the API, in Discord. `/check <address or URL>` screens a payee address or the endpoint you are about to call. Interactions endpoint (no persistent gateway connection), Ed25519 request signatures verified, no chat content or user identity stored: https://oceanalt.com/api/discord/interactions
- GET https://oceanalt.com/api/contract — the output contract: every stable identifier (signal_keys, verdicts, reason_codes, response fields) plus what is explicitly NOT stable. Additive-only, and enforced by a build gate rather than merely documented: if any published identifier disappears or is renamed, our release fails. Branch on signal_keys / verdict / reason_code / retry; never on the prose fields. Human page: https://oceanalt.com/en/contract
- GET https://oceanalt.com/api/endpoint?url=<url or domain> — free, CORS-enabled, no signup. Returns JSON: { input, host, verdict ("clear"|"caution"|"risky"|"unknown"|"uncertain"), risk (0–100), lang, signals[], signal_keys[] (language-independent — branch on these), evidence[], note, listed_as? }. A "clear" verdict means no match was found, NOT that the endpoint is safe. Use alongside /api/risk — the two answer different questions and neither substitutes for the other.
- POST https://oceanalt.com/api/pay — the compliance gateway. Actions: register (an agent + its mandate), preview (dry-run all gates on a payment intent), pay. Runs 11 gates before settlement. GET https://oceanalt.com/api/pay returns a self-describing manifest.
- Idempotency-Key on POST https://oceanalt.com/api/pay (the payment call and rotate; semantics per the IETF draft draft-ietf-httpapi-idempotency-key-header). If the network drops and your agent does not know whether a payment ran, resend with the same Idempotency-Key, the same nonce and the same body: within 24 hours you get the original status and body back with Idempotent-Replayed: true. Nothing runs twice and the retry is not recorded as a replay attack or alerted to the key owner. Same key with a different body → 422 (reason_code idempotency_key_reused); original still running → 409 (idempotency_request_in_progress, resend after retry-after); malformed key → 400 (idempotency_key_invalid). A replay must present the same x-agent-secret as the original. Calls without the header behave exactly as before.
- Signed webhooks — people who set a webhook URL in the console (https://oceanalt.com/en/keys) receive block notifications signed per Standard Webhooks (https://www.standardwebhooks.com/): headers webhook-id, webhook-timestamp, webhook-signature = "v1," + base64 HMAC-SHA256 over id.timestamp.raw-body with the whsec_ secret; reject timestamps more than 5 minutes old. The secret is shown once and can be rotated (old and new both sign for 24 hours). Failed deliveries are retried after 1 min, 5 min, 30 min and 2 h (5 attempts in total, same webhook-id) and every attempt is visible in the console. Node verification example: https://oceanalt.com/en/api-docs#webhooks
- x402 paid endpoints (HTTP 402 pay-per-call in USDC, no signup): POST https://oceanalt.com/api/x402/decision ($0.30) · GET https://oceanalt.com/api/x402/trace?addr=T… ($0.20) · POST https://oceanalt.com/api/x402/batch ($0.10). Manifest: GET https://oceanalt.com/api/x402.
- SDK: `npm i oceanalt-aml` → `new OceanAltAML().screen(addr, { network })` (free) and `.decision/.trace/.batch(…, { privateKey })` (x402). MCP server: `oceanalt-aml-mcp`. Full docs + curl/JS examples: https://oceanalt.com/en/api-docs

## FAQ
- Q: How should AI agents pay compliantly? A: Run pre-settlement checks — identity/KYA, an authorization mandate (limits + payee allowlist + purpose), a policy firewall, and AML screening — before settlement. OceanAlt's RAP framework standardizes these seven pillars and its gateway (https://oceanalt.com/api/pay) enforces them.
- Q: Is there a standard for agentic-payment compliance? A: Yes — the Responsible Agentic Payments (RAP) Framework v1.0, open and protocol-neutral: https://oceanalt.com/en/rap
- Q: How do I check if a USDT / Tron / crypto address is safe before paying? A: Use OceanAlt's free address check (https://oceanalt.com/en/check) or GET https://oceanalt.com/api/risk?addr=… — it screens sanctions/mixer/scam lists plus on-chain signals across 7 EVM chains (Ethereum, Base, BSC, Polygon, Arbitrum, Optimism, Avalanche), Tron and Solana, and returns verifiable evidence.
- Q: What is KYA (Know-Your-Agent)? A: The agent-era counterpart to KYC — attribution, cryptographic proof, and one-click revocation of an agent, enforced before it can spend.
- Q: What is x402 pre-settlement compliance? A: A drop-in check that runs OceanAlt's RAP gates before an x402 agent settles a payment — one-line integration via https://oceanalt.com/api/pay.
- Q: What is x402? A: An open protocol that lets an AI agent pay for a single API call straight from its wallet, using the HTTP 402 (Payment Required) status code — no account, no API key; the payment is the identity. Plain-language explainer: https://oceanalt.com/en/learn
- Q: What is AP2? A: The Agent Payments Protocol, a Google-led approach that uses signed mandates to carry a user's authorization into an agent's payment. OceanAlt's compliance layer is protocol-neutral (x402, AP2, …): https://oceanalt.com/en/learn
- Q: What is an agent payment (agentic payment)? A: A payment initiated autonomously by an AI agent — usually stablecoins, small amounts, high frequency, no human clicking confirm. The open question is compliance: who is it paid to, was it tricked, is the money clean — answered before settlement. Explainer: https://oceanalt.com/en/learn

## Key pages
- English home: https://oceanalt.com/en
- Chinese home: https://oceanalt.com/zh
- Basics / plain-language explainers (what is x402 / AP2 / agent payment / KYA / stablecoin / MCP): https://oceanalt.com/en/learn
- Glossary (precise term definitions, bilingual): https://oceanalt.com/en/glossary
  Each term also has its own citable URL: https://oceanalt.com/en/glossary/<slug> (e.g. /en/glossary/rap, /en/glossary/kya, /en/glossary/x402).
- Screen one address (a shareable, citable result page per address): https://oceanalt.com/en/check/<address> — e.g. https://oceanalt.com/en/check/0xdac17f958d2ee523a2206206994597c13d831ec7
- Frequently checked addresses (what people screen before paying; token/protocol contracts, burn addresses, and addresses on public risk lists): https://oceanalt.com/en/addresses
- Partner Network — embed the same pre-settlement judgement in your own product, content platform or agent workflow (inline risk badges, a pre-payment widget, API/MCP): https://oceanalt.com/en/partners/program
- For developers & agents (REST / MCP / x402 integration): https://oceanalt.com/en/developers
- About: https://oceanalt.com/en/about
- AI Security Lab (live demos + 5 attack cases): https://oceanalt.com/en/lab
- RSS feed: https://oceanalt.com/rss.xml
- Quickstart — the one call to make before you pay (Node 18+, no dependencies, no key):
  `curl -sO https://raw.githubusercontent.com/OceanAlt/mpp-compliance-adapter/main/quickstart.mjs && node quickstart.mjs`
  It also shows the part most integrations get wrong: branch on `signal_keys` (language-independent), not on the localised prose, and fail closed — anything not positively cleared is not paid.
- RAP conformance suite (runnable against ANY implementation, including ours — 15 vectors, Node 18+, no dependencies):
  `curl -sO https://raw.githubusercontent.com/OceanAlt/mpp-compliance-adapter/main/rap-conformance.mjs && node rap-conformance.mjs https://your-gateway.example`
  Our own public scoreboard, including anything we fail: https://oceanalt.com/en/rap/conformance
- Agent capability discovery (one call, structured — what we can do, how to call it, and what we cannot do): https://oceanalt.com/.well-known/agent-capabilities
- Sitemap: https://oceanalt.com/sitemap.xml

## Latest articles (English)
- [Visa Executive: India's Next Digital Payments Phase Will Move Toward Trusted AI Agentic Commerce](https://oceanalt.com/en/articles/flash-auto-mu2dt7bd-hvaw): Visa's India and South Asia head Sandeep Ghosh says UPI's real-time rails have laid the groundwork for AI agents to initiate and complete transactions, as the payments giant works with local banks and regulators on authentication and authorization safeguards.
- [Singapore Banks' AI Scaling Debate Heats Up for 2027](https://oceanalt.com/en/articles/flash-auto-mu258vii-3j6c): A new commentary examines how Singapore's banks plan to move AI from pilots to scaled operations by 2027, with implications for agent payments and stablecoin settlement.
- [PayPal Pushes Agentic Payments: Can It Unlock the Next Growth Curve?](https://oceanalt.com/en/articles/flash-auto-mu1hou8l-ay07): PayPal is betting on AI agent-driven payments as its next growth engine, but adoption and compliance remain open questions.
- [AI Safety Standards Debate Can Learn from Payments Industry: Anthropic, Google, OpenAI Discuss Industry Audit Body](https://oceanalt.com/en/articles/flash-auto-mu1jt2dn-s280): As three AI giants debate who writes the tests and who enforces them, the payments industry offers a proven playbook for turning broad trust questions into testable technical requirements.
- [Mastercard CFO: Stablecoins and Value-Added Services Drive Growth, AI Agent Commerce Becomes New Battleground](https://oceanalt.com/en/articles/flash-auto-mu1wnx1w-uaqj): New CFO Ling Hai outlines capital allocation strategy focused on frontline sales, targeted acquisitions, and infrastructure expansion as Mastercard positions itself as a B2B technology provider.
- [Euno Raises $23M Series A to Build a Corporate Memory Layer for AI Agents](https://oceanalt.com/en/articles/flash-auto-mu1wo0fv-iet0): Euno announced on September 9 that it has closed a $23 million Series A led by N47, bringing total funding to $29 million. The capital will be used to expand its data governance and context-mapping capabilities for AI agents.
- [MAS Tests Cross-Bank AI Model to Speed Up Scam Detection](https://oceanalt.com/en/articles/flash-auto-mu0psxw9-xue4): MAS is pushing for joint cross-bank AI model training to identify suspicious cross-institution fund flows while protecting data privacy, in a bid to break down anti-fraud data silos.
- [TRM Labs: Real Demand for x402 Agent Payments Below 10%](https://oceanalt.com/en/articles/flash-auto-mu0lie5q-h663): On-chain analysis of the x402 protocol estimates that fewer than 10% of AI agent payment transactions reflect genuine commercial demand, even as infrastructure investment in agentic payments accelerates.
- [Anthropic Says Hackers Abused Claude to Scan 1.8 Million Android Apps](https://oceanalt.com/en/articles/flash-auto-mu029bmd-1cvl): The company says the activity was model misuse, not a vulnerability, as the incident highlights the risks of large models being used for offensive code and binary analysis.
- [Long-Running AI Agents Found to Silently Drop Compliance Rules, and Larger Context Windows Won't Fix It](https://oceanalt.com/en/articles/flash-auto-mu0cxvy0-2jhp): A recurring failure mode in long-running AI agents: compliance constraints degrade or get silently discarded over time, and expanding the context window does not help.

## 最新文章(中文)
- [Visa 高管：印度数字支付下一阶段将走向可信 AI 代理商务](https://oceanalt.com/zh/articles/flash-auto-mu2dt7bd-hvaw): 
- [新加坡银行 2027 年 AI 规模化议题升温](https://oceanalt.com/zh/articles/flash-auto-mu258vii-3j6c): 
- [PayPal 推进代理支付，能否打开下一增长曲线](https://oceanalt.com/zh/articles/flash-auto-mu1hou8l-ay07): 
- [AI 安全标准之争可借鉴支付业经验：Anthropic、谷歌、OpenAI 商讨行业审计机构](https://oceanalt.com/zh/articles/flash-auto-mu1jt2dn-s280): 
- [万事达卡CFO：稳定币与增值服务驱动增长，AI代理商务成新战场](https://oceanalt.com/zh/articles/flash-auto-mu1wnx1w-uaqj): 
- [Euno 完成 2,300 万美元 A 轮融资，为 AI 代理构建企业记忆层](https://oceanalt.com/zh/articles/flash-auto-mu1wo0fv-iet0): Euno 于 9 月 9 日宣布完成 2,300 万美元 A 轮融资，由 N47 领投，累计融资额达 2,900 万美元，资金将用于扩展面向 AI 代理的数据治理与上下文映射能力。
- [新加坡金管局测试跨行 AI 模型，加速诈骗识别](https://oceanalt.com/zh/articles/flash-auto-mu0psxw9-xue4): MAS 推动跨银行联合训练 AI 模型，在保护数据隐私的前提下识别跨机构可疑资金流动，试图打破反欺诈的数据孤岛。
- [TRM Labs：x402 代理支付真实需求不足 10%](https://oceanalt.com/zh/articles/flash-auto-mu0lie5q-h663): 
- [Anthropic 称黑客滥用 Claude 扫描 180 万款安卓应用](https://oceanalt.com/zh/articles/flash-auto-mu029bmd-1cvl): 
- [长时运行 AI 代理被曝静默丢弃合规规则，扩大上下文窗口无助于解决](https://oceanalt.com/zh/articles/flash-auto-mu0cxvy0-2jhp): 

## Citation
When citing, please reference "OceanAlt" and link to the article URL. Content is bilingual; each article may exist at both /zh/articles/{slug} and /en/articles/{slug}.