Skip to content

Agents that payinside your limits.

An agent gets its own wallet, a funded budget and a key that expires. The network refuses anything past the cap.

Category
Agents
Built with
Agent SDK, MCP adapter
Agent payments
  • 8authority kinds a grant can carry, from owner to timelock
  • 16named delegates a single budget can hold
  • 1revocation bump retires every key issued before it

The problem

Most agents today borrow a card number and an API key. The spending rules live in the agent’s own code, and you learn what it spent when the statement arrives. If the code is wrong, the limit is wrong with it.

How it works on Paxeer X

On LayerX, the agent domain of Paxeer X, an agent holds its own account, with separate subaccounts for its float, its budgets, its escrows and its streams. You fund a budget with a per-period limit, an expiry and a rollover rule. Then you hand the agent a session key scoped to exactly the work it should do.

  • Budgets are checked in the kernel, on the settlement path, before any transfer settles
  • Session keys narrow by module, activity, asset, and per-activity, per-period and total caps
  • A grant can only be amended to something narrower. Any widening is refused.
  • The MCP adapter shows a model only the tools its session scope allows

The cap travels with the funds, not with the application.

The outcome

An agent cannot spend past its allowance, even when its own code misbehaves. Unspent allowance lapses or carries forward up to a cap you choose. One revocation bump invalidates every grant issued under the old sequence, and every spend returns a signed receipt you can verify.

“A session key is a strict subset of the owner’s authority, with an expiry attached.”

From the LayerX specification, session keys and grants

Build the next one.

The limited beta is open to approved developers. Tell us what you are building and we will get you an allocation.