> ## 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.
# Overview
> Key terminology, architecture, and APIs for the Anchorage Digital ETF integration.
This guide covers the core concepts for integrating an ETF program with Anchorage Digital: the roles involved, how the ledger keeps fund assets separate from operating costs, vault design options, and how to automate operations with the API.
## Roles in an ETF program
Owns the fund and its mandate. Approves onboarding and the custody relationship, and decides which liquidity providers and settlement partners can participate.
An optional subadvisor or settlement partner that tokenizes the fund's holdings and directs creation and redemption on-chain, if the issuer delegates this role.
The qualified custodian. Custodies fund assets, configures trusted destinations, and provides the API and reporting the other parties rely on.
Authorized participants that deliver and receive assets against the fund to perform creation and redemption arbitrage. Most programs work with four to five liquidity providers.
Maintains the investor register and net asset value (NAV), and whitelists investor-facing wallets as trusted destinations.
## How the ledger works
From your side of the integration, an ETF program looks like a standard Anchorage Digital vault and wallet setup — the same building blocks covered in [Account hierarchy](/knowledge-base/platform/developers/account-hierarchy) and [B2B2X accounts](/knowledge-base/platform/developers/b2b2x). You don't create or manage anything through the Subaccounts API the way the [wealth management integration](/knowledge-base/platform/developers/wealth/wealth-management-overview) does.
Internally, Anchorage Digital's ledger still splits each ETF vault's holdings into three balances, visible on the web dashboard's Balances tab:
| Balance | What it tracks |
| :------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fund balance | The grantor trust's actual custodied assets. This is what the fund's NAV is based on. |
| Network fee balance | Assets set aside to pay on-chain network fees (sometimes called gas), kept separate so spending on fees never affects the fund's NAV or creates an unexpected taxable event. |
| Unattributed balance | Dust or unattributed deposits, excluded from both balances above. |
Anchorage Digital funds one network fee balance per organization, not per wallet, so you don't need a wallet-specific top-up before using a new wallet. If you need to withdraw an exact amount without drawing on the shared network fee balance, contact your account representative to fund that specific wallet directly.
## Vault topology
How you structure vaults across your liquidity providers is a trade-off between segregation and operational simplicity.
| Model | How it works | Trade-off |
| :------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Dedicated vault per liquidity provider | Each liquidity provider gets its own vault or wallet, visible only to them. | Maximum segregation and per-counterparty control, at the cost of managing more vaults as you add liquidity providers. |
| Shared settlement vault | All liquidity providers settle into one working vault, identified only by their registered trusted-source address. A separate reserve vault holds core fund assets off the settlement path. | Simpler to operate, but relies on every liquidity provider using a unique, non-reused trusted-source address — a shared or reused address breaks attribution between counterparties. |
You can combine either vault model with API-driven operations below.
## Automating operations with the API
Rather than Anchorage Digital manually adding and removing individual users for an operating partner, you can issue that partner a single [API key](/knowledge-base/platform/developers/api-keys) and let them manage their own users under it. This removes Anchorage Digital from routine access requests and lets the partner move as fast as their own approval process allows.
Pair this with [webhooks](/knowledge-base/platform/developers/webhooks/webhooks-overview) instead of polling for status — subscribe to deposit, settlement, and report-ready events to drive same-day, event-based reconciliation instead of manual checks. See [Trusted destinations](/knowledge-base/platform/developers/move-money/setup/trusted-destinations), [Deposits](/knowledge-base/platform/developers/move-money/deposit), and [Withdrawing crypto](/knowledge-base/platform/developers/move-money/withdraw/crypto) for the underlying transfer APIs.
## Reporting
Anchorage Digital sends the transfer agent (or fund administrator) two automated reports each day: account balances and the prior day's transactions, delivered by email or SFTP. Monthly custody statements cover the fund balance only — network fee and unattributed balances are excluded.
Each ETF asset type is set up as its own organization. An issuer with both a BTC ETF and an ETH ETF has two separate organizations, one per fund.