Vestiarion

An AI treasury agent that pays a business's bills in USDC on Arc, inside limits a contract enforces and a signed ledger proves.

Open the app · Watch the demo · See your first decision · Open numbers · Docs · @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 the money itself can only leave through a spending-limit contract the owner's own 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 (4:58), both recorded on the live product on October 12, 2026: a new workspace and its first payments, a freelancer paid by the agent on its own, a first payment code holds for a person, shadow mode, Xero, QuickBooks Online, HubSpot and GitHub, treasury, Arc mainnet and the public numbers.

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

• 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

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 -> follow-up -> recurring -> services -> liquidity -> AP -> contractors -> treasury -> forecast -> proposals -> collections -> notices -> telegram -> slack, 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, settled in 3 s: 0xcecef38e…dee6.

Contract: 0xd90cA89Fc318d0330Bb14eaeF78B72C3CA7E7fB6. 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.

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, or sent through the API; recurring payables; early-payment discounts taken when they pay.
• 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 or 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.
• 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).
• 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. 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, four roles, per-member notifications.
• 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

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.

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.

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. Arc, Circle, Slack, Telegram, 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.