What is Probarion

An owner puts USDC in a vault, a NEAR contract of their own, and signs mandates from their own wallet: who gets paid, how much per payment and in total, how many times, until when, and above what amount a person must approve. The agent gets one key that can call spend and nothing else.

Testnet today, and one small vault on mainnet. Testnet and mainnet says what differs between the two.

The problem it solves#

Giving an AI agent a wallet means trusting a prompt with money. Probarion moves the rule into a NEAR contract.

The limit sits on the money's path, not in a prompt or in the agent's own process. Even if every line of off-chain code were wrong, the vault refuses a payment outside its mandate. A payment made through the SDK passes these layers, in this order:

The ledger is kept by the SDK, not required by the contract. The vault checks only the form of a spend's decision hash, not that a ledger holds the decision, so a spend sent with the agent key alone has no decision in the ledger, and verifier check d fails on it. That is the case today on v0.probarion.testnet: its 2026-11-01 smoke run sent spends with no SDK and no ledger, so a live verify of that vault prints RESULT: FAIL. On the testnet demo vault, demo.vaults.probarion.testnet, the console's Payables agent signed each decision into the ledger before its spend, so a live verify of it prints RESULT: PASS.

Some outcomes stay out of the ledger. A result entry that fails to write is skipped, and the outcome says ledgerComplete: false. An approver's later approve or reject, and the expiry of a hold, are recorded on chain, and no code writes them to the ledger. That last point is inferred: it follows from the code, and no test shows it yet.

How one payment works follows one payment through these steps.

The idea in four numbers#

The 9 checks belong to the verifier, which reads the record afterwards. They are not the 14 checks the vault runs on every spend before it pays. Payment checks lists the 14, and verifier checks lists the 9.

The request an agent sends, in full:

export interface SpendRequest {
  mandate_id: number;
  amount: U128;
  invoice_hash: string;
  ref: string;
  decision_hash: string;
}

The parts#

Live means it works in this deployment; where a Live part runs on a chain, it runs on NEAR testnet. On testnet a stub stands in for NEAR Intents, so a Base or Solana payout is only logged as a burn with its memo, and nothing leaves NEAR. Preview means it is built but not yet run end to end with real wallets, or not open yet.

@probarion/core counts as Live because its verifier already runs on this site. The "Change one field. Watch it break." test on the landing page runs checks a to i in your browser, and so does "Try the verifier here" on /proof while no public vault is listed there. In the status list it is the offline verifier row. @probarion/core, @probarion/sdk and the probarion CLI are on npm at 0.1.1, as is the MCP server @probarion/mcp (Live): see Install the packages. In the status list the SDK and the CLI are the TypeScript SDK and CLI row, Live since release 0.1.0. Their read-only calls run against the testnet vault, as Evaluate in 5 minutes shows. The console's Payables runs the payment loop through process() on testnet, but no run of that loop in an agent of your own is recorded, so the pages that walk it are Preview. What works today has the full status list.

Who does what#

• The owner signs every mandate, adds and removes agent keys and sets the ledger key, all from their own wallet. Without Probarion, the owner can also freeze the vault, unfreeze it, and withdraw its USDC and its NEAR Intents balance, the tokens it holds inside NEAR Intents to pay Base and Solana payees. Freeze takes no deposit. A mandate takes a storage deposit, and the vault sends back the excess. Most other owner methods need exactly 1 yoctoNEAR, which a function-call key cannot attach, so a dapp login key on the owner's account cannot call them.
• Approvers decide a held spend: approve sends the payment, reject releases the amount the hold set aside under the mandate. They are named when the vault is created, and no method changes them later.
• The agent asks to spend. Its key can call spend and nothing else, and only under the mandates that name that key.
• Anyone can read a vault on chain and run the verifier, with no account.
• Probarion runs the site and the console. If you use the console's Keys tab or Payables, Probarion generates the vault's agent and ledger keys on its server and stores each secret encrypted.

Vaults, roles and keys covers each role and key in full, and mandates covers every mandate field.

Where to go next#

• You own the money. The owner quickstart sets up a testnet vault in the web console, with test USDC, an agent key, a ledger key and one signed mandate.
• You build the agent. The developer quickstart connects your agent to a testnet vault with the TypeScript SDK and runs one payment cycle with process().
• You want to check the claims. Evaluate in 5 minutes runs the verifier and reads the testnet vault with no wallet, key or account.

The two quickstarts are Preview: their flows have not yet run end to end with real wallets.

What this does not do#

• It holds no owner key. In the site's own words: "Non-custodial: Probarion holds no owner key." The agent and ledger keys the console makes are another matter: see who does what.
• It cannot change the rules underneath the owner. The vault has no upgrade method, no method to change the owner, and no full-access key.
• It does not edit a mandate. The payee is fixed when the mandate is created. A new payee needs a new mandate, and the owner can revoke the old one.
• A vault's NEAR does not come back out. The vault pays for its storage and its spends' gas from its own NEAR, and it has no method to withdraw NEAR. That NEAR is the vault's runway, and one plain transfer tops it up.
• The contract does not judge whether a payment is wise. It holds the agent to the limits the owner signed, and a spend above approval_above waits for a person. Off chain, decide() can still hold or refuse a payment the mandate allows, through its built-in rules, your own custom.* rules or an attested model's proposal.
• It has no HTTP API that an agent pays through. The console's invoice API answers only a signed-in owner or approver, on a same-origin request. An agent pays through the SDK, in its own process.
• Some parts are not done yet. On mainnet one small vault runs, but no Base payout has run there and the mainnet factory is not deployed. On testnet, Payables paid two invoices on its own with an attested model on 2026-11-12, with test tokens (the record (opens in a new tab), the second (opens in a new tab)). It has not run on mainnet, and an unfinished payment stays marked "do not resend" until its reconcile job is built.