Giving Software a Mandate, Not a Wallet
Payment infrastructure has always assumed that a person or an institution stands behind each transaction. Cards are issued to people, accounts are opened by organisations, and approval workflows exist because somebody eventually approves.
Software is now beginning to participate directly. Agents request resources, encounter a price, settle it, and continue with their work.
These payments are small and numerous. An agent might pay a fraction of a penny for an API call or a few cents for a document, hundreds of times in an hour, and that shape does not fit the instruments available. A card authorisation costs more to process than the payment is worth. A subscription means buying a bundle in advance and hoping it matches what is consumed. A prepaid balance means capital parked with every supplier and watched so nothing stalls when it empties.
Each works around the same underlying problem: conventional payment rails were never built to carry amounts this small, this often.
The x402 protocol addresses that directly, allowing payment to be requested and settled within an ordinary web request using the HTTP 402 Payment Required status code. In July, the Linux Foundation confirmed the operational launch of the x402 Foundation as an open governance body for the protocol, with around forty organisations participating. INFTF has joined as an Associate member, because machine payments require common rails and fragmentation at this layer would be inherited by everyone who builds above it.
But a payment protocol settles how a payment is made. It does not settle whether it should be made at all.
That question belongs to the blockchain, and it is the question that will determine whether institutions are willing to deploy any of this at scale. The Xahau Network was conceived around it, attaching programmable spending rules to the account that holds the value rather than to a separate address. That one structural choice is what makes a mandate expressible at all.
The problem a payment protocol cannot solve
Under x402, the seller states the amount and the destination. The buyer’s software decides whether to pay.
In most implementations, the limits on that decision live inside the same software that makes the decision. The agent checks its own spending against its own configuration.
This is not a strong final control. It fails if the code is modified, if the configuration is changed, if another program is pointed at the same wallet, or if somebody raises a limit to unblock a task and forgets to restore it.
Organisations do not delegate money this way anywhere else. Employees hold corporate cards, departments hold budgets, suppliers collect under direct debit mandates, and subsidiaries transact within limits set by a parent company. None of these arrangements depends on the spender restraining themselves. The authority is bounded at the point it is granted, by systems the spender does not control.
The mandate is a foundational instrument of commercial finance, letting an organisation distribute spending capability widely without distributing control of its accounts. But those instruments were designed for payments large enough to carry their own overhead, and none reaches a fraction of a penny, which is precisely where agents operate.
Autonomous software needs the same instrument, and whether a blockchain can provide one depends on something structural about how that network was built. Xahau was built with that structure from the start; to see why it matters, it helps to look at what the alternatives ask of you.
Three broad architectural models
For the purposes of this discussion, it is useful to distinguish three broad architectural models according to where programmable logic sits in relation to the value. These are not a formal taxonomy, and many networks combine characteristics of more than one, but the distinction helps in locating where a spending mandate can be expressed.
The first model provides a fixed set of built-in behaviours. The network defines what a transaction can do, and an account holder selects from that set rather than extending it. Some networks following this model are deliberately minimal; others are extremely capable, offering escrow, payment channels, multi-signature quorums, deposit controls and native asset issuance. These are substantial features, carefully designed, covering a great deal of genuine financial activity.
What they do not compose into is a mandate. Multi-signature rules govern who must approve a transaction, not how much may be spent. Escrow commits a specific amount against a specific condition. A payment channel is pre-funded and points at a single counterparty. None expresses a revolving allowance that a delegate may draw against, adjustable and revocable by the account holder, and such an allowance is not generally available on these networks without adding new protocol functionality.
The second model places programmability at a separate address. This is the dominant one. A contract is itself an account, holding assets and applying logic when releasing them, and the majority of applications built on public networks rest upon it.
But consider what it requires of an organisation that wants a spending rule. The assets must be moved into the contract, which thereafter holds them. The original account continues to function, and whatever remains in it can be transferred with no rule applied, because an ordinary transfer never reaches the contract.
The rule protects a location rather than an owner. Account abstraction narrows this considerably, but a smart account remains a different kind of account, adopted deliberately, rather than a property added to the account an organisation already has.
The third model attaches programmable logic to the account itself, and it is the model Xahau was designed around. Rules travel with the account holding the value and apply to the transactions that account takes part in. Xahau is a production implementation and has operated this way since its earliest days. Its own network governance and reward distribution run on the same mechanism, on the same terms as anyone else’s.
The assets are not transferred into a separate, program-controlled account for the rule to apply. Payments still move value, as payments must, but they leave from the account that already held it. While the rules remain installed, ordinary transactions from that account cannot bypass them, because the rules run on whatever that account does rather than waiting at a separate address funds must be routed through. The same account holds the balance and the mandate.
In the second model, obtaining a spending rule means surrendering possession to a program; in the third, possession is retained and permission granted against it.
The former relocates the assets; the latter leaves them where they are, which is closer to how delegated spending is normally arranged. A company issuing corporate cards sets limits on each card without first moving its balances into a separately controlled account for the purpose.
The direction of travel
These models describe where networks are today rather than where they are fixed. Several established networks have set out roadmaps that move towards the third, and account abstraction is being pursued elsewhere with related intent.
We read this as a common conclusion being reached across the industry rather than as a contest. That others are moving at all suggests the requirement is real and general rather than the preference of any single design. For an organisation making decisions this year, though, the question is what is available and proven now, and on Xahau this is not a roadmap item.
One account, many agents
The practical form this takes on Xahau is straightforward. An organisation holds value in a single account, and recorded against it is a list of the agents permitted to draw on that account and what each may spend. Every agent holds an account of its own containing almost nothing.
When an agent needs to pay, it does not sign the payment. It asks. The funded account evaluates the request against that agent’s limits and either declines it or pays.
The agent is never given the account holding the money, nor any credential controlling it. Its authority is a permission recorded on-chain, granted and revocable by the operator.
The operational consequences follow immediately. Twenty agents require one funded account and twenty inexpensive ones, rather than twenty separately funded and configured accounts. Limits are set in a single place, and granting an agent its authority is an entry in a list.
Limits in the currency the business actually uses
A limit denominated in a network’s native token is a limit in a floating exchange rate, meaning one thing this quarter and something else the next, which is no basis for a mandate.
On Xahau, limits can be denominated in issued currencies. A mandate of two cents per request and five dollars a day is enforced as those amounts, on the dollar-denominated asset the business already holds, and held as decimal values, so two cents is two cents rather than an approximation to be rounded.
At this scale the second figure carries most of the weight. A ceiling of two cents prevents little on its own, because the risk is not one large payment but a great many small ones. What bounds the exposure is the daily total, and a running total that resets on a schedule is precisely the kind of rule a fixed set of built-in behaviours does not generally provide without new protocol functionality.
A mandate can go further and specify whose currency may be spent. On Xahau, an issued currency is identified by both its issuer and its currency code, so a dollar from one issuer is a different asset from a dollar issued by another. An organisation can authorise its agents to spend a particular partner’s currency and decline superficially similar assets, so the permission recorded on-chain reflects the counterparties it has actually approved. Correspondent relationships are how regulated finance already works.
What failure costs
If an agent is compromised, an attacker acquires that agent’s remaining allowance. They do not acquire the balance of the funded account, and they cannot alter the mandate, because the agent was never given the means to do either. Exposure is bounded by what was already authorised, which at these amounts is the remainder of a daily allowance in single-figure dollars. For an organisation deciding whether to let software transact unattended, that is the difference between an incident and a loss.
Withdrawal of authority is equally direct. Removing an agent from the permitted list stops it spending, with no credentials rotated and no funds moved.
A public record of what each agent did
Every request an agent makes is recorded on-chain under its own identity. The permissions granted to it, and the transactions made under them, are therefore on the record rather than only in a log maintained by the party being examined. Auditors and counterparties can establish from the same source what an on-chain permission allowed and what was spent under it.
This covers what happened on-chain rather than the organisational intent behind it, and does not by itself constitute a compliance record. It does provide an independent reference point for the on-chain part, which is likely to matter more as regulatory attention turns towards autonomous systems.
Beyond agents
Autonomous payments make the problem impossible to ignore, because software spending without supervision forces an organisation to state precisely what it has authorised. The requirement is not peculiar to agents, though. Departments require budgets, subsidiaries require limits, and processors and marketplaces act with delegated authority on behalf of others. Each of those relationships is presently administered through contracts and reconciliation rather than by the infrastructure carrying the value. Where the blockchain expresses the mandate directly, part of that overhead shifts onto the ledger.
Why we are engaged
Low transaction costs are what make payments of this size possible at all, and that much is now widely available. But cost only determines whether a payment can be made, not whether it should have been.
x402 will succeed as a standard to the extent that organisations are willing to put real money behind it, in volume and without supervision. That willingness will turn on whether they can state, precisely and verifiably, what their software is permitted to spend.
x402 governs the exchange. The agent decides what it wants. The account decides what is allowed.
Networks following the first model do not presently provide a native mechanism for that third question. Those following the second can address it, provided an organisation is willing to move its assets into a program-controlled account. Those following the third address it where the money already sits. That is why we advocate Xahau’s approach, and why we are participating in the Foundation as the standard develops.
The immediate applications of machine payments are easy enough to imagine. The more interesting question is what organisations will build once extending spending authority to software carries the confidence of extending it to people.