Agents can ask.
They can never
take.
Almoner is a vault for AI agents on NEAR. The agent holds a key that can only ask to buy. Rules a person signed decide. Money waits in escrow until delivery is checked, and junk gets refunded.
No account, no install. The agent's real private key is already loaded.
Four steps
How it works
A person signs the rules
Purpose, allowed categories, blocked terms, sellers, budget, per-purchase cap and an approval line. One task, one mandate.
The vault issues the agent's key
A NEAR function-call key on the vault's own account. It can call three methods. It can't transfer, add keys or call anything else.
Sellers sign every price
The agent forwards a signed quote. The vault checks the signature on-chain, so nobody can edit the price, the item or the payee.
Escrow, then proof
Funds wait until the seller delivers. Accepted work is paid. Junk or silence is refunded and the seller goes on hold.
Why another agent wallet
A spending limit isn't enough
| What goes wrong | Agent wallet with a spending cap | Almoner |
|---|---|---|
| The agent's key leaks | Wallet can be drained up to the cap, or entirely | Nothing moves. The key can only ask, so we publish it |
| A hijacked agent buys something off-purpose, within budget | Goes through: a cap only asks "can it afford this?" | Refused: IntentLock checks what is bought against the signed purpose |
| Someone edits the price or the payee | Agent pays whatever it was told | Refused: the seller's signature no longer matches |
| The seller delivers junk, or nothing | Money is gone | Refunded from escrow; the seller goes on hold |
| The agent retries or loops | Pays twice | Same request returns the same decision; hourly limit stops loops |
| You ask "what happened last night?" | Scattered logs that can be edited | Every decision, refusals included, on-chain and hash-chained |
Public challenge
Break it
The private key of this vault's agent is published in the repository on purpose. One command signs six theft attempts with it and shows how each is stopped: four by the NEAR protocol, two by the vault, which records them on-chain.
git clone https://github.com/phoenix-2203/almoner
cd almoner/ts && npm ci
npm run attack# recorded output, 13 Nov 2026
1. Transfer NEAR out of the vault account
blocked by the NEAR protocol · Access key requires full access
2. Add our own full-access key to the vault account
blocked by the NEAR protocol · Access key requires full access
3. Call ft_transfer on the token contract directly
blocked by the NEAR protocol · Deposit is not allowed with function call
4. Call the vault's owner-only withdraw
blocked by the NEAR protocol · Access key does not allow method withdraw
5. Pay a quote we signed in the seller's name
refused by the vault · QUOTE_INVALID
6. Pay a 'seller' account we control
refused by the vault · SELLER_UNKNOWN
Vault token balance: 19.85 tUSDC before, 19.85 tUSDC after.
Nothing moved.See it refuse you.
Open the product, press a button, and watch a real transaction signed with the agent's key bounce off the vault. Every attempt shows up in the public record a few seconds later.
Straight answers
Questions a careful reader asks
Isn't this just a spending limit?
No. A limit answers "can the agent afford this?". Almoner also answers "is this what it was asked to buy, at the price the seller signed, and did the work arrive?". Purchases inside the budget are still refused when they don't serve the task.
What can the published key actually do?
Three things: ask the vault to buy, accept or reject a delivery for its own task, and settle a purchase whose time window has passed. It can also burn its own gas allowance of 1 NEAR, after which it stops working. It can't transfer funds, add keys or call any other contract. NEAR enforces that, not our code.
Why does this need NEAR?
NEAR accounts can hold several keys with different powers, and a contract can add and delete keys on its own account. That lets the vault hand an agent a key that is limited by the protocol itself. Seller signatures are checked with a built-in host function, and payments use the NEP-141 token standard.
What doesn't it protect against?
IntentLock is rule-based: it checks categories and blocked terms, not meaning. A seller can mislabel an item, at the risk of rejection, a refund and a hold. Delivery quality is judged by the buyer. The owner is trusted to set sensible rules. The full list is in the README.
Is it ready for real money?
No. It runs on NEAR testnet with a test token, and the contract hasn't been audited. It was built in a few days for NEAR HACKATHON, with 31 contract tests and the public challenge above.