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 field in ROBOT.md for EU AI Act compliance (the model number is the anchor for §26 EU Register filings).
§ 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 ops@example.com

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/fria FRIA — Fundamental Rights Impact Assessment ● Live
§23 /v2/safety-benchmark Safety benchmark (ISO 42001 self-assessment) ● Live
§24 /v2/ifu IFU Art. 13(3) — Instructions for Use ● Live
§25 /v2/incident-report Incident report Art. 72 ● Live
§26 /v2/eu-register EU Register Art. 49 filing ● 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 actually enforced.
Physical safety is enforced at Layer 3 (robot-md-gateway) or Layer 4 (a runtime that embeds it, e.g., OpenCastor). 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.