Skip to main content
← Back to Blog

We Need an ICANN for Robotics: Introducing RCAN (Part 4)

• 8 min read • By Craig Merry
Robotics AI Governance Protocol Standards RCAN Series

We Need an ICANN for Robotics: Introducing RCAN (Part 4)

Before the Domain Name System, the internet was chaos.

In the 1970s, if you wanted to connect to another computer, you needed to know its raw IP address. The Stanford Research Institute maintained a single text file—HOSTS.TXT—that mapped every known computer on the network to a name. As the internet grew, this became impossible. The file was updated weekly. Conflicts arose. Machines became unreachable.

Then came DNS. Then came ICANN. The internet finally had a namespace.

Robotics in 2026 is in its pre-DNS era. We have millions of robots being manufactured—arms in warehouses, quadrupeds in research labs, humanoids on assembly lines, delivery bots on sidewalks. But there is no standard way to identify them. No standard way to authenticate who can control them. No standard way to coordinate them.

We are building the physical internet without any addressing scheme.

The Problem: Four Missing Standards

In Part 2 of this series, I argued that we need a “constitutional operating system” for robots—a governance stack that encodes safety, law, and social norms. In Part 3, I showed how the UNIX philosophy can provide the architecture for that system.

But an operating system is useless without a network. And a network is useless without addressing.

Today, the robotics industry lacks standards in four critical areas:

1. Addressing: How do I uniquely identify a robot? Not just on my local network, but globally? When I buy a used robot, how do I know its provenance?

2. Authentication: Who is allowed to control this robot? The owner? A temporary user? A fleet manager? How do I verify they are who they claim to be?

3. Role-Based Access: Not everyone should have the same permissions. An owner can install new skills. A guest can only chat. A lessee has time-bound control. How do we encode and enforce these differences?

4. Multi-Robot Coordination: When robots work in fleets or swarms, who has authority? What happens when two users issue conflicting commands? How do we handle handoffs?

The internet solved these problems with DNS, SSL certificates, OAuth, and pub/sub protocols. Robotics has none of these equivalents.

The Proposal: RCAN

I am proposing a new protocol called RCAN: Robot Communication & Addressing Network. Think of it as DNS meets OAuth meets ROS—but designed from first principles for embodied AI.

The Robot URI (RURI)

Every robot gets a globally unique identifier:

rcan://continuon.cloud/continuon/companion-v1/d3a4b5c6-7890-1234-5678-abcdef012345

This RURI contains everything you need to know: the registry (like a TLD), the manufacturer, the model, and a unique device ID. You can extend it with capability endpoints:

rcan://continuon.cloud/continuon/companion-v1/d3a4b5c6/arm
rcan://continuon.cloud/continuon/companion-v1/d3a4b5c6/vision

Just as you can navigate to google.com/search or google.com/maps, you can address specific subsystems of a robot.

Role Hierarchy

RCAN defines a five-level role hierarchy:

RoleLevelKey Permissions
Creator5Full hardware/software control, OTA push, safety override
Owner4Configuration, skill installation, user management
Leasee3Time-bound operational control, cannot change ownership
User2Operational control within allowed modes
Guest1Limited interaction, chat, read-only status

This matters for the emerging robot economy. When you rent a robot, you are a Leasee—not an Owner. You can operate it, but you cannot wipe its training data or install untrusted skills. When a child interacts with a home assistant, they are a Guest—they can ask questions, but they cannot reconfigure the safety limits.

Local Discovery

When cloud connectivity is unavailable, robots broadcast their presence via mDNS:

_rcan._tcp.local.

Your app discovers robots on the local network, validates cached credentials, and operates in offline-autonomous mode. When connectivity returns, logs sync to the cloud for audit.

This is critical for resilience. A warehouse cannot shut down because the internet is flaky.

Safety Invariants

RCAN encodes three safety invariants at the protocol level:

  1. Local safety always wins. No remote command can bypass on-device safety checks. Period.

  2. Graceful degradation. Network loss triggers safe-stop, not undefined behavior.

  3. Audit trail. Every command is logged with user, timestamp, and outcome. This is non-optional.

These are not suggestions. They are protocol requirements.

How RCAN Differs from Existing Proposals

The embodied AI space is not lacking proposals. But they address different layers of the stack:

ProposalFocusApproachGap
ROS2/DDSPub/sub messagingTechnical middlewareNo identity or auth
Matter/ThreadIoT interoperabilityIndustry consortiumSmart home only, not robots
SophiaDAOHumanoid governanceDecentralized DAOSingle manufacturer (Hanson)
Dynamic CertificationAdaptive regulationAcademic frameworkCompliance, not protocol
IEEE SMC CommitteeResearch collaborationStandards bodyResearch, not enforcement
Physical AI (Japan JST)National R&DGovernment strategyNational, not global
Fostering Robots (EU)Domestic governanceRegulatory frameworkPolicy, not protocol

RCAN is different. It operates at the addressing and authentication layer—like DNS and SSL—not at the messaging layer (ROS) or the policy layer (regulations).

You can run ROS2 over RCAN. You can implement EU compliance on top of RCAN. But without something like RCAN, you cannot even begin to answer the question: “Who is allowed to tell this robot what to do?”

The “Skynet” Objection: Federation vs. Control

A valid critique of any global addressing system is that it creates a single point of failure—or worse, a single point of control. If there is an “ICANN for Robots,” can’t the authorities just delete your robot’s entry? Can’t a bank seize your domain and brick your hardware?

This fear is well-founded. But it ignores a terrifying reality: We are already living in the worst-case scenario.

Right now, if you buy a consumer robot, it connects to a single, hardcoded manufacturer cloud. If that startup goes bankrupt, your robot becomes e-waste. If that manufacturer decides you violated their Terms of Service, they can remotely disable your hardware. You do not own your robot; you are merely a subscriber to its proprietary API.

RCAN is designed to break this monopoly through Federation and Local Sovereignty.

1. Federated, Like Email

RCAN is not a single platform like Facebook or X; it is a protocol like SMTP (Email). Just as anyone can host their own email server, anyone can host an RCAN Registry.

rcan://continuon.cloud/...     (Managed Service)
rcan://my-local-server.lan/... (Self-Hosted)
rcan://robotics-co-op.org/...  (Community Run)

2. The Right to Redirect

The protocol explicitly grants the Owner (Level 4) the right to change the robot’s upstream registry. If a manufacturer becomes hostile or a cloud provider becomes too expensive, you can “point” your robot to a new registry, just as you can switch your domain name from GoDaddy to Namecheap.

3. Local Supremacy

Most importantly, RCAN enforces Local Safety Invariants. Even if the cloud registry deletes your ID, or the internet is severed, the robot must respond to local discovery (_rcan._tcp.local) and local auth tokens.

RCAN doesn’t build Skynet. It builds the escape hatch.

Why This Matters Now

China’s robotics industry is scaling at a pace the West has not fully internalized. Unitree is shipping quadrupeds at consumer price points. BYD is pivoting from EVs to humanoids. The Chinese government has declared a target of over 100,000 humanoid robots by 2027.

These robots will need to be addressed, authenticated, and coordinated. The question is: whose protocol will they use?

If we do not propose open standards, the default will emerge from proprietary ecosystems. We will end up with a fragmented world of “Walled Gardens,” where a Unitree robot can only talk to a Unitree server, and a Tesla bot can only talk to Tesla.

This leads to a future where:

  • Obsolescence is guaranteed: When the company dies, the robot dies.
  • Censorship is trivial: The manufacturer controls the off-switch.
  • Interoperability is zero: Your warehouse bot cannot talk to your security bot.

In the 1990s, the United States exported its values by encoding them into the protocols of the internet—openness, federation, and permissionless innovation. We ensured that email didn’t belong to AOL, and the web didn’t belong to Microsoft.

We must do the same for embodied AI. We need a protocol that guarantees robots remain useful tools for their owners, rather than tethered surveillance devices for their manufacturers.

But only if we propose something.

Call to Action

RCAN is currently an RFC—a Request for Comments. It is implemented in prototype form in the ContinuonBrain runtime. But it needs broader adoption to matter.

If you are building robotics infrastructure, I invite you to:

  1. Read the spec. The full RCAN protocol is documented in our next blog post.

  2. Critique it. What is missing? What is over-specified? What would not work for your use case?

  3. Implement it. The protocol is designed to be transport-agnostic—WebSocket, gRPC, MQTT, or plain HTTP.

  4. Advocate. If you are involved with standards bodies (IEEE, ISO, W3C), raise the question: why does robotics not have a DNS?

The hardware revolution is already here. The protocol revolution is waiting to be written.

This is Part 4 of an ongoing series on values, governance, and architecture in embodied AI. Read Part 1: When Robots Carry Values, Part 2: We Need a Constitution for the Robot Age, and Part 3: One Brain, Many Shells.