Check and reserve land in one atomic step
NEAR runs a call as one step until its first promise. Purser checks the budget and reserves inside that step, so two requests can't both pass.
Give AI agents money without giving them the keys.
Purser is a spending limit AI agents can't talk their way around. It lives in a NEAR contract, and every payment has to clear it.
Hackathon build, NEAR testnet only. Read what it won't do.
completed + outstanding <= budget
NEAR TESTNET / SECURITY, SWARMS, AGENTS
purser.demo.arjuna-purser.testnet ->
A spending limit inside the agent is only a suggestion.
Agents are starting to buy data, compute and API access. Today's controls break in three places.
-
The limit
The limit lives with the spender.
A bug, a jailbreak or a bad tool walks straight past a cap in a config file.
-
The balance
Two agents read the same balance.
Both see enough, so both spend. A deliberately naive baseline, on NEAR testnet:
120 / cap 100
Each agent saw 100 left and spent 60. Real transfers, from a throwaway account built to fail: tx FR2SJm -> tx 4r9umk -> -
The timeout
A timeout gets mistaken for a failure.
A timed-out payment can still land. Release the hold, and you've overspent without knowing it.
Three agents ask for 30. There is 40 left.
- All three hit the contract in the same block.
- The first reserves 30 before any money moves. Now there's 10 left.
- The other two get refused. The budget stops at 10.
10 / 100 left
- ADMITTED30tx AwrG7n ->
- REFUSED: exceeds task budget30tx BHc6av ->
- REFUSED: exceeds task budget30tx 3yLKJC ->
A real run: testnet block 276744286, task demo-20261108071557. 1 unit = 0.001 NEAR. The animation illustrates it.
One budget, one real run
Every drop is a payment the contract admitted. Nothing went below 10.
- Scout paid 3070 lefttx HcCdWD ->
- Forge paid 3040 lefttx DnfbNm ->
- One of three admitted10 lefttx AwrG7n ->
Every payment takes the same path.
The AI proposes. The contract does the rest.
Open a task
One shared budget with a hard cap, set by
create_task.Name the crew
Register each agent. On the NEAR path, list who can get paid.
An agent proposes
A recipient, an amount and a
request_id. The contract builds the rest.The contract checks
Active agent? New request? Allowed recipient? Room under the cap?
The budget is reserved first
Check and reservation run as one step, before any promise exists. That's why a race can't overspend.
The contract pays
It builds the transfer from the fields it validated. On the EVM path, the MPC signer signs what the contract built.
Only proof closes it
The settlement callback confirms the payment. Silence keeps the hold.
Where the money sits
| State | Budget | What moves it on |
|---|---|---|
| Reserved | Held | A signature, a settled transfer or a proven failure |
| Signed | Held | Proof of the outcome, or a timeout |
| Unknown | Held | Later proof, or the owner reconciling the observed outcome |
| Confirmed | Spent | Final |
| Failed | Released | Set only on a proven failure |
| Cancelled | Released | EVM only: a confirmed nonce-burn and the owner's release |
Why NEAR
Purser builds on what the protocol already enforces.
-
Function-call access keys
An agent's key can call one method on one contract:
propose_payment. It can't move the account's funds. -
Chain Signatures
One contract can govern spending on another chain. Run live on Sepolia: NEAR tx 523rR7 -> Sepolia tx 0xbf264f ->
-
Contract custody
Budget and policy live in the contract, out of reach of a compromised tool.
-
Receipts and callbacks
NEAR payments report their own outcome back to the contract, with no relayer in the path.
-
NEAR AI Cloud
Attestation shows where the agents' model ran, with Intel TDX and NVIDIA GPU evidence. The contract never reads it.
What an agent can't get away with.
What the contract did, each time.
Spend past the cap
REFUSED: exceeds task budget
tx BHc6av ->Pay twice with a retry
Same commitment, no new spend
tx HSvCY6 ->Pay someone off the allowlist
REJECTED: recipient not allowlisted
tx 4PNRgP ->Reuse a
request_idfor something elseREJECTED: request_id reused with a different request
tx 13dNBM ->Keep spending after a revoke
BLOCKED: delegate revoked
tx EMSwHf ->Free a hold by timing out
The hold stays through silence, retry and revoke
Sandbox replay: the shipped contract can't lose a callback
The numbers come with receipts.
0 overruns in 50 concurrent races, checked against the merchant's balance.
- Duplicate authorizations
- 0 of 150 request pairs
- Valid requests blocked
- 0 of 400
- Holds released on silence
- 0 of 10 runs
- Attack suite
- 8 core cases, 10 of 10 each
- Property sequences
- 10,002 + 2,002
- Gas per authorization
- 5.74 Tgas
- Added time
- +256 ms, 2 blocks
- Storage per commitment
- 375 bytes
Measured on a local nearcore sandbox with the production wasm, 10 repeats. These are not testnet or mainnet figures, and this is not an audit. Regenerate with make metrics or read the full report ->.
What Purser won't do
The full list is in the README ->.
- It can't recall a payment. Revoking stops new proposals. Anything already issued stands.
- It can't fix bad judgment. A prompt-injected agent can still waste budget on an allowed merchant.
- It trusts the owner. A wrong owner attestation can overspend by one in-flight value per lane, and then the task freezes.
- It relies on a relayer for other chains. The relayer reports what happened on Sepolia. Only the owner can release budget.
- It's early. One token per task, testnet and Sepolia only, and no audit.
Check our work.
You need Rust 1.95, cargo-near, Node 26 and pnpm 10. The first two commands cost nothing. Testnet steps also need near-cli-rs 0.30.1.
make proveAttack cases and property tests, with the race's block heights.
make testEvery unit, property and sandbox suite.
OPERATOR_ACCOUNT_ID=<you>.testnet make deploy-testnetContract and crew on testnet, from a funded near-cli account.
./scripts/demo.shSeven outcomes: six live on testnet, one labeled sandbox replay.
make boardThe operator board, with the live invariant and the Revoke control.