A new field demonstration by developer MrBen (Palmer) shows small robotic cars responding to BSV Blockchain micropayments transmitted from a handheld radio device without an internet connection.
The experiment extends Palmer’s earlier payment-controlled robotics work by combining local wallet signing, LoRa radio communication, and payment verification performed by the receiving machines themselves.
In the October demonstration, the operator sends a payment associated with a movement command. A radio relay forwards the transaction information to the network and the robotic cars, which check the payment before deciding whether to execute the requested movement.
One car demonstrates an additional capability: it recognizes a valid payment but refuses an instruction that violates its own programmed operating rule.
From Web-Based Control to Radio Payments
BSV TIMES previously covered Palmer’s robotic-car experiments in its August 14 Today’s Community Picks.
That demonstration, presented during the August Metanet Meetup, connected individual wheel movements with BSV Blockchain micropayments. It also showed how a web-based application could allow a person or an AI system to control the vehicle without requiring the user to manage a wallet directly.
The earlier work illustrated the use of BRC-105 payment mechanisms to connect a service request with a physical action.
The October field test introduces a different communication arrangement.
Palmer uses a handheld device with its own wallet and private key. The key is generated and retained on the device, which signs payment transactions locally and transmits them using LoRa, a long-range radio communication technology.
An internet-connected relay receives the radio messages, forwards the transactions to BSV Blockchain, and passes the relevant payment information to the cars.
The handset itself does not need an internet or cellular connection. The arrangement still depends on a relay with network access, but the device holding the private key can operate separately from that connection.
Payment Verification Inside the Machines
The receiving cars do more than respond to commands from a remote controller.
According to Palmer, each car uses an inexpensive onboard chip to examine the payment information and verify the relevant cryptographic signatures before allowing its motor to operate.
He reports that the verification takes approximately one-tenth of a second and does not require an application server to tell the machine whether the payment is acceptable.
The design separates communication, payment verification, and physical action.
The radio system transports the instructions and transaction information. The blockchain provides the underlying payment records. The receiving machine evaluates the evidence and applies its own operating conditions before acting.
This is significant for devices that need to sell small amounts of work or services without relying on a centralized controller to authorize every action.
The demonstration remains experimental, and the reported verification performance has not been independently benchmarked for this field setup.
A Machine That Can Refuse a Valid Payment
One of the most distinctive parts of the experiment concerns a robot identified as Car 5.
Palmer programmed the car with a restriction: it must never turn right.
During the demonstration, he sent a payment requesting a right turn. According to his account, the car accepted the payment as valid but refused to perform the prohibited movement.
The video shows the experiment as part of the broader sequence of payment-controlled robot activity.
The distinction is between verifying a payment and authorizing an action. A machine may recognize valid payment evidence while still enforcing separate restrictions on what it is permitted to do.
Palmer also reports that the refused payment remains recorded on BSV Blockchain.
That behavior raises a practical question for future commercial implementations: whether a rejected instruction should still incur a charge, trigger a refund, or be prevented from reaching the payment stage.
In this prototype, the refusal demonstrates that the machine’s operating rules remain separate from the validity of the payment itself.
Micropayment Costs and Field-Test Limitations
Palmer reports that each movement command cost 130 satoshis, including the BSV Blockchain transaction fee.
A satoshi is one hundred-millionth of a BSV token. Such small payment units allow developers to experiment with charging for individual machine actions rather than collecting payment for a larger session or service package.
Potential applications include brief motor operations, sensor readings, small quantities of computing resources, or other narrowly defined services.
The developer also documented limitations encountered during the field test.
One refused payment reached the blockchain network later than intended because the handset stopped retransmitting the radio message too early. Another car failed to receive a right-turn command for the same reason. A vehicle also became stuck on a physical obstruction during the demonstration.
These issues show that successful payment verification is only one component of a functioning system. Radio reliability, message delivery, physical operation, and recovery from failures remain important engineering requirements.
The cars’ reported ability to act after checking a payment should also be distinguished from final blockchain confirmation. Local acceptance of transaction evidence does not necessarily establish that settlement has become irreversible.
Toward Payment-Controlled Machine Services
The October demonstration combines several components that have been explored separately in BSV Blockchain development: small-value payments, locally held private keys, lightweight verification, and communication between devices.
Its particular contribution is bringing those components into a physical experiment where payment information influences what a machine does.
The receiving cars are not merely displaying transaction notifications. They use payment checks as part of their decision to perform a service, while retaining independent operational restrictions.
This remains a human-initiated payment demonstration rather than a fully autonomous machine-to-machine marketplace. Nevertheless, it illustrates an architecture in which connected devices could provide services in small increments, verify payment evidence locally, and record the associated transactions on public blockchain infrastructure.
The broader opportunity extends beyond robotic vehicles. Similar arrangements could support equipment, sensors, automated services, and other machines whose work can be measured and charged in small units.
The significance of the field test lies in the combination of a low-cost physical device, payment verification, and enforceable local operating conditions—not simply in the use of radio communication.
Developer Context
MrBen (Palmer), publicly active as @71Nous, has been experimenting with BSV Blockchain micropayments, lightweight transaction verification, and robotic devices.
His earlier demonstrations included web-based robot control and BRC-105 payment integration, covered by BSV TIMES in August 2026.
The October field test extends that work to LoRa-connected payment transmission and local verification by multiple robotic cars. The developer has published video demonstrations and technical explanations, while describing the current work as an early field test.
Palmer has also published the source code for the radio-based machine-payment system on BSV Blockchain, describing it as a collection of individually readable transaction records. According to the developer, the robotic-car code is released into the public domain, while the radio modules use the GPL-3 license. This provides additional material for examining the experimental implementation beyond the video demonstrations.
Source Links
MrBen (Palmer) — Radio-Based Robot-Car Field Test
BSV TIMES — Today’s Community Picks, August 14, 2026
MrBen (Palmer) — On-chain source-code announcement
BSV TIMES – Under the Surface
Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.
Posted on October 20, 2026 (UTC)
Leave a Reply