Skip to main content
← Back to Blog

The Robot Identity Stack: RCAN v1.3, OpenCastor, and the Robot Registry Foundation

• 7 min read • By Craig Merry
rcan opencastor robotics open-source robot-registry

As of today, there’s a complete open stack for robot identity. Not a roadmap, not a vision doc — actual software you can install, a spec you can read, and a registry you can submit to.

Three pieces:

  1. RCAN v1.3 — the identity and accountability protocol
  2. OpenCastor v2026.3.12.0 — the universal runtime for embodied AI, with RCAN built in
  3. Robot Registry Foundation — the independent body launching at robotregistryfoundation.org

Let me explain what each does and why they fit together.

The problem: robots don’t have passports

Every robot on the internet — your warehouse picker, your delivery bot, your Raspberry Pi arm — operates without any standard identity. You can’t look one up. You can’t verify who owns it. If it misbehaves, accountability is ad hoc at best.

RCAN (Robot Communication and Addressing Network) is the spec I’ve been building to fix this. Think of it like HTTPS for robots: a protocol layer that makes identity, signing, and behavioral accountability first-class. Or think of it like DNS: every robot gets a resolvable URI like rcan://registry.rcan.dev/acme/arm/v2/unit-001 — manufacturer, model, version, and device ID baked in, resolvable against a real registry.

RCAN v1.3: the spec is stable

The spec covers 19 stable sections (§1–§16 and §18–§20), Appendix B (WebSocket transport binding), and two draft sections: §17 (Distributed Registry Node Protocol) and §21 (Robot Registry Integration). §1–§16 are stable, organized around four concerns:

  • Identity & addressing: Robot URI (§1), Role-Based Access Control (§2), Message Format (§3), Authentication (§5), Federation (§7 — federated like email; any operator can run an RCAN registry node)
  • Connectivity: mDNS Discovery (§4 — LAN broadcast on _rcan._tcp.local.; works without cloud connectivity)
  • Robot runtime: Configuration (§8), Capabilities (§9), Navigation (§10), Behavior Scripts (§11), Depth & Sensing (§12), Telemetry Streaming (§13), Provider Management (§14), Swarm Coordination (§15)
  • Safety: Safety Invariants (§6 — “Local safety always wins”; network loss triggers safe-stop), AI Accountability (§16)

§16 matters most for AI-driven robots. RCAN defines four cumulative conformance tiers: L1 (baseline: addressing, RBAC, basic audit), L2 (safety: confidence gates, HMAC audit chain, emergency stop), L3 (AI accountability: model identity + HiTL gates in every audit record, e.g. confidence: 0.91, model: "Qwen2.5-7B"), L4 (registry integration: RRN↔RURI canonical mapping, ownership proof, registry handshake). Levels are cumulative — an L4 implementation must also pass L1 through L3.

What v1.3 promotes to Stable and introduces today:

  • §18: Capability Advertisement Protocol — robots declaring capabilities in CONNECT and STATUS messages; five standard types defined: move, grip, speak, stream, invoke (promoted from Draft)
  • §19: Behavior/Skill Invocation Protocol (INVOKE) — a standard way to trigger robot behaviors and skills remotely (promoted from Draft)
  • §20: Telemetry Field Registry — standardized field names for joint telemetry, robot state, and position (SI units throughout) so telemetry is interoperable across robots (promoted from Draft)
  • Appendix B: WebSocket transport binding (promoted from Draft)
  • §21: Registry Integration — RRN↔RURI canonical mapping, ownership proof, registry handshake (new Draft; §17 Distributed Registry Node Protocol shipped March 6 as the other current Draft)

The spec is CC BY 4.0. The SDKs are MIT licensed. Two SDKs exist:

pip install rcan           # core SDK
pip install rcan[all]      # includes registry client + Ed25519 signing
npm install @continuonai/rcan-ts

The full spec lives at rcan.dev.

OpenCastor v2026.3.12.0: hardware auto-detection

OpenCastor is an open-source Python runtime for embodied AI — it connects any AI provider (Claude, Gemini, OpenAI, Ollama, Hugging Face, Groq, llama.cpp, and more) to any robot hardware through a single YAML config, with RCAN identity and audit logging built into the execution path. v2026.3.11.0 introduced hardware auto-detection; today’s v2026.3.12.0 expands it with four new detectors covering most of what builders are actually using:

pip install opencastor

What it detects automatically:

  • Dynamixel servos via U2D2 USB adapter
  • I2C devices: VL53L1X (time-of-flight), SSD1306/SH1106 (OLED), ADS1115, LSM6DSO/LSM6DSOX, and others
  • RPLidar vs YDLIDAR — differentiates between them, not just “a lidar”
  • Raspberry Pi AI Camera (IMX500) — Sony image sensor with an on-chip NPU; detects whether firmware is loaded so you know before trying to run inference
  • LeRobot / SO-ARM101 — Feetech STS3215 servos on the 5-DOF arm
  • RealSense, OAK-D — depth cameras (Intel and Luxonis)
  • Hailo-8, Coral TPU — edge AI accelerators (Coral USB dongle and M.2 both detected)
  • ODrive, Arduino, CircuitPython boards — motor controllers and microcontrollers

I’m running this on a Raspberry Pi 5 — two nodes, alex.local and bob. The detection isn’t aspirational. It works on real hardware in my garage.

The goal: you plug in your hardware, run castor scan, and it tells you exactly what’s connected and which profile to use — no manual VID/PID hunting, no guessing baud rates. The scan output feeds directly into your RCAN config.

OpenCastor is Apache 2.0 licensed.

Robot Registry Foundation: independent governance

The Robot Registry Foundation is the independent governance body for robot registration. As of today, rcan.dev/registry redirects to robotregistryfoundation.org/registry/ — the registry has moved to their domain. Five robots are already registered: RRN-000000000001 (OpenCastor Bob, Community), RRN-000000000002 (Spot, Boston Dynamics), RRN-000000000003 (Unitree Go2), RRN-000000000004 (SO-ARM101, TheRobotStudio / Hugging Face), and RRN-000000000005 (OpenCastor Alex, Verified).

Find it at robotregistryfoundation.org:

  • RRN (Robot Registry Number) — globally unique, permanent identifier; format is 12 digits with leading zeros (RRN-000000000001)
  • Four verification tiers: Community → Verified → Certified → Accredited
  • Governance structure: independent technical board with seats for robot manufacturers, safety standards bodies (ISO/TC 299 and A3), academic institutions, and civil society — not controlled by any single vendor
  • Free to register — open to any robot, any manufacturer

RRF is in formation. It’s not a legal entity yet. I’m looking for co-founders who understand that the governance structure of a robot registry matters as much as the technology. A registry controlled by one company or one government is worse than no registry at all.

You don’t need all three

These compose but aren’t coupled.

  • RCAN without RRF: implement the protocol, use local or private identifiers, no registration required
  • RRF without RCAN: register your robot under any protocol or none — the registry is protocol-agnostic
  • OpenCastor without RCAN: use it as a hardware detection and runtime layer, ignore the identity pieces
  • All three: your robot has a globally resolvable identity, an auditable capability manifest, and a registration number tied to real accountability

Why now

The EU AI Act’s compliance deadlines are approaching: August 2026 for Annex III high-risk AI systems, and 20 January 2027 for AI embedded in regulated products under Annex I. Autonomous robots deployed as safety components of machinery fall into the Annex I category under Article 6(1) — specifically, the Machinery Regulation (EU) 2023/1230 — with the 20 January 2027 deadline. Registration and accountability mechanisms won’t be optional for much longer in some jurisdictions. This stack is one path toward compliance that doesn’t require buying into a vendor.

I’m not building this because a VC told me to. I’m building it because I want to deploy robots responsibly and the infrastructure didn’t exist. Now some of it does.

Get started

  • Try OpenCastor: pip install opencastor — opencastor.com (on Raspberry Pi OS Bookworm, use a --system-site-packages venv first)
  • Read the RCAN spec: rcan.dev
  • Register your robot: robotregistryfoundation.org/registry
  • Install the Python SDK: pip install rcan
  • Install the TypeScript SDK: npm install @continuonai/rcan-ts

If you’re building robots and want to talk through how any of this fits your stack, reach out.