OpenCastor is becoming a California Benefit Corporation — here’s why that matters

There’s a tension at the center of every open-source infrastructure project: the protocol should be neutral, but someone has to pay the people who maintain it. Open source alone doesn’t fund a standards body. A VC-backed startup can fund it, but then the standard serves the VC’s interests. A foundation can fund it, but foundations need income too.

We’ve been thinking about this problem since before we shipped the first line of OpenCastor code. This post explains how we’re resolving it — not just rhetorically, but structurally.

What we built and why

OpenCastor is a robot runtime. It sits between your hardware and your AI: handling the agent harness, enforcing safety invariants (the P66 invariant), managing the RCAN v1.8 protocol stack (36 canonical message types), streaming telemetry, and running two nightly improvement loops that push directly to main when they find something better.

The whole thing is Apache 2.0. The RCAN specification is CC BY 4.0. The SDKs (rcan-py — 609 tests, rcan-ts — 447 tests) are MIT licensed. The robot client app code is open. The runtime ships with 7,827+ tests.

That’s the right call for the protocol layer. Robotics needs standards that aren’t owned by any one company — the same way the web needed HTTP and IP to be neutral. But open source doesn’t pay for the engineers who write spec v1.9, the legal work to establish the Robot Registry Foundation as a proper independent entity, or the board infrastructure to keep the RCAN Foundation genuinely neutral.

So we’re building a company around the runtime, with legal obligations that lock in the mission.

The compute insight

There was a moment earlier this year — listening to Andrej Karpathy on No Priors — where something clicked. The conversation was about what matters in an AI-native economy. Compute is the new currency. Not money, not even talent. Compute.

I kept thinking about Bob. Bob is our reference robot — a Pi 5 with a Hailo-8 NPU (26 TOPS). Bob idles around 20 hours a day. That idle time is compute that could be doing something useful. Specifically, it could be evaluating harness configurations — how aggressively the model reasons before acting, how much context it carries, when to retry a failing action, at what cost threshold to fall back to a local model.

Here’s the thing about harness candidate evaluation: it’s embarrassingly cheap to verify and expensive to compute in aggregate. One robot running one evaluation is fast. But exploring the parameter space broadly — across hardware profiles, task types, cost constraints — requires more compute than any single machine running nightly. Spread that across a fleet that’s already sitting idle, and you close the loop much faster.

That’s what we built. The nightly harness optimizer uses Gemini 2.0 Flash to generate 8 candidates, evaluates them against 30 synthetic scenarios (navigation, manipulation, multi-step reasoning, error recovery, P66 constraint handling), and ranks each by a weighted scorer: success rate (50%), P66 compliance (25%), token efficiency (15%), latency (10%). Any configuration that beats the current champion by more than 5% gets promoted. The first champion — lower_cost, dropping cost_gate_usd from $0.05 to $0.01 — scored 0.9101 against a baseline of 0.0. More aggressive cost control turned out to improve P66 compliance (fewer runaway cloud calls) without meaningfully hurting success rate. The next step: run that optimizer per hardware profile, seeded with hardware-aware candidates — your Pi 5, someone’s Jetson Orin Nano, a Pi 4 with 4 GB RAM each getting a champion tuned to their exact tier.

Your robot contributes. The fleet gets better. That’s the loop.

Castor Credits — your robot’s idle compute has real value

When Bob idles with castor contribute enabled — it’s opt-in, disabled by default — he runs harness evaluations matched to his hardware profile. Any real command preempts the evaluation within 100ms — the contribute scope sits at level 2.5 in the RCAN scope hierarchy, above chat but below control, so the robot’s primary job is always protected. That data feeds the nightly pipeline. When enough robots with a given hardware profile have submitted results, the optimizer produces a champion config for that tier and pushes it back to every matching robot.

For doing that work, Bob earns Castor Credits.

The credits system is intentionally simple:

• Castor Credits — built on the credit/reputation system defined in RCAN v1.8 — accumulate whenever your robot contributes compute to the fleet, starting with harness evaluation and expanding to other workloads (climate modeling, protein folding, biodiversity monitoring via BOINC) as the fleet grows
• Credits offset OpenCastor Pro costs — run enough evaluations and your subscription bill goes down or goes away
• Diamond tier holders participate in profit sharing once OpenCastor reaches sustainability

This isn’t a speculative token. Credits represent real work that makes the fleet measurably better. The accounting is straightforward: you donated compute, the platform got value from it, some of that value comes back to you.

We think this is the right economic model for a distributed fleet. The robots that contribute most should benefit most. And the fleet as a whole should be the thing that improves — not just our reference hardware.

Why a California Benefit Corporation

We could have just written “we promise to be good stewards of RCAN.” A lot of startups write that. It lasts until the acquisition or the funding round.

A California Benefit Corporation is a legal structure that expands fiduciary duties beyond shareholders alone — directors must consider the mission alongside financial returns, and shareholders can bring a benefit enforcement proceeding in court if the board abandons it. The mission is part of the corporation’s articles of incorporation, not just its marketing copy.

Our mission statement commits us to this:

10% of net revenue goes directly to the RCAN Foundation and the Robot Registry Foundation.

Not “we’ll donate when we’re profitable.” Not “subject to board discretion.” 10% of net revenue, to neutral foundations that we don’t control.

Both foundations are part of the answer. Right now the RCAN spec lives in continuonai/rcan-spec — fine for bootstrapping, not acceptable long-term. The spec needs a foundation with its own board, its own governance, its own annual reports — and real legal separation from OpenCastor the company. The RRN namespace needs the same.

The foundations

We’re building two organizations. Both structured as independent nonprofits with proper governance — the exact legal form (US 501(c)(3) vs 501(c)(6), Swiss foundation, or EU association) is still being determined, but the governance model is clear.

RCAN Foundation

The RCAN Foundation stewards the Robot Communication and Addressing Network protocol. That means maintaining the spec, stewarding the conformance test suite (19 machine-readable test cases across L1 addressing and audit, L2 safety gates, and L3 AI accountability), and ensuring that RCAN evolves based on technical merit rather than any single party’s roadmap.

The board is designed to be genuinely pluralistic — multi-stakeholder representation across robot manufacturers, safety standards bodies (ISO/TC 299 and A3), academic institutions, and civil society. No single constituency controls the vote. OpenCastor gets one board observer seat — we can speak, we can’t vote.

Board seat elections. Annual reports published.

Robot Registry Foundation

The Robot Registry Foundation governs the RRN (Robot Registry Number) namespace. The registry is already live at robotregistryfoundation.org — think of it as ICANN for robots, the organization that ensures rcan://registry.rcan.dev/acme/arm/v2/unit-001 — manufacturer, model, version, device ID — means something stable and unambiguous, regardless of which company made the robot or which runtime it’s running.

The RRN namespace needs to exist outside of OpenCastor’s control because OpenCastor is a company. Companies get acquired. They pivot. They go out of business. The namespace should outlast any individual company in the ecosystem.

The Robot Registry Foundation’s governance is similar: independent board, neutral governance, no single-company control.

Ecosystem independence, not ecosystem capture

We’re not building a platform where OpenCastor extracts rent from every robot transaction. We’re building the protocol and runtime layer that any robot can use, regardless of hardware manufacturer, AI model provider, or programming language (Python, Rust, Go, C++, and more).

A robot running Physical Intelligence’s π0 for manipulation and Anthropic’s Claude for reasoning should be able to run OpenCastor and speak RCAN without any artificial dependencies on our cloud or our revenue model. The RCAN spec is open. The conformance test suite is open. Safety standards say what to demonstrate; RCAN provides the plumbing that makes it demonstrable. If someone builds a better runtime that’s fully RCAN-compliant, that’s good for the ecosystem — and the B Corp structure means we’re legally bound to care about the ecosystem, not just our market share.

This isn’t altruism. It’s the right strategy for building trust with a technical community that has seen enough “open core” bait-and-switches to be skeptical of anything with a business model. The foundations are the structural commitment. The B Corp binds the company to the mission. Together they make the promise credible.

What’s next

A few concrete things happening now:

OpenCastor Pro waitlist — We’re launching the waitlist soon. Pro is earnable with Castor Credits from fleet contribution. The Pro tier funds the foundations directly via the 10% revenue commitment.

Incorporation — The California Benefit Corporation paperwork is in progress. When it’s done, the mission commitment becomes legally binding.

RCAN Foundation board formation — We’re in early contact with ISO/TC 299 WG3 (industrial robot safety standards) and beginning the broader process of identifying and recruiting the initial board. If you work in robotics policy, compliance, open source governance, academic robotics research, or ISO/IEC standards committees and are interested in a seat, reach out.

Robot Registry Foundation — The registry is already live at robotregistryfoundation.org with five robots registered: Bob (RRN-000000000001), Boston Dynamics Spot (RRN-000000000002), Unitree Go2 (RRN-000000000003), a TheRobotStudio/Hugging Face SO-ARM101 (RRN-000000000004), and Alex (RRN-000000000005). Three of the five aren’t running OpenCastor — which is the point. What it still needs is a legal entity and co-founders who understand that the governance structure of a robot registry matters as much as the technology. The EU AI Act’s high-risk AI system provisions take effect from August 2026 — a registry with legal standing is better positioned than an unincorporated project for the standards processes that follow. Once incorporated, formal legal ownership of the RRN namespace moves to the foundation.

If you’re running a robot on OpenCastor, contributing compute to the fleet, or just watching the ecosystem develop — this is what the structure looks like. Not a promise. A legal obligation.

---

OpenCastor is open source: github.com/craigm26/OpenCastor. The RCAN spec: rcan.dev. Pro waitlist and foundation board interest: opencastor.com.