Open Robot Economy
An open source ROS 2 package that lets one robot pay another. Wallets, escrow, payment requests and sensor-triggered settlement, exposed as ordinary ROS 2 primitives so a machine can hold up its end of a deal without a human in the loop.
- Package
- robopay, native rclpy API
- Primitives
- Wallets, escrow, requests, conditions
- Networks
- Runs on testnet and on mainnet
- Licence
- MIT
The step that still needs a human
A robot can plan a route, drive it, dock and hand over a parcel with nobody watching. It cannot pay for the electricity it used on the way, or charge for the delivery it just made. That step still goes through a person, an account and a settlement delay.
robopay allows each robot to get a wallet it controls, and a way to move value that is triggered by the same things the rest of its stack already reacts to: a topic, a service response, a sensor reading.
Payments as ROS 2 nodes
The design constraint I set was that nothing should feel bolted on. A roboticist who already knows nodes, topics and callbacks should be able to add a payment to a stack without learning a payments SDK.
Each robot runs a small set of cooperating nodes. The wallet holds the keypair and the balance. The policy guard enforces the limits their operator set: spending caps, allowed counterparties, ceilings per transaction. The condition watcher is the piece that makes this robotics rather than finance, subscribing to ordinary ROS 2 topics and services and releasing money when the world says the work happened.
Money that waits for proof
Two machines that have never met do not trust each other, and there is no dispute desk to call. Escrow removes the need for trust: the payer commits the funds up front, and they only move when a condition the payer specified is satisfied.
The failure case is the one that matters, and it is handled by construction. If the parcel is never scanned, if the dock is never reached, the condition never fires, the escrow expires and the funds return to the payer automatically. Nobody has to notice, chase or arbitrate. Every release produces a signed receipt, so an operator has an auditable record of what their fleet spent and against which physical event.
A balance a robot earns on Monday has to still buy the same charge on Friday, otherwise every spending policy you write has to model an exchange rate as well. Settling in a dollar stablecoin keeps that variable out of the control problem entirely, which is the only reason the asset choice matters here.
Why I think this matters
The library is the engineering. The reasoning behind it is an essay I wrote in September 2026, and the running demos live on the project site.
Why software agents crossed this line first, why robots follow, and what an economy of such machines would mean for growth and for the cost of living.
Read the essay