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

# Changelog

> User-visible changes to Anchorage Agentic Banking and these docs.

<Update label="2026-08-06" description="Locked accounts no longer hand out crypto deposit addresses">
  While an account is locked for review, the Deposit page now withholds its
  crypto deposit addresses — generating a new address and viewing the current
  one are both refused, and the page explains the lock in place of the
  address. The account's deposit history stays visible throughout,
  and deposits already on their way to a previously issued address still
  arrive and follow the usual screening steps. A frozen account is unchanged:
  it still accepts deposits and still shows its deposit addresses.
</Update>

<Update label="2026-08-06" description="Budgets and agents must name at least one allowed merchant, or allow all">
  Creating or editing a budget — including the budget created with a new agent
  — now requires the merchant scope to either allow all merchants or name at
  least one. Previously, choosing a specific allowlist while selecting no
  merchants was accepted and produced a budget that silently blocked every
  payment; the same request now returns a clear validation message instead. To
  deliberately stop a budget's spending, pause it — that is what pause is for,
  and it is reversible. Existing budgets in this state can still be edited to a
  valid merchant scope, paused, or revoked.
</Update>

<Update label="2026-08-06" description="Solana payments that can no longer settle decline automatically">
  A Solana payment authorization is signed against recent network state and can
  only land on chain for a short window. When that window has provably closed
  and the network shows no settlement, the payment now declines automatically
  and its reserved funds release — matching what already happens on Base.
  Previously such a payment stayed pending until Anchorage resolved it
  manually. A payment whose settlement did land on chain is never declined this
  way; it completes as usual.
</Update>

<Update label="2026-08-06" description="Budget allowlists follow merchant records through catalog consolidation">
  When Anchorage consolidates duplicate entries for one merchant in the
  merchant catalog, budgets whose allowlist names the duplicate now follow
  to the surviving entry automatically. The grant keeps admitting the same
  real-world merchant, and its cap and spend-to-date stay untouched.
  Previously a payment against such a grant was refused until an org admin
  re-added the surviving entry to the allowlist. See
  [Budgets](/agentic-banking/concepts/budgets).
</Update>

<Update label="2026-08-05" description="Payments refuse a merchant that mislabels what is being sold">
  When a paid URL quotes its price, the quote may also name the resource
  being sold. That name must now sit at the same address as the URL actually
  reached — the same host and port, so a sibling or CDN subdomain counts as a
  different address. A mismatch refuses the payment before anything is
  signed, and a cost estimate for the same URL reports the same refusal.
  Merchant screening is keyed by the resource's address, so a mismatched
  address could otherwise let one merchant present itself as another. Quotes
  that omit the resource name keep working unchanged. See the failure-modes
  table in [Crypto payments](/agentic-banking/concepts/payments#failure-modes).
</Update>

<Update label="2026-08-04" description="Invitations to organizations whose setup is incomplete wait visibly instead of failing">
  A pending invitation to an organization whose setup did not finish now shows
  **Setup incomplete** in its row instead of an Accept button — accepting
  becomes available the moment Anchorage completes the organization's setup.
  Declining stays available throughout. Signing in also now requires an
  organization that is ready for you: an invitation to an organization with
  incomplete setup admits you once that setup completes, or once another of
  your invitations or memberships points somewhere active. (Organizations are
  active from the moment they are created — see the entry below — so this
  state is rare and always something Anchorage resolves, never a step you wait
  out.)
</Update>

<Update label="2026-08-04" description="Sign out directly from the organization chooser">
  The organization chooser — including the pending-invitations view shown
  before you belong to an organization — now names the account you are signed
  in to and includes a sign-out button. Signing in with the wrong account
  recovers in one step: sign out from the page and sign back in with the right
  account.
</Update>

<Update label="2026-08-04" description="New organizations are ready to use as soon as they are created">
  A new organization is active from the moment Anchorage creates it. Anyone it
  invites can accept and sign in straight away, and paying, transferring, and
  approving a queued payment all work immediately.

  This replaces the separate activation step organizations used to wait on. An
  invitation into a newly created organization is accepted on the spot, and a
  payment is no longer refused at approval time for an organization awaiting
  activation. Anchorage's onboarding checks on an organization and its members
  still run in full — they now complete as the organization is set up.

  An organization can still be frozen, which stops payments and transfers and
  pauses its agents, and approving a queued payment stays blocked until it is
  unfrozen.
</Update>

<Update label="2026-08-04" description="Browsing the merchant directory works when signed out">
  The merchant directory at `/merchants` now returns results whether or not you
  are signed in. Searching it while signed out shows the same live merchants a
  signed-in user sees; previously a signed-out search came back empty.
</Update>

<Update label="2026-07-31" description="Invited members can sign in regardless of email domain">
  An invited member can now sign in for the first time with the email address
  the invitation was sent to, whatever its domain — a personal address, or a
  contractor's own company address, for example. Signing in creates their
  account and shows them the invitation; accepting it is what adds them to the
  organization, with the role the invitation specified. An expired, revoked,
  or already-accepted invitation grants nothing.

  Sign-in for a domain with an identity provider configured still goes through
  that provider. Someone invited from outside that domain signs in with an
  email code and accepts the invitation the same way.

  Two cases now decline an invitation at the moment it is accepted rather than
  letting it through: an organization that has since restricted membership to
  its own email domain, and one still awaiting activation. Both leave the
  invitation open — the first needs a fresh invitation from an address the
  organization now admits, the second only needs activation to finish.
</Update>

<Update label="2026-07-27" description="New organizations are activated by the compliance team before first use">
  A new organization now starts in a review state and must be activated by
  Anchorage's compliance team before it can be used — signing in, paying, and
  transferring wait until activation, and approving a queued payment is
  rejected until the organization is activated. Existing organizations are
  already active and unaffected. Merchant availability is likewise reviewed by Anchorage's
  compliance team.
</Update>

<Update label="2026-07-27" description="A starting page at agentic.anchorage.com">
  Visiting [agentic.anchorage.com](https://agentic.anchorage.com) without being
  signed in now shows a short starting page linking to sign-in, these docs, the
  product overview, and a way to reach us, instead of going straight to the
  sign-in form. If you are already signed in, you still go directly to your
  account — nothing changes for you.
</Update>

<Update label="2026-07-23" description="Try deposits and payments in sandbox mode">
  You can now switch to sandbox mode to try deposits and payments on a test
  network without moving real funds. Your sandbox balance is kept separate from
  your live one, and test-network deposit addresses differ from your live ones —
  copy the address shown for the network you are on. Switch back to your live
  account at any time.
</Update>

<Update label="2026-07-21" description="Frozen organizations can no longer approve queued payments">
  Approving a payment that is waiting in the approval queue now checks the
  organization's status first: if the organization is frozen, the approval is
  rejected with a message naming the reason and the payment stays in the queue.
  The same check runs when an approved payment is re-issued. Nothing is lost —
  once the organization is unfrozen, the approval and re-issue work as before.
</Update>

<Update label="2026-07-21" description="Collapse the navigation sidebar on desktop">
  On a computer you can now collapse the navigation sidebar to give the page
  more room, and open it again from the menu button in the top bar — the
  sidebar stays the way you left it as you move between pages. The bar holding
  the logo and the light and dark theme controls now sits at the top of every
  screen, on computers as well as phones.
</Update>

<Update label="2026-07-21" description="Easier navigation on phones and clearer section highlighting">
  The navigation menu on phones opens from the top bar, the Escape key
  closes it, and keyboard focus moves into the menu when it opens and
  returns to the menu button when it closes. Switching between light and
  dark themes is available directly from the top bar on phones. The
  sidebar also keeps the current section highlighted while you view its
  subpages — for example, a card's detail page keeps Cards highlighted —
  so it is always clear where you are.
</Update>

<Update label="2026-07-20" description="List paging rejects invalid page markers">
  Paging through long lists — purchase requests, budgets — uses an opaque
  marker to fetch the next page. A corrupted or outdated marker now returns a
  clear invalid-request error, and restarting the listing from the first page
  recovers; previously such a marker could quietly return the wrong page.
  Markers issued before this release are invalidated once at rollout, with the
  same recovery.
</Update>

<Update label="2026-07-08" description="These docs have a new home">
  This documentation now lives at docs.anchorage.com/agentic-banking. Old
  links under agentic.anchorage.com/docs redirect here automatically, so
  bookmarked pages keep working. The docs MCP server moved with it: requests
  to the old address are redirected with the method preserved, which most
  MCP clients follow transparently — if yours does not, update its
  configured address to docs.anchorage.com/mcp. Updating saved links is a
  good idea either way.
</Update>

<Update label="2026-06-26" description="One merchant catalog, richer results, for agents and browsers">
  Finding a merchant now happens in one place: the merchant catalog, browsable
  by anyone in the web UI — signed in or anonymous — and searchable by agents
  over MCP. An agent's results are limited to what it can actually pay on its
  network (mainnet or testnet), and this catalog search is now the only way
  an agent discovers where it can pay; the earlier separate list of allowed
  merchants has been retired in its favor. Each result now also shows
  the merchant a service belongs to, whether that merchant runs the service
  itself or resells another provider's, and the payment methods the service
  accepts, so an agent can tell up front what it's able to pay and who it's
  dealing with. Services from the same merchant are grouped together, and
  pulling a single service's detail lists the payment methods its endpoints
  accept. Only merchants that have cleared review appear in results.
</Update>

<Update label="2026-06-26" description="Agents can report catalog gaps and broken services">
  Agents can now report problems with the merchant catalog as they browse it. When
  an agent cannot find a merchant it expected, finds that no merchant offers what
  it needs, hits a service that does not work, or gets search results that miss the
  mark, it can send that feedback to Anchorage Agentic Banking — noting the search
  it tried or the service in question. The reports help us fill gaps in the catalog
  and fix listings that have gone stale.
</Update>

<Update label="2026-06-23" description="Solana deposit setup warning">
  The Deposit page now warns when a Solana deposit address still needs its token
  account created. If you see the warning, complete the setup before sending
  funds to that Solana address. Existing ready addresses are unchanged.
</Update>

<Update label="2026-06-22" description="Pay and fund with USDC on Solana">
  Agents can now make crypto payments with USDC on Solana, alongside USDC on
  Base — Anchorage Agentic Banking automatically settles on Solana when a
  merchant prices a request there. You can also fund your account by depositing
  USDC on Solana; it credits your account's USD balance on that network
  (mainnet or testnet — Base and Solana deposits feed the same balance, not
  separate ones per chain) and is screened like any other deposit. Existing
  Base payments and deposits are unchanged.
</Update>

<Update label="2026-06-22" description="Repeat deposits can reuse sender details">
  After you attribute a self-hosted deposit sender once, later deposits from the
  same sender in your org can reuse those details automatically. The deposit still
  runs screening before funds become available, so a fresh review can still block
  the funds.
</Update>

<Update label="2026-06-20" description="Agents can search the merchant catalog">
  Agents can now find merchants and services to pay by describing what they
  need — for example, "weather data" or "image generation" — instead of needing
  a URL up front. Search returns the matching live merchants, and an agent can
  then pull a service's payable endpoints and documentation links to make the
  call. Only merchants that have cleared review appear in results.
</Update>

<Update label="2026-06-17" description="Stronger linked-card compliance screening">
  Linked-card compliance screening was strengthened. As before, a card that does
  not pass is refused at link time and stays in your card list, marked with the
  reason.
</Update>

<Update label="2026-06-15" description="Attribute a held deposit">
  When a deposit reads **Needs attribution**, you can now enter the sender's
  name and country directly from your deposit history. Submitting those details
  runs the review and releases the funds in the same step if it passes.
</Update>

<Update label="2026-06-14" description="Blocked agent connections end the session">
  When an agent connection does not pass compliance screening, its session now
  ends, not just the one request it was making. The agent must reconnect to
  continue. No action required — a runaway agent is stopped at the connection,
  not asked again on the next call.
</Update>

<Update label="2026-06-14" description="Deposit screening labels">
  Each deposit now shows where it stands in review: **Needs attribution**,
  **Reviewing attribution**, **Cleared**, or **Blocked on screening**. A deposit
  becomes available to spend once it reads **Cleared**. The label sits next to
  each deposit in your deposit history, so you can tell at a glance whether
  funds are ready or still in review.
</Update>

<Update label="2026-06-10" description="Larger paid-URL responses">
  Paid URLs that return large payloads now come back to your agent whole.
  Responses up to 10 MB are delivered in full instead of being cut short, so
  data-heavy APIs behind a paid URL work as expected.
</Update>

<Update label="2026-05-28" description="Linked-card compliance screening">
  Linked-card support now runs compliance screening when a card is linked and on
  each purchase. A card or purchase that does not pass is refused; rejected cards
  stay visible in your card list for audit, marked with the reason. No action
  required — if a link or purchase is refused, the web UI explains why.
</Update>

<Update label="2026-05-27" description="Pilot launch and public docs">
  The first public release of **Anchorage Agentic Banking**, alongside the
  launch of this docs site.

  * **Two payment rails.** Crypto payments to paid URLs on the open
    internet, and linked-card purchases via a one-shot credential scoped
    per merchant. Each agent can use both rails and picks one per spend.
  * **Agent-scoped budgets.** Org admins pre-authorize crypto spend with
    a USD spend limit and a merchant allowlist; agents see the limit, not
    the account balance.
  * **Per-purchase passkey approval for linked cards.** Each card purchase
    an agent requests goes through a fresh passkey approval in the
    browser.
  * **Safety cap that no approval can override.** \$1,000 per UTC day, per
    agent, across both rails.
  * **Instant revoke** of any agent from the web UI, with no grace window.
  * **Sign-in** via work SSO or a one-time email code.

  Orgs fund their account by stablecoin deposit on the supported crypto
  chains; each deposit credits the account as USD at confirmation. Bank
  linking and ACH deposits are on the roadmap.

  The docs cover the [agent connection flow](/agentic-banking/guides/connect-an-agent),
  the [concepts](/agentic-banking/concepts/agents) behind agents, accounts, budgets,
  payments, and linked cards, and per-action
  [how-to guides](/agentic-banking/guides/make-a-crypto-payment).
</Update>