Robot Registry Foundation RCAN protocol · 5 §22-26 endpoints live

Permanent identity for every robot.

The Robot Registry Foundation issues RRNs — permanent numeric robot identities — and hosts the five RCAN §22-26 compliance endpoints. robot-md register handles the signed-POST flow.

§ 01 — Identifiers

RRN and RMN — two identifier types.

An RRN identifies a robot instance. An RMN identifies a robot model. Both are permanent once issued.

RRN — Robot Registration Number
RRN-000000000003
Identifies a specific robot instance. Numeric, zero-padded to 12 digits. URI form: rrn:000000000003. Resolves at robotregistryfoundation.org/r/RRN-000000000003.
RMN — Robot Model Number
RMN-000000000004
Identifies a robot model (e.g., SO-ARM101 v2). Required in ROBOT.md before emitting a §26 EU-register packet; the CLI files that packet with RRF, one per model.
§ 02 — Registration

robot-md register — mint an RRN.

One command mints an RRN and writes it back into your ROBOT.md. Requires a valid ROBOT.md declaring an rcan_version from the live compatibility matrix. 

$ robot-md register ROBOT.md \
    --manufacturer "Acme Robotics" \
    --contact-email [email protected]

The command signs the registration payload with your robot's key (generated at init time) and POSTs to https://robotregistryfoundation.org/v2/register. On success, metadata.rrn and metadata.rrn_uri are written back to your ROBOT.md.

§ 03 — RRF endpoints

5 §22-26 endpoints, all live.

All five RCAN compliance endpoints are live at robotregistryfoundation.org as of 2026-04-24.

RCAN § Endpoint Packet name Status
§22 /v2/robots/<rrn>/fria FRIA — Fundamental Rights Impact Assessment ● Live
§23 /v2/robots/<rrn>/safety-benchmark Safety benchmark (synthetic timing of software safety paths) ● Live
§24 /v2/robots/<rrn>/ifu IFU Art. 13(3) — Instructions for Use ● Live
§25 /v2/robots/<rrn>/incident-report Incident report (post-market monitoring, Art. 72; reporting to authorities under Art. 73 is the provider's step) ● Live
§26 /v2/models/<rmn>/eu-register EU-register packet (Art. 49 fields), filed with RRF only ● Live
§27 /v2/fria-signed FRIA with post-quantum signature (in flight) ◌ In flight

Live endpoint status: robotregistryfoundation.org →

§ 04 — Identity & signing

Post-quantum hybrid keys.

Every compliance packet is signed before posting. Keys are stored locally.

Key algorithm pqc-hybrid-v1  — ML-DSA-65 + Ed25519 hybrid (RCAN protocol L2+)
Keystore path ~/.robot-md/keys/  — one key pair per robot instance
Rotate key robot-md rotate-key ROBOT.md  — generates new key pair, re-binds at RRF
Revoke key robot-md revoke-key ROBOT.md  — marks key as revoked at RRF; triggers downstream M2M_TRUSTED re-auth

Keys are generated at robot-md register time and bound to the RRN. The ed25519 algorithm is accepted at RCAN protocol L1 only; L2+ requires pqc-hybrid-v1.

§ 05 — Revocation

M2M_TRUSTED §2.9 revocation polling.

Any system that trusts a robot's key via the M2M_TRUSTED tier MUST poll for revocation. robot-md handles this automatically.

When a key is revoked (via robot-md revoke-key or directly at RRF), the RRF broadcasts a revocation event to all registered M2M_TRUSTED listeners. Peer runtimes (OpenCastor, robot-md-gateway) poll https://robotregistryfoundation.org/v2/revocation/<rrn> on a configurable interval (default: 60 seconds). Any request signed with a revoked key is rejected with 403 KEY_REVOKED.

RRF live site → File compliance packets → ROBOT.md spec →
Where safety is meant to be enforced.
Physical limits are meant to be enforced at Layer 3 (robot-md-gateway and the actuator driver it calls), and only for commands that pass through it. OpenCastor (Layer 4) does not embed the gateway yet, so actuators it drives directly are not covered. Declaration alone (Layer 1) does not enforce safety. Agent host alone (Layer 2) is not the safety boundary. If a deployment lacks Layer 3, no safety claim attaches to it. Layer 3 is not a certified safety function, and hostile-input testing in simulation (October 2026) found motions it does not yet bound.