Vestiarion

Vestiarion

Your AI agent for bills and payments, for small businesses: it checks every bill before it is paid, pays in USDC on Arc inside limits a contract enforces, and signs every decision into a ledger you can verify.

Full tour (7:22) · See your first decision · Open numbers · Mainnet proof · Docs · MCP server · Security

Built on Arc and Circle · Works with Xero · QuickBooks Online · Zoho Books · HubSpot · Pipedrive · Zoho CRM · BlindPay · Asana · Google Sheets · GitHub · Slack · Telegram · Discord · Chrome · @vestiarionhq

Vestiarion runs a small business's money cycle with one agent: it screens counterparties, pays vendors, releases contractor pay, collects receivables and keeps idle cash working. A model proposes each action; ordinary code decides whether it may happen; a person decides what code sends to them; and on Arc mainnet, when the treasury is the owner's own wallet, the money itself can only leave through a spending-limit contract that wallet deployed. Every outcome, refusals included, is signed into a hash-chained ledger anyone in the workspace can verify.

Watch it work: the demo (2:59) or the full product tour (7:22), both recorded on the live product on October 15, 2026, with the Arc mainnet payment from October 12: a freelancer the agent pays on its own once a second member confirmed the address, a new supplier's first bill the model wanted to pay and code refused until a second member approved, the day the agent picks to pay, shadow mode and the customers' figures, Arc mainnet and the proof. The tour opens how the agent decided, line by line, on three of those decisions.

Tameion is ancient Greek for a treasury, the room the money was kept in. In Byzantium that room grew into the vestiarion, the department that minted the coin, held the stores and paid the army.

Contents

• How to evaluate Vestiarion in 5 minutes
• Watch each flow
• What Vestiarion does
• Why it is different
• How payments work
• Safety architecture
• Arc mainnet and Arc testnet
• Product capabilities
• Integrations
• Primitives for Arc builders
• Quick start
• Verifiable activity
• Documentation
• Development
• License

How to evaluate Vestiarion in 5 minutes

Everything below runs on the live app, www.vestiarion.xyz, with an email address and nothing else: no wallet, no USDC, no API key, nothing to install.

1. Open a workspace on Arc testnet. Sign in at www.vestiarion.xyz/login with Continue with Google or Email me a sign-in link, give the workspace a name and choose Create workspace (a Test workspace, on Arc testnet, if you are asked). It starts as a sandbox: payments are simulated and nothing reaches a chain.
2. Load sample data and run the agent. On Treasury, the console, choose Load sample data: six counterparties, eight invoices (seven to pay and one to collect) and two contractor milestones, chosen so that one cycle shows every outcome. Then choose Run cycle now. To try one of your own bills instead, follow See your first decision.
3. Read the decisions and the refusals. On Bills & receivables, each bill shows what the agent decided: pay it, pay it on its discount's last day, ask for a missing purchase order, hold it above its supplier's limit, or flag it as a duplicate. Its card shows Agent’s reasoning and How the agent decided. Where the model wanted to pay and a rule in code stopped it, the card says "Blocked by code, not by the model" and names the rule. How payments are controlled lists every rule, and When the model and the policy disagree shows the payments code refused in production.
4. Verify the signed ledger. Open Audit log and choose Verify hash chain: it checks every Ed25519 signature and hash link and answers "Chain intact". Under Download, Signed JSON exports the chain, and verify-ledger-export.mjs checks it on your own machine with Node.js alone (Verify an audit export).
5. Check production. Open numbers reads production on every load: workspaces, payments, decisions and what code refused, per network, with our own payments linked to the explorer under "Verify it yourself". Mainnet proof walks through the first payment on Arc mainnet: held by code as a first payment to a new address, approved by a second person, and paid through the owner's spending-limit contract.

Watch instead: the demo (2:59), the full product tour (7:22), and a short video for each main flow, two minutes or less each.

Reviewing security: www.vestiarion.xyz/security covers the architecture, tenant isolation, encryption, access control, connector tokens, webhooks, the subprocessors and what we do not claim. SECURITY.md says how to report a vulnerability.

Where things are in this repository:

Watch each flow

One short video for each main flow, recorded in the live product on Arc testnet with demo data in the team's own workspaces. Each plays at the top of its guide, with its transcript, and on YouTube.

What Vestiarion does

A small business pays vendors, contractors and recurring bills through several tools a person stitches together by hand, and checks none of it continuously. Vestiarion replaces that with one decision loop, the agent cycle, that reads the whole book each time it runs:

The agent cycle: reconcile -> receipts -> compliance -> document checks -> follow-up -> recurring -> services -> liquidity -> AP -> contractors -> treasury -> forecast -> proposals -> collections -> early offers -> customer offers -> term requests -> document requests -> cash alert -> notices -> telegram -> slack -> discord, each stage's outcome appended to the ledger.

Why it is different

• The model argues; it cannot pay. Anthropic, OpenAI or DeepSeek returns a structured {action, reasoning, confidence}. Code re-checks every hard rule after the model decides and before money moves, and with no model key at all a transparent rule-based policy takes the model's place. Every ledger entry records which one decided, and the written policy's answer is recorded beside the model's (research: when the model and the policy disagree).
• The limit is on the money's path, not only in the code. On Arc mainnet a workspace can pay from a wallet its owner holds. The agent's wallet can only call pay on a contract that wallet deployed, which refuses anything past the daily or 7-day figure, whatever Vestiarion's code decided.
• Vestiarion does not hold that treasury's USDC. On that path the USDC stays in the owner's wallet or passkey smart account; Vestiarion holds no key to it, and the agent's wallet holds only gas. (Other setups differ; see Custody, by setup.)
• People decide what matters. A first payment to a new address, a payment above the two-approval figure, and anything the agent held all wait for a person, and some for two.
• Figures are read, not asserted. Open numbers is queried from the production database on every load, with Arc mainnet and Arc testnet counted apart and our own workspaces counted apart from customers'.

How payments work

On Arc mainnet, a workspace whose treasury is its owner's wallet pays like this:

flowchart TD
    T["Owner's treasury<br/>passkey smart account or browser wallet<br/>(Circle Modular Wallets)"]
    C["VestiarionSpendingLimit<br/>deployed and approved by the treasury"]
    A["Vestiarion agent<br/>proposes pay / hold / flag"]
    P["Code: deterministic policy and guardrails"]
    H["Approvals inbox<br/>one or two people"]
    W["Agent wallet<br/>holds gas only"]
    V["Vendor address"]

    T -- "approve(contract)" --> C
    A --> P
    P -- "held, flagged, new payee,<br/>above two-approval figure" --> H
    P -- "allowed" --> W
    H -- "approve and pay" --> W
    W -- "pay(to, amount, ref)" --> C
    C -- "transferFrom(treasury, vendor)<br/>within daily and 7-day figures" --> V
    V -. "settles on Arc in seconds;<br/>Paid event + signed ledger entry" .-> L[("Ledger")]

In words:

1. The owner's wallet is the treasury. In Go live the owner either connects a browser wallet (MetaMask, Rabby…) or creates a passkey wallet: a Circle smart account on Arc mainnet owned by their passkey, with an optional recovery address. The owner's wallet deploys the workspace's VestiarionSpendingLimit, approves it on USDC and sends the agent's wallet its gas; with a passkey that is one confirmation, after the browser checks every call against what it built itself.
2. The agent proposes. Each cycle the model reads the invoice, the counterparty's screening, the match and the cash position, and proposes an action with its reasoning.
3. Code decides. Duplicate, risk, payment-limit, three-way-match, new-payee, spending-limit and liquidity rules run as ordinary code. They can overrule the model; nothing the model writes can overrule them.
4. A person decides what code sends them, in the approvals inbox (or from Slack on Arc testnet). A person's approval goes through the same payment step the agent uses.
5. The contract decides last. The agent's wallet calls pay(to, amount, ref). The contract pulls USDC from the treasury to the vendor only within the daily and 7-day figures, and never twice for the same ref. Only the owner's wallet can change the figures (setLimits), or stop the agent by setting its approval to 0.
6. Arc settles; the ledger records. Payment status is read back from Circle and the chain, the fee from the receipt (Arc's gas token is USDC, so the receipt is the dollar cost), and the outcome is signed into the ledger.

On Arc testnet the same decision path pays from Circle wallets instead, through the same contract once an owner or admin turns on Enforce on Arc.

Custody, by setup

Safety architecture

flowchart LR
    M["Model<br/>proposes"] --> R["Rules in code<br/>refuse or hold"] --> P["People<br/>approve"] --> K["Contract<br/>caps the spend"] --> S["Signed ledger<br/>records all of it"]

The contract source is in contracts/. It was written for Vestiarion and has not been audited.

Arc mainnet and Arc testnet

Each workspace lives on one network, chosen when it is created, and never moves.

Mainnet proof

On Oct 7, 2026 a workspace we run made its first payment on Arc mainnet, from a passkey wallet, through its spending-limit contract:

1. The owner's passkey wallet deployed and approved its contract in one transaction, with figures of 50 USDC a day and 150 USDC in 7 days: 0xe6261540…a9bb.
2. The agent decided to pay a 0.10 USDC invoice. Code held it: a first payment to a new address (counterparty.new_payee).
3. A second member, an admin, approved and paid it. The agent's wallet called the contract, which moved 0.10 USDC from the passkey treasury to the vendor and emitted Paid; fee 0.0035 USDC, confirmed in under a second, in block 24,710,870 at 09:43:13 UTC: 0xcecef38e…dee6.

Contract: 0xd90cA89Fc318d0330Bb14eaeF78B72C3CA7E7fB6.

On Oct 19, 2026 two of our own test workspaces, not customers, made the first payouts from Arc mainnet to Base. Each paid 1 USDC to a wallet on Base through CCTP V2, with Circle's Forwarding Service minting it there, the CCTP fee on top. In both, the agent read the live CCTP fee and chose to pay on the due date: the bill offered no early-payment discount, so keeping the cash until then cost nothing. Code then held it as a first payment to a new address, and the workspace's only approver approved it.

• From a workspace's own Circle account (#453): the burn on Arc, 0x89f66f7b…17e9, and the mint on Base, 0x33b0f0e5…f0ac.
• From the owner's passkey wallet, through version 2 of the spending-limit contract: the agent's gas-only wallet called payAcrossChains (#454), which took the payment and its fee from the passkey wallet and burned them on Arc, 0x7c3b4b6b…2a17, and the mint on Base, 0x9ea0fe5a…150c.

On Oct 22, 2026 the same test workspace on its own Circle account made the first payout from Arc mainnet to Arbitrum (#498). The agent read Circle's live fee to Arbitrum, 0.077 USDC, weighed it against the 10% cap on a 1 USDC bill, and chose the due date again; code held it as a first payment to a new address, and the workspace's only approver approved it. The burn on Arc, 0xce0a7911…d7b8, and the mint on Arbitrum, 0x385363d4…f987: 1 USDC to the payee, the 0.077084 USDC fee on top. Its shared receipt checks the mint on Arbitrum and states the invoice number, the fee and who paid it.

Arc mainnet has no customer workspace yet; Open numbers shows the current count.

Proof on Arc testnet

Made by the agent in production:

• a USDC payable paid 53 seconds after it was added, with no one pressing Run: 0x81381c50…4e68;
• a payment through the spending-limit contract, within its daily figure: 0xa79cb982…e71e;
• a EURC invoice, weighed against a USDC limit at a rate quoted by Circle's Stablecoin Service: 0x2e66257f…8f58;
• a payout to Base Sepolia through CCTP: the burn on Arc, 0xbc1961bb…d49c, and the mint Circle forwarded, 0x6c749323…ef9a;
• an invoice read from a PDF by the model, checked by a person, and paid 16 seconds after it was added: 0x197e979f…64b3;
• idle cash into Circle's USYC through its Teller, 0x1cf65900…f42e, then the missing 0.88 USDC redeemed for a bill due today, 0x4b5186db…c7f2, and the bill paid 34 seconds after it was added, 0x365da374…9d8b;
• with the cash short of two bills due the same day, the 50 USDC of database backups the agent chose to pay first, over a 30 USDC one-off migration the written policy put first, 0x1adfad84…3a7b;
• with the payee lock on, a vendor's payout address changed to a fresh wallet holding 0 USDC. The agent held its 3 USDC bill while the address was unconfirmed. The member who entered the address could not confirm it, even with a full record. A second member confirmed it, and the agent then held the bill through the 4-hour wait. Only after that did it pay, and the wallet went from 0 to 3 USDC: 0x49787501…0551;
• the same in a workspace with one member. A record that did not say the contact was on file before the change was refused, and so was Agree and pay during the wait. Once the wait ended, the first payment to the new address still needed the approver: 0x7948ea38…72c5.

Each feature's design under docs/superpowers/specs/ ends with its rollout record: what was run in production, with its ledger entries and transactions.

Product capabilities

• AP automation — invoices typed in, imported from a bill list in its own columns, dates and currency, read from a PDF, forwarded by email, captured from the browser with the Chrome extension, or sent through the API; recurring payables; early-payment discounts taken when they pay; late fees weighed when a bill waits and when cash is short, never added to what is paid.
• Approvals inbox — approve and pay, reject, or return to the agent; claims keep two people from deciding the same row.
• Try a limit first — see which past bills a new payment limit, two-approvals figure or spending limit would have held or let through, then apply it from the result.
• Contractor milestones — verified by a merged pull request, by a person accepting the Asana task the work was delivered in, or by a person; GitHub bounties with /bounty and /payto; a pull request comment once paid.
• Payee links — a payee enters and confirms their own address, or creates a passkey wallet to be paid in.
• Receivables — pay links on Arc, matched receipts, payments applied to several invoices or part of one with the agent's suggestions, credit and fees kept apart, reversals appended, reminders for what is still owed that follow the customer's context (a dispute, a claim, a promise, its own rules, its HubSpot deal's owner), and a search by invoice number, id, purchase order, amount or transaction.
• Customer statements — a link per customer to a page of what it owes, where it can say it paid, promise a day or dispute an invoice; the agent's reminders wait while a promise or a dispute stands.
• Commissions — a sales partner or referrer earns only on money a customer actually paid on Arc, for exactly the amount applied; a person turns what is due into a payable the agent pays like any bill, and the partner never approves their own payout.
• Deals — a signed deal (a deposit and the balance, milestones, a retainer or custom lines) as a schedule that adds up to its total exactly; each line released as a receivable on its day, by a person or the agent; a price change or a cancel is a signed new version that never rewrites what was invoiced or paid.
• Projects — a budget and a buffer in USDC for each job, client or launch; its bills, milestones and deals, what is set aside, paid and still available, what its deals collected, and its days in the payment plan. The agent never sets aside the same money twice, and holds what a budget cannot cover for a person.
• Treasury — safe-to-spend today, cash outlook, USYC reserve with Bring cash back (Arc testnet).
• Cross-currency and cross-chain — EURC invoices and swaps, CCTP and Gateway payouts (Arc testnet), and CCTP payouts to Base and Arbitrum from Arc mainnet.
• Supplier payment status — a link per supplier to a page of its own bills: where each one stands, from received to paid, with each payment's transaction on Arc, and never why a bill is held.
• Early-payment offers — the agent's later bills, each with the discount worth asking for paying today; an owner or admin sends the supplier a one-time link, or turns on the agent's own offers: it picks the bills and the discount up to a ceiling, only from cash it can pay today, and emails the supplier the link. An accepted offer is paid at the discounted amount the same day.
• When the cash is short — the agent checks each scheduled bill against the cash ahead and holds one it will not cover days early. When the bills due within 14 days come to more than the cash, the model orders them by what costs the business most to pay late, saying why for each, and code pays in that order only while the cash lasts. When turned on, it asks a supplier for more time on a bill it cannot pay, answers a supplier who proposes fewer days, and takes the request back once the cash is there; and it offers customers a small discount to pay sooner. It tells the owner how much is needed and by when, in the console, Telegram and Slack.
• Weekly brief — on Mondays, owners, admins and approvers get the week by email: what was paid and received, the decisions, what waits for them, what leaves next, whether the cash covers the next 30 days, and the week's payee address changes, frozen payees first. In shadow mode it reports the verdicts instead, and how often the business agreed with the agent.
• Bank payouts — a vendor's bills paid to its bank account in Mexico, in pesos over SPEI through BlindPay, from the workspace's USDC; a person sees what the vendor receives and approves every one (BlindPay's development instance).
• Shadow mode — try the agent on real bills, paid in the business's own way, before it pays anything itself.
• Report — what the agent did with a workspace's real bills: payments with their transactions, what it stopped and why, how often a person stepped in, discounts measured from the transfers, and what is left before a live slice, with how often the business agreed with the agent by decision and by vendor and the number of verdicts behind each figure, which an owner then opens on Arc mainnet with the vendors they choose, each showing that agreement, carried over without typing them in again. Agent vs what really happened lays each bill's decision beside what the business recorded paying outside Vestiarion, one bill at a time, from a CSV, or from a bank statement whose lines are matched to the bills they could have paid, each figure linked to its signed entry. Value keeps measured, estimated and not-counted figures apart, and an owner or admin can share a live copy by a revocable link, with suppliers as labels and amounts hidden if they choose.
• Workspaces and members — per-network workspaces, invitations, five roles, per-member notifications; an accountant console across the businesses an outside accountant looks after, and a one-time link an accountant sends a new client, who opens their own workspace in shadow mode with the accountant already in it.
• When a payment does not settle — each exceptional state says who acts, what Vestiarion already did and what to do next; paying again always looks for the earlier transfer first.
• Why it was paid — one page per payment, link by link from the purchase order to the receipt, each fact marked checked by code, verified outside or stated by a person; entries checked again in the browser, and a JSON download.
• Audit — the signed ledger, one-click verification, exports, and signed webhooks.

Integrations

Circle integrations

Team and developer tools

The Postman collections are also in a public workspace, Vestiarion API, and the MCP server is in the MCP Registry as io.github.duongnq2798/vestiarion.

npm install @vestiarion/sdk            # the typed client
npm install --global @vestiarion/cli   # the vestiarion command

The vestiarion command works with a workspace from a terminal, with a key from Settings → API keys:

vestiarion login                                            # asks for the key, checks it, saves it for your user
vestiarion bills list --status held                         # what the agent held; bills show <id> says why
vestiarion ledger verify vestiarion-acme-ledger-1042.json   # an audit export, checked offline

Operators of a deployment of their own also run the repository's scripts (npm run cycle, npm run status, …), listed in docs/self-hosting.md.

Primitives for Arc builders

Pieces of Vestiarion another Arc app can take as they are, under this repository's license. Each is tested on its own.

To fork just the two contracts and the ledger verifier, without the app, use duongnq2798/vestiarion-primitives: a Foundry project with both contracts byte for byte, a build that reproduces the Arc mainnet bytecode and a script that checks it against the chain, unit, fuzz and invariant tests, deploy scripts, the deployment addresses, and viem examples for each call.

What these add to the circlefin/arc-\* samples. The samples show how to move USDC on Arc: checkout, peer-to-peer payments, a treasury across chains, an escrow released by an AI review, an agent paying for x402 services. An agent's budget there, as in arc-nanopayments' --limit, is enforced by the agent's own process. Here the bound is a contract on Arc that the agent's wallet cannot get past, while the treasury keeps custody. Each payment carries a signed record of why it was made, and shadow mode measures how often people agree with the agent before it pays on its own.

Quick start

Use the hosted app — no wallet or keys needed to start:

1. Sign in at www.vestiarion.xyz with your email and open a workspace on Arc testnet, in shadow mode.
2. Add a supplier and one of your bills, or load sample data, and watch the agent decide within a minute.
3. Agree or disagree with its decision, read the Report of what the agent did, then verify the signed ledger.

The whole path is in See your first decision. To move testnet USDC, follow Go live and fund the wallet from Circle's faucet.

Call the API — create a key under Settings, then:

curl -H "Authorization: Bearer $VESTIARION_API_KEY" https://www.vestiarion.xyz/api/v1/status

See the Quickstart and Authentication.

Verifiable activity

• Open numbers — workspaces, payments, the agent's decisions, what code refused and what people decided, per network, customers apart from us, read from production on every load. Figures change daily, so this README links there instead of copying them.
• The ledger — every workspace's /audit verifies its whole chain in one click; exports and webhooks carry the same signed entries.
• Research — three weeks of the model's decisions recorded beside the written policy's, including where code had to refuse it.
• Quality Lab — fixed scenarios run through the real decision code on every change, each one's expected and actual outcome, and how many wrong payments: none may merge.
• Address lookalike checker — a free page that compares an address with ones you know, with a broader rule than the lookalike warning on Counterparties, and checks its characters, checksum and OFAC's list in the browser.

Contracts on Arc testnet

Vestiarion's own contracts, the copies in our test workspace:

The Circle contracts it calls:

What each one is for, the wallets around them, and the USDC of the chains payees are paid on: Contracts.

Documentation

Development

Next.js, TypeScript, Supabase Postgres with row-level security, Vitest, Solidity 0.8.37.

npm install
cp .env.example .env.local   # Supabase URL and keys, VESTIARION_MASTER_KEYS, SUPABASE_JWT_SECRET
npm run db:migrate
npm run dev

You need a Supabase project (Project Settings → API for the URL and keys, the JWT secret under JWT Keys). With no Circle or model keys, payments are simulated against Arc's measured fee and latency, and decisions come from the rule-based policy, so the app runs end to end with no credentials.

npm run verify   # typecheck, lint and the full test suite: what CI runs

The suite needs no Supabase, Circle or model key: it covers the ledger's tamper cases, risk tiering, treasury economics, guardrails and provider fallback, and runs every migration on an in-process Postgres (PGlite) to hold the database's half of the hash chain to the verifier.

It also runs the Quality Lab (tests/quality-lab.test.ts): the scenarios in src/lib/quality-lab/scenarios.ts through the real AP stage, with the model's answers scripted. Beside them, tests/quality-lab-shadow.test.ts replays the team's own shadow-mode decisions (src/lib/quality-lab/shadow-decisions.json) through the same stage, with the model's answers as recorded. Each fails on any wrong payment, and while its committed result (src/lib/data/quality-lab.json, src/lib/data/quality-lab-shadow.json) is not what the run gives. After a change to the decision code, the scenarios or the exported decisions:

npm run quality-lab   # runs the scenarios and the replay and writes both result files; commit them

docs/self-hosting.md covers the rest: environment variables, the founding workspace, every script, going live per path, the scheduled jobs (Supabase Cron), Circle notifications, GitHub, and what is live versus simulated.

License

MIT. Zoho, Zoho Books and Zoho CRM are trademarks of Zoho Corporation Pvt. Ltd. Google Sheets and Google Drive are trademarks of Google LLC. Arc, Circle, Slack, Telegram, Discord, Xero, QuickBooks, HubSpot, Pipedrive, Asana and npm are trademarks of their respective owners; their names show what Vestiarion is built on and connects to, not an endorsement.