Blog
RCAN v2.1:
The First Major Protocol Release
March 26, 2026 · ContinuonAI
Status: Spec stable · SDK target: Q1 2027 · Depends on: RCAN Foundation formation (Q3–Q4 2026)
Why a major version?
RCAN v2.1 is the first major version bump of the protocol. It introduces breaking wire-format changes that cannot be made under the v1.x backwards-compatibility guarantee. The release consolidates lessons learned from v1.0–v1.10 and addresses five strategic areas:
Signed Firmware Manifests
Cryptographic proof of robot software provenance. Every v2.1 robot publishes an Ed25519-signed firmware manifest at a well-known endpoint.
Supply Chain Attestation
Hardware and software bill-of-materials on the wire. CycloneDX-based SBOM publication with RCAN extensions.
M2M_TRUSTED Fleet Orchestration
RRF-issued level-6 tokens allow an orchestration system to command an entire fleet without per-robot CREATOR approval at runtime.
ISO/TC 299 Alignment
Formal mapping to ISO 13482, ISO 10218-2, and ISO/IEC 42001. RCAN safety invariants aligned with international standards.
EU AI Act Article 16
Production-ready compliance for high-risk AI systems. New message types for regulatory authority access and audit data export.
RCAN v2.1 is a clean break from v1.x. There is no version negotiation, no downgrade path, and no support for v1.x envelope fields in v2.1 receivers. Several changes — new required envelope fields, removal of deprecated aliases, RURI format extensions, and role level restructuring — made this the right boundary for a major version.
External drivers
| Driver | Deadline | Impact |
|---|---|---|
| EU AI Act (2024/1689) Art. 16 | August 2026 | High-risk AI systems must maintain traceability and post-market monitoring. v2.1 provides wire-level compliance. |
| ISO/TC 299 (Robotics) | Ongoing | International safety standards for service and industrial robots. v2.1 aligns RCAN safety invariants with ISO normative requirements. |
| NIST AI RMF | 2026 updates | Risk management framework for AI systems. v2.1 audit trail maps directly to NIST RMF functions. |
| Supply chain attacks | Ongoing | Firmware integrity attacks on IoT/robotics. v2.1 makes firmware provenance verifiable at the protocol level. |
Breaking changes
Deprecated alias removal
The following rcan-ts aliases, deprecated in v1.8, are removed in v2.1:
| Deprecated Alias | Canonical Name | Value | Notice Period |
|---|---|---|---|
FEDERATION_SYNC | FLEET_COMMAND | 23 | v1.8 (Mar 2026) → v2.1 (Q1 2027): 10+ months |
ALERT | FAULT_REPORT | 26 | v1.8 (Mar 2026) → v2.1 (Q1 2027): 10+ months |
AUDIT | TRANSPARENCY | 16 | v1.8 (Mar 2026) → v2.1 (Q1 2027): 10+ months |
signature: "pending" | (hard-removed) | — | v1.0 (Jan 2026) → v2.1 (Q1 2027): 12+ months |
Message envelope changes
New required fields in the v2.1 message envelope:
v2.1 receivers reject messages missing firmware_hash. There is no fallback.
RURI format extension
The sig query parameter carries a detached Ed25519 signature over the RURI path. At L2+,
unsigned RURIs are rejected. At L1, unsigned RURIs are accepted. Invalid signatures always fail regardless of level.
Role level restructuring
v2.1 restructures human roles and introduces two machine authorization tiers:
| Level | v1.x Name | v2.1 Name | Change |
|---|---|---|---|
| 1 | GUEST | GUEST | No change |
| 2 | USER / LEASEE | OPERATOR | Consolidated; LEASEE removed |
| 2.5 | (contribute scope) | CONTRIBUTOR | Formalized as a proper level |
| 3 | OWNER | ADMIN | Renamed; OWNER removed |
| 4 | (new) | M2M_PEER | Robot-to-robot peer authorization; issued by ADMIN |
| 5 | CREATOR | CREATOR | No change |
| 6 | (new) | M2M_TRUSTED | RRF-issued fleet orchestration; multi-owner consent required |
New features
Signed firmware manifests
Every RCAN v2.1 robot MUST publish a firmware manifest at
{ruri}/.well-known/rcan-firmware-manifest.json.
The manifest is Ed25519-signed by the manufacturer's key registered in the RRF:
FAULT_REPORT (26) with fault_code: "FIRMWARE_INTEGRITY_FAILURE".
Supply chain attestation (SBOM)
v2.1 defines a standard for robots to advertise their software bill of materials at
{ruri}/.well-known/rcan-sbom.json, following the
CycloneDX v1.5+ format with RCAN extensions.
The attestation_ref field in the v2.1 message envelope points to this SBOM endpoint,
enabling any message recipient to verify the sender's software supply chain.
M2M_TRUSTED fleet orchestration
The new M2M_TRUSTED (level 6) role enables a cloud orchestration system to
issue COMMAND, INVOKE, and CONFIG messages to an entire
fleet without requiring per-robot CREATOR approval at runtime. Unlike M2M_PEER (authorized by
a single ADMIN), M2M_TRUSTED tokens are issued exclusively by the RRF root key after aggregating
explicit consent from every fleet owner:
Hard constraints: tokens expire in ≤ 24 h, fleet_rrns must be an explicit list (no wildcards),
the orchestrator cannot issue further tokens, and ESTOP from any source is always honored regardless of role level.
Any CREATOR can revoke consent at any time; revocation propagates within 60 seconds via the RRF revocation list.
ISO/TC 299 alignment
v2.1 introduces normative references to ISO safety standards and maps RCAN provisions to ISO requirements:
| RCAN Provision | ISO Standard | Mapping |
|---|---|---|
| §6 Safety invariants | ISO 13482:2014 | RCAN ESTOP maps to ISO 13482 protective stop |
| §2 RBAC | ISO 10218-2:2011 | RCAN role levels satisfy ISO access control |
| §16 Transparency | ISO/IEC 42001:2023 | RCAN audit chain provides ISO AI management evidence |
| §7 ConfidenceGate | ISO 13482:2014 | Confidence thresholds map to ISO risk-based decision gates |
| §9 Ed25519 signing | ISO/IEC 27001:2022 | Ed25519 satisfies ISO cryptographic control requirements |
A new iso_conformance block in the DISCOVER payload lets robots declare which ISO standards they conform to:
EU AI Act Article 16
Article 16 of the EU AI Act requires providers of high-risk AI systems to maintain quality management, technical documentation, logging, corrective action capability, and authority cooperation. v2.1 maps these requirements directly to protocol features:
Quality Management
v2.1 audit chain + SBOM provide continuous quality evidence for the entire robot lifecycle.
Technical Documentation
Firmware manifests + transparency records keep documentation up to date automatically.
Logging (Art. 12)
RCAN commitment chain (§16) satisfies the logging capabilities requirement.
Authority Cooperation
New AUTHORITY_ACCESS message type (41) lets regulators request audit data per Art. 16(j).
New message types
| Value | Name | Direction | Description |
|---|---|---|---|
| 41 | AUTHORITY_ACCESS | authority → robot | Regulator requests audit data access per EU AI Act Art. 16(j) |
| 42 | AUTHORITY_RESPONSE | robot → authority | Robot provides requested audit data |
| 43 | FIRMWARE_ATTESTATION | robot → registry | Robot publishes signed firmware manifest to registry |
| 44 | SBOM_UPDATE | robot → registry | Robot publishes updated SBOM |
Conformance levels
v2.1 introduces L5: Supply Chain and adds M2M_TRUSTED requirements on top of the existing L1–L4 hierarchy:
| Level | Label | Key Requirement |
|---|---|---|
| L1 | Core | DISCOVER, STATUS, COMMAND, RURI addressing, JWT auth |
| L2 | Secure | L1 + HiTL gates, Ed25519 signing, AuditChain, firmware_hash, signed RURI |
| L3 | Federated | L2 + commitment chain, cross-registry discovery |
| L4 | Registry | L3 + REGISTRY_REGISTER/RESOLVE roundtrip, RRN validation |
| L5 | Supply Chain | L4 + firmware manifest verification, SBOM publication, AUTHORITY_ACCESS handler, EU AI Act Art. 16 |
Migration from v1.x
v2.1 is a clean break. There is no version negotiation and no downgrade path. Upgrade all robots in a fleet simultaneously, or run v1.x and v2.1 fleets as separate networks.
Why no negotiation? The new required envelope fields (firmware_hash,
attestation_ref) have no safe fallback in v1.x receivers. A v2.1 sender omitting them
for negotiation would be operating below its declared conformance level. Given the small ecosystem
size and our goal of clean security guarantees, a coordinated fleet upgrade is the right path.
Timeline
| Milestone | Target | Status |
|---|---|---|
| v2.1 spec published | March 2026 | ✓ Done — wire format locked |
| RCAN Foundation formed | Q3 2026 | Foundation board ratifies spec |
| EU AI Act enforcement | August 2026 | Art. 16 obligations enforceable; OpenCastor L5 critical path |
| v2.1 SDK alphas | March 2026 | rcan-py 1.1.0a1, rcan-ts 1.1.0a1 |
| v2.1 RC | March 2026 | Release candidate; conformance suite L5 finalized |
| v2.1 Release | March 2026 | rcan-py 1.1.0, rcan-ts 1.1.0, OpenCastor ≥2027.1.x |
Open questions
- M2M_PEER mutual TLS — Should M2M_PEER (level 4) require mutual TLS in addition to JWT?
- SBOM format — CycloneDX is normative. Should SPDX be supported as an alternative?
- Firmware attestation frequency — Re-attest on every boot, or only on firmware change?
- ISO liaison — Should TC 299 membership be a Foundation or ContinuonAI responsibility?
- MessageType range — Reserve 41–50 for regulatory types and 51–99 for extensions, or allow flexible allocation?
References
- RCAN Specification (current: v1.10 · upcoming: v2.1)
- EU AI Act (2024/1689)
- ISO 13482:2014 — Safety requirements for personal care robots
- ISO/IEC 42001:2023 — AI management system
- CycloneDX SBOM Standard
- NIST AI Risk Management Framework
- rcan-py SDK
- rcan-ts SDK
- Robot Registry Foundation