# What works today

> What is live, in preview or planned in Probarion today, from the same status list as the home page, plus more parts that list leaves out.

The same list as the home page, from one source. Each row is Live (works in this deployment), Preview (built, not yet run end to end with real wallets or providers, or not yet open) or Planned (not built).

Reviewed: 2026-11-12 · Built from: 4ab41ca1436589c22073fa842ee46f970415e3d5

Canonical page: https://probarion.xyz/docs/start/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](https://probarion.xyz/docs/start/testnet-and-mainnet.md) 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`](#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](https://github.com/probarion/probarion/blob/main/docs/evidence/trial-vault/README.md#2026-11-12-reject-revoke-a-spare-agent-key-and-withdraw-all)).

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`](https://github.com/probarion/probarion/blob/main/contracts/code-hashes.json) records the hash of each reproducible build, and [verify a vault](https://probarion.xyz/docs/trust/verify-a-vault.md) shows how to run the verifier on a vault yourself.

> **Unaudited beta.**
>
> No third party has audited this code. [SECURITY.md](https://github.com/probarion/probarion/blob/main/SECURITY.md#what-is-not-proven-yet) lists what `verify` does not prove yet, and the [security model](https://probarion.xyz/docs/trust/security-model.md) covers the rest.

## Also in the source

The status list leaves these parts out, among others. Each one follows one row of the [README Status table](https://github.com/probarion/probarion/blob/main/README.md#status) and has its own section below, with the code it links.

| Part | Status |
| - | - |
| [NEAR AI Cloud adapter](#near-ai-cloud-adapter) | Preview |
| [npm release 0.1.1](#npm-release-011) | Live |
| [Test USDC on testnet](#test-usdc-on-testnet) | Preview |
| [Browser extension, server half](#browser-extension-server-half) | Preview |
| [Browser extension for Chrome](#browser-extension-for-chrome) | Preview |
| [Testnet and mainnet from one deployment](#testnet-and-mainnet-from-one-deployment) | Preview |
| [Owner alerts by Telegram and email](#owner-alerts-by-telegram-and-email) | Preview |
| [Watcher](#watcher) | Preview |
| [Usage page](#usage-page) | Preview |
| [Health checks and the status page](#health-checks-and-the-status-page) | Preview |
| [Error reports to Sentry](#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`](https://github.com/probarion/probarion/blob/main/docs/RUNBOOK.md), [`docs/THREAT_MODEL.md`](https://github.com/probarion/probarion/blob/main/docs/THREAT_MODEL.md), [`SECURITY.md`](https://github.com/probarion/probarion/blob/main/SECURITY.md)); the [/security](https://probarion.xyz/security), [/terms](https://probarion.xyz/terms) and [/privacy](https://probarion.xyz/privacy) pages, built and tested; and a browser smoke test of the built site ([`apps/web/e2e/smoke.spec.ts`](https://github.com/probarion/probarion/blob/main/apps/web/e2e/smoke.spec.ts)), 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](https://github.com/probarion/probarion/blob/main/docs/evidence/canary-vault/README.md#the-signed-ledger-published-2026-11-11), [online output](https://github.com/probarion/probarion/blob/main/docs/evidence/canary-vault/verify-online-2026-11-11.txt)). 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](https://github.com/probarion/probarion/blob/main/docs/evidence/demo-vault/README.md#2026-11-12-payables-pays-on-its-own-with-an-attested-model), [the second](https://github.com/probarion/probarion/blob/main/docs/evidence/demo-vault/README.md#2026-11-12-filmed-a-second-invoice-paid-on-its-own-freeze-and-unfreeze), [online output](https://github.com/probarion/probarion/blob/main/docs/evidence/demo-vault/verify-online-2026-11-12.txt)). 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](https://github.com/probarion/probarion/blob/main/docs/evidence/demo-vault/verify-a8-2026-11-12.txt)). The [attested model run](#attested-model-run) row above is Preview too.

Code: [`packages/sdk/src/nearai.ts`](https://github.com/probarion/probarion/blob/main/packages/sdk/src/nearai.ts)

### 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](https://probarion.xyz/docs/build/install.md) has the install lines, and the build from a clone that the evaluation uses.

Code: [`.github/workflows/release.yml`](https://github.com/probarion/probarion/blob/main/.github/workflows/release.yml)

### 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`](https://github.com/probarion/probarion/blob/main/apps/web/src/lib/topup/faucet.ts)

### 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`](https://github.com/probarion/probarion/tree/main/apps/web/src/lib/ext)

### Browser extension for Chrome

Preview. Version 0.1.0 is published: install it from the [Chrome Web Store](https://chromewebstore.google.com/detail/probarion/hhadnmnjdlamihjjoejphkimnbcfidmn). 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](https://github.com/probarion/probarion/blob/main/apps/extension/README.md) 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`](https://github.com/probarion/probarion/tree/main/apps/extension)

### 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`](https://github.com/probarion/probarion/blob/main/apps/web/src/lib/network.ts)

### 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](https://github.com/probarion/probarion/blob/main/docs/evidence/trial-vault/README.md)). 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`](https://github.com/probarion/probarion/blob/main/docs/ops/alerts.md) has the setup.

Code: [`apps/web/src/lib/alerts`](https://github.com/probarion/probarion/tree/main/apps/web/src/lib/alerts)

### 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`](https://github.com/probarion/probarion/blob/main/docs/ops/watcher.md) 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](https://github.com/probarion/probarion/blob/main/docs/evidence/trial-vault/README.md)). The schedule itself has not been read in Supabase.

Code: [`apps/web/src/lib/watcher`](https://github.com/probarion/probarion/tree/main/apps/web/src/lib/watcher)

### Usage page

Preview. Built and tested. [/usage](https://probarion.xyz/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`](https://github.com/probarion/probarion/tree/main/apps/web/src/app/usage)

### Health checks and the status page

Preview. Built and tested. [/status](https://probarion.xyz/status) shows the health checks live for its network. The uptime monitors are not set up yet.

Code: [`apps/web/src/lib/health.ts`](https://github.com/probarion/probarion/blob/main/apps/web/src/lib/health.ts)

### 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`](https://github.com/probarion/probarion/blob/main/apps/web/src/lib/sentry-scrub.ts)

## 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](https://github.com/probarion/probarion/blob/main/docs/THREAT_MODEL.md#known-gaps) 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](https://probarion.xyz/docs/build/let-an-agent-pay.md) shows how. The other agent interface is the [MCP server](#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](https://probarion.xyz/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](https://probarion.xyz/docs/concepts/vaults-roles-and-keys.md) explains the allowances.

### A third-party audit

No third party has audited this code, as the note under the status list says. [SECURITY.md](https://github.com/probarion/probarion/blob/main/SECURITY.md#reporting-a-vulnerability) 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`](https://github.com/probarion/probarion/blob/main/apps/web/src/lib/site/facts.ts), 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`](https://github.com/probarion/probarion/blob/main/apps/web/test/site-facts.test.ts) 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`](https://github.com/probarion/probarion/blob/main/apps/web/test/docs-reference.test.ts) 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`](https://github.com/probarion/probarion/blob/main/apps/web/test/docs-pages.test.ts) checks that this page renders the table.

The sections under [also in the source](#also-in-the-source) and [what does not exist](#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](https://probarion.xyz/docs/start/what-is-probarion.md): the parts, and who does what.
- [Testnet and mainnet](https://probarion.xyz/docs/start/testnet-and-mainnet.md): what differs between the two networks.
- [Install](https://probarion.xyz/docs/build/install.md): install the SDK and the CLI from npm, or build them from source.
- [Verify a vault](https://probarion.xyz/docs/trust/verify-a-vault.md): run the verifier on a vault yourself.
- [Security model](https://probarion.xyz/docs/trust/security-model.md): the security design in one page.
