Imagine a delivery robot running low on power. It checks nearby charging services, compares prices, pays and gets back to work. Nobody takes out a phone.
It is easy to describe this as “a machine with a wallet.” But a wallet only addresses how money moves. It does not tell us whose money it is, what it may buy or who seeks redress when the service is not delivered.
What a machine economy really needs is authority to act on someone’s behalf that has limits, can be revoked and carries accountability. Payment is only one part.
If we mistake an address for a complete commercial entity, automation may outrun authorization.
When machines execute economic decisions, who bears the consequences?
A robot can buy energy, parts or other machines’ services on an operator’s behalf. This technical agency does not automatically give it independent legal personhood, or make the people and organizations behind it disappear.
Authorization needs to be more specific than “allowed to pay”: which providers may it buy from, which items may it purchase, when and where may it act, what is the cumulative budget, and which situations require further approval?
Permission to buy charging does not imply permission to buy a long-term membership. Permission for an emergency repair does not imply permission to replace an expensive component. A per-transaction limit is not enough either: many small purchases can still consume substantial funds.
I suggest connecting task authorization with spending authority. A machine should identify the approved work a purchase serves, and lose the relevant permissions when the task ends, the equipment changes hands or an anomaly occurs. Autonomy then has a scope that can be checked.
People do not have to approve every transaction. Low-risk, clearly repetitive purchases can happen automatically. Decisions beyond the agreed scope go to someone authorized to bear the consequences.
A successful payment is not a completed job
Existing technical work already reflects these layers. Fabric’s RoboPay documentation separates payment verification, request routing and execution, explicitly leaving final safety control with the robot controller. Receiving a valid payment does not mean a machine should move unconditionally.Official RoboPay documentation
This is a technical design description, not evidence of widespread commercial adoption. It does, however, clarify an important distinction: permission for a transaction and suitability of an action are different judgments.
A third judgment is needed too: was the agreed work completed? The charging station received payment—but did the robot receive the service? The handling fee was charged—but did the goods reach the correct location? Payment records alone cannot answer those questions.
With on-chain settlement, real-world data still needs a route into the system. Ethereum’s oracle documentation addresses precisely this connection to off-chain information. A record’s resistance to tampering does not automatically make the original input true.Ethereum oracle documentation
A reliable machine transaction must therefore connect identity, authorization, payment, action safety and acceptance of the work. Any layer can fail, and each needs an appropriate response.
Machines need ways to resolve disputes too
Automation looks most complete along its ideal path: request, payment, execution, completion. Commercial relationships are often tested when things depart from that path.
How do we prevent duplicate payments when a device reconnects and repeats a request? How is payment settled when some service has been delivered and the rest fails? If the price changes while the robot waits, does the original authorization still hold? If a provider reports completion but the customer’s sensors disagree, who decides?
These are not arguments for unlimited complexity. They are reasons to limit the scope of transactions in advance. Start with services that are measurable, easy to verify and inexpensive to dispute, then expand gradually.
Refunds, escrow, later reconciliation and human arbitration are all possible options. None suits every setting. Immediate settlement reduces some waiting costs, but may also leave less room to correct mistakes. Designers need to state the trade-offs they have chosen.
Stolen keys and compromised device permissions matter too. Revoking future authority, isolating abnormal devices and limiting cumulative spending are as important as securing payment credentials. Whether completed transactions can be recovered depends on the payment channel and arrangements. There is no universal “undo” button to promise.
Why would this require a new currency?
This returns us to the second essay’s question: could Physical AI produce an important new asset? Machine payments provide a possible use case, not an answer.
Conventional accounts, payment interfaces, prepaid credits, stablecoins and native network tokens can each form part of different designs. Settlement across organizations, open access and automated execution may favor some approaches. Custody, conversion, governance and compliance arrangements can add costs too.
One possible architecture is an operator-held account with restricted payment credentials and a device-level ledger. It need not treat the robot as an independent account holder, and it does not require a new currency. The test should be what the new mechanism solves that existing approaches cannot readily address.
Proken must meet the same test. If it measures accepted work, it should help both parties verify performance. If it represents service credits, the redemption terms need to be clear. If it becomes a transferable network asset, holders need to know exactly what rights they receive.
More machine transactions do not necessarily make a particular token more valuable. Work performed, services paid for and asset value still need an institutional connection that can be explained. A useful network might settle mainly through instruments with stable prices.
Good autonomy means fewer manual steps, while people remain in control
The strongest objection is that overly detailed permissions will leave machines waiting on every small decision, defeating real-time coordination. Tiered authorization is a better response than choosing between complete freedom and approval for every payment.
Begin with a limited set of merchants, a clearly defined service and an expiration date, then adjust the scope based on performance. Monitor unusual spending, task completion, dispute resolution and human intervention—not just the number of wallets created.
Operators must also be able to understand the authorization. If an interface shows only complex addresses and protocol terminology, formal consent offers little practical control. An ordinary manager should be able to answer: how much can this machine spend today, on which task, and when will it stop to ask me?
The more autonomous Physical AI becomes, the clearer its governance interface needs to be. We want machines to handle repetitive transactions while people still understand which decisions they have delegated.
How much freedom would you give a robot to spend automatically: only on specified services, or choosing for itself within a budget? Which purchases must it ask you about first?