Skip to main content
A budget is a pre-authorized USD spend limit for crypto payments. It is the spend control on the crypto rail. A budget exposes a spend limit to the agent. Every budget references one account — the funding pool the spend draws against — but the agent only ever sees the limit, not the account’s balance.

​
What an org admin configures today

The org settings page exposes one budget per network the org runs on (typically mainnet and/or testnet). Each budget is org-wide: it applies to every member of the org, and each member gets their own independent USD cap. The fields the admin sets are:
  • Name — a label (e.g., “Research travel”).
  • Cap (USD) — the per-member limit.
  • Merchant scope — either all merchants (every merchant Anchorage has screened and promoted to Active) or a specific allowlist picked from the merchant catalog. A specific allowlist must name at least one merchant; saving an empty selection is rejected. When Anchorage consolidates duplicate catalog entries for one merchant, allowlists naming the duplicate follow to the surviving entry automatically — the budget keeps admitting the same real-world merchant, and its cap and spend-to-date stay untouched.
That’s the full set of pilot configuration. The underlying model supports period rollover, parent/child cascades, and per-agent or shared-pool variants; those will reach the org-settings UI in later releases.

​
Period

Pilot budgets are fixed: spend accumulates against the cap until the admin raises it. Daily, weekly, and monthly calendar-period caps are on the roadmap.

​
States and actions

Each budget is in one of three states; the admin can transition between them from the org settings page:

​
Two gates per payment

Every crypto payment runs through two distinct gates:
  1. Compliance gate — the merchant must be Active and on the budget’s allowlist. A failure here is a hard reject with no approval path.
  2. Spending gate — the requested amount, plus existing holds, must fit inside the cap. See Approvals for what happens when a payment crosses the cap.

​
What the agent sees

Through MCP, the agent reads its own allotted cap, its spend-to-date, and the merchant allowlist that applies to it. The agent’s view is scoped to its own slice. An agent you connect through the browser consent screen or a pairing code gets the merchant scope your org’s budget has at that moment: all merchants when the org budget allows all merchants, or the same allowlist when it names specific merchants. The agent keeps that scope, so merchants you add to the org budget later don’t reach agents you already connected.

​
What the org member sees

A member’s profile page in the web UI shows their own slice of each org budget — the cap, the merchants admitted, and a progress bar for spend-to-date. Each member’s view stays scoped to their own slice. On an agent’s page, a budget with its own cap shows a spend meter: how much of the cap is used this period, how much is left, and the share used. When the agent also draws on a member’s budget, that budget’s meter appears on the same card. If an org admin lowers a cap below what is already used, the meter shows how far over the new cap the budget is. A revoked budget is permanently disabled, so its meter shows only the share it used, not how much is left. On the org’s member list, a plain member sees each member’s name and role. Other members’ email addresses and budget use are shown to org admins only; a plain member finds their own on their profile page.