Crypto deposit - Anchorage Digital

Receiving a digital asset is a single end-to-end flow: create a wallet and deposit address, verify and share it, then track the incoming deposit and—when it arrives from an unrecognized sender—attribute it before the funds become available. This page walks the full path. For the shared wallet and address mechanics, see Deposit. Two endpoints describe the same deposit from different angles, and you use both once funds are inbound:

GET /v2/transactions — the money view: how much arrived, in what asset, from which address, and its on-chain status.
GET /v2/deposit-attributions/attributions — the compliance view: whether the deposit is held or cleared, and who sent it.

They link on the transaction id, which is the depositTransactionId in the attributions response, and both carry the same blockchainTxId.

Deposit flow

Create a wallet

Call POST /v2/vaults/{vaultId}/wallets, passing the networkId and a walletName.

Provision a deposit address

Call POST /v2/wallets/{walletId}/addresses, or list existing addresses with GET on the addresses endpoint.

Verify the address

Anchorage Digital signs every deposit address so you can confirm it was generated for your organization and hasn’t been tampered with. Confirm both that the signature is valid and that the signed address matches the one you intend to share. See Address verification.

Share the address and receive the asset

Share the verified address with the sender, who sends only the correct asset on the correct network. If you expect recurring deposits from this sender, add their address as a trusted source so future deposits attribute automatically and skip the manual step below.

Track the incoming deposit

Subscribe to webhooks to be notified on arrival. A deposit from an unrecognized sender fires deposit.pending-attribution with the transactionId. Read the deposit with GET /v2/transactions: it shows status: SUCCESS on-chain, but the funds are excluded from availableBalance until attribution completes.

{
  "data": [
    {
      "id": "0e2b2f9d8d104f1e960b28567255045f",
      "transactionType": "DEPOSIT",
      "status": "SUCCESS",
      "assetType": "ETH",
      "amount": {
        "quantity": "5.0",
        "assetType": "ETH",
        "currentPrice": "3450.12",
        "currentUSDValue": "17250.60"
      },
      "blockchainTxId": "0x84ddb76708d570101db89fd27b1717484c54417c9f32c63052cdfac9a0bfc0a2",
      "sourceAddresses": ["0xb4Bb4E3D7f35ede58d99F5e2b8B04f7AC87f9c88"],
      "destinationAddresses": ["0x39d9f4640b98189540A9c0Ede2b8B04f7AC8aa21"],
      "dateTime": "2026-06-24T14:08:31.000Z",
      "vaultId": "1c920f4241b78a1d483a29f3c24b6c4c",
      "vaultName": "End Client A",
      "walletId": "d24b424293c0d64c6194f52801b3d293"
    }
  ],
  "page": { "next": null }
}

Check attribution status

The same deposit appears under GET /v2/deposit-attributions/attributions with status: PENDING and empty originator fields—this is what you complete. No amount or value is returned here. A deposit from a trusted source is already ATTRIBUTED at this point, so you can skip the next step.

{
  "data": [
    {
      "depositTransactionId": "0e2b2f9d8d104f1e960b28567255045f",
      "blockchainTxId": "0x84ddb76708d570101db89fd27b1717484c54417c9f32c63052cdfac9a0bfc0a2",
      "assetType": "ETH",
      "status": "PENDING",
      "attributionType": null,
      "originatorName": null,
      "originatorCountry": null,
      "sourceWalletType": null,
      "sourceAddresses": ["0xb4Bb4E3D7f35ede58d99F5e2b8B04f7AC87f9c88"],
      "subaccountId": "ec761b5e-fd2c-497a-a9a0-f8738ac97bdf",
      "createdAt": "2026-06-24T14:08:45.953571Z",
      "attributedAt": null
    }
  ],
  "page": { "next": null }
}

Attribute the sender

Identify who sent the funds. Attribution via API requires the Deposit Attribution permission.

// POST /v2/deposit-attributions/{depositTransactionId}
{
  "notes": "Q2 funding",
  "originatorCountry": "US",
  "originatorName": "Acme Holdings",
  "sourceWalletType": "SELF_HOSTED"
}

The record moves to status: ATTRIBUTED, and the funds are released into availableBalance. A deposit.attributed webhook fires to confirm.

Poll GET /v2/transactions to reconcile the money and GET /v2/deposit-attributions/attributions to clear the hold. A deposit can be SUCCESS on-chain while still PENDING for KYT.

Trusted sources and automatic attribution

Not every deposit needs the manual attribution step. Attribution is applied automatically when:

Trusted sources — Any address you add as a trusted source is attributed automatically on future deposits. Create them in the dashboard (not currently available via API). They’re recommended for senders you receive from repeatedly, and turn the flow above into a track-only path.
Travel rule — Crypto deposits from VASPs above the $2,100 travel-rule reporting threshold are attributed automatically when Anchorage Digital receives a travel-rule message from a participating VASP. This isn’t instant; use the API if you need faster access to funds.
Everything else needs manual attribution.

Field guidance

originatorName and originatorCountry — The actual person or entity that sent the funds, not the financial institution.
sourceWalletType — CUSTODIAL when the sender doesn’t hold the private key (a third party does, for example an exchange or custodian), or SELF_HOSTED when the sender holds the private key (for example, a self-custody wallet).

Deposits identified as spam or dusting can be attributed as spam through the spam endpoint, which keeps unwanted balances out of statements and trading balances.

Attribution status values

`status`	Description
`INITIATED`	Deposit detected; Anchorage Digital is attempting automatic spam attribution. Moves to `PENDING` if that fails.
`PENDING`	Deposit landed after the auto-attribution attempt and needs attribution. Deposits marked spam by Anchorage Digital don’t appear here.
`UNDER_REVIEW`	Attribution completed but triggered a sanctions hit pending compliance clearance.
`ATTRIBUTED`	Terminal success state; funds are available.
`BLOCKED`	Confirmed sanctions hit.
`NON_ATTRIBUTABLE`	Semi-terminal state for specific edge cases.

Attribution type values

`attributionType`	Description
`AUTOMATIC`	Attributed automatically via travel-rule information from the originating VASP.
`TRUSTED_SOURCES`	Attributed automatically using stored information for a designated trusted source.
`MANUAL_STAFF`	Attributed by Anchorage Digital staff from previously known source information.
`MANUAL_CLIENT`	Attributed by the client via the web dashboard.
`CLIENT_API`	Attributed by the client via API key.
`SPAM`	Attributed as spam by Anchorage Digital or the client.

Address integrity

Always verify a deposit address before use. The addresses API returns a signature and metadata that prove the address belongs to your vault and network. See Address verification for the V1 and V2 schemes.

Failed and unrecognized deposits

Sending the wrong asset type to an Anchorage Digital address results in a failed deposit. An asset sent on a different chain than the address is not recognized. If the address is correct but the asset is unsupported—for example, an unsupported ERC-20 sent to an ETH address—contact your client experience team.

​Deposit flow

​Trusted sources and automatic attribution

​Field guidance

​Attribution status values

​Attribution type values

​Address integrity

​Failed and unrecognized deposits

Deposit flow

Trusted sources and automatic attribution

Field guidance

Attribution status values

Attribution type values

Address integrity

Failed and unrecognized deposits