The open protocol for
AI-accountable robotics
RCAN gives every robot a unique, verifiable identity — and makes every AI decision it takes auditable, signed, and provable.
The problem
When a robot causes an incident — a warehouse arm injures a worker, a delivery robot makes the wrong call — investigators hit a wall. Not because the robot failed, but because no one can prove what it did.
Which command arrived? Who authorized it? What was the AI model's confidence? Was there a human in the loop? The answers are usually scattered across proprietary logs, local storage, and undocumented formats — or simply missing.
RCAN is the protocol layer that makes those answers available and forensically defensible — before the incident happens.
Key concepts
Robot Addressing
§1Every robot gets a globally unique URI: rcan://registry.rcan.dev/manufacturer/model/version/device-id. Like a domain name, but for physical machines. Persistent, portable, and human-readable.
Commitment Chain
§7Every outbound action is appended to an HMAC-SHA256 chained audit log. Tamper any record, and the chain breaks. Every record is verifiable without a central server.
AI Accountability Layer
§16Confidence gates block actions below a threshold. Human-in-the-loop gates require token-based approval. Model identity is recorded with every decision — so you know which model made the call.
Message Signing
§5Ed25519 keypairs sign every command at the source. The signature travels with the message, binding it to a specific key ID. Keys are registered in the robot's record.
Who maintains it
RCAN is designed and maintained by Craig Merry, with the goal of eventually transferring governance to an independent Robot Registry Foundation.
The spec is licensed CC BY 4.0 — free to implement, fork, and build on. Any robot runtime, fleet system, or manufacturer can implement RCAN and register robots at the RCAN Registry. There is no exclusivity. The goal is a universal standard, not a proprietary ecosystem.
The reference SDKs (rcan-py, rcan-ts) and the OpenCastor robot runtime (one reference implementation that informed the spec) are Apache 2.0 licensed. OpenCastor is not the only way to implement RCAN — it is an example.
Standards engagement is underway with ISO/TC 299 WG3 (industrial robot safety) and EU harmonized standards bodies ahead of the August 2026 EU AI Act high-risk provisions deadline.
Roadmap
AI Accountability Layer (§16): confidence gates, HiTL gates, model identity, thought log. Ed25519 signing. Commitment chain. §17–§20 + Appendix B (Distributed Registry, Capability Advertisement, INVOKE, Telemetry Fields, WebSocket).
§17–§20 + Appendix B promoted to Stable. §21 Robot Registry Integration — RRN↔RURI canonical mapping, ownership proof, registry handshake. Conformance L4.
§1–§16 dedicated section pages — all 16 core spec sections now have standalone pages with full content, code examples, and cross-references. CLAUDE.md agent context files added to all ecosystem repos.
18 of 22 security/safety gaps addressed: replay attack prevention (30s window), robot identity revocation, command delegation chains, consent wire protocol, ESTOP QoS exactly-once, offline operation mode, training data consent (EU AI Act Art.10), cloud relay identity audit. P66 conformance 87%→94%. rcan-py v0.5.0, rcan-ts v0.5.0.
4 deferred gaps closed: federated consent protocol (FEDERATION_SYNC, cross-registry JWT trust, 3-tier registry hierarchy), bandwidth-constrained transports (32-byte RCAN-Minimal for LoRa, RCAN-Compact CBOR, BLE L2CAP), multi-modal payloads (media_chunks SHA-256 audit trail, streaming), human identity LoA 1/2/3 (FIDO2, min_loa_for_control). All 22 original audit gaps addressed. rcan-py v0.6.0, rcan-ts v0.6.0.
Competition protocol: COMPETITION_ENTER (37), COMPETITION_SCORE (38), SEASON_STANDING (39) for fleet competition events. PERSONAL_RESEARCH_RESULT (40) for private local research runs. Canonical MessageType table extended to 40 entries.
M2M_TRUSTED (level 6), signed firmware manifests, SBOM attestation, EU AI Act §12/§16. OpenCastor v2026.3.21.2.
ML-DSA-65 primary signing (FIPS 204), Ed25519 deprecated, dual-brain VLA+Claude architecture, ISO 42001 + EU AI Act compliance. OpenCastor v2026.3.27.1.
pqc-hybrid-v1 cryptographic profile: Ed25519 + ML-DSA-65 (NIST FIPS 204) dual signatures. Both halves required. /.well-known/rcan-node.json extended with crypto_profile, pqc_public_key, ed25519_public_key. §1.6.4 RURI combined sig format.
EU AI Act compliance schemas as first-class protocol citizens. §23–§26 added. Three breaking changes: mandatory ML-DSA-65/pqc-hybrid-v1 signatures, Ed25519-only profiles rejected, Annex III REGISTRY_REGISTER requires fria_ref. §23 Safety Benchmark Protocol, §24 Instructions for Use, §25 Post-Market Monitoring, §26 EU Register Submission.
§26 EU Register: top-level rmn (Robot Model Number) required. Art. 49 registration is per-model, not per-robot — rmn identifies the registered model; system.rrn becomes submission provenance only. §26 is Experimental tier per VERSIONING.md; breaking MINOR change permitted with release notice (zero production consumers at bump time). Requires rcan-py 3.2.0 + rcan-ts 3.3.0 for byte-parity.
Multi-runtime agent declaration (agent.runtimes[]) for peer-runtime deployments. §8.6 adds optional agent.runtimes[] array allowing a single ROBOT.md identity to declare multiple supported runtimes (robot-md, opencastor, …) with per-runtime harness + model config. Flat agent.provider / agent.model soft-deprecated; validators emit DeprecationWarning and normalize to single-entry runtimes[]. Removal scheduled for v4.0.
Get started in 5 minutes
Install the SDK, run your first RCAN message, and register your robot with a global RRN.