How robopay works

The shape of it

   your nodes                         payment_node                     Base
 ┌─────────────┐   services/actions  ┌──────────────────────┐  RPC   ┌──────────┐
 │ task logic  │ ──────────────────▶ │ wallet (encrypted)   │ ─────▶ │ USDC     │
 │ triggers    │ ◀────────────────── │ spending caps        │        │ escrow   │
 │ perception  │   results/feedback  │ idempotency store    │ ◀───── │ contract │
 └─────────────┘                     │ resolver (background)│        └──────────┘
                                     └──────────────────────┘

payment_node is the only process that touches keys. It holds the wallet, signs internally, and exposes everything else as ROS 2 services, actions, and topics. Your nodes deal in addresses and amounts, never in keys.

Underneath the node, a pluggable backend talks to the chain. The same robot code runs against a mock, the Base Sepolia testnet, or Base mainnet by changing one parameter.

The chain carries money, the developer carries coordination

robopay deliberately splits the problem in two.

On chain: balances, transfers, and escrow state. These are public, final, and verifiable by anyone. robopay handles everything here: fees, nonces, signing, retries, confirmation.

Off chain: how robots find each other, agree on a price, and decide that a job was done. These depend on hardware and deployment, so robopay does not impose an answer. It gives you data types (invoices, escrow signatures) and an optional topic-based exchange for robots on a shared ROS network.

In practice: robopay moves the money, your application decides when.

What happens when you pay

  1. Your node calls transfer/send with an idempotency key.

  2. The node checks the spending caps. If the payment would exceed them, it is rejected before anything is signed.

  3. The payment is written to a local SQLite store as pending.

  4. The transaction is signed and broadcast. The store moves to broadcast.

  5. The service returns immediately with the transaction hash. It does not block while the network confirms.

  6. A background resolver watches broadcast payments and marks them confirmed or failed once the chain settles.

If the process dies between any two steps, the resolver picks up where it left off on restart, by checking the chain rather than guessing. Retrying a call with the same idempotency key returns the existing payment instead of sending a second one.

What happens in an escrow

  1. The payer opens an escrow: funds move from the payer’s wallet into the shared escrow contract, locked against a payee, an amount, a deadline, and a hash of the agreed terms.

  2. The payee does the work.

  3. Both robots sign a release message (EIP-712 typed data) over the escrow’s exact contents.

  4. Either robot submits both signatures. The contract checks them and pays the payee.

  5. If the deadline passes without both signatures, anyone can trigger a refund, and the payer’s resolver does so automatically.

Neither side can take the money alone. See Escrow, end to end.