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. There is nothing to explain.
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 — which is what makes them part of a standard rather than 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
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 — make everything mandatory and people simply do not run it, or 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 |
Want to enter?
Run it yourself first — the script is public, dependency-free and needs no signup. Results are published in full, including failed vectors.
curl -sO https://raw.githubusercontent.com/OceanAlt/mpp-compliance-adapter/main/rap-conformance.mjs
node rap-conformance.mjs https://your-gateway.example
# happy with it? then submit
curl -X POST https://oceanalt.com/api/rap/conformance/submit -H "content-type: application/json" -d '{"name":"Acme Gateway","baseUrl":"https://gateway.acme.example"}'