Skip to main content

Pay-to-Actuate

How do you take payment for a physical thing without a merchant account, a card terminal, or a centralized processor — and prove you delivered?

The classic answer requires three trusted middlemen: an acquirer, a payment processor, and a fulfilment workflow. Each takes a cut. Each can refuse you. None can be inspected by the customer. Pay-to-actuate collapses the stack into four moves: a QR code on a wall, a wallet in a pocket, a smart-contract account on a public chain, and a small computer wired to a motor.

The Loop​

HUMAN scans QR             →  signs intent (the QR is the tap)
WALLET submits transaction →  on-chain receipt of payment
PROGRAM flips state         →  Boolean / counter / struct
DEVICE listens via WS       →  actuates motor / valve / lock
DEVICE writes back receipt  →  on-chain proof of delivery

Five steps, two receipts, zero merchants. The first receipt proves the customer paid. The second receipt proves the device delivered. Both live on a public ledger that neither party owns.

The QR Code Is the Tap​

When a human taps a card, the tap is the consent. When an agent or a poster on a wall takes a payment, the consent has to be reconstructed somehow. A static printed QR with a pay-flow embedded is enough. The wallet does a GET to the URL, displays the merchant name + icon, and the human signs.

The wallet POSTs the signed transaction back. The URL composes the right instruction (pay, switch on, dispense, unlock) and returns the transaction shape. The wallet relays it to the chain. From the device's perspective, the only thing it ever does is listen for a state change.

The device never exposes a network port. It only watches.

Two Circuits, One Trigger​

Hardware lesson worth keeping. A general-purpose I/O pin on a small board carries about 3.3 volts — enough to light an LED, not enough to spin a motor or release a solenoid. The pattern that solves this generalises beyond hardware:

  • A low-current trigger (the GPIO pin, or the on-chain state flip)
  • Controls a high-current path (the motor circuit, or the real-world fulfilment)
  • Through a switch that isolates them (the transistor, or the listener daemon)

You'd never wire a 12V motor directly to a 3.3V control line. You'd never let a customer's payment intent drive a fulfilment action without a gate. The same principle in two domains.

Listen Don't Accept​

The device subscribes to the on-chain account that represents its state. It does not open an inbound port. It does not run a public API. It does not accept commands from an app. If the chain says "switch on", the device switches on. Otherwise nothing happens.

This collapses the attack surface to a single question: who can pay? Anyone with the QR code can. The same authority that lets them pay is the only authority that triggers the device. There is no admin override, no merchant key, no out-of-band protocol.

If you want gated access, gate the chain — require an NFT, require a signed credential, require a budget delegation. The device is downstream of all of that.

The Return Receipt​

Most pay-flows stop after payment confirms. The customer can prove they paid. The merchant can prove they were paid. Neither can prove the goods showed up.

Pay-to-actuate fixes this by having the device write a receipt back on chain after it actuates. A vending example: the customer pays, the motor turns, a limit switch triggers when the product drops, the device signs a transaction saying delivered. The customer's wallet can show "delivered" with the same cryptographic weight as "paid".

This is the missing half of agentic commerce. The customer's intent is on chain. The device's delivery should be too. Without the return leg you have a one-sided loop — and one-sided loops produce disputes.

What This Unlocks​

  • Vending machines that take any wallet, anywhere, with no merchant account
  • Pour bars where the receipt names the drink and the volume
  • Door locks that open when you hold the right token or have the right delegation
  • Geocaches that gate physical prizes behind a small payment
  • Sensors that publish readings directly into a smart-contract account — air quality, moisture, temperature, sound — making the device both a payment endpoint and a verifiable data source
  • Hardware wallets built from cheap microcontrollers, putting key management on a dedicated device for far less than a commercial alternative

The bill of materials for a working demo is a single-board computer, a transistor, a resistor, a motor, and a few cents of network fees. The cheapest possible commerce loop. The pattern doesn't care which chain — any chain with low fees, account subscription, and a wallet-friendly transaction request format will do.

Where This Sits​

Pay-to-actuate is a concrete instance of the layered intent → action → receipt model that Verifiable Intent describes abstractly. The human's payment is the L2 intent. The device's actuation is the L3 action. The on-chain return receipt is the proof that L3 stayed inside L2.

It's also the smallest demonstrable case of a Validated Virtuous Feedback Loop running on commerce rails — every payment compiles to a delivery, every delivery compiles to a receipt, every receipt compounds trust for the next payment. No middleman owns the trust; the chain proves the loop.

Design Principles​

  • The QR scan is the tap. Don't reinvent a card terminal.
  • Listen to state, never accept commands. No inbound port on the device.
  • Two circuits, one trigger. Always isolate the small signal from the big action.
  • Write the return receipt. Without it, commerce is one-sided.
  • Static signage beats live UI. A printed QR keeps working when the app changes.

Open Problems​

  • How does the device prove its identity to the chain, so a counterfeit cannot sign a delivery receipt for a real one? Hardware roots of trust become important.
  • What latency budget is acceptable per vertical — vending is forgiving, lock-opening less so, livestream-triggered actions least?
  • At what unit price does on-chain pay-to-actuate beat a traditional card terminal on margin, once you include fees and reliability cost? The crossover point matters for any operator deciding which path to wire.

Source​

Pattern distilled from a working Solana + Raspberry Pi reference rig published in the Solana developers DePIN examples. Variants in that repo cover a bar with a 5V pump, an air-quality sensor that writes readings on chain, a transactions-per-second tracker, and a microcontroller hardware wallet — each a different cut of the same five-step loop.

For the Solana-specific recipe — GPIO mapping for Pi 5, Anchor program shape, Solana Pay QR generation, ngrok / Vercel exposure, motor wiring through an NPN transistor — see Solana DePIN Programs. The same loop ports to any chain with low fees, account-change subscriptions, and a wallet-friendly transaction request format.