Privacy notice

What is public on chain

Your vault, its mandates, its spends and its anchors are NEAR transactions. Anyone can read them, on testnet and on mainnet. They are public and permanent, and we cannot delete them.

Your account

You sign in by signing a message with your NEAR wallet. We keep your account name and a session cookie, pb_session, which lasts 12 hours and which page scripts cannot read. While you sign in, a second cookie of the same kind, pb_chal, holds the sign-in challenge for 5 minutes.

Invoices

The file of an invoice you upload is encrypted before it is stored. The facts read from it, such as the amount and its references, and its file name are stored with it, not encrypted. With zero-retention on, the invoice's record keeps only its hashes and the outcome, and, for an invoice that asked for your Confirm, its amount: not the file, its text, its other facts or its name. The signed ledger still records the amount, any PO reference the model was shown, and the model's answer, which may quote details of the invoice.

When the payables agent runs, the invoice text goes to a private model on NEAR AI Cloud. The attested decisions recorded in the repository so far are all on testnet: two of the Canary's, which pass A1 to A7 offline and, on 2026-11-11, O1 and O2 online, and five of the payables agent's on the demo vault, which pass A1 to A7 offline; four of them, entries 10 to 13, also passed O1 and O2 online on 2026-11-12. The TEE measurement is not pinned, 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.

The signed ledger

Each decision goes into a signed ledger for your vault. The model's answer, which may quote details of an invoice, is part of it. A vault's ledger is public only if you turn on its public proof page.

Alerts

If you add an alert, we store the email address or the Telegram chat it goes to, and send through Resend or Telegram. Remove on the vault's Alerts tab stops it.

The Canary

A message you send to the Canary goes to a private model on NEAR AI Cloud. We store a sha256 hash of the message, not its text, plus technique labels and the on-chain result. The model's answer, which can quote your message, goes into the Canary's own signed ledger, which is not public. Your IP address and a cookie are stored as keyed hashes with each attempt, for rate limits and for the leaderboard's count of visitors. A link of ours can say where it was posted, as in /canary?via=x on a post on X. Your attempt then also stores that one word, so we can tell which links bring people. A word that is not one of ours is not stored.

Operations

Our servers log events such as sign-in, invoice uploads and payments, each with a request id. A line can name your account and your vault. Known secrets are masked before a line is written. Vercel, which hosts the site, also keeps its own request logs.

Rate limits on sign-in, alert links, the proof pages and downloads, and pairing the browser extension with a code count requests per IP address (an IPv6 address cut to its /64). That address is stored as it is, in a counter that a daily cleanup deletes about two days after your last request. The Canary keeps only keyed hashes.

On testnet, the Add test USDC button counts its mints per vault, per owner account and for all vaults together, each for one UTC day, with no IP address, in counters the same cleanup deletes. Each mint is a NEAR transaction that names your vault, so it is public on chain.

Error reports go to Sentry once it is enabled, without cookies, request headers or query strings. A report carries the log line of the error, which can name your vault or your account, and the page or route it came from.

Who processes data

Vercel hosts the site. Supabase holds the database. NEAR AI Cloud runs the model. Telegram and Resend deliver alerts. Sentry receives error reports once it is enabled.

On mainnet, a top-up sends NEAR Intents 1Click the amount and the asset, your account name (for a refund) and the vault's (to receive the funds). Chain reads go to NEAR RPC providers. Your browser loads the wallet connectors' code from GitHub.

We use no analytics service and no advertising trackers.

Your choices

You can freeze your vault and withdraw its funds with your own keys at any time, without Probarion, for example with near-cli-rs.

In the vault's Settings, zero-retention keeps no invoice file, text or file name, and the signed ledger still records the amount, any PO reference the model was shown, and the model's answer, which may quote details of the invoice. The public proof page stays off unless you turn it on.

A member of a vault can download its signed ledger at /proof/<vault>/ledger.jsonl, whether or not its proof page is public.

To ask what we hold about your account, or to have it removed, send a direct message to @probarionhq on X.

Browser extension

Install the Probarion extension for Chrome from the Chrome Web Store (opens in a new tab).

You can also build it from apps/extension in Probarion's repository and load it unpacked. This section says what it does, and what Probarion stores for it. You connect it to your account on the Browser extension page, /extension, signed in with your wallet, or with a pairing code that page shows.

The extension sends an invoice to Probarion only when you ask it to: the PDF or text you choose, with the vault and the mandate you pick. It sends it to the Probarion address you connected, and nowhere else. A PDF or text file it reads from a tab or a link is fetched from that site the way the tab loaded it, with your own session for that site. In your browser it keeps the connection token, your account name and network, and, until you send it or close Chrome, the invoice you captured. It reads no page except the PDF or the selection you send and Probarion's own Browser extension page when you connect, and, when you open it, the address of the tab you are on, to see whether it is a PDF. It has no analytics and runs no code from elsewhere, and its Disconnect button ends its connection.

For each browser you connect, we store a hash of its connection token, not the token, with the token's last four characters, your account and network, a name for the browser such as Chrome on Windows, and when it was connected, last used, set to end and revoked. The record of a connection stays after it ends. A pairing code is stored as a hash, with your account and network and when it was made, set to end and used. It works once, for ten minutes, and once it is used or expired, its record is deleted the next time a code is made, for anyone.

An invoice sent from the extension is stored under the same vault settings as an upload in the console, with the mandate that was picked, the account that sent it and the checks it was queued with. If your vault is set to keep no invoice files, its record keeps the invoice's hashes and amount, the mandate, the account that sent it and those checks, which name the mandate's payee: not the file, its text, its other facts or its name. It then waits for the vault's owner to confirm it in the console.

A connection works only for your account, and only at the address of the network it was made on. It reads the invoices and held payments waiting for you and your vaults' active mandates, and it can send an invoice to a vault where you are the owner or an approver, under one of its mandates. It cannot pay, approve or confirm a payment: an invoice it sends is paid only after the vault's owner confirms it in the console with their wallet.

A connection ends after 30 days, and a sixth connection on the same network ends the oldest one. You can end one sooner with Revoke on the Browser extension page.