Robonomics 5.0: a runtime-only repo on polkadot-omni-node, and a resource model for cyber-physical systems

Tech Talk
1

Hi all — EnsRationis, software architect at Robonomics (parachain on Polkadot, previously also on Kusama).

This summer we started Robonomics 5.0: moving from “a parachain with robotics pallets attached” to an infrastructure protocol for cyber-physical systems. The first step shipped on 15 September as release 50 “Runtime-First”. Full write-up: Robonomics 5.0, part one

A few things in it that may be useful to other parachain teams, plus some questions at the end.

1. Runtime-only repository, generic omni-node for collators

airalab/robonomics now contains only the runtime, pallets, chain specs and upgrades. bin/ and tools/ are gone; the node and service tooling moved to airalab/robins. Collators run the generic polkadot-omni-node driven by a chain spec; what remains on our side is a thin binary built on polkadot-omni-node-lib. Net effect on the workspace: −21k / +2.5k lines.

2. Chain specs as a dependency-free crate

chains/ became a chain-spec crate exposing the raw Kusama and Polkadot specs as &'static str constants, with an empty [dependencies] section. Downstream tooling depends on it instead of vendoring JSON. Pallets, runtime, subxt-api and chain-spec are all published to crates.io.

3. Cleanup

RemovePallet<TeleportXRT> and RemovePallet<ClaimXRT> single-block migrations purge storage of two retired pallets; completed Cumulus / XCMP-queue migrations were dropped, only MigrateToLatestXcmVersion stays. spec_version 43 → 50.

Status: runtime 50 is built and published but not enacted yet — live chains run 43 (Polkadot) and 42 (Kusama, deprecated). Our first milestone is replacing Sudo with governance.

4. The 5.0 model

The architecture is in docs/robonomics-5.0-roadmap.md. In short:

  • CPS — a tree of nodes with permanent ids and parents (device → floor → building); on-chain state is topology plus a small current state, not time series.
  • Scope — a boundary with an owner and budgets; authority and budgets do not cross it.
  • Access — separate grants: Write, Transaction, Storage, Compute, CreateScope.
  • Subscription — per-account resource entitlement (locked XRT via RWS or auction).
  • Storage (planned on Bulletin Chain), Compute (off-chain, RISC Zero proofs), Policy (which proof may update which node, with replay guards).

The part we’d most like feedback on is fees. There is no second price list: transactions are priced in XRT at the ordinary rate, and the only choice is the payer — the signer’s balance, the signer’s subscription, or the subscription of the Scope owner (requires the Transaction grant in that Scope). That lets a fleet of devices sign transactions without holding tokens: they sign, the owner pays.

Storage and Compute have no code yet — this is the plan, not a status report.

Questions

  1. Teams already running collators on polkadot-omni-node: anything that bit you in production (upgrades, telemetry, custom RPC)?
  2. Has anyone built a “third party pays the fee” scheme at the transaction-extension level? How did you handle weight and failed-payment edge cases?
  3. Anyone planning to use Bulletin Chain for device data? We’d be glad to compare notes.

Part two (connectivity layer: protobuf envelopes, LoRa/Meshtastic transport) is coming next — happy to post it here too.

3 Likes