Vestiarion v0.1.0-beta.14 — Free tools, the monthly close pack and the Quality Lab

The fourteenth beta of Vestiarion. Four free tools now run in anyone's browser, with no sign-up: a payment terms
calculator, an OFAC check for a whole vendor list, a check of a bill list for duplicates and deadlines, and the
address checker that was already there. A workspace opened from one of them is counted for it in Vestiarion's own
growth figures. For the books, an owner or their accountant gets one page per month that lists every payment Circle
confirmed, what was checked before it, and the signed ledger entry that records it. The page can be downloaded, read
through the API or sent to Google Sheets. The Quality Lab runs fixed scenarios, and the team's own shadow-mode
decisions, through the real decision code on every change, and fails CI when any of them makes a wrong payment.
Also in this release:

• a vendor's document is checked against its bill, and a note the AI reader (the workspace's model) wrote about it is
  quoted on the bill's card, marked as its words, not Vestiarion's;
• in shadow mode, the report shows how often you agreed with the agent, by decision and by vendor;
• the landing page follows the payee lock holding a payment on Arc testnet, in the team's own workspace;
• Slack lists the bills waiting for approval, each with a Review button;
• a PDF built to expand when opened is refused, and one that cannot be measured is read within limits;
• the repository has a contributing guide, a code of conduct and an accessibility statement.

This release covers 22 merged pull requests (#516 to #537) since
v0.1.0-beta.13. Each change passed CI.

• Reviewed by an independent reviewer before merge: #517, #518, #519, #520, #522, #523, #524, #525, #526, #527,
  #528, #529, #530, #531, #532, #533, #534, #535 and #536.
• Not reviewed by an independent reviewer before merge, as far as the pull requests record: #516, #521 and #537.
  • #516 and #521 change only release docs: the notes and CHANGELOG section for v0.1.0-beta.13 (#516), and the SDK
    versions listed in docs/RELEASING.md (#521).
  • #537 adds /robots.txt.

The notes for v0.1.0-beta.13 (#516) were merged after the commit that release's tag is on, so their one commit is in
this release and is counted among the 22. They change no code.

Production deploys from main on every merge, so it may already run changes newer than this list.

Highlights

• Four free tools, no sign-up (#533, #534, #535, #536, #537). Each tool runs in the browser, and nothing typed or
  pasted is sent anywhere or kept. Each page says it may count the visit and a click on Try it on your bills, by
  the page's address, and its start links can set a first-touch cookie (below).

  • Payment terms calculator (#534), at /payment-terms. Enter an
    invoice's date, amount and terms, such as 2/10 net 30, net 45 or net 30 EOM. It gives:

    • the due date and the discount deadline;
    • what skipping the discount costs a year, each with its formula: for 2/10 net 30, 37.2% simple on 365 days, 36.7%
      simple on 360 days and 44.6% compounded;
    • the break-even rate, and a late fee after any number of days;
    • one decision, "Pay on" a day, with its reason, from the same written policy the agent's decisions are checked
      against.

    Terms it can read only in part are refused, never guessed. Seven pages explain common terms with a worked example.

  • OFAC vendor check (#535), at /check-vendor. Type one vendor, or
    paste or drop a whole list of up to 5,000 rows.

    • Each name written in Latin letters is compared with every name and other name on OFAC's SDN list as of Oct 28,
      2026. A name written only in another script is marked not compared, not cleared.
    • Each wallet is compared with the addresses OFAC's list gives, and each 0x wallet also with the other 0x wallets
      in your list, so one made to look like another vendor's is caught.
    • A possible match says why it matched and links to Treasury's own search, and the results download as a CSV.

    It covers the SDN list only, and says it is a first look, not a compliance decision.

  • Bill list check (#536), at /check-bills. Paste rows, or drop a CSV
    from QuickBooks, Xero, Zoho Books or a sheet. It lists:

    • bills that may repeat each other, scored by the agent's own duplicate rule, plus invoice numbers written
      differently (BP-1042 and bp 1042);
    • bills of the same amount about a month apart, to check each is a new month's bill;
    • early-payment discounts ending, and late fees starting, in the next 7 days, with what each is worth.

    Its sample list of made-up vendors finds 2 likely duplicates, 1,700 USD at stake.

  • Counting which tool brought a workspace (#533). On a tool's page, Try it on your bills and the footer's
    Get started set Vestiarion's first-party vx_ft cookie when the browser holds no first touch yet.

    • It holds the tool's name and page, the site that linked to it when the page was opened straight from that link,
      and the time, never anything typed.
    • A workspace opened next in that browser within 90 days is counted for that tool in Vestiarion's own growth
      figures, sign-in included. An earlier campaign's first touch is never replaced.
    • The privacy page says so. The footer has a Free tools group, and the sitemap lists every tool.

  • Search engines can find them (#537). /robots.txt now names the sitemap. Before, it answered with the
    not-found page.

• The monthly close pack (#517, #519, #520, #525).

  • One page per month (#517). Every payment Circle confirmed in a month, one row each, with:

    • the bill, with its invoice number and document;
    • who decided and approved it, an accountant's co-sign included;
    • what was checked before it was paid;
    • the transaction, with its explorer link;
    • the signed ledger entry that records it, verified against the workspace's keys.

    Print or save as PDF, Download CSV and Download signed JSON, which carries the cited entries and the
    workspace's public keys. Each download is recorded in the ledger. Open it from the Audit log or the accountant
    console.

  • Google Sheets (#519). An owner or admin connects one Google account per workspace. Export to Google Sheets
    writes the month to a spreadsheet in that account's Drive: a Payments tab with 51 columns and a Summary
    tab. Every cell is written as a value, so nothing runs as a formula. Vestiarion asks Google only for access to the
    files it makes.

  • Through the API, and SDK 0.4.0 (#520). A workspace API key reads the same signed files the pages download, with
    members named by user id instead of email:

    • one payment's evidence;
    • a paid bill's receipt;
    • the payee lock's evidence for a period;
    • a month's close pack.

    The TypeScript SDK 0.4.0, on npm, has a method for each, and verifyEvidence checks any of these files offline.

  • Faster (#525). The page starts each read as soon as what it needs is in, so its reads take three rounds
    instead of five or six. Its files are the same, byte for byte.

• Vendor documents checked against the bill (#518, #522).
  • While vendor requests are in shadow or on, each PDF a vendor sends for a bill's missing purchase order or goods
    receipt is read within a minute. A rule-based reader reads it, and so does the workspace's AI model when one is
    set up; that model's provider then receives the PDF's text, as the privacy page lists.
  • Code then checks the document's vendor, currency, amount, purchase order and any address it asks to be paid to
    against the bill.
  • With requests on, a match adds the purchase order and nothing else. The agent then holds the bill for a person: it
    never pays such a bill on its own.
  • A mismatch keeps the bill waiting and gives the reason, such as "The document says 8.50 USDC; the bill says 8.00
    USDC." Owners and admins can also Attach a document a vendor emailed them.
  • When the AI reader notes something for a person, such as a changed bank account, the card now quotes that note as
    the reader's words, cleaned of links, hidden characters and codes (#522).
• The Quality Lab (#526, #527).
  • Fixed scenarios (#526). 39 scenarios run in CI through the agent's real decision code, with the model's
    answers scripted, often to what an attacker would want: prompt injection in an invoice, a payee whose address just
    changed, OFAC's list, the limits, a repeat of a paid bill, a send whose answer was lost.
  • A wrong payment in the lab fails CI. Any of these counts as one:
    • a transfer or a schedule where money should stop;
    • a transfer to another address, or for another amount;
    • a second transfer for one bill.
  • Replayed decisions (#527). The team's own shadow-mode decisions are rebuilt from their signed ledger entries and
    replayed through today's code. Of 46 decisions: 37 reach the same outcome and 9 cannot be rebuilt from their
    record, with 0 wrong payments.
  • The results are on Open numbers and How the agent decides. Every scenario is in
    the docs. The Quality Lab tests the code, not the model's own judgement.
• How often you agreed, before a live slice (#523). In shadow mode, the report's Before a live slice shows how
  often you agreed with the agent, by what it decided and by vendor, each with the number of verdicts behind it. Under
  five verdicts it says Too few to tell yet. Each vendor shows the same figure beside its checkbox under Start
  the live slice. It only measures, and changes nothing the agent may do.
• The payee lock on the landing page (#524). The safety section names the p...

Vestiarion v0.1.0-beta.13 — Evidence for your accountant, vendor documents and late fees

The thirteenth beta of Vestiarion. This release brings the people around a small business's bills into the workspace.
An accountant can co-sign larger bills, sees what waits for them, and can invite a client with one link. A vendor can
be asked for a bill's missing purchase order or goods receipt, and its statement of account can be checked against
the books. A bill can carry the late fee its supplier charges, so waiting shows what it costs. Also in this release:

• the payee lock's evidence pack, for an insurer or an accountant, and a payee's own contact asked "Was this you?" when
  its address changes;
• a payout address on OFAC's sanctions list is never paid, and an invoice that asks to be paid elsewhere is held;
• the approval card and the receipt say what a payment costs and who paid each fee;
• Arc mainnet pays vendors on Arbitrum, as well as on Base;
• bills waiting for a person are posted to Discord and Telegram, each with a link to review it;
• every page enforces a Content Security Policy.

This release covers 45 merged pull requests (#471 to #515) since
v0.1.0-beta.12. Each change passed CI.

• Reviewed by an independent reviewer before merge: #471, #472, #474, #475, #476, #477, #478, #479, #480, #481,
  #482, #484, #485, #487, #488, #495, #504, #511, #512, #513, #514 and #515.
• Not reviewed by an independent reviewer before merge, as far as the pull requests record: #473, #483, #486,
  #489, #490, #491, #492, #493, #494, #496, #497, #498, #499, #500, #501, #502, #503, #505, #506, #507, #508, #509 and
  #510.
  • Six of them change only the README or the docs: #473, #486, #489, #501, #502 and #510.
  • The others include the Arbitrum payouts (#498), the hold on an invoice that asks to be paid elsewhere (#483), the
    enforced Content Security Policy (#490), Discord (#508, #509), the accountant console (#507), the statement check
    (#503, #505) and screening health (#506).

The notes for v0.1.0-beta.12 (#470) were merged after its tag, so their one commit is in this release too. They change
no code.

Production deploys from main on every merge, so it may already run changes newer than this list.

Highlights

• Your accountant, in the workspace (#503, #504, #505, #507, #513).

  • Co-sign (#504). In Settings, under Two approvals, an owner can choose Let accountants co-sign. An
    accountant's Co-sign on a bill above the two-approvals figure records one of the two approvals and never pays,
    so the approval that pays is always an owner's, admin's or approver's. A founder alone with their accountant can
    then use two approvals. It is off by default, and milestones are not co-signed.

  • What waits for them (#507). The accountant console lists each bill waiting for their co-sign and each changed
    address no one has confirmed. A bill that cannot be co-signed says why, in place of a button that would be refused.
    The month's hand-off lists co-signs among the decisions.

  • Invite a client with one link (#513). On the accountant console, under Invite a client, an accountant makes
    a one-time link that works for 7 days. The client opens it signed in, names a workspace and gives consent. The
    workspace opens as theirs, on Arc testnet in shadow mode, with the accountant already in it. Only the link's
    SHA-256 is kept. Going live offers to bring the accountant along.

  • Check a vendor's statement (#503, #505). On Counterparties, Check their statement reads a vendor's
    statement of account, pasted or as a CSV, and matches each line to your bills and your payments. It lists:

    • what is missing here, with an Add for each;
    • what is listed twice, and amounts that differ;
    • payments of yours they have not credited, with the transaction to send them;
    • payments they list that you have no record of;
    • both balances.

    Nothing is paid or changed.

• Vendors send what a bill is missing (#512).
  • In Settings, beside the payee lock, an owner sets Ask vendors for missing documents to off (the default),
    shadow or on.
  • On, when a bill waits for its purchase order or goods receipt and its vendor has a billing email, Vestiarion
    emails the vendor a one-time link in the workspace's name. Without an account, the vendor sends one PDF, PNG or
    JPEG of up to 10 MB, and may type the purchase order number and a note.
  • The file is kept in the workspace's private storage, and the bill's card, on Approvals and on Bills, shows what
    arrived.
  • Nothing is paid because a document arrived: a person adds the details, and the agent decides the bill again.
  • In shadow, nothing is sent, and each card says what Vestiarion would ask.
• Late fees (#514). A bill can carry the late fee its supplier charges: a percent a month, or a fixed amount, from
  the day it starts. It is entered in the invoice form, through the API or in an imported list, or read from a
  document, an email, the Chrome extension or a chat. A late fee is never added to what is paid; it shows what waiting
  costs:
  • the approval card's cost box ends with "Late after date" and what a month of the fee costs;
  • past its due date, a bill names the fee beside its decide-by day, in Approvals, on Bills & receivables and in the
    accountant console;
  • past the due date, one more escalation email comes on the eve of the fee, while paying still avoids it;
  • when cash is short, the written policy pays first, among the bills due or overdue, the one whose fee costs most in
    the coming month.
• Proof of how each changed address was checked (#474, #479, #502).
  • Any member opens the payee lock's evidence pack from Settings, under Payee lock, for a period they choose.
  • It shows one row per payout address change: who entered the address, how it was checked and whether by a second
    person, the lock's wait, the payments the agent held for it, and its first payment.
  • It answers, from those records, the questions insurers ask about changed payment details.
  • It prints, saves as a PDF, downloads as CSV, and downloads as a JSON file carrying every ledger entry it cites, to
    check offline.
  • A new guide, Share the evidence pack and receipts,
    walks an owner or their accountant through it.
• Fewer ways to pay the wrong address (#475, #477, #483, #488, #492, #493, #494).
  • Sanctioned addresses (#475). Every cycle checks each counterparty's payout address against the addresses on
    OFAC's SDN list, read every 12 hours in production. A listed address makes the counterparty high risk, and the
    agent, Approve and pay and Pay now refuse to pay it.
  • An invoice that asks to be paid elsewhere (#483). When an invoice read from a document asks to be paid to an
    address that is not the counterparty's address on file, the agent holds the payment for a person, naming both
    addresses. Approve and pay still pays only the address on file.
  • "Was this you?" (#488). When a payee's address changes, its billing email on file is asked, through a one-time
    link, whether they made the change. "No, this wasn't me" freezes the payee: no one can confirm its address and no
    approval pays it until an owner or admin checks with them and unfreezes it, saying how.
  • The payee lock starts on for a new Arc mainnet workspace (#492). Workspaces already on Arc mainnet keep their
    setting.
  • ENS names and Basenames (#493). Type northwind.eth or northwind.base.eth in a payee's address field to see
    the address it points to. Only the address is saved.
  • The weekly brief (#494) has a Payee addresses section in a week when a payee's address changed.
  • A free address lookalike checker (#477) at /check-address. It runs
    in the browser: nothing pasted is sent anywhere.
• What a payment costs, before and after (#495, #496, #499, #500).
  • The approval card shows the invoice, an early-payment discount that still applies, the fee for a payee on another
    chain, what leaves the wallet in all, and what the payee receives (#496).
  • A bank payout's card compares it with USDC sent to a wallet, where no fee is taken (#500).
  • A payee link that lets a vendor choose a network says what each one costs the business (#499).
  • A shared receipt lists the invoice and its number, the discount, the route's fee and who paid it, and what the
    payee received, read from their chain. It saves as a PDF (#495).
• Pay a vendor on Arbitrum from Arc mainnet (#498, #501).
  • Arbitrum joins Base as a chain Arc mainnet pays across to through CCTP, in real USDC. Circle quoted about
    0.077 USDC to forward a payout there on Oct 22, paid on top of the invoice.
  • The TypeScript SDK 0.3.6 accepts ARB.
  • Proven on Oct 22 from the team's own test workspace, for a 1 USDC bill the workspace's only approver approved:
    • burn on Arc;
    • 1 USDC minted on Arbitrum.
• Bills that wait for you, where you already talk (#508, #509, #511, #515).
  • Discord (#508, #509). An owner or admin pastes a channel webhook's URL in Settings. After each cycle, the
    bills held, flagged or waiting for details are posted to that channel, each with a link to review it. Vestiarion
    reads no message in Discord.
  • Telegram (#511). The message after each cycle ends with the bills still waiting, each with Review.
  • Why code stopped a bill (#515). In those messages and in /waiting, a bill a check in code stopped now says
    what stopped it, in the words of its row on Bills & receivables, inst...

Vestiarion v0.1.0-beta.12 — The payee lock

The twelfth beta of Vestiarion. The costliest fraud a small business meets is a payee's payout details being changed
to the fraudster's. This release adds a payee lock: when it is on, a changed payout address is paid only after a
second person records how they checked it, and optionally only after a wait. Also in this release:

• payees send their invoice, and choose where they are paid, through their payee link;
• the app's functions now run beside the database, so pages and actions answer several times sooner;
• the landing page now follows one recorded bill from start to finish;
• the public pages share one visual system.

This release covers 14 merged pull requests (#456 to #469) since
v0.1.0-beta.11. Each change passed CI.

• Reviewed by an independent reviewer before merge: #457, #458, #459, #461, #462, #463, #464, #466 and #468.
• Not reviewed by an independent reviewer before merge, as far as the pull requests record: #456 (the beta.11 notes), #460, #465, #467 and #469.

Production deploys from main on every merge, so it may already run changes newer than this list.

Highlights

• The payee lock (#466, #467, #468).

  • An owner turns it on in Settings, under Payee lock. It is off by default, so nothing changes for a
    workspace that leaves it off.
  • Confirm address now asks how the address was checked: a call or a message to a contact held before the
    change, in person, or another way, with the contact used and a note. The record is signed with the confirmation.
  • With the lock on:
    • the record is required;
    • whoever entered or asked for the address cannot confirm it while another member can;
    • approving a payment no longer confirms its address;
    • an optional wait of 4 to 72 hours keeps a changed address from being paid, confirmed or not. The agent holds a
      payable as counterparty.cooling_off and decides it again when the wait ends. A verified milestone waits too,
      and its card on Contractors reads "Payee lock wait".
  • With the lock on or off, Counterparties warns about an address that matches or looks like another payee's, or
    like one the same payee had before, which is how address poisoning works.
  • Checked live in the team's own Arc mainnet workspace:
    • turning the lock on was signed;
    • a weak record was refused;
    • a confirmation with a record was signed with its 24-hour wait.

  No money moved in that check.

• A payee sends its invoice through its link (#458, #460, #462).

  • A payee link can also ask for the payee's invoice: number, amount in USDC, due date, and the file's text and
    SHA-256. The invoice lands in Bills → Waiting for review.
  • It can also let a vendor with no address choose where it is paid: Arc mainnet or Base, or Arc testnet or a
    Sepolia chain.
  • The page moves to its next step as soon as an answer is accepted, and names the payee's chain.

• Pages and actions answer sooner (#463).

  • The app's functions moved from Washington to Tokyo, beside the database.
  • Measured on production, time to the last byte, before → after:
    • Bills: 6.3 s → 1.0 s;
    • Treasury: 4.4 s → 0.7 s;
    • Counterparties: 3.4 s → 0.5 s;
    • a payee link's step: 1.7 s → 0.4 s;
    • creating a payee link: 3 to 7 s → 1.1 s.

• A landing page that follows one bill (#457, #459, #461).

  • It follows a bill from the team's own workspace through the agent's checks, the coded hold, a person's approval
    and the payment, with signed ledger entries and explorer links.
  • The hero names the decisions it shows.
  • It rests on a shared visual system.

• Public pages in the same system (#465, #469). The payee, supplier, payment, receipt, statement and sign-in pages
  share the landing's look and have larger touch areas on phones. The sign-in card ends at its button.

• A fix (#464). "Pay early for a discount" was hidden, with an error in the logs, in workspaces without a
  reserve. It shows again.

Database

Three new migrations, applied in production before this release:

• 0133_payee_link_invoices.sql
• 0134_landing_team_journeys.sql
• 0135_payee_lock.sql

The total is 128 (0001_init.sql to 0135_payee_lock.sql; numbers 0091 to 0093, 0096 to 0098 and 0119 are unused).

Known limitations

• Beta. Screens, wording and features change often. The spending-limit contracts (versions 1 and 2) and the
  escrow contract have not been audited.
• The payee lock covers addresses on Arc and the chains it pays. A bank payout already waits for a person every
  time, so the lock adds nothing there. It has been checked live in the team's own workspace only. No customer has
  turned it on yet.
• Base only, USDC only, across chains on Arc mainnet.
• No customer has paid a real bill on Arc mainnet yet. The Arc mainnet payments so far are the team's.
• Bank payouts run on BlindPay's development instance, to vendors in Mexico over SPEI only.
• QuickBooks Online still connects to sandbox companies only, until Intuit's app assessment is complete.

Contributors

• Nguyen Quoc Duong (@duongnq2798): 14 merged pull requests and 25
  commits in this release. Built with Claude (Anthropic) as an AI pair programmer, credited as co-author on most
  commits.
• Codex (OpenAI) wrote the visual-system and landing pull requests (#457, #459, #461, #465), which were reviewed and
  merged by the maintainer.

This release

• Tag v0.1.0-beta.12 is on commit 8e4751b, the merge
  of #469, where CI's verify passed.
• It is a prerelease, so it is not marked Latest.
• The changes for business readers are in
  CHANGELOG.md.
• How releases are made is in
  docs/RELEASING.md.

What's Changed

Other changes

• Write the release notes for v0.1.0-beta.11 by @duongnq2798 in #456
• Add shared visual foundations for the bill journey by @duongnq2798 in #457
• Let a payee send its invoice and choose where it is paid through its payee link by @duongnq2798 in #458
• Rebuild the landing around a bill journey by @duongnq2798 in #459
• Explain recorded decisions in the landing hero by @duongnq2798 in #461
• Move a payee link to its next step as the action answers by @duongnq2798 in #460
• Answer the payee before the members' email, and name the payee's chain by @duongnq2798 in #462
• Run the functions in Tokyo, beside the database by @duongnq2798 in #463
• Show early-payment offers in a workspace with no reserve by @duongnq2798 in #464
• Apply the visual system to public pages by @duongnq2798 in #465
• Add the payee lock: a recorded check by a second person before a changed address is paid by @duongnq2798 in #466
• Say until when a confirmed address still waits under the payee lock by @duongnq2798 in #467
• Show the payee lock's wait on a verified milestone's card by @duongnq2798 in #468
• End the sign-in card at its button by @duongnq2798 in #469

Full Changelog: v0.1.0-beta.11...v0.1.0-beta.12

Vestiarion v0.1.0-beta.11 — Pay contractors on Base from Arc mainnet

The eleventh beta of Vestiarion. A business on Arc mainnet can now pay a vendor's USDC address on Base, where most
contractors who want USDC already hold it. It works from the workspace's own Circle account, and from the owner's own
wallet through a new version of the spending-limit contract. Both routes were proven with real USDC on Oct 19, 2026.
The rest of the batch is about bringing people in and keeping them:

• a one-time reminder to a workspace that stops before its first bill or first verdict;
• a prompt to bring in an approver and the accountant;
• one step to ask every payee for an address;
• pages and emails a counterparty gets now say who sent them;
• a rewritten landing page.

This release covers 15 merged pull requests (#441 to #455) since
v0.1.0-beta.10. Each change passed CI. The
payment changes (#453, #454) were reviewed by an independent reviewer before merge and then tested with real USDC on
Arc mainnet. The review of #453 also found and fixed a defect that predates it: a milestone for a vendor on another
chain would have been paid on Arc. Production is deployed from main on every merge, so it may already run newer
changes than this release lists.

Highlights

• Pay a vendor on Base from Arc mainnet (#453).
  • Arc mainnet now lists Base as a chain a vendor can be paid on, through Circle's CCTP V2 with its Forwarding
    Service. The operating wallet burns the USDC on Arc, Circle mints it to the vendor on Base, and the vendor needs no
    gas there.
  • The fee (about 0.055 USDC when tested) is read before the agent decides and again before the burn, paid on top of
    the invoice, and held for a person above 10% of the bill. A payment counts as paid only once it is minted on Base.
  • This route runs from a workspace on its own Circle account.
  • A milestone is never paid across chains: a vendor on another chain cannot be given one, and one made earlier is
    held.
  • A live slice carries a vendor on Base Sepolia over as a vendor on Base, without the address.
  • TypeScript SDK 0.3.5 accepts BASE.
  • Proven on Arc mainnet:
    • burn on Arc;
    • 1 USDC minted on Base.
• Pay a vendor on Base from your own wallet (#454).
  • Version 2 of the spending-limit contract adds payAcrossChains. The agent's wallet, which holds only gas, asks
    the contract to pay. The contract takes the payment and its CCTP fee from the owner's wallet, counts both against
    its daily and 7-day figures, and burns them for Base, so the agent never holds the owner's USDC.
  • The contract itself refuses a fee above 10% of the payout or above 2 USDC, and any chain but Base.
  • Every new setup deploys version 2. A workspace on version 1 upgrades from Go live, in one passkey confirmation
    or three wallet steps.
  • Proven on Arc mainnet from a passkey wallet, in a workspace that began in shadow mode:
    • payAcrossChains on Arc;
    • 1 USDC minted on Base.
  • In both tests the agent read the live fee and chose to pay on the due date, the first-payment guardrail held the
    bill, and the workspace's only approver approved it.
• A reminder when a workspace stops (#452).
  • A customer workspace with no real bill a day after it was opened gets one email with the ways to give the agent a
    bill.
  • A workspace in shadow mode whose agent's decisions still wait for a first verdict three days on gets one email
    saying how many wait.
  • Each email goes once per workspace. The agent tick sends them, since its scheduled cycles reach only live
    workspaces.
  • The founder dashboard counts the workspaces reminded and how many came back.
  • The first two went out on Oct 19.
• Bring in a second person (#450). While one person runs a workspace, Treasury asks an owner or admin to invite an
  approver and the accountant, and the weekly summary adds an invite link.
• Ask every payee for an address at once (#442). On Counterparties, one step sends every vendor and contractor
  with no address of its own a payee link, emailed where the payee has a notice email.
• Counterparties see who sent a page or email (#449). The supplier status page, payee link, receipt and the emails
  a counterparty gets now say which business sent them, with a link back to Vestiarion tagged so the founder dashboard
  counts the workspaces it brings.
• A new landing page (#443 to #447, #451). Questions an owner asks first, proof that leads with one real payment on
  Arc mainnet, who holds each safety rule, what each integration does, real code for each developer way in, and a page
  that stays still at rest.
• Smaller fixes (#448, #455).
  • Docs tables keep names and codes whole.
  • Get started counts the USDC in the owner's own wallet as soon as the workspace goes live.
  • The README shows the two Arc mainnet to Base proofs.

Database

One new migration, applied in production before this release: 0132_spending_limit_v2.sql. Two existing
migrations were edited so the chain check allows BASE for a vendor, 0044_cctp_payouts.sql and
0078_mainnet_go_live.sql. db:migrate re-runs every file, and the change is applied in production.
0044_cctp_payouts.sql now rewrites unknown chains only on its first run.

The total is 125 (0001_init.sql to 0132_spending_limit_v2.sql; numbers 0091 to 0093, 0096 to 0098 and 0119 are
unused).

Known limitations

• Beta. Screens, wording and features change often. The spending-limit contracts (versions 1 and 2) and the escrow
  contract have not been audited.
• Base only, USDC only. Arc mainnet pays across chains to Base alone; other chains, and EURC across chains, are not
  offered there yet.
• Proofs are the team's. Both Arc mainnet to Base payouts were made from the team's own test workspaces. No
  customer has paid a real bill on Arc mainnet yet.
• The live slice has not yet carried a shadow-mode business to its first real payment.
• Bank payouts run on BlindPay's development instance. Only vendors in Mexico, over SPEI.
• QuickBooks Online still connects to sandbox companies only, until Intuit's app assessment is complete.

Contributors

Nguyen Quoc Duong (@duongnq2798): 15 merged pull requests and 35 commits in this
release, built with Claude (Anthropic) as an AI pair programmer, credited as co-author on most commits.

This release

• Tag v0.1.0-beta.11 on commit
  769dc26, the merge of
  #455, where CI's verify passed.
• A prerelease, so it is not marked Latest. The changes for business readers are in
  CHANGELOG.md; how releases are made is in
  docs/RELEASING.md.

What's Changed

Other changes

• Write the release notes for v0.1.0-beta.10 by @duongnq2798 in #441
• Ask every payee for an address at once by @duongnq2798 in #442
• Rewrite the landing page's questions around what an owner asks first by @duongnq2798 in #443
• Lead the landing's proof with one real payment on Arc mainnet by @duongnq2798 in #444
• Show who holds each safety rule on the landing, with one real refusal by @duongnq2798 in #445
• Show what each landing integration does, with Xero's loop and one page for all by @duongnq2798 in #446
• Show real code for each developer way in on the landing by @duongnq2798 in #447
• Keep names and codes whole in docs tables by @duongnq2798 in #448
• Say who sent every page and email a counterparty gets by @duongnq2798 in #449
• Ask a workspace run alone to bring in an approver and its accountant by @duongnq2798 in #450
• Keep the landing still at rest, and let the hero's sample bill check itself by @duongnq2798 in #451
• Remind a workspace that stopped before its first bill or first verdict by @duongnq2798 in #452
• Pay a vendor on Base from Arc mainnet through CCTP by @duongnq2798 in #453
• Pay a vendor on Base from your own wallet through version 2 of the spending limit contract by @duongnq2798 in #454
• Tick Fund it with USDC from what the agent can move; add the Arc mainnet to Base proof by @duongnq2798 in #455

Full Changelog: v0.1.0-beta.10...v0.1.0-beta.11

Vestiarion v0.1.0-beta.9 — The agent works through a cash shortfall

The ninth beta of Vestiarion. This batch is about the days when the cash is short. The agent now chooses which bills
get the cash first and says why, asks suppliers for more time and answers their counters, and offers customers a
discount to pay sooner. It checks scheduled payments against the cash ahead, and tells the owner before the cash runs
short. Every Monday it sends a brief of the week, and businesses in shadow mode get one about their verdicts. The main
guides open with a short video.

This release covers 22 merged pull requests (#409 to #430) since
v0.1.0-beta.8. Not every change in this
batch was reviewed by an independent reviewer before merge. The five largest were (#412, #418, #420, #427, #429), and
those reviews found 33 defects, of which 31 were fixed before merge. One was documented as a limitation, and one, an
index, waits for a migration. Each change passed CI, and each feature was tested end to end on the live product,
where the live tests found the defects fixed in #415, #416, #417, #419, #422 and #430. Production is deployed from
main on every merge, so it may already run newer changes than this release lists.

Highlights

• The agent chooses which bills to pay first (#429, #430).
  • When the bills due within 14 days add up to more than the cash, the model orders them by what costs the business
    most to pay late, saying why for each. The written policy's date order is its reference and its fallback.
  • Code keeps bills in that order only while the cash lasts, so the agent never keeps more than the wallet holds. It
    holds the rest for a person, even a bill the model would pay.
  • The choice is signed once as cash_priority_set, and reused with no model call while the bills stay the same.
  • Proven on Arc testnet, with 57.03 USDC and two bills due the same day: the written policy would have paid a 30 USDC
    one-off archive migration and left no room for the 50 USDC database backups. The agent paid the backups and held
    the migration: "The production database backups stop if this 50 USDC monthly renewal on Oct 17, 2026 is unpaid,
    so it costs the most to delay." Earlier, with 147.03 USDC, it kept 45 USDC hosting and storage bills over a
    140 USDC one-off render job the policy would have paid first.
  • The live test found the model misreading a supplier's history: it read a request the agent withdrew as the
    supplier's yes, then a counter the agent declined as its no. #430 tells it how each request ended.
• Requests for more time (#411, #413, #414, #415, #417, #419).
  • When the operating wallet cannot pay a bill due within two weeks, the agent emails the supplier a one-time link
    asking for the same amount on a later day. An owner or admin turns it on, with the most days it may ask.
  • The supplier agrees, declines, or proposes fewer days. The agent answers a counter itself: it accepts only a date
    the business can keep, with what it holds and what customers owe by then.
  • The agent withdraws a request it no longer needs, when money comes in or the bill is no longer held, and tells the
    supplier.
  • Code works out when a bill is covered and gives the model that. Only a supplier's own decline pauses further
    requests to it, and the model is told which requests the agent took back.
  • Proven: the agent asked for 5 more days on a 150 USDC bill, the supplier proposed 3, and the agent declined, since
    the bill was not covered by then. A request on a 140 USDC bill was withdrawn, and the supplier told, once cash came
    in.
• Customer discounts while cash is short (#412). When bills are held for want of cash, the agent can offer customers
  a small discount, within the most an owner or admin sets, to pay an open invoice within 5 days. Proven: a customer
  accepted and paid 29.925 USDC on a 30 USDC invoice, and the agent matched it at the discount.
• Scheduled payments checked against the cash ahead (#418). Each cycle the agent measures every USDC bill scheduled
  for a later day, and decides again now one the cash will not cover then. That gives it days to ask for more time or
  offer discounts. Proven: two 45 USDC bills set for Oct 24 and 25 were held a week early.
• Told before the cash runs short (#420, #421). A new cycle stage, cash_alert, says once in the console,
  Telegram and Slack how much is needed and by when, what customers owe by then, and what the agent is already doing.
  It says it again only when that changes, and says when the cash covers everything again. The amount is rounded up to
  the cent.
• The weekly brief (#427, #428).
  • 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, and whether the cash covers the next 30 days.
  • In shadow mode, the brief reports the verdicts instead, and how often the business agreed with the agent.
  • Send me this week's summary, in Settings, sends it at once. Both were proven by email.
• A short video for each main flow (#423, #425, #426). Twelve guides open with a narrated walkthrough of two
  minutes or less, recorded in the live product, with a transcript. The demo and product tour are voiced again, and
  every video is linked on YouTube.
• The landing page's proof says which rule decides (#410). Rules in code decide; the written policy is kept only
  to compare. The FAQ says how long it takes to start and what it costs.
• Fixes.
  • Receipts and evidence pages check Arc testnet again, at its new RPC address (#422).
  • Leaving Bills & receivables no longer asks about a bill already added (#416).
  • The live provider tests no longer reach the network (#424).
• Release notes (#409) for v0.1.0-beta.8.

Database

Three new migrations, each applied in production before this release: 0128_term_requests.sql,
0129_customer_discounts.sql and 0130_term_counters.sql.

The total is 123 (0001_init.sql to 0130_term_counters.sql; numbers 0091 to 0093, 0096 to 0098 and 0119 are
unused).

Known limitations

• Beta. Screens, wording and features change often. The spending-limit and escrow contracts have not been audited.
• Cash priority covers USDC bills only, not bills paid to a bank account, and does not run in shadow mode. A bill
  waiting for cash that a guardrail would flag is held for cash first, and flagged when it is decided again.
• Requests for more time: accepting a supplier's counter has not been tested live yet.
• The cash alert reads the ledger without an index for its action; one is planned with the next migration.
• Bank payouts run on BlindPay's development instance. Only vendors in Mexico, over SPEI.
• QuickBooks Online still connects to sandbox companies only, until Intuit's app assessment is complete.

Contributors

Nguyen Quoc Duong (@duongnq2798): 22 merged pull requests and 31 commits in this
release, built with Claude (Anthropic) as an AI pair programmer, credited as co-author on most commits.

This release

• Tag v0.1.0-beta.9 on commit
  d4bf5c3, the merge of #430, where CI's verify passed.
• A prerelease, so it is not marked Latest. The changes for business readers are in
  CHANGELOG.md; how releases are made is in
  docs/RELEASING.md.

What's Changed

Other changes

• Say on the landing proof that rules in code decide, not the policy by @duongnq2798 in #410
• Write the release notes for v0.1.0-beta.8 by @duongnq2798 in #409
• Let the agent offer customers a discount to pay early while cash is short by @duongnq2798 in #412
• Let the agent ask suppliers for more time when cash is short by @duongnq2798 in #411
• Withdraw a request for more time once it is no longer needed, and tell it by @duongnq2798 in #413
• Let suppliers propose fewer days on a request for more time by @duongnq2798 in #414
• Give the model the coverage code works out for a request for more time by @duongnq2798 in #415
• Keep New's form clean after a save until something is typed again by @duongnq2798 in #416
• Count only a supplier's own decline toward the 30-day pause on requests by @duongnq2798 in #417
• Check scheduled payments against the cash ahead by @duongnq2798 in #418
• Tell the model which requests for more time the agent took back by @duongnq2798 in #419
• Tell the owner before the cash runs short by @duongnq2798 in #420
• Round what the cash alert says is short up to the cent by @duongnq2798 in #421
• Point Arc testnet reads at rpc.testnet.arc.io by @duongnq2798 in #422
• Add a walkthrough video to each main guide by @duongnq2798 in #423
• Keep the live provider tests off the network by @duongnq2798 in #424
• Say USDC letter by letter in the guide videos, and link three on YouTube by @duongnq2798 in #4...

Vestiarion v0.1.0-beta.10 — From shadow mode to the first real payment

The tenth beta of Vestiarion. This batch is about the people around the agent. Suppliers can see when they will be paid
without asking. A person can change which bills the cash goes to first, and the agent keeps that order. A business that
has watched the agent in shadow mode can open its first real-money workspace on Arc mainnet in one step, with its
suppliers carried over. The scheduled cycles reach every live workspace again.

This release covers 10 merged pull requests (#431 to #440) since
v0.1.0-beta.9. The three features (#436, #437,
#440) were each reviewed by an independent reviewer before merge. Those reviews found 23 defects, and all of them were
fixed before merge. The smaller changes were not reviewed independently. Each change passed CI, and each feature was
tested end to end on the live product, where the live test of #437 found the issues fixed in #439. Production is
deployed from main on every merge, so it may already run newer changes than this release lists.

Highlights

• Start the live slice (#440).
  • On the report of a workspace in shadow mode, under Before a live slice, an owner ticks the vendors to pay in
    real USDC and opens a workspace on Arc mainnet with them. Each vendor carries its name, payment limit, notice email
    and purchase-order setting, so nothing is typed in again.
  • A vendor's own confirmed Arc address is carried and waits for a person to confirm it again there. A mirror address,
    an address on another chain and one not yet confirmed are never carried: the vendor adds its own from a payee link.
  • No bill and no money moves. The new workspace goes live from its own Settings, and the report's last step ticks
    once it is live. Signed as live_slice_started.
  • Proven in production: a shadow workspace opened its live slice on Arc mainnet with two vendors, one own address
    waiting for confirmation and one mirror address left behind.
• A person's order for which bill first (#437, #439).
  • The Payment plan tab shows the agent's order under Which bill first, with each bill's reason and what the
    written policy would pay first. An owner, admin or approver moves bills up or down and saves.
  • The agent keeps that order with no model call while the bills stay the same, and keeps it for the bills still due
    once some are paid. It never pays more than the cash holds. Whoever entered a bill cannot move it ahead on their
    own, unless they are the workspace's only approver.
  • Proven on Arc testnet: a member put a 45 USDC storage bill first, and once 80 test USDC came in, the next cycle
    reopened both 45 USDC bills in that order and scheduled them for their due days.
  • The live test found the reasons naming bills by an internal ref and in dollars, and the model reading the agent's
    own requests for more time as the supplier's offers. #439 fixed both, and closed a maker-checker gap when the cash
    covers no bill.
• A supplier's payment status (#436).
  • An owner or admin sends a vendor a link to its own bills: where each one stands (received, being reviewed, the
    day it is set to be paid, on its way, or paid), what is still to be paid in each currency, and each payment's
    transaction on Arc.
  • The link needs no account. It never says why a bill is held and shows nothing else of the workspace. It works for
    7, 30 or 90 days and can be stopped at any time. In shadow mode it shows no bills.
• Every live workspace gets its scheduled cycle again (#433). The six-hourly cycles ran one workspace after another
  and, with twelve live workspaces, outran their five minutes, so the last workspaces by name got no cycle. Four now run
  at once, and a cycle that cannot finish in time is left to the next run. All twelve were measured finishing in about
  100 seconds.
• Docs and README. The README and ARCHITECTURE describe the Oct 17 batch (#431). The README links the new demo and
  full tour (#432, #434, #435), and the Xero and HubSpot guides link their videos on YouTube (#438).

Database

One new migration, applied in production before this release: 0131_supplier_status.sql.

The total is 124 (0001_init.sql to 0131_supplier_status.sql; numbers 0091 to 0093, 0096 to 0098 and 0119 are
unused).

Known limitations

• Beta. Screens, wording and features change often. The spending-limit and escrow contracts have not been audited.
• The live slice opens the workspace and carries the vendors. No shadow-mode business has made its first real
  payment on Arc mainnet through it yet. Two owners pressing at the same moment can open two slices; the report shows
  the newer one.
• A supplier's payment status is for vendors only, not contractors or customers.
• Cash priority covers USDC bills only, not bills paid to a bank account, and does not run in shadow mode.
• The cash alert still reads the ledger without an index for its action.
• Bank payouts run on BlindPay's development instance. Only vendors in Mexico, over SPEI.
• QuickBooks Online still connects to sandbox companies only, until Intuit's app assessment is complete.

Contributors

Nguyen Quoc Duong (@duongnq2798): 10 merged pull requests and 16 commits in this
release, built with Claude (Anthropic) as an AI pair programmer, credited as co-author on most commits.

This release

• Tag v0.1.0-beta.10 on commit
  52c3bf7, the merge of #440, where CI's verify passed.
• A prerelease, so it is not marked Latest. The changes for business readers are in
  CHANGELOG.md; how releases are made is in
  docs/RELEASING.md.

What's Changed

Other changes

• Write the release notes for v0.1.0-beta.9 by @duongnq2798 in #431
• Link the new demo upload from the README by @duongnq2798 in #432
• Run up to four workspaces' scheduled cycles at once by @duongnq2798 in #433
• Link the new full tour upload from the README by @duongnq2798 in #434
• Drop the bill screenshot from the README by @duongnq2798 in #435
• Show a supplier when it will be paid by @duongnq2798 in #436
• Let a person set which bills the cash goes to first by @duongnq2798 in #437
• Link the Xero and HubSpot videos on YouTube by @duongnq2798 in #438
• Name bills by payee in priority reasons and check a person's order by place by @duongnq2798 in #439
• Start the live slice: open an Arc mainnet workspace from shadow mode by @duongnq2798 in #440

Full Changelog: v0.1.0-beta.9...v0.1.0-beta.10

Vestiarion v0.1.0-beta.8 — The agent negotiates early payment, bank payouts and Zoho

The eighth beta of Vestiarion. The agent now negotiates early payment with suppliers: on a bill it scheduled for later,
it offers to pay today for a discount it picks within the owner's ceiling. The supplier accepts, declines or proposes
a smaller discount by a one-time link. The agent answers the counter itself, within limits code sets, and pays the same
day. A vendor's bills can be paid to its bank account in Mexico, in pesos over SPEI, through BlindPay. Bills and won
deals come in from Zoho Books and Zoho CRM. And code now keeps the agent from paying a bill early when nothing is gained.

This release covers 34 merged pull requests (#375 to #408) since
v0.1.0-beta.7. Unlike earlier betas, not
every change in this batch was reviewed by an independent reviewer before merge. Each passed CI, and each feature was
tested end to end on the live product, where the live tests found the defects fixed in #380 to #388, #393, #394, #396,
#402 and #405. Production is deployed from main on every merge, so it may already run newer changes than this
release lists.

Highlights

• Early-payment offers (#390, #394, #396, #402).
  • Bills & receivables lists the bills the agent will pay later under Pay early for a discount, each with the
    discount worth asking: twice what the cash would earn in the reserve by the due date.
  • An owner or admin offers it to the supplier through a one-time link, kept only as a hash. The supplier's page
    needs no account.
  • An accepted offer puts the discount on the bill, ending today, and the agent pays it at once, after every check.
  • Proven on Arc testnet: a 1.00% offer on a 2.00 USDC bill was paid 1.98 USDC 24 seconds after the supplier
    accepted it.
• The agent makes the offers itself (#398).
  • An owner or admin turns it on with the most the agent may ask.
  • Each cycle, the agent weighs each scheduled bill code allows: in USDC, a week or more out, never offered, the
    supplier reachable, and the cash there to pay it today. The model picks whether to offer and the discount, and the
    link goes to the supplier in a fixed template.
  • Proven: the agent offered 0.50% on a 0.50 USDC bill by email, and paid 0.4975 USDC 23 seconds after the supplier
    accepted.
• Suppliers counter, and the agent answers (#404).
  • On the agent's offer, the supplier may propose a smaller discount.
  • Code declines a counter no better than the reserve's yield, or one the cash cannot cover, without asking a model.
    The model decides the rest, the supplier gets the answer by email, and an accepted counter is paid the same day.
  • Proven: the supplier proposed 0.25% against 0.50%, and the agent accepted and paid 0.01995 USDC.
• Results, cover, activity and a sandbox (#406, #407, #408).
  • Bills says what the offers came to and what paying early saved, as a yearly rate.
  • The agent withdraws its own offers when the cash no longer covers them.
  • Each step shows in the activity toasts, Telegram and Slack.
  • In a sandbox, the agent's offers go to the member who turned them on, who plays the supplier. The sample data
    adds a bill for it to offer.
• No early payment for nothing (#405). When the model chose to pay a bill early with no discount and no shortfall,
  code now schedules it for its due date and says so in the reasoning. A discount, a due or overdue bill, or a day a
  person set still pays today.
• Bank payouts to Mexico through BlindPay (#379 to #388).
  • An owner sets the workspace up from Settings, accepting BlindPay's terms on BlindPay's page.
  • An owner or admin gives a vendor its CLABE, checked before BlindPay sees it.
  • The agent decides the vendor's bills as any other, and a person approves every bank payout after seeing BlindPay's
    quote.
  • On Arc testnet, BlindPay takes its test token USDB, minted from the Bank payouts card, and the agent times those
    bills against the wallet's USDB.
  • Proven on BlindPay's development instance: 10.00 USDB became 173.00 MXN over SPEI.
• Zoho Books and Zoho CRM (#376, #377, #378).
  • Open bills come in from a Zoho Books organization for a person to add.
  • Won deals come in from Zoho CRM with their accounts and contacts, open ones are listed as not won yet, and lost
    ones never come in.
  • Both were proven on a live organization.
• The docs and the landing page.
  • The docs have a new navigation, reading surface and home (#395, #397, #399).
  • The landing page groups its integrations by what each tool does, gives Arc and Circle their own pair, and leads
    each network's proof card with whoever has paid on it (#383, #384, #389, #392, #400, #403).
  • The README's Add to Chrome is drawn like its other buttons (#391).
• Fixes.
  • A migration re-run never narrows the payout route check again (#393).
  • The in-process test database runs on UTC (#401).
• Release notes (#375) for v0.1.0-beta.7.

Database

Six new migrations, each applied in production before this release: 0122_zoho_books_connections.sql,
0123_zoho_crm_connections.sql, 0124_bank_payouts.sql, 0125_early_payment_offers.sql,
0126_agent_early_payment_offers.sql and 0127_offer_counters.sql.

0047_milestone_escrow.sql and 0124 now widen the payout route check only while it lacks their value. The total
is 120 (0001_init.sql to 0127_offer_counters.sql; numbers 0091 to 0093, 0096 to 0098 and 0119 are unused).

Known limitations

• Beta. Screens, wording and features change often. The spending-limit and escrow contracts have not been audited.
• Bank payouts run on BlindPay's development instance, with its test business values. Only vendors in Mexico, over
  SPEI.
• Early-payment offers are in USDC only. The agent offers a bill once, and asks no more than the ceiling an owner
  or admin sets.
• QuickBooks Online still connects to sandbox companies only, until Intuit's app assessment is complete.
• Pipedrive and Asana listings are prepared, not yet submitted.

Contributors

Nguyen Quoc Duong (@duongnq2798): 34 merged pull requests and 44 commits in this
release, built with Claude (Anthropic) as an AI pair programmer, credited as co-author on most commits.

This release

• Tag v0.1.0-beta.8 on commit
  2942560, the merge of #408, where CI's verify passed.
• A prerelease, so it is not marked Latest. The changes for business readers are in
  CHANGELOG.md; how releases are made is in
  docs/RELEASING.md.

What's Changed

Other changes

• Write the release notes for v0.1.0-beta.7 by @duongnq2798 in #375
• Bring open bills in from Zoho Books by @duongnq2798 in #376
• Name each accounting tool's data with its own possessive by @duongnq2798 in #377
• Bring won deals in from Zoho CRM by @duongnq2798 in #378
• Pay a vendor's bills to its bank account in Mexico through BlindPay by @duongnq2798 in #379
• Fix bank payout keys and fund test USDB on Arc testnet by @duongnq2798 in #380
• Give BlindPay's test business owner a well-formed SSN by @duongnq2798 in #381
• Bind BlindPay idempotency keys to what they ask for by @duongnq2798 in #382
• Serve the test document BlindPay's development set-up downloads by @duongnq2798 in #385
• Keep a workspace's BlindPay customer with its terms by @duongnq2798 in #386
• Regroup the hero and show Invoice Capture beside its own Add to Chrome by @duongnq2798 in #384
• Group the landing page's integrations by what each tool does by @duongnq2798 in #383
• Match bank payouts to BlindPay's live answers by @duongnq2798 in #387
• Time bank payouts on Arc testnet against the wallet's USDB by @duongnq2798 in #388
• Show the agent's decision beside each use case, not a receipt by @duongnq2798 in #389
• Offer suppliers payment today for a discount by @duongnq2798 in #390
• Draw the README's Add to Chrome like its other buttons by @duongnq2798 in #391
• Give Arc and Circle their own pair under the landing integrations by @duongnq2798 in #392
• Never narrow the payout route check on a migration re-run by @duongnq2798 in #393
• Keep an early-payment offer's link on screen after it is made by @duongnq2798 in #394
• Redesign the docs' navigation, reading surface and home by @duongnq2798 in #395
• Keep Withdraw and its result on screen around a new offer by @duongnq2798 in #396
• Polish the docs' home and keep one sidebar section open by @duongnq2798 in #397
• Let the agent make early-payment offers itself by @duongnq2798 in #398
• Lead e...

Vestiarion v0.1.0-beta.7 — Invoice Capture on the Chrome Web Store, and safer resends

The seventh beta of Vestiarion. Vestiarion Invoice Capture is on the Chrome Web Store, and the copy you install there
connects with no change on the deployment. When Circle never answered a payment's send, the agent now looks the send up
before it checks or decides anything, and a payment sent again to a new address needs two people behind that address,
like any first payment. The Pipedrive and Asana listings are ready to submit, and the README links a new demo and
product tour.

This release covers 8 merged pull requests (#366 to #374) since
v0.1.0-beta.6. Each change was reviewed by an
independent reviewer before merge, and every defect found was fixed with a test that failed first. Production is
deployed from main on every merge, so it may already run newer changes than this release lists.

Highlights

• Invoice Capture on the Chrome Web Store (#370, #374). Install it with Add to Chrome from
  its store page.
  The store gave it the ID jfhjgbdbolhnneomgifdnjamoldlioan, which Vestiarion now allows as soon as invoice capture
  is on, so the store's copy connects with no change to CHROME_EXTENSION_IDS. A zip to load unpacked stays in the
  guide for where the store is not available;
  every downloaded copy has the one ID pemkppoklecedoebjfgjlgfibbepikki, set by a public key in its manifest. The
  landing page and the README have an Add to Chrome button.
• Look for an unanswered send before anything else (#367, #368). When Circle never answered a payment's send, the
  transfer may have gone through anyway. The agent now looks it up on Circle first, sending nothing: a transfer Circle
  has is recorded as paid, one not listed yet waits for the next cycle, and only a send Circle never took goes on to the
  checks. A payment sent again to an address that two different people do not stand behind is held as
  counterparty.new_payee for a person, and their Approve and pay looks the earlier send up first, so a transfer
  Circle took is recorded rather than sent twice. Each send now records the address it pays.
• Lost batches and escrow releases reconciled in one cycle (#372). Milestones released together in one transaction
  are all recorded paid in the cycle that finds the transaction. A release already sent from an escrow hold is recorded
  as paid, and the hold as released, whatever the contractor's address says now.
• Ready for the Pipedrive Marketplace and the Asana App Directory (#371). What to submit to each, field by field
  within their limits, with the scopes and why each is needed, the reviewers' path, a demo script, the listing images
  and the icons, is in docs/distribution. An
  install started in Pipedrive now leads to the connect page instead of an expired-link error.
• A new demo and product tour (#374). The demo (2:55) and
  the full product tour (7:15), recorded on the live product on October 15, 2026. The
  README says what shipped this week (#369).
• Release notes (#366) for v0.1.0-beta.6.

Database

No new migration: the total stays 114 (0001_init.sql to 0121_invoice_capture.sql; numbers 0091 to 0093, 0096 to
0098 and 0119 are unused).

Known limitations

• Beta. Screens, wording and features change often. The spending-limit and escrow contracts have not been audited.
• Invoice capture sends drafts only to a workspace where the person connecting it is an owner or admin.
• Commissions. When the payout's creator and the partner it pays are a workspace's only approvers, a payout the
  agent holds can be approved by neither.
• QuickBooks Online still connects to sandbox companies only, until Intuit's app assessment is complete.
• Pipedrive and Asana listings are prepared, not yet submitted.

Contributors

Nguyen Quoc Duong (@duongnq2798): 8 merged pull requests and 16 commits in this
release, built with Claude (Anthropic) as an AI pair programmer, credited as co-author on most commits.

This release

• Tag v0.1.0-beta.7 on commit
  3edf49c, the merge of #374, where CI's verify passed.
• A prerelease, so it is not marked Latest. The changes for business readers are in
  CHANGELOG.md; how releases are made is in
  docs/RELEASING.md.

What's Changed

Other changes

• Release notes for v0.1.0-beta.6 by @duongnq2798 in #366
• Ask the new payee check before sending again a payment never sent by @duongnq2798 in #367
• Show in the README what shipped this week by @duongnq2798 in #369
• Look for an unanswered send before the reconcile holds it, and record the address each send pays by @duongnq2798 in #368
• Offer the Chrome extension as a download, and a cleaner README header by @duongnq2798 in #370
• Prepare the Pipedrive Marketplace and Asana App Directory submissions by @duongnq2798 in #371
• Reconcile a lost batch's other releases in the cycle that finds the batch by @duongnq2798 in #372
• Link the Chrome Web Store listing of Invoice Capture, and allow its ID by @duongnq2798 in #374

Full Changelog: v0.1.0-beta.6...v0.1.0-beta.7

Vestiarion v0.1.0-beta.6 — Invoice capture from Chrome, a security page, two people per new payee

The sixth beta of Vestiarion. A Chrome extension sends an invoice you are looking at to your workspace as a draft for
review. A public security page sets out how data moves through the product and where each boundary is. Developers can
try the API from Postman and find the MCP server in the MCP Registry. And the first payment to a new payee's address now
always rests on two different people, however the address came in.

This release covers 8 merged pull requests (#358 to #365) since
v0.1.0-beta.5. Each feature was reviewed by an
independent reviewer before merge, and every defect found was fixed with a test that failed first. Production is
deployed from main on every merge, so it may already run newer changes than this release lists.

Highlights

• Capture invoices from Chrome (#361). Vestiarion Invoice Capture sends an invoice you select on a page, or a file
  you choose, to your workspace as a draft. You check the fields it read, with what is missing named, and send it; an
  owner or admin then adds it as a bill through the same step as any bill, or discards it.
  • The extension connects by signing in and allowing it, never with an API key. It can only create and read its own
    drafts: it never adds a bill, approves or pays. A connection lasts at most 90 days and ends when its member can no
    longer add bills; Settings lists connected extensions with Disconnect.
  • The captured text is kept until the draft is decided, 30 days at most.
  • Proven in production end to end, from connecting the extension to adding the captured draft as a bill. Submitted
    to the Chrome Web Store; until it is listed, it is loaded unpacked.
• A security page for reviewers (#359). vestiarion.xyz/security describes,
  as the code does it today, tenant isolation, encryption, who can approve what, connector tokens, webhook signing, the
  signed ledger, retention and deletion, how the model is used and the services that process data, and ends with what
  we do not claim. The repository has a security policy, SECURITY.md.
• Two people behind every new payee (#364). The first payment to a payee at an address needs two different people
  behind it. Whoever creates a payee link now counts as having given the address the payee sends through it, read from
  the workspace's signed ledger. For an address sent on GitHub with /payto, or one no member can be named as having
  given, one member confirms it and a different one approves its first payment; approving never counts as confirming.
  "Who can act" and the overdue email leave out whoever cannot approve it, and the workspace's only approver may still
  pay it, which the ledger records.
• Try the API from Postman, and the MCP server in the Registry (#360, #363). Two Postman collections and an
  environment, generated from the API's own description: "Getting Started" goes from a key to a first answer in three
  reads; the reference has every operation. server.json describes the remote MCP server for the official MCP
  Registry, and the MCP page says which key to use.
• Plain words (#365). The site says what Vestiarion is: your AI agent for bills and payments, for small businesses.
• Release notes (#358) for v0.1.0-beta.5.
• Fixes (#362, #359). Connector consent says what the model provider does under its own API terms (new consent
  versions 2026-10-15). On Arc mainnet the agent's spending limit always stands, even when a workspace's was missing.
  An API write's idempotency outcome is deleted after its 24 hours.

Database

One new migration brings the total to 114 (0001_init.sql to 0121_invoice_capture.sql; numbers 0091 to 0093, 0096
to 0098 and 0119 are unused):

Migration	Adds
0121_invoice_capture.sql	Captured invoice drafts, the extension's connections and one-time codes, and the functions that create, claim and decide drafts

It is additive and idempotent, and is applied in filename order by npm run db:migrate. Publishing a release never
runs migrations.

Known limitations

• Beta. Screens, wording and features change often. The spending-limit and escrow contracts have not been audited.
• Invoice capture is loaded unpacked until the Chrome Web Store lists the extension.
• Commissions. When the payout's creator and the partner it pays are a workspace's only approvers, a payout the
  agent holds can be approved by neither.
• QuickBooks Online still connects to sandbox companies only, until Intuit's app assessment is complete.

Contributors

Nguyen Quoc Duong (@duongnq2798): 8 merged pull requests and 25 commits in this
release, built with Claude (Anthropic) as an AI pair programmer, credited as co-author on most commits.

This release

• Tag v0.1.0-beta.6 on commit
  cae5724, the merge of #364, where CI's verify passed.
• A prerelease, so it is not marked Latest. The changes for business readers are in
  CHANGELOG.md; how releases are made is in
  docs/RELEASING.md.

What's Changed

Other changes

• Release notes for v0.1.0-beta.5 by @duongnq2798 in #358
• Add Postman collections and an MCP Registry server.json by @duongnq2798 in #360
• Link the public Postman workspace and the MCP Registry entry from the docs by @duongnq2798 in #363
• Add a security page, SECURITY.md and a five-minute evaluation path by @duongnq2798 in #359
• Say the model provider sees connector data under its own terms by @duongnq2798 in #362
• Say what Vestiarion is in plain words: an AI agent for bills and payments by @duongnq2798 in #365
• Capture invoices from Chrome as drafts a person adds as bills by @duongnq2798 in #361
• Treat a payee link's creator as the giver of the address it collects by @duongnq2798 in #364

Full Changelog: v0.1.0-beta.5...v0.1.0-beta.6

Vestiarion v0.1.0-beta.5 — Commissions, payment exceptions and one answer to "is this real money?"

The fifth beta of Vestiarion. Sales partners earn commission only on money customers actually paid on Arc. A payment
that does not settle cleanly now says who acts and what to do, and paying again always looks for the earlier transfer
first. Every page now gives the same answer to whether a payment is real, and the console asks why, in one optional
line, when someone goes against the agent.

This release covers 6 merged pull requests (#351, and #353 to #357) since
v0.1.0-beta.4. Each feature was reviewed by an
independent reviewer before merge, and every defect found was fixed with a test that failed first. Production is
deployed from main on every merge, so it may already run newer changes than this release lists.

Highlights

• Commissions on money received (#353). An owner or admin sets a plan for a sales partner or referrer on file: the
  rate, net of fees or gross, every deal or chosen deals, and a hold window.
  • A commission is recorded only when a customer's payment confirmed on Arc is applied to an invoice of a covered
    deal, for exactly the amount applied, with its formula shown. A partial payment earns a partial commission.
  • After the hold window, a person reviews what is due and turns it into one payable, which the agent decides and pays
    like any other bill, under every guardrail.
  • A reversed payment records a negative adjustment carried into the partner's next payout; nothing is ever pulled
    back from a wallet. The partner can never approve their own payout, enforced in the database.
  • Live on Arc testnet: a customer paid a 2 USDC invoice, the 0.20 USDC commission (2.00 USDC received × 10%) was
    recorded 9 seconds after the payment was matched, and the partner was paid and confirmed on Arc in 2 seconds.
• What to do when a payment does not settle (#356). Each exceptional state (slow to confirm, outcome unknown,
  failed or cancelled, not sent, a Gateway payout reported failed) says who acts, what Vestiarion already did, what to
  do next and where the trail is: on the bill's card, in Treasury's payments in flight, in Approvals and in the
  stuck-payment email, with a new guide, "When a payment does not settle".
  • Approve and pay and Pay now look for an unanswered send before anything else. A transfer Circle has is only
    recorded; one Circle has not listed yet is refused with a time to try again; only a send Circle never took is paid
    as a new payment, through every check.
  • A milestone paid in one transaction with others is never closed while that transaction may have paid it.
• One answer to "is this real money?" (#357). Every page that says what a payment does (the header, Settings, Agree
  and pay, Approve and pay, Pay now, reports, payee pages, receipts, the reserve, /open and GET /api/v1/status) now
  reads one source and uses the same words for live on Arc mainnet, live on Arc testnet, simulated, shadow mode, and
  unavailable (switched off or held). GET /api/v1/status answers unavailable while payments are switched off.
• Asking why, in the moment (#357). When a person rejects or returns a bill, pays one the agent held anyway, or
  disagrees in shadow mode, the console asks why in one optional line, never required. Owners and admins see the latest
  reasons on Insights; the privacy page says what is kept and who sees it.
• Smaller changes (#354, #355). The header names the page you are on inside a section (for example Bills &
  receivables › Commissions, or a deal's title), and the New deal form's fields line up.

Database

Two new migrations bring the total to 113 (0001_init.sql to 0120_decision_reasons.sql; numbers 0091 to 0093, 0096
to 0098 and 0119 are unused):

Migration	Adds
0118_commissions.sql	Commission plans, their deals, commission lines and payouts, the functions that set plans, record commissions and create payouts, and the partner's refusal in the approval claim
0120_decision_reasons.sql	The reasons people give for going against the agent, and a team-only reading of them

Both are additive and idempotent, and are applied in filename order by npm run db:migrate. Publishing a release never
runs migrations.

Developer packages

@vestiarion/sdk 0.3.4 describes the unavailable status while payments are switched off; its types are unchanged.

Known limitations

• Beta. Screens, wording and features change often. The spending-limit and escrow contracts have not been audited.
• Commissions. When the payout's creator and the partner it pays are a workspace's only approvers, a payout the
  agent holds can be approved by neither: give the partner a role that does not approve payments, or add another
  approver. Refunds paid as payables are not linked back to a commission; reverse the application instead.
• CCTP and Gateway payouts whose send went unanswered cannot be looked up by reference; Approve and pay asks Circle
  again under the same payment key, which Circle takes only once.
• QuickBooks Online still connects to sandbox companies only, until Intuit's app assessment is complete.

Contributors

Nguyen Quoc Duong (@duongnq2798): 6 merged pull requests and 19 commits in this
release, built with Claude (Anthropic) as an AI pair programmer, credited as co-author on most commits.

This release

• Tag v0.1.0-beta.5 on commit
  4c17e74, the merge of #357, where CI's verify passed.
• A prerelease, so it is not marked Latest. The changes for business readers are in
  CHANGELOG.md; how releases are made is in
  docs/RELEASING.md.

What's Changed

Other changes

• Release notes for v0.1.0-beta.4 by @duongnq2798 in #351
• Commissions on money received by @duongnq2798 in #353
• Name the page inside a section in the workspace breadcrumb by @duongnq2798 in #354
• Label the deal form's payment terms Terms (days) so its row lines up by @duongnq2798 in #355
• Say what to do when a payment does not settle, and check the earlier transfer first by @duongnq2798 in #356
• One capability state on every surface, and asking why in the moment by @duongnq2798 in #357

Full Changelog: v0.1.0-beta.4...v0.1.0-beta.5