Robonomics wants ESP32 sensors to sign Polkadot transactions on their own
Serguey Asael Shinder2 min readRobonomics, a Polkadot parachain aimed at the internet of things, has asked the community for feedback on a design that would let very small devices build and sign complete transactions by themselves. Its sensors are ESP32 microcontroller boards, some of them reachable only by LoRa radio. The post, by the project's software architect, was published on the Polkadot Forum on 25 September.
The difficulty, as the post puts it, is not signing or reaching a node; it is the precise layout of each call, which on Polkadot can change with any runtime upgrade. Full clients learn it by reading the runtime's metadata at run time; a microcontroller cannot. So the plan moves that knowledge to build time, in three steps. First, the repository that holds the runtime would ship a prepared listing of all its pallets, calls and types, including Robonomics' own transaction extension that decides who pays fees, generated from metadata a single time at crate build; anything that cannot be captured precisely stops the build rather than being guessed. Second, a separate generator writes C code only for the calls a given firmware uses. Third, each firmware gets a fingerprint of the calls it relies on, so after a runtime upgrade the team can tell which devices are still compatible - a device that only logs readings should not need a reflash when some unrelated pallet is modified.
Only the preparation step is merged: runtime metadata has been moved into its own crate. The rest is design, tracked in three GitHub issues, with no code yet. The post asks whether anyone has already published such a description for no_std or non-Rust clients. Two days later the team separately showed a demo of Robonomics reached through a light client with no public RPC endpoints.
What it means
Upgradeable runtimes are one of Polkadot's strengths and one of its costs for constrained clients: a chain that can change its own call formats is a moving target for firmware that cannot be updated easily in the field. Compiling the description in and fingerprinting what each device depends on is a way to turn "did the upgrade break my sensors?" into a question with a mechanical answer.
It is a proposal, not a shipped feature. The interesting outcome would be a shared, published runtime description that other embedded and non-Rust clients could reuse - which is exactly what the post is asking for.