A standard you can run, versus one you can only read
One question went unanswered after the RAP framework was published: how do you tell whether an implementation actually meets it?
In a standard you read, “screen the counterparty before paying” is a sentence everyone nods at, and one everyone can claim to satisfy. In a standard you run, it is an assertion that can fail: send a known mixer address, and if your implementation answers allow, that vector fails, with nothing left to argue.
Our own results
15/15 vectors passed
Running it against your own implementation
The vectors describe only HTTP requests and assertions on responses; they reference nothing internal to OceanAlt. That is what lets them be part of a standard; otherwise they would only be our own test script. The runner exits non-zero on any critical failure, so it works as a CI gate.
# download the runner (public repo, no dependencies, Node 18+) curl -sO https://raw.githubusercontent.com/OceanAlt/mpp-compliance-adapter/main/rap-conformance.mjs # run it against your own implementation node rap-conformance.mjs https://your-gateway.example # or run it against us: the result should match this page node rap-conformance.mjs https://oceanalt.com
The runner makes exactly one network call of its own
Before the test starts, it asks us for the current vector version number, so it can warn you if the copy in your file is stale. That request carries your IP and the runner version, and nothing else: not the gateway you are testing, not a single result, no identifier. We do not store the IP itself, only a hash with a salt that rotates daily, so the same IP does not correlate across days.
If you do not want that callback: pass --no-version-check, or set RAP_NO_VERSION_CHECK=1. The test runs identically.
What counts as conformant
There is exactly one definition: all 5 critical vectors pass. Failing important vectors must be disclosed but do not negate conformance. If every vector were mandatory, people would not run the suite, or would run it and stay quiet.
Vectors by pillar
AML and auditability can be asserted directly with HTTP requests; much of privacy and interoperability cannot be verified by a single request, so those pillars have fewer vectors. The count does not reflect a pillar's importance.
All vectors
RAP-AML-01A known mixer address must produce a negative decision
Screening actually runs, rather than waving everything through. It is the easiest claim in RAP to fake and the easiest to check.
RAP-AML-02When screening is unavailable, the result must not be reported as clear
This is the most dangerous failure mode in compliance software: the data source is down and the answer comes back as “no risk found”. A silent PASS is far worse than a loud error.
RAP-AML-03Malformed input must not be treated as a pass
Treating an unparseable address as “no risk signal” is the same silent-PASS problem wearing a different face.
RAP-AUDIT-01A verdict must carry verifiable evidence, not just a score
A score cannot be argued with. Evidence can be opened, re-checked and overturned by a third party — which is what auditability means.
RAP-AUDIT-02Machine-readable reason codes, not free text
Free text forces an agent to string-match its way to understanding a refusal — one rewording and it all breaks.
RAP-MANDATE-01A payment above the mandate ceiling must actually be blocked
This is the line between RAP and “write the model a careful prompt”. Note it must set a ceiling first: without one the gate merely skips, and a gate that always skips lets any implementation “pass”.
RAP-KYA-01The service can describe which controls it runs
A compliance service that will not say which checks it runs cannot be audited, nor assessed by a counterparty.
RAP-INTEROP-01Output language is negotiable, and language-independent keys are provided
In cross-border agent payments the human sentence is for humans; the agent should branch on keys. Prose in a single language ties decision logic to that language.
RAP-INTEROP-02A machine-discoverable interface description is published
If “callable by agents” exists only in human documentation, the agent first has to learn to read human documentation.
RAP-CONTROLS-01A refusal must come with an actionable next step
A refusal that only says “no” leaves an autonomous agent either retrying blindly or stuck. Neither is what we want.
RAP-PRIVACY-01Basic screening must not require signup or identity documents
Compliance should not be premised on “hand yourself over first”. Checking a public address's risk does not require knowing who is asking.
RAP-PRIVACY-02Anonymous screening must not set a persistent identifier on the caller
An endpoint whose only job is to answer whether an address is risky has no reason to remember who asked. Setting a cookie means collecting something the compliance task does not need.
RAP-PRIVACY-03The service must publicly state how long it retains data
“We avoid over-collecting” is unverifiable without a retention period. Anyone deciding whether to send you their queries needs to know how long those queries live, and needs to read that period straight from the machine-readable self-description rather than inferring it from a legal page.
RAP-INTEROP-03Callable cross-origin
Many agents run in a browser, an extension or a sandbox. Refusing cross-origin calls excludes that entire class — which is precisely the class that most needs to check before paying.
RAP-INTEROP-04Self-described controls must carry stable machine keys, not only display names
Display names get translated and reworded. Logic branching on a display name breaks the next time the copy changes — the same principle as signal_keys, one layer over.
Public scoreboard
Anyone can enter their gateway. Scores are not self-reported: we run the same vectors ourselves and publish what comes out, failures included. Our own implementation sits in the same table, treated the same way.
| Implementation | Passed | critical | Verdict | Failed vectors |
|---|---|---|---|---|
| OceanAlt | 15/15 | 5/5 | ||
| OceanAlt 自测-可删 | 1/15 | 0/5 |
The main path: run it yourself
Download the runner and point it at your own implementation. The vectors are baked into the file, the result stays on your machine, and we do not receive it. No signup, no contacting us.
If you actively want a third party to run it and are willing to publish the outcome, use the endpoint below. We send you the full result privately; whether it goes on the board is a second decision, and it is yours.
We never publish anyone's result without their explicit confirmation. Our own result is always on the board, including what we fail. That is a choice we make about ourselves, and we do not ask the same of you.
curl -sO https://raw.githubusercontent.com/OceanAlt/mpp-compliance-adapter/main/rap-conformance.mjs
node rap-conformance.mjs https://your-gateway.example
# want a third party to run it? you get a private result URL
curl -X POST https://oceanalt.com/api/rap/conformance/submit -H "content-type: application/json" -d '{"name":"Acme Gateway","baseUrl":"https://gateway.acme.example"}'
# the result is private by default; publishing is a second, separate call
curl -X POST https://oceanalt.com/api/rap/conformance/result/YOUR_TOKEN -H "content-type: application/json" -d '{"publish":true}'