> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anchorage.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Budgets

> How agents are pre-authorized to spend on the crypto rail.

A **budget** is a pre-authorized USD spend limit for crypto payments. It is
the spend control on the crypto rail; linked-card purchases use per-purchase
passkey approval instead and are covered separately.

A budget exposes a spend limit to the agent. Every budget references one
[account](/agentic-banking/concepts/accounts) — 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:

| State   | Meaning                              | Available actions   |
| ------- | ------------------------------------ | ------------------- |
| Active  | Budget admits payments under the cap | Edit, Pause, Revoke |
| Paused  | Budget rejects all payments          | Resume, Revoke      |
| Revoked | Budget is permanently disabled       | (none)              |

## 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](/agentic-banking/concepts/payments#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.

## 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.


## Related topics

- [Check your budget](/agentic-banking/guides/check-your-budget.md)
- [Accounts](/agentic-banking/concepts/accounts.md)
- [Changelog](/agentic-banking/changelog.md)
- [Make a crypto payment](/agentic-banking/guides/make-a-crypto-payment.md)
- [Agents](/agentic-banking/concepts/agents.md)