Build robot swarms with
cryptographic trust
Traditional robot swarms have no standard identity layer — unverifiable commands, no audit trail, and catastrophic failure modes when one node is compromised. RCAN fixes this.
Traditional swarms are security nightmares
Without a standard identity layer, any robot in a swarm can impersonate another, inject commands, and leave no forensic trail.
No standard identity
Robots have no universally verifiable ID. Robot B has no way to prove it is who it claims to be to Robot A.
Unverifiable commands
When Robot A receives a "move to zone 7" command, it cannot verify whether that command came from a trusted peer or an attacker.
No audit trail
When a swarm makes a catastrophic decision, there is no cryptographic record of who authorized what, when, and with what confidence.
The RCAN Swarm Safety Stack
Four protocol layers combine to give every swarm member a provable identity, reliable communication, full accountability, and no single point of failure.
Identity Layer
— RRN + Verification TiersEvery robot receives a globally unique Robot Registration Number (RRN) registered at rcan.dev. Verification tiers (community → verified → certified → accredited) give swarm members a cryptographically anchored trust signal. Before accepting any command, a robot can call castor node resolve <rrn> to check a peer's certification level in real time.
Communication Layer
— RURI Addressing + mDNS DiscoveryRCAN Robot URIs provide globally unique, routable addresses for every robot. mDNS local discovery lets swarm members find each other on the LAN without an internet connection or central broker — the swarm self-assembles.
Accountability Layer
— §16 Commitment Chain + Thought LogEvery action in the swarm is sealed into a tamper-evident HMAC commitment chain. The §16 AI Accountability layer records which model made each decision, at what confidence, with what reasoning. Full forensic trail across the entire swarm — no gaps.
Federation Layer
— §17 Distributed RegistryNo single point of failure. The §17 distributed registry protocol allows federated resolution — robots resolve each other's identity from any node in the network. Stale cache means the swarm keeps working even if the central registry is temporarily unreachable.
How swarm verification works
Every cross-robot interaction follows this protocol. Each step is cryptographically enforced.
Robot B sends an RCAN message addressed to Robot A's RURI. The message contains Robot B's RRN as the sender identity.
Robot A calls castor node resolve RRN-BD-000000000042. The NodeClient queries the distributed registry (or stale cache if offline) and returns B's full record.
Robot A reads verification_tier from the resolved record. If B is only "community" and this task requires "certified", the command is rejected before execution.
For safety-critical swarm commands, Robot A's HITL gate may require human approval before proceeding. The request is queued at POST /api/hitl/authorize.
Robot A's own ConfidenceGate ensures its AI model is sufficiently certain before acting. Actions below the threshold are blocked regardless of who sent them.
The executed action, sender identity, confidence score, model identity, and timestamp are sealed into the HMAC commitment chain. Tamper-evident. Auditable forever.
from rcan import NodeClient, ConfidenceGate, CommitmentRecord
from rcan.audit import AuditChain
# ─────────────────────────────────────────────
# Step 1: Verify the peer robot's identity
# ─────────────────────────────────────────────
client = NodeClient()
peer_status = client.resolve("RRN-BD-000000000042")
# Check verification tier before accepting any commands
tier = peer_status['record'].get('verification_tier', 'community')
TRUSTED_TIERS = ('verified', 'certified', 'accredited')
if tier not in TRUSTED_TIERS:
raise SecurityError(
f"Peer robot not sufficiently verified: {tier}. "
f"Required one of: {TRUSTED_TIERS}"
)
print(f"✅ Peer verified: {peer_status['robot_name']} ({tier})")
# ─────────────────────────────────────────────
# Step 2: Gate on our own model's confidence
# ─────────────────────────────────────────────
gate = ConfidenceGate(threshold=0.80)
my_confidence = 0.91 # from your AI model
if not gate.allows(my_confidence):
raise RuntimeError(f"Confidence too low to act on peer command: {my_confidence}")
# ─────────────────────────────────────────────
# Step 3: Execute and log to commitment chain
# ─────────────────────────────────────────────
chain = AuditChain(secret="your-chain-secret")
record = chain.append(CommitmentRecord(
action="move_to_waypoint",
robot_uri="rcan://registry.rcan.dev/acme/rover/v1/unit-007",
confidence=my_confidence,
model_identity="claude-sonnet-4-6",
params={"waypoint": "zone-7", "authorized_by": "RRN-BD-000000000042"},
safety_approved=True,
))
print(f"📝 Logged to chain: {record.content_hash[:16]}...")RCAN-Swarm Safe requirements
A robot can claim the RCAN-Swarm Safe designation when it meets all five criteria below. Run rcan-validate config myrobot.rcan.yaml to check.
Valid RRN
RCAN config present with a registered, globally unique Robot Registration Number.
rcan.dev/registry Verification tier ≥ verified
The robot's identity has been confirmed — at minimum, email/domain verification completed.
verification_tier: verified Commitment chain enabled
All actions are sealed into the HMAC-chained audit log. Tamper detection active.
security.commitment.enabled: true HITL gate for swarm commands
Safety-critical commands received from swarm peers require human approval before execution.
hitl_gates: [swarm_commands] Confidence gate ≥ 0.7
At least one confidence gate configured. The robot will not act on peer commands when its own model is uncertain.
confidence_gate.threshold: 0.7 rcan-validate all config.yaml
OpenCastor is the reference implementation for
RCAN-Swarm Safe robots
OpenCastor ships with peer verification, commitment chain audit, HITL gates, confidence gates, and mDNS swarm discovery — all configured and ready to run. It is the fastest path to a RCAN-Swarm Safe robot.
castor node resolve <rrn> castor commit verify castor discover