Skip to main content

How it works

1

Create a deposit wallet

Create a subaccount-specific deposit wallet for the asset your client wants to deposit.
2

Share the address with your client

Share the deposit address, along with the blockchain and asset details.
3

Monitor and attribute the deposit

Detect the deposit via webhook or polling, then attribute it to the correct end client.
4

Add a trusted destination and withdraw

When your client wants to withdraw, register their external address as a trusted destination, then initiate the withdrawal.

Fund accounts with digital assets

Steps must be completed in order — out-of-sequence execution risks funds being lost or returned.

Deposit attribution

Status values Attribution type values Trusted sources Trusted sources auto-attribute recurring deposits from the same address. Create them in the Anchorage Digital web dashboard (API not available in production).
Trusted sources should not be used if a single source address is shared by multiple end clients. Doing so may cause incorrect attribution and require the wealth manager to provide additional originator details to Anchorage Digital.
Spam / unknown deposits Attribute dust or spam deposits as SPAM using POST /v2/deposit-attributions/{depositTransactionId}/spam. This prevents unwanted balances from appearing on the end client’s account. Anchorage Digital will sweep these funds from on-chain wallets using the shared API key as needed. Automated attribution from VASPs Crypto deposits from VASPs over $2,100 (the travel rule threshold) are automatically attributed if Anchorage Digital receives a travel rule message from an active TRUST network VASP. This is not instant — use the attribution API for faster fund access.

Step 1: Get your vaultId

GET /v2/vaults

Step 2: Create a deposit wallet for the subaccount

POST /v2/vaults/{vaultId}/wallets Create one wallet per subaccount per asset, specifying subaccountId. Create wallets on demand — when the customer requests a deposit address — rather than pre-creating wallets for every supported asset. Recommended naming convention: [PC name]_[Subaccount #]_Deposit Wallet
Wallet creation is limited to 10 wallets per asset per 30 minutes. This limit will increase in coming months.
Sandbox testnet assets: BTC_T (BTC testnet), ETHHOL (ETH Holesky), USDANCHOL (USDC Holesky)
Share the deposit address with the end client, along with the blockchain details (e.g., Ethereum mainnet vs. Base) and any deposit attribution requirements.
For the first few deposits, have the end client send a small test amount to confirm the address and network are correct before transferring the full balance. Ensure both parties are aligned on the exact asset symbol and supported network — deposits to the wrong network may result in lost funds.

Step 3: Identify a new deposit

Deposit confirmations are not immediate — they typically require 2 on-chain confirmations, which may take a few minutes. Option A: Poll for pending attributions — GET /v2/deposit-attributions?status=PENDING
Response
Option B: Webhook notification — subscribe to deposit.pending-attribution:
Webhook payload
The message_id maps to the depositTransactionId.
Ensure end clients only deposit supported assets. Deposits of unsupported assets into a wallet will result in lost funds.

Step 4: Attribute the deposit

PATCH /v2/deposit-attributions/{depositTransactionId} In production, collect AML deposit attribution data from the end client before sharing the deposit address — this enables automatic attribution once the deposit is detected. sourceWalletType values:
For spam/dust deposits, use POST /v2/deposit-attributions/{depositTransactionId}/spam instead to prevent unwanted balances from appearing on the account.
After attributing in-kind deposits, update the missing cost basis via PATCH /v2/tax/transaction/{transactionId}.

Step 5: View account balances

GET /v2/subaccounts/customers/{customerId}/accounts

Withdraw digital assets

New programmatic in-kind withdrawals (released 2025-04-15). Three key changes:
  1. New create trusted destinations API.
  2. New DocuSign approval required from the end client before creating the trusted destination.
  3. Updated withdrawal API payload for withdrawals to trusted destinations.
  4. API permission and key updates required.

Step 1: Update API key permissions

Add the following two permissions to your API key permission group:
  • Withdrawal — Yes
  • Manage trusted destinations — Yes
Quorum approve the change before proceeding.

Step 2: Add trusted destinations

Submit trusted destination requests via POST /v2/trusted_destinations for each end-client’s external withdrawal address. For wealth management integrations, trusted destinations are tied to an owner representing the end client (customerId). After submission: A DocuSign is sent to the end client for each destination. Once signed, the Anchorage Digital ops team reviews and approves. If issues arise, Anchorage Digital will reach out.

Step 3: Initiate the withdrawal

Use POST /v2/transactions/withdrawal. Anchorage Digital account admins will need to verify on their iOS devices. Once quorum is complete, the operation proceeds through risk review, then broadcasts on-chain.
Admins can batch approve multiple operations on iOS. See Batched endorsements.
Multiple withdrawals for the same asset queued simultaneously may be processed sequentially rather than in parallel. Flagged withdrawals may also delay same-asset withdrawals.
Withdrawal request
purpose values: TRADING_SETTLEMENT, LENDING, INVESTMENT, EXPENSES, FEE_PAYMENT, GRANT_PAYMENT, PRIZE_AWARD, GIFT, REIMBURSEMENT, REBALANCE, INTRA_COMPANY