Software needs a wallet of its own

Software already does a great deal of buying on our behalf. It searches, compares, books and calls paid services. Then the moment comes to pay, and it borrows. It borrows a card number that belongs to a person, or an API key tied to one company’s monthly invoice.

That arrangement holds up in a demo. It breaks when an agent makes thousands of small purchases a day from services it found an hour ago.

The tools we have assume a person at the keyboard

Almost every payment system in use today assumes someone is present to approve each purchase. The controls reflect that assumption.

• A card cannot be told to spend at most a fixed amount per day with one vendor and nothing after Friday.
• An invoice cannot sensibly settle a payment worth a fraction of a cent.
• An API key, once leaked, is a blank check against whatever account stands behind it.
• When money does move, the buyer rarely holds proof it can check, and the seller rarely knows the payment is good until a statement arrives.

None of these are failures of the tools. They were built for a different user. Software that transacts on its own needs controls that do not depend on the software behaving well.

A wallet with limits, not a borrowed card

Paxeer X starts from the opposite assumption. A program will do business by itself, many times a day, and the person who owns it wants to stay in charge without approving every transaction.

So the network gives software a wallet of its own. In LayerX, the agent domain of Paxeer X, every agent holds typed accounts derived from readable names: a main account, budget accounts, escrow accounts, stream accounts and margin accounts. A balance always carries its purpose in its address. An agent’s operating float, a budget, a held escrow and a margin posting are separate accounts, not one pooled balance.

The person who funds the agent writes the rules once:

• A budget with a period cap. Funds sit in a dedicated budget account with a per-period limit, a period length, an expiry and a rollover policy. Up to 16 named delegates may spend from it.
• A session key with a narrow grant. The key works only for the modules, assets and amounts the grant names, and only between two timestamps.
• Escrow and streams for larger work. Money can be held until delivery, with a named arbiter, or paid out continuously as a job runs.

Enforced by the network, not by the agent

The difference that matters is where the rules live. A limit written into the agent’s own code can be skipped by a bug, a bad prompt or a stolen key. A limit held by the network cannot.

On Paxeer X, a budget spend is checked in the LayerX kernel against both the remaining period allowance and the funded balance before any transfer settles. A spend above the allowance is refused with a specific error. A spend above the funded balance is refused with another. Nothing moves in either case.

Session keys follow the same principle. A session key is a strict subset of its owner’s authority with an expiry attached. A compromised agent process cannot exceed what its grant allowed and cannot outlive the grant’s window. When the owner wants to end the arrangement, revocation invalidates the grants issued under the old revocation sequence, and the next activity the agent attempts fails.

The damage from a compromised agent is capped at the limit a person wrote, not at the balance of the account behind it.

A receipt for every move

Control is half the problem. The other half is knowing what happened.

Every activity in LayerX returns a receipt signed by the sequencer. It records the result, the state root before and after, the effects produced, the fee charged and the batch it landed in. Anyone holding that receipt can check the signature and the state roots offline, without trusting the node that served it. Checkpoints covering those receipts settle on the Paxeer X chain.

For the owner, that means the agent can be reconciled the way a bank account is reconciled. Every line has evidence behind it.

Why this belongs in the network

It would be possible to assemble something similar from parts: a chain wallet for assets, a payments provider for billing, a vault for API keys, and glue code holding them together. Each part would keep its own balance, its own credentials and its own idea of when a payment is done.

Paxeer X puts these functions in one network. Limits, payments, receipts and settlement come from the same ledger. A limit cannot be bypassed by paying through another rail, because there is no other rail. A receipt cannot disagree with the balance, because both come from the same state.

Not only for AI agents

Agents are the clearest case because they make many small decisions quickly. The same model serves a billing system, a marketplace or a trading desk. Any service, script or app can hold a wallet, pay per request and keep receipts, under rules a person set in advance.

That is the thesis behind Paxeer X. Software should be able to earn, spend and prove what it did. A person should decide how far it can go.

The network is in a limited beta on mainnet, with approved developers receiving allocations from the team. The documentation covers budgets, session keys and receipts in depth.