> ## 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.
# Crypto deposit
> Receive digital assets end to end: create and verify a wallet address, track the deposit, and attribute the sender.
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](/knowledge-base/platform/developers/move-money/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
Call `POST /v2/vaults/{vaultId}/wallets`, passing the `networkId` and a `walletName`.
Call `POST /v2/wallets/{walletId}/addresses`, or list existing addresses with `GET` on the addresses endpoint.
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](/knowledge-base/api-reference/address-verification).
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.
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.
```json theme={null}
{
"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 }
}
```
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.
```json theme={null}
{
"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 }
}
```
Identify who sent the funds. Attribution via API requires the `Deposit Attribution` permission.
```json theme={null}
// 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](/knowledge-base/api-reference/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.