What works today

NEAR testnet is live. Where a Live part runs on a chain, it runs on NEAR testnet with test tokens, except the mainnet vault. On mainnet one small vault, v0.probarion.near, has run since 2026-11-11 with real USDC: one NEAR payment and one refusal. No Base payout has run on mainnet, and the mainnet factory vaults.probarion.near is not deployed. Testnet and mainnet says what differs between the two networks.

The status list#

Feature	Status	Detail
Vault contract	Live	On testnet
Offline verifier, checks a to i	Live	Shipped, on npm
Reproducible builds	Live	Shipped
Vault factory	Live	On testnet
Web console: vault, keys, faucet, NEAR USDC top-up, mandate, Payables, Agent (MCP) tab, Freeze, approvals, Reject, revoke, withdraw, key removal, proof page	Live	Tried on testnet
Web console: email alerts, Base top-up	Preview	Built, not tried yet
Public proof page	Live	Live for the testnet demo vault
TypeScript SDK and CLI	Live	0.1.1 on npm
Payables agent	Live	Live on testnet
Live attested model run	Preview	Checked online on testnet, image not pinned
Canary public challenge	Live	Live on testnet
MCP server	Live	0.1.1 on npm, run by a real MCP client on testnet
Mainnet vault	Live	On mainnet: 1 payment, 1 refusal, no Base payout yet

The Detail column is the landing page's own wording for each row. Each row's id is its anchor here. In the order of the rows, the ids are vault-contract, offline-verifier, reproducible-builds, vault-factory, web-console, web-console-not-tried, public-proof-page, sdk-and-cli, payables-agent, attested-model-run, canary, mcp-server and mainnet-vault, so #mainnet-vault links the last row. The web console has two rows: what was tried on testnet with a real wallet, and the console actions that are built but not tried yet, adding an email alert and the Base top-up through 1Click, which is mainnet only. Reject on a held spend, revoking a mandate, Withdraw and removing an agent key moved to the first row on 2026-11-12, when the owner of a testnet vault tried each with a real wallet (Meteor), in a desktop browser (the record (opens in a new tab)).

Under its list, the landing page lists its known gaps, and the beta strip on every page links them. One is the contract build: "It also runs a build from before the 2026-11-03 set_ledger_key fix. The vaults the testnet factory creates, the demo vault among them, run the fixed build recorded in contracts/code-hashes.json." The vault source changed after v0.probarion.testnet was deployed, with a set_ledger_key fix on 2026-11-03. On the older build, replacing the ledger key could fail in a way that left the vault unable to anchor again. Every vault the testnet factory creates, the console's included, runs the fixed build. contracts/code-hashes.json (opens in a new tab) records the hash of each reproducible build, and verify a vault shows how to run the verifier on a vault yourself.

Also in the source#

The status list leaves these parts out, among others. Each one follows one row of the README Status table (opens in a new tab) and has its own section below, with the code it links.

Part	Status
NEAR AI Cloud adapter	Preview
npm release 0.1.1	Live
Test USDC on testnet	Preview
Browser extension, server half	Preview
Browser extension for Chrome	Preview
Testnet and mainnet from one deployment	Preview
Owner alerts by Telegram and email	Preview
Watcher	Preview
Usage page	Preview
Health checks and the status page	Preview
Error reports to Sentry	Preview

The README Status table also has rows that this page does not cover: the incident runbook, the threat model and the security contact, which are documents in the repository (docs/RUNBOOK.md (opens in a new tab), docs/THREAT_MODEL.md (opens in a new tab), SECURITY.md (opens in a new tab)); the /security, /terms and /privacy pages, built and tested; and a browser smoke test of the built site (apps/web/e2e/smoke.spec.ts (opens in a new tab)), which runs locally only and is not in CI.

NEAR AI Cloud adapter#

Preview. Built and tested against a fake NEAR AI Cloud. On testnet, the Canary's ledger of 2026-11-10, published in the repository, holds two real attested decisions that pass A1 to A7 offline and, on 2026-11-11, O1 and O2 online (evidence (opens in a new tab), online output (opens in a new tab)). On the testnet demo vault, Payables made five more, which pass A1 to A7 offline; four of them, entries 10 to 13, also passed O1 and O2 online on 2026-11-12. Code refused three of them on 2026-11-11, and on 2026-11-12 the code allowed the fourth and the fifth, both by Qwen/Qwen3.8-27B, and the vault paid each invoice, 2.00 test USDC, as spends 4 and 5 (evidence (opens in a new tab), the second (opens in a new tab), online output (opens in a new tab)). The TEE measurement is not pinned, so this does not show which model image ran, and A8 was not run on the Canary's two; on the demo vault's five it passed on 2026-11-12, with the invoices committed in the repository (output (opens in a new tab)). The attested model run row above is Preview too.

Code: packages/sdk/src/nearai.ts (opens in a new tab)

npm release 0.1.1#

Live. On 2026-11-11, release 0.1.1 of @probarion/core, @probarion/sdk, probarion, the CLI, and @probarion/mcp, the MCP server, was published to npm under the latest tag. It came from the tag sdk-v0.1.1 on main, through the release workflow, with npm provenance (SLSA v1). It is the first release of @probarion/mcp, which the official MCP registry lists as io.github.probarion/probarion. Release 0.1.0, of the other three, came out on 2026-11-09. Install the packages has the install lines, and the build from a clone that the evaluation uses.

Code: .github/workflows/release.yml (opens in a new tab)

Test USDC on testnet#

The testnet faucet is Preview: it is built and tested, and its key is set on probarion.xyz. On 2026-11-09 its button minted 25 test USDC into the testnet demo vault, demo.vaults.probarion.testnet.

On a testnet vault's Top-up tab (/console/<vault>/topup), signed in as the vault's owner, the "Add test USDC" button mints 25 test USDC into the vault, with no wallet: the Probarion team's key signs the mint, and that key can only mint the test token. It works once a UTC day per vault, and for up to 3 vaults per signed-in account a day. A cap of 50 mints a UTC day for all vaults together can also stop it until midnight UTC, and the button then answers "Today's test USDC for all vaults is given out." with the time to wait.

An approver or a viewer who opens the tab sees no button, only "Only this vault's owner can top it up."

Without a faucet key on the server, the tab shows instead: "Need test USDC? Send @probarionhq a direct message on X with your vault's name."

Code: apps/web/src/lib/topup/faucet.ts (opens in a new tab)

Browser extension, server half#

Preview. Built and tested. The signed-in /extension page connects a browser for one network, and GET /api/ext/inbox lets that connection read what waits for its account: invoices waiting for the owner, holds an approver can still approve, and the mandates an invoice can still be sent under. POST /api/ext/invoices lets it queue an invoice under one of those mandates, for a vault where the account is an owner or an approver, at most 20 in 10 minutes: the invoice waits in the console for the owner's wallet-signed Confirm. A connection cannot pay, approve or confirm.

Code: apps/web/src/lib/ext (opens in a new tab)

Browser extension for Chrome#

Preview. Version 0.1.0 is published: install it from the Chrome Web Store (opens in a new tab). No end-to-end run of it with a real wallet against this deployment is recorded yet, so it stays Preview, like the server half it calls. To build it from source instead, load it unpacked from apps/extension, as its README (opens in a new tab) says. It connects from the /extension page or with a one-time code, shows on its toolbar badge and in its popup what waits for you, and queues an invoice from selected text, the PDF in the tab, a linked PDF on the same site, or a file, through the server half above. It cannot pay, approve or sign: a queued invoice waits for the owner's wallet-signed Confirm in the console.

Code: apps/extension (opens in a new tab)

Testnet and mainnet from one deployment#

Preview. Built and tested. The address a request was opened at sets its network, and the console's invoice and top-up APIs answer 409 wrong_network for a vault of the other network, except the testnet faucet, which answers 404 not_found so that a vault id is never confirmed. Only the testnet address is live.

Code: apps/web/src/lib/network.ts (opens in a new tab)

Owner alerts by Telegram and email#

Preview. Built and tested against a fake Telegram and a fake Resend. Telegram is on at probarion.xyz: on 2026-11-11 the owner of a testnet vault linked a chat from its Alerts tab, and the bot sent real messages, "Approval needed" for a held spend and "Paid" once an approved spend paid (the record (opens in a new tab)). No email has been sent yet. Each channel switches on by itself. Telegram needs TELEGRAM_BOT_TOKEN set and the bot's webhook registered by the setup script, since a chat links through that webhook. Email needs RESEND_API_KEY set and probarion.xyz, the domain the alerts are sent from, verified in Resend. The runbook docs/ops/alerts.md (opens in a new tab) has the setup.

Code: apps/web/src/lib/alerts (opens in a new tab)

Watcher#

Preview. Built and tested against a fake chain. For each vault registered with the app, it reads the spends, mandates and anchors from the chain, and the ledger, and records them for /usage and the alerts. It runs once a day on Vercel and right after an invoice upload or a Canary attempt. Its runbook docs/ops/watcher.md (opens in a new tab) also sets out a per-minute schedule through Supabase Cron. The Telegram alerts of 2026-11-11 point to a schedule of about a minute running that day: each came within two minutes of its event, and no invoice upload on that vault started the watcher (the record (opens in a new tab)). The schedule itself has not been read in Supabase.

Code: apps/web/src/lib/watcher (opens in a new tab)

Usage page#

Preview. Built and tested. /usage shows counts, not dollar volumes, refreshed at most hourly while people view it and once a day by a job, for the network of the address it is opened at.

Code: apps/web/src/app/usage (opens in a new tab)

Health checks and the status page#

Preview. Built and tested. /status shows the health checks live for its network. The uptime monitors are not set up yet.

Code: apps/web/src/lib/health.ts (opens in a new tab)

Error reports to Sentry#

Preview. Built and tested with the real SDK sending nothing. Off until SENTRY_DSN is set.

Code: apps/web/src/lib/sentry-scrub.ts (opens in a new tab)

What does not exist#

None of these is on the status list as Planned. The README's known limitations, such as no Content-Security-Policy yet, and the threat model's known gaps (opens in a new tab) list the rest.

Outbound webhooks#

The code has no webhook that calls a server of yours. Its one webhook is incoming: Telegram calls /api/telegram/webhook for the alert bot. To follow a vault yourself, index the NEP-297 events its contract logs (EVENT_JSON: lines with the standard probarion).

A public HTTP API for agents#

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: let an agent pay shows how. The other agent interface is the MCP server, which runs beside the agent over stdio and pays through the same SDK.

Pricing#

There is no price list and no paid plan. The terms say "Probarion charges nothing for the console." Your wallet pays for the transactions you sign and for the storage deposits: when you create the vault, and for each mandate. The agent's spends and the ledger key's anchors burn gas from the vault's own NEAR, up to each key's allowance, so the vault needs some NEAR of its own. Vaults, roles and keys explains the allowances.

A third-party audit#

No third party has audited this code, as the note under the status list says. SECURITY.md (opens in a new tab) says how to report a vulnerability.

How this list stays true#

The status list is STATUS.rows in apps/web/src/lib/site/facts.ts (opens in a new tab), the module the landing page renders. The docs home and this page render the same rows and turn each row's tone into a docs word: live becomes Live, work becomes Preview and plan becomes Planned.

Tests hold the list to the repository:

• apps/web/test/site-facts.test.ts (opens in a new tab) holds each row to the words of its README Status row, and pins the exact rows, ids and pills. A row cannot change unless that test changes with it.
• apps/web/test/docs-reference.test.ts (opens in a new tab) checks that every row maps to Live, Preview or Planned and has a stable id, the anchor of its row on this page.
• apps/web/test/docs-pages.test.ts (opens in a new tab) checks that this page renders the table.

The sections under also in the source and what does not exist are written by hand, so no test holds them to the README. Where the two differ, the README Status table and the code it links are the record.

Related pages#

• What is Probarion: the parts, and who does what.
• Testnet and mainnet: what differs between the two networks.
• Install: install the SDK and the CLI from npm, or build them from source.
• Verify a vault: run the verifier on a vault yourself.
• Security model: the security design in one page.