> ## 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.
# API Changelog
> Subscribe to Anchorage API updates, additions, and breaking changes.
[2026](/knowledge-base/porto/api-reference/changelog) · [2025](/knowledge-base/api-reference/changelog-2025) · [2024](/knowledge-base/api-reference/changelog-2024)
## Added Stablecoin Reserves Endpoints
**Added** two new endpoints to the Stablecoins API for retrieving reserve information.
**Category**: Stablecoins
**Endpoints Added**:
* `GET /stablecoins/reserves`: Retrieves the history of stablecoin reserves.
* `GET /stablecoins/reserves/entitled-stablecoins`: Gets a list of stablecoins for which the organization is entitled to view reserves.
**Impact**: These new endpoints allow users to programmatically access stablecoin reserve data and history.
## Improved Response Structure for the List Tags Endpoint Beta
**Improved** The response body for the `GET /tags` endpoint now nests the list of tags within a `data` object for consistency with other API endpoints.
**Category**: Tagging
**Endpoint Changed**:
* `GET /tags`: Returns the list of tags nested under a `data` object instead of at the top level.
**Impact**: This is a breaking change. Integrations must be updated to read the list of tags from `response.data.tags` instead of the top-level `response.tags`.
**Example**:
*Previous Response Structure:*
```json theme={null}
{
"tags": [
{
"name": "urgent",
"tagType": "client"
}
]
}
```
*New Response Structure:*
```json theme={null}
{
"data": {
"tags": [
{
"name": "urgent",
"tagType": "client"
}
]
}
}
```
## Improved Field Naming for Creating Wallets on Compatible Networks
**Improved** The `createOnAllCompatibleNetworks` field for creating wallets has been renamed to `activateAllCompatibleNetworks`.
**Category**: Wallets
**Endpoint Changed**:
* `POST /vaults/{vaultId}/wallets`: The `createOnAllCompatibleNetworks` boolean property was removed and replaced by `activateAllCompatibleNetworks`.
**Impact**: This is a breaking change. Integrations using `createOnAllCompatibleNetworks` must switch to `activateAllCompatibleNetworks` to avoid request failures. The field's behavior is unchanged: when set to `true`, it activates the new wallet on every network that is key-compatible with the primary `networkId` and enabled for your organization.
## Improved Wallet Creation and Activation Across Compatible Networks
**Improved** wallet creation and activation to support all compatible networks with a single flag.
**Category**: Wallets
**Endpoints Changed**:
* `POST /vaults/{vaultId}/wallets`: Accepts a new optional boolean parameter, `createOnAllCompatibleNetworks`.
* `POST /wallets/{walletId}/activate`: Accepts a new optional boolean parameter, `activateAllCompatibleNetworks`.
**Impact**: This provides a more efficient way to manage wallets across multiple networks. Instead of listing every compatible network ID, you can use a single boolean flag to create or activate a wallet on all available compatible networks for your organization. The new `...AllCompatibleNetworks` parameters are mutually exclusive with the existing `compatibleNetworkIds` parameter, so you must provide exactly one of them.
## Added Endpoints for Tag Management
**Added** a new Tags API to create, list, and manage tags for entities.
**Category**: Tags
**Endpoints Added**:
* `GET /tags`: Lists tags.
* `POST /tags`: Creates a tag.
* `POST /tags/apply`: Applies tags to an entity.
* `DELETE /tags/apply/{entityId}/{tagName}`: Removes a tag from an entity.
* `GET /tags/search`: Searches for entities by tag.
**Impact**: This introduces a new feature for users to programmatically organize, categorize, and search for their resources using tags.
## Improved Asset Type Details with Compatible Network IDs
**Improved** The `GET /asset-types` endpoint response now includes a list of compatible network IDs.
**Category**: Asset Types
**Endpoint Changed**:
* `GET /asset-types`: The `AssetTypeDetails` object now contains `compatibleNetworkIds`, an array of network IDs that share wallet key derivation with the asset's primary network.
**Impact**: This helps you identify which networks can be used when creating a new wallet or activating an existing wallet on additional networks.
**Example**:
```json theme={null}
{
"data": [
{
"assetType": "ETH",
"name": "Ethereum",
"decimals": 18,
"networkId": "ETH",
"onchainIdentifier": null,
"featureSupport": [
"TRANSFERS",
"HOLDS"
],
"compatibleNetworkIds": [
"POLYGON",
"AVAX_C"
]
}
]
}
```
## Added Tax Lot Selection for Async Orders
**Added** the ability to specify a tax lot ID for async sell orders for tax reporting.
**Category**: Trading
**Endpoints Changed**:
* `POST /trading/async-order`: Accepts a new optional `specLotId` field to specify a tax lot to retire for `SELL` orders with a `timeInForce` of `FOK`; the `rejectReason` field in the response now includes `InvalidSideForSpecLotID` and `InvalidTimeInForceForSpecLotID`.
* `POST /trading/async-order/cancel`: The `rejectReason` field in the response now includes `InvalidSideForSpecLotID` and `InvalidTimeInForceForSpecLotID`.
**Impact**: You can now programmatically manage tax lot retirement for specific `SELL` orders, enhancing tax reporting capabilities.
## Improved Collateral Package Endpoint with Value and Price Details
**Improved** The response for the collateral packages endpoint now includes additional value and pricing details for each package and its underlying assets.
**Category**: Collateral Management
**Endpoint Changed**:
* `GET /collateral_management/packages`: The response now includes optional `exposureValue` and `packageValue` fields at the top level of each package, plus `price`, `quantity`, and `weightedValue` for each asset in the `collateralAssets` array.
**Impact**: This is a non-breaking change that gives you a more complete financial overview of each collateral package directly in the list view.
**Example**:
```json theme={null}
{
"data": [
{
"packageId": "unique-package-id",
"clientReferenceId": "client-ref-123",
"active": true,
"exposureValue": "50000.00",
"packageValue": "100000.00",
"collateralAssets": [
{
"asset": {
"assetType": "BTC",
"type": "ANCHORAGECUSTODY"
},
"price": "60000.00",
"quantity": "1.5",
"weight": "0.9",
"weightedValue": "81000.00"
}
],
// ... other fields
}
],
"page": {
"next": null
}
}
```
## Added Endpoint to Request Collateral Decrease
**Added** a new endpoint that lets users request a collateral decrease for a specified collateral package.
**Category**: Collateral Management
**Endpoint Added**:
* `POST /collateral_management/packages/{packageId}/collateral-decrease`: Initiates a two-way Atlas settlement to return assets from the secured party's collateral wallets to the pledgor's return wallets.
**Impact**: This lets either the pledgor or the secured party programmatically initiate the return of collateral assets. A successful call creates an Atlas settlement, and the `settlementId` is returned in the response for tracking.
**Example**:
```json theme={null}
{
"assetAmounts": [
{ "assetTypeID": "BTC", "value": "1.1" },
{ "assetTypeID": "ETH", "value": "20.62" }
],
"idempotencyKey": "decrease-2024-01-15-pkg-abc",
"useGasStation": false
}
```
## Added Endpoint to Activate Wallets on Additional Networks
**Added** a new endpoint to activate an existing wallet on additional compatible networks.
**Category**: Wallets
**Endpoint Added**:
* `POST /wallets/{walletId}/activate`: Activates an existing wallet on additional compatible networks.
**Impact**: This lets you enable a single wallet for use across multiple networks that share the same key family, streamlining asset management without needing to create separate wallets.
## Added Fiat Details to Transaction Responses
**Added** A new `fiatDetails` object is now included in transaction responses to provide banking details for fiat transactions.
**Category**: Transactions
**Endpoints Changed**:
* `GET /transactions`: The response now includes a `fiatDetails` object for fiat-related transactions.
* `GET /transactions/{transactionId}`: The response now includes a `fiatDetails` object for fiat-related transactions.
**Impact**: This provides key banking information, such as account number, bank name, and FedWire number, which aids in reconciliation and tracking.
**Example**:
```json theme={null}
"fiatDetails": {
"accountNumber": "123456789",
"bankId": "987654321",
"bankName": "Anchorage Digital Bank",
"fedWire": "WIRE12345",
"memo": "Q1 Payout",
"name": "Jane Doe"
}
```
## Added Endpoint to List All Subaccounts
**Added** a new endpoint to retrieve all subaccounts associated with an organization.
**Category**: Subaccounts
**Endpoint Added**:
* `GET /subaccounts/customers/accounts`: Lists all subaccounts for your organization, with filtering by `subaccountIds`, `externalIds`, `endDate`, and `statuses`, plus pagination via `afterId` and `limit`.
**Impact**: This provides a comprehensive, organization-level view of all subaccounts, enabling more efficient and complete data retrieval than fetching subaccounts on a per-customer basis.
## Improved Transfers and Withdrawals with Trusted Destination Support
**Improved** Transfers and withdrawals can now use a Trusted Destination as the destination, and wallet responses can reflect it as a resource type.
**Category**: Transfers, Transactions, Wallets
**Endpoints Changed**:
* `POST /transactions/withdrawal`: Accepts `TRUSTED_DESTINATION` as a `destination.type` value.
* `POST /transfers`: Accepts `TRUSTED_DESTINATION` as a `destination.type` value.
* `GET /transfers`: Can return `TRUSTED_DESTINATION` as a destination type in the response.
* `GET /transfers/{transferId}`: Can return `TRUSTED_DESTINATION` as a destination type in the response.
* `GET /vaults/{vaultId}/wallets`: Can return `TRUSTED_DESTINATION` as a wallet resource type.
* `POST /vaults/{vaultId}/wallets`: Can return `TRUSTED_DESTINATION` as a wallet resource type.
* `GET /wallets`: Can return `TRUSTED_DESTINATION` as a wallet resource type.
* `GET /wallets/{walletId}`: Can return `TRUSTED_DESTINATION` as a wallet resource type.
**Impact**: This simplifies withdrawal and transfer workflows. You can send funds to a pre-configured Trusted Destination by providing its ID, without needing to re-specify address details, memos, or destination tags in each API call. Using Trusted Destinations also reduces the risk of sending funds to an incorrect address.
**Example**:
```json theme={null}
{
"assetType": "XRP",
"amount": "100.00",
"source": {
"id": "1c920f4241b78a1d483a29f3c24b6c4c",
"type": "WALLET"
},
"destination": {
"id": "your_trusted_destination_id",
"type": "TRUSTED_DESTINATION"
}
}
```
## Removed Wallet Activation Endpoint
**Removed** The endpoint for activating an existing wallet on additional compatible networks has been removed.
**Category**: Wallets
**Endpoint Removed**:
* `POST /wallets/{walletId}/activate`
**Impact**: You can no longer programmatically activate an existing wallet on additional compatible networks.
## Added Endpoint to Activate Wallets on Additional Networks
**Added** a new endpoint to activate an existing wallet on additional compatible networks.
**Category**: Wallets
**Endpoint Added**:
* `POST /wallets/{walletId}/activate`: Activates an existing wallet on additional compatible networks that share the same key family, without creating a new wallet.
**Impact**: This lets you enable a single wallet for use across multiple networks that share the same key family, streamlining asset management by reusing a single wallet instead of creating a new one for each network.
## Added Endpoint for Collateral Decrease Requests
**Added** a new endpoint that lets users request a collateral decrease.
**Category**: Collateral Management
**Endpoint Added**:
* `POST /collateral_management/packages/{packageId}/collateral-decrease`: Enables programmatic requests to decrease collateral for a specified package.
**Impact**: This lets you programmatically initiate a decrease in collateral for a specific package.
## Added Compatible Networks Support to Wallet Creation
**Added** an optional `compatibleNetworkIds` field for activating a new wallet on additional compatible networks at the time of creation.
**Category**: Wallets
**Endpoint Changed**:
* `POST /vaults/{vaultId}/wallets`: Accepts a new optional `compatibleNetworkIds` field (an array of strings).
**Impact**: This lets you create a wallet and activate it on multiple compatible networks in a single API call. All specified networks must share the same key family as the primary `networkId`, and activation happens synchronously after wallet creation.
**Example**:
```json theme={null}
{
"networkId": "ETH",
"walletName": "My EVM Wallet",
"compatibleNetworkIds": [
"POLYGON",
"AVAX"
]
}
```
## Improved Memo Handling for Fiat Trusted Destinations
**Improved** The behavior of the `memo` field for fiat transfers and withdrawals to Trusted Destinations has been clarified.
**Category**: Transactions, Transfers, and Trusted Destinations
**Endpoints Changed**:
* `POST /transactions/withdrawal`: The `memo` field within `assetParametersFiatTrustedDestination` is now optional; if omitted, the default memo from the saved Trusted Destination is used.
* `POST /transfers`: The `memo` field within `assetParametersFiatTrustedDestination` is now optional; if omitted, the default memo from the saved Trusted Destination is used.
* `GET /trusted_destinations`: The response now specifies that the `memo` for a fiat destination has a maximum length of 140 characters.
**Impact**: This simplifies API calls by letting you rely on the pre-configured memo on a Trusted Destination, reducing the need to specify it in every withdrawal or transfer request.
## Improved Stablecoin History Response Field Naming
**Improved** In the response for the stablecoin history endpoint, the `issueRedeemId` field has been renamed to `id`.
**Category**: Stablecoins
**Endpoint Changed**:
* `GET /stablecoins/history`: The unique identifier for an issue or redeem operation is now returned as `id` instead of `issueRedeemId`.
**Impact**: This is a breaking change. Integrations that parse `issueRedeemId` must switch to the new `id` field.
**Example**:
*Before:*
```json theme={null}
{
"data": [
{
"issueRedeemId": "b1a1c1...",
"operationType": "ISSUE",
...
}
]
}
```
*After:*
```json theme={null}
{
"data": [
{
"id": "b1a1c1...",
"operationType": "ISSUE",
...
}
]
}
```
## Improved Stablecoin History Endpoint Pagination and Status Detail
**Improved** The stablecoin history response now aligns with the standard paginated format and includes more detailed status information.
**Category**: Stablecoins
**Endpoint Changed**:
* `GET /stablecoins/history`: The response now returns a `data` array plus a `page` object for pagination (replacing `hasNextPage`), adds `destinationOperationId` and `sourceOperationId`, adds a `status` field (`INITIATED`, `EXECUTING`, `COMPLETED`, `FAILED`, `UNKNOWN`), adds an optional `subStatus` field, and expands `operationType` to include `BRIDGE` and `SWAP`.
**Impact**: This is a breaking change. The `conversions` array is now nested under `data`, and pagination uses a `page.next` URL instead of the previous `hasNextPage` boolean. Integrations must be updated to parse the new response structure.
**Example**:
```json theme={null}
{
"data": [
{
"issueRedeemId": "...",
"operationType": "ISSUE",
"status": "COMPLETED",
"subStatus": null,
"sourceAssetTypeId": "USD",
"destinationAssetTypeId": "USDC",
"amount": "100.00",
"sourceOperationId": "...",
"destinationOperationId": "..."
}
],
"page": {
"next": "/v2/stablecoins/history?..."
}
}
```
## Improved Order Type Support with LIMIT\_ALL\_IN
**Improved** Added `LIMIT_ALL_IN` as a new possible enum value for the `orderType` field in trading order responses.
**Category**: Trading
**Endpoints Changed**:
* `GET /trading/orders`: The `orderType` field in the response may now include `LIMIT_ALL_IN`.
* `GET /trading/orders/{orderId}`: The `orderType` field in the response may now include `LIMIT_ALL_IN`.
**Impact**: Responses from the list orders and get order by ID endpoints may now include `LIMIT_ALL_IN` as an `orderType`. Make sure your client can handle this new value.
## Improved Statements with Correction Timestamps and Filtering
**Improved** Added filtering and timestamp information for corrected statements, so you can track and query statements updated after their initial generation.
**Category**: Statements
**Endpoints Changed**:
* `GET /statements`: Accepts two new optional query parameters, `correctedAfter` and `correctedBefore`, to filter for statements corrected at or after or before a given time.
* `GET /statements/{statementId}`: The response now includes a `correctedAt` field indicating when a correction was made.
**Impact**: You can now programmatically identify and filter for statements that have been corrected, improving audit and reconciliation workflows.
**Example**:
```json theme={null}
{
"data": {
"customerId": "fbcdb420fca4439d919089e60d59cd5b12b692d215694681b636bffb6cb1618c",
"createdAt": "2025-09-01T00:47:16.937934Z",
"correctedAt": "2025-09-15T10:00:00.000000Z",
"displayName": "ETF Statement September 2025",
"id": "8de0fc33-7443-4dcf-bbf1-4ca8d0e0509f",
"typeId": "058da362-31a7-4e2b-ae3e-77b095389a5f"
}
}
```
## Added Subaccount ID Filter for Deposit Attributions
**Added** You can now filter deposit attributions by one or more `subaccountIds`.
**Category**: Deposit Attribution
**Endpoint Changed**:
* `GET /deposit-attributions/attributions`: Accepts a new query parameter, `subaccountIds`.
**Impact**: This allows for more granular filtering of deposit attributions, making it easier to retrieve records associated with specific subaccounts.
**Example**: `GET /v2/deposit-attributions/attributions?subaccountIds=subaccount_id_1,subaccount_id_2`
## Improved Permission Requirements for Stablecoin History
**Improved** permission requirements for the stablecoin history endpoint.
**Category**: Stablecoins
**Endpoint Changed**:
* `GET /stablecoins/history`: Now uses the more specific `Read Stablecoin Conversions` permission as the primary requirement.
**Impact**: For backward compatibility, the endpoint continues to accept the older `Read vault activity` permission too, so no immediate changes are required for existing integrations.
## Added Stablecoin Conversion History Endpoint
**Added** a new endpoint to retrieve the history of stablecoin issuance and redemption operations.
**Category**: Stablecoins
**Endpoint Added**:
* `GET /stablecoins/history`: Returns a historical list of your stablecoin issuance and redemption operations.
**Impact**: You can now programmatically access your stablecoin conversion history for tracking and reporting purposes.
## Added Binance as a Price Source for Collateral Management
**Added** support for `BINANCE` as a price source in Collateral Management.
**Category**: Collateral Management
**Endpoints Changed**:
* `GET /collateral_management/price_sources`: Now returns `BINANCE` as an available source and accepts it as a filter in the `exchange` query parameter.
* `POST /collateral_management/packages`: The `priceSource` field now accepts `BINANCE`.
* `PATCH /collateral_management/packages/{packageId}`: The `priceSource` field now accepts `BINANCE`.
* `POST /collateral_management/exposures`: The `priceSource` field now accepts `BINANCE`.
**Impact**: This allows for more flexible pricing options when creating and managing collateral packages and exposures.
**Example**:
```json theme={null}
"collateralAssetsConfig": [
{
"asset": {
"assetType": "BTC",
"type": "ANCHORAGECUSTODY"
},
"priceSource": "BINANCE",
"weight": "1.0",
"liquidationPriority": 1
}
]
```
## Added Accelerated Margin Call for Collateral Management
**Added** A new `acceleratedMarginCall` configuration level for collateral packages, letting you set an additional margin call threshold with its own LTV, cure period, and action.
**Category**: Collateral Management
**Endpoints Changed**:
* `POST /collateral_management/packages`: Accepts a new `acceleratedMarginCall` object in the request body.
* `PATCH /collateral_management/packages/{packageId}`: Accepts a new `acceleratedMarginCall` object in the request body.
* `GET /collateral_management/packages`: The response now includes the `acceleratedMarginCall` object.
**Impact**: You can now define and monitor an additional, accelerated margin call level for your collateral packages, providing more granular risk management.
## Removed TRUSTED\_DESTINATION Resource Type from Transfers and Wallets
**Removed** The `TRUSTED_DESTINATION` enum value from the `destination.type` field for transfer and withdrawal requests, and from the `type` field in several Wallet and Transfer responses.
**Category**: Transfers, Transactions, and Wallets
**Endpoints Changed**:
* `POST /transactions/withdrawal`: `destination.type` no longer accepts `TRUSTED_DESTINATION`; the `assetParametersATOM` field is now deprecated in favor of `assetParametersCosmos`.
* `POST /transfers`: `destination.type` no longer accepts `TRUSTED_DESTINATION`; the `assetParametersATOM` field is now deprecated in favor of `assetParametersCosmos`.
* `GET /transfers`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `GET /transfers/{transferId}`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `GET /vaults/{vaultId}/wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `POST /vaults/{vaultId}/wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `GET /wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `GET /wallets/{walletId}`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
**Impact**: This is a breaking change. Requests that specify `destination.type` as `TRUSTED_DESTINATION` will now fail. To send funds to a trusted destination, use `destination.type: 'ADDRESS'` with the specific blockchain address, and update any logic that parses the `type` field in Wallet and Transfer responses. Users are encouraged to migrate from the deprecated `assetParametersATOM` to `assetParametersCosmos`.
## Improved Order Filtering Parameter Description
**Improved** the description for the `orderTypes` query parameter to enhance clarity.
**Category**: Trading
**Endpoint Changed**:
* `GET /trading/orders`: The description for the `orderTypes` parameter was updated.
**Impact**: This is a non-breaking documentation change. No integration updates are required.
## Improved Statement Filtering and Response Structure
**Improved** the Statements endpoints with updated filtering parameters and a restructured response body.
**Category**: Statements
**Endpoints Changed**:
* `GET /statements`: Removed the `statementIds`, `statementTypes`, `accountIds`, `affiliateIds`, `vaultGroupIds`, and `subaccountIds` filter parameters, and added `ids`, `typeIds`, and `customerIds`. The response no longer includes `accountId`, `affiliateId`, `subaccountId`, `vaultGroupId`, or the required `type` field, and now includes `customerId` and the new required `typeId` field (`type` is now optional).
* `GET /statements/{statementId}`: The response no longer includes `accountId`, `affiliateId`, `subaccountId`, `vaultGroupId`, or the required `type` field, and now includes `customerId` and the new required `typeId` field (`type` is now optional).
**Impact**: This is a breaking change. Integrations using the `/statements` endpoints must be updated to use the new query parameters and handle the modified response structure.
## Improved Order Type Support with MANUAL
**Improved** Added support for a new `MANUAL` order type.
**Category**: Trading
**Endpoints Changed**:
* `GET /trading/orders`: The `orderType` field in the response can now include `MANUAL`.
* `GET /trading/orders/{orderId}`: The `orderType` field in the response can now include `MANUAL`.
**Impact**: Clients should update their integrations to handle this new enum value when listing or retrieving orders.
## Improved Fiat Trusted Destination Response Structure
**Improved** The structure of the `fiat` object in the trusted destinations response has been refactored for clarity, with beneficiary and financial institution details now grouped into nested `beneficiary` and `beneficiaryBank` objects, plus new `intermediaryBank` and `usage` fields.
**Category**: Trusted Destinations
**Endpoint Changed**:
* `GET /trusted_destinations`: The `fiat` object's flat beneficiary and institution properties are now nested under `beneficiary` and `beneficiaryBank`, and the object gains `intermediaryBank` and `usage` fields.
**Impact**: This is a breaking change. Integrations that parsed the flat properties within the `fiat` object must be updated to handle the new nested structure. The new `usage` field indicates whether the recipient account is owned by your organization or a third party.
**Example**:
*Before:*
```json theme={null}
{
"fiat": {
"beneficiaryName": "Satoshi Nakamoto",
"beneficiaryAccount": "*****1234",
"institutionName": "The Bank of New York Mellon",
"institutionId": "IRVTUS3N",
//... other flat properties
}
}
```
*After:*
```json theme={null}
{
"fiat": {
"beneficiary": {
"name": "Satoshi Nakamoto",
"account": "*****1234",
//... other beneficiary properties
},
"beneficiaryBank": {
"name": "The Bank of New York Mellon",
"id": "IRVTUS3N",
//... other bank properties
},
"intermediaryBank": {},
"usage": "MY_ORGANIZATION"
}
}
```
## Added Fiat Support for Trusted Destinations
**Added** support for fiat (bank account) trusted destinations.
**Category**: Trusted Destinations
**Endpoint Changed**:
* `GET /trusted_destinations`: The response now includes details for fiat-based trusted destinations.
**Impact**: When listing trusted destinations, a fiat destination now has a `type` of `fiat` and contains a new `fiat` object with detailed bank account information.
**Example**:
```json theme={null}
{
"data": [
{
"id": "td_fiat_12345",
"name": "Corporate Bank Account",
"description": "Primary USD account",
"type": "fiat",
"owner": {
"id": "customer_abc",
"type": "CUSTOMER"
},
"fiat": {
"beneficiaryName": "Example Corp",
"beneficiaryAccount": "987654321",
"beneficiaryType": "BUSINESS",
"institutionName": "Example Bank",
"institutionId": "121000358",
"institutionCode": "ABA",
"memo": "For operating expenses"
},
"crypto": null
}
]
}
```
## Improved Order Allocation Details with Filled Quantity
**Improved** The `allocation` object in trading order responses now includes the `cumQty` field, which specifies the filled quantity for each subaccount allocation.
**Category**: Trading
**Endpoints Changed**:
* `POST /trading/order`: The `allocation` object in the response now includes the required `cumQty` field.
* `GET /trading/orders`: The `allocation` object in the response now includes the required `cumQty` field.
* `GET /trading/orders/{orderId}`: The `allocation` object in the response now includes the required `cumQty` field.
* `POST /trading/async-order`: The `allocation` object in the response now includes the required `cumQty` field.
* `POST /trading/async-order/cancel`: The `allocation` object in the response now includes the required `cumQty` field.
**Impact**: This is a non-breaking change that provides more granular data on order fills at the subaccount level.
**Example**:
```json theme={null}
"allocation": [
{
"subaccountId": "905272f0-52f9-404e-b6cd-ad879e671790",
"quantity": "10000",
"cumQty": "10000",
"counterQtyAllIn": "10000",
"counterQtyAllInToSettle": "10000",
"fee": "10000"
}
]
```
## Improved Collateral Management Price Sources Endpoint
**Improved** Added a new `501 Not Implemented` response and clarified the `exchange` query parameter description.
**Category**: Collateral Management
**Endpoint Changed**:
* `GET /collateral_management/price_sources`: Now returns a `501 Not Implemented` error if the price sources feature is disabled; the `exchange` parameter description was simplified.
**Impact**: API consumers will now receive a `501 Not Implemented` error if the price sources feature is disabled.
## Improved Clarity for Tax Reporting Deposit Transaction Endpoints
**Improved** descriptions for the Tax Reporting endpoints to clarify that cost basis management applies specifically to deposit transactions.
**Category**: Tax Reporting
**Endpoints Changed**:
* `PATCH /tax/accounts/{accountId}/transactions/{transactionId}`: The endpoint and `hasCostBasis` parameter descriptions were improved for accuracy.
* `GET /tax/accounts/{accountId}/transactions`: The endpoint and `hasCostBasis` parameter descriptions were improved for accuracy.
**Impact**: This is a documentation-only change to improve clarity. The functionality of the endpoints remains unchanged.
## Improved Async Order Responses with Counter Currency Details
**Improved** Added `counterCurrency`, `counterQty`, and `counterQtyAllIn` fields to the responses for placing and canceling async orders.
**Category**: Trading
**Endpoints Changed**:
* `POST /trading/async-order`: The response now includes `counterCurrency`, `counterQty`, and `counterQtyAllIn`.
* `POST /trading/async-order/cancel`: The response now includes `counterCurrency`, `counterQty`, and `counterQtyAllIn`.
**Impact**: The responses for placing and canceling an async order now include the counter currency, the filled quantity of the counter currency, and the filled quantity including all fees.
**Example**:
```json theme={null}
{
"data": {
"clOrderId": "6fb5fc79-0bb4-446d-82dd-d4687fb56a02",
"orderId": "a94c8d75-6c9d-4903-95f3-5b0893e76cb7",
// ... existing fields
"counterCurrency": "BTC",
"counterQty": "0.4760680586896702",
"counterQtyAllIn": "0.4760544606302961",
"transactTime": "2023-03-12T22:22:09.925050Z"
}
}
```
## Added Collateral Management Price Sources Endpoint
**Added** a new endpoint to get available price sources and their supported assets.
**Category**: Collateral Management
**Endpoint Added**:
* `GET /collateral_management/price_sources`: Returns supported price sources and the specific assets available for each source.
**Impact**: This lets clients programmatically retrieve supported price sources, which can be used to validate configurations for collateral packages.
## Improved Price Strategy Options for Collateral Management
**Improved** The `priceStrategy` options for creating and managing collateral packages and exposures now include `MID` and `LAST`; `VWAP` has been removed.
**Category**: Collateral Management
**Endpoints Changed**:
* `POST /collateral_management/packages`: The `priceStrategy` field now accepts `MID` and `LAST`; `VWAP` is no longer supported.
* `PATCH /collateral_management/packages/{packageId}`: The `priceStrategy` field now accepts `MID` and `LAST`; `VWAP` is no longer supported.
* `POST /collateral_management/exposures`: The `priceStrategy` field now accepts `MID` and `LAST`; `VWAP` is no longer supported.
**Impact**: This is a breaking change. Integrations using the `priceStrategy` field must switch from `VWAP` to `MID` or `LAST`.
## Added Fiat Parameters for Trusted Destination Transfers and Withdrawals
**Added** A new `assetParametersFiatTrustedDestination` object to the request body for fiat transfers and withdrawals to Trusted Destinations.
**Category**: Transactions, Transfers
**Endpoints Changed**:
* `POST /transactions/withdrawal`: Accepts a new optional `assetParametersFiatTrustedDestination` object with `memo` and `purpose` fields.
* `POST /transfers`: Accepts a new optional `assetParametersFiatTrustedDestination` object with `memo` and `purpose` fields.
**Impact**: This lets you provide additional context when sending fiat assets to a Trusted Destination, which is useful for record-keeping and compliance.
**Example**:
```json theme={null}
{
"assetType": "USD",
"amount": "5000.00",
"source": {
"id": "1c920f4241b78a1d483a29f3c24b6c4c",
"type": "WALLET"
},
"destination": {
"id": "td_123abc...",
"type": "TRUSTED_DESTINATION"
},
"assetParametersFiatTrustedDestination": {
"memo": "Q1 Payout",
"purpose": "INVESTMENT"
},
"idempotentId": "unique-withdrawal-id-123"
}
```
## Improved Offchain Vesting Schedule Response with Asset Type
**Improved** the response for listing offchain vesting schedules to include the asset type.
**Category**: Vesting
**Endpoint Changed**:
* `GET /offchainvesting/schedules`: Each schedule object in the `data` array now includes the `assetType` field, specifying the asset abbreviation (for example, BTC or ETH).
**Impact**: This is a non-breaking, additive change that makes it easier to identify the asset associated with each vesting schedule directly from the list endpoint.
## Improved Transfers and Withdrawals with Trusted Destinations
**Improved** You can now use pre-configured Trusted Destinations when creating transfers and withdrawals, sending funds to a `TRUSTED_DESTINATION` ID instead of a full address.
**Category**: Transfers & Withdrawals
**Endpoints Changed**:
* `POST /transfers`: The `destination.type` field now accepts `TRUSTED_DESTINATION`.
* `POST /transactions/withdrawal`: The `destination.type` field now accepts `TRUSTED_DESTINATION`.
* `GET /transfers`: The response can now reflect `TRUSTED_DESTINATION` as a destination type.
* `GET /transfers/{transferId}`: The response can now reflect `TRUSTED_DESTINATION` as a destination type.
**Impact**: When sending to a `TRUSTED_DESTINATION`, you no longer need to include asset-specific parameters like `assetParametersXRP` or `assetParametersXLM` — the destination tag or memo is inherited automatically from the trusted destination's configuration.
**Example**:
```json theme={null}
// POST /transactions/withdrawal
{
"assetType": "XRP",
"amount": "100.0",
"source": {
"id": "your_wallet_id",
"type": "WALLET"
},
"destination": {
"id": "your_trusted_destination_id",
"type": "TRUSTED_DESTINATION"
},
"idempotentId": "unique-id-for-withdrawal-123"
}
```
## Improved Market Data Endpoint with Amount-Based Depth
**Improved** The market data endpoint now supports returning market depth by notional value, such as USD, in addition to asset size.
**Category**: Trading
**Endpoint Changed**:
* `GET /trading/marketdata`: A new `amount` field has been added to the `bids` and `offers` objects, returned when using the `amountBuckets` query parameter; the existing `size` field is returned when using `sizeBuckets`.
**Impact**: This is a non-breaking change that lets you request market depth in notional terms instead of, or alongside, asset size.
**Example**:
```json theme={null}
// Request using amountBuckets
GET /trading/marketdata?symbol=BTC-USD&amountBuckets=10000,50000
// Sample Response Snippet
"bids": [
{
"price": "65000.00",
"amount": "10000.00" // New field: value in USD
},
{
"price": "64950.00",
"amount": "50000.00" // New field: value in USD
}
]
```
## Added Endpoint to Propose Trusted Counterparties
**Added** A new endpoint to propose a new trusted counterparty.
**Category**: Atlas Settlement Network
**Endpoint Added**:
* `POST /atlas/directory/counterparties`: Proposes a new trusted counterparty.
**Impact**: You can now programmatically propose new trusted counterparties, streamlining the process of adding new settlement partners.
## Improved Market Data Parameter Descriptions
**Improved** descriptions for the `sizeBuckets` and `amountBuckets` query parameters to clarify their usage and impact on the response.
**Category**: Trading
**Endpoint Changed**:
* `GET /trading/marketdata`: `sizeBuckets` is clarified as a comma-separated list; `amountBuckets` is clarified as a comma-separated list of USD values, with a note that using it affects how `size` is represented in the response.
**Impact**: This is a non-breaking documentation change that provides better guidance for querying market depth.
## Improved Cost Basis Reporting with Tax Lots
**Improved** the Tax Reporting endpoints to support lot-level cost basis management for more granular and accurate tax data.
**Category**: Tax Reporting
**Endpoints Changed**:
* `PATCH /tax/accounts/{accountId}/transactions/{transactionId}`: The request body now requires a `lots` array (each with `lotId`, `quantity`, and `costBasis`) in place of the previous `data`, `acquisitionDatetime`, and `assetType` fields.
* `GET /tax/accounts/{accountId}/transactions`: The response now includes a required top-level `assetType` field per transaction, and an `acquisitionDatetime` field on each lot in the `receivedAssets` array.
**Impact**: This moves cost basis reporting from a per-transaction model to a per-lot model, letting you specify and retrieve cost basis information for individual lots within a single transaction.
## Added Market Data Endpoint
**Added** a new endpoint to retrieve a snapshot of market data.
**Category**: Trading
**Endpoint Added**:
* `GET /trading/marketdata`: Returns a snapshot of current market data.
**Impact**: You can now programmatically access market data for pricing, analysis, and other trading-related activities. See the [Market Data Guide](https://developers.anchorage.com/docs/websocket-api-market-data) for more information.
## Improved Transaction Types and Settlement Parameter Documentation
**Improved** Added the `FIAT_INTEREST` transaction type and clarified the `applyPostLock` parameter description.
**Category**: Transactions, Atlas Settlement Network
**Endpoints Changed**:
* `GET /transactions`: The `transactionType` field in the response can now include `FIAT_INTEREST`, representing fiat interest payments.
* `GET /transactions/{transactionId}`: The `transactionType` field in the response can now include `FIAT_INTEREST`, representing fiat interest payments.
* `POST /atlas/settlements`: The description for the `applyPostLock` parameter now clarifies it applies only to clients using Atlas settlements integrated with Anchorage Vesting.
**Impact**: Clients should update their systems to handle the new `FIAT_INTEREST` transaction type. The `applyPostLock` documentation change is non-breaking and only clarifies existing behavior.
## Deprecated `totalDistribution` Field in Tax Tagging
**Deprecated** the `totalDistribution` field for tagging tax transactions.
**Category**: Tax
**Endpoint Changed**:
* `POST /tax/transaction/{transactionId}/tag`: The `totalDistribution` field in the request body is now deprecated and ignored if provided.
**Impact**: Any value passed in `totalDistribution` is disregarded — total distribution status is now calculated automatically from account balances. Remove this field from your requests, since it no longer has any effect.
## Added Post-Settlement Locking for Atlas Settlements
**Added** a new `applyPostLock` parameter to automatically create post-settlement holds on funds received through the Atlas Settlement Network.
**Category**: Atlas Settlement Network
**Endpoint Changed**:
* `POST /atlas/settlements`: Accepts a new optional boolean `applyPostLock` parameter; when `true`, indefinite holds are placed on the acceptor's destination wallets after a successful settlement.
**Impact**: This enables the automatic creation of post-settlement vesting schedules on received funds, streamlining workflows that require funds to be locked after settlement.
## Added Vesting Schedules Endpoint and Tax Transaction Cost Basis Filter
**Added** a new endpoint for listing offchain vesting schedules and a new filter for tax transactions.
**Category**: Vesting, Tax Reporting
**Endpoints Changed**:
* `GET /offchainvesting/schedules`: New endpoint that lists all offchain vesting schedules for your organization.
* `GET /tax/accounts/{accountId}/transactions`: Accepts a new `hasCostBasis` query parameter to filter transactions that do or don't have a cost basis.
**Impact**: This provides programmatic access to vesting schedules and lets you filter tax transactions by whether they have a cost basis, improving transparency and reporting.
## Improved Transaction Types with Priority Fee Reward
**Improved** The `transactionType` field in transaction-related endpoints now includes `PRIORITY_FEE_REWARD` to represent priority fee rewards.
**Category**: Transactions
**Endpoints Changed**:
* `GET /transactions`: The `transactionType` field in the response can now include `PRIORITY_FEE_REWARD`.
* `GET /transactions/{transactionId}`: The `transactionType` field in the response can now include `PRIORITY_FEE_REWARD`.
**Impact**: This new type identifies priority fee rewards, such as those from Jito priority fee distributions on Solana.
## Improved Clarity for Trusted Destination Asset Type
**Improved** The description for the `assetType` field has been updated to provide better clarity when creating a trusted destination.
**Category**: Trusted Destinations
**Endpoint Changed**:
* `POST /trusted_destinations`: The description for `assetType` in the `trustedDestinations` array now clarifies what an asset type is and points to `GET /asset-types` for a list of supported types.
**Impact**: This is a non-breaking documentation change. The endpoint's functionality remains the same.
## Improved Security with Signature Requirements for Collateral Management
**Improved** security by requiring `Api-Signature` and `Api-Timestamp` headers for write operations on Collateral Management endpoints.
**Category**: Collateral Management
**Endpoints Changed**:
* `PATCH /collateral_management/operations/{operationId}`: Now requires `Api-Signature` and `Api-Timestamp` headers.
* `PATCH /collateral_management/packages/{packageId}`: Now requires `Api-Signature` and `Api-Timestamp` headers.
* `POST /collateral_management/exposures`: Now requires `Api-Signature` and `Api-Timestamp` headers.
* `POST /collateral_management/operations`: Now requires `Api-Signature` and `Api-Timestamp` headers.
* `POST /collateral_management/packages`: Now requires `Api-Signature` and `Api-Timestamp` headers.
**Impact**: This is a breaking change. Requests to these endpoints will now fail if they don't include valid signature and timestamp headers. See the Request Signatures section of the documentation for instructions on generating a valid signature.
## Improved Wallet Responses with Unvested and Unstakeable Balances
**Improved** Wallet-related endpoints now include more detailed balance information for offchain vesting.
**Category**: Wallets
**Endpoints Changed**:
* `GET /vaults/{vaultId}/wallets`: The `assets` object now includes `unvestedBalance` and `unvestedUnstakeableBalance` fields.
* `POST /vaults/{vaultId}/wallets`: The `assets` object now includes `unvestedBalance` and `unvestedUnstakeableBalance` fields.
* `GET /wallets`: The `assets` object now includes `unvestedBalance` and `unvestedUnstakeableBalance` fields.
* `GET /wallets/{walletId}`: The `assets` object now includes `unvestedBalance` and `unvestedUnstakeableBalance` fields.
**Impact**: This is a non-breaking change. Responses now contain additional balance details for assets in offchain vesting contracts, where applicable.
## Improved Vesting Balance Retrieval for Multiple Allocations
**Improved** vesting balance retrieval by adding a new endpoint to fetch balances for multiple allocations in a single request.
**Category**: Vesting
**Endpoint Added**:
* `POST /vesting/balances`: Retrieves vesting balances for multiple allocations in a single request.
**Impact**: This allows for more efficient retrieval of balance data by fetching information for multiple allocations at once, reducing the number of required API calls.
## Improved Security with Request Signing for Atlas Settlement Endpoints
**Improved** security by adding request signing to key Atlas Settlement Network endpoints, which now require `Api-Signature` and `Api-Timestamp` headers.
**Category**: Atlas Settlement Network
**Endpoints Changed**:
* `POST /atlas/settlements`: Now requires `Api-Signature` and `Api-Timestamp` headers.
* `POST /atlas/settlements/{settlementId}/accept`: Now requires `Api-Signature` and `Api-Timestamp` headers.
* `POST /atlas/settlements/{settlementId}/authorize`: Now requires `Api-Signature` and `Api-Timestamp` headers.
* `POST /atlas/settlements/{settlementId}/reject`: Now requires `Api-Signature` and `Api-Timestamp` headers.
**Impact**: This is a breaking change. Requests made to the listed endpoints will now fail if they don't include the required signature headers. See the Request Signatures section of the documentation for instructions on generating the required signatures.
## Improved Stablecoin Conversion Documentation
**Improved** the description for the `sourceAssetType` field in the stablecoin conversion request body for clarity.
**Category**: Stablecoins
**Endpoint Changed**:
* `POST /stablecoins/conversion`: The `sourceAssetType` description now clarifies that it must be `USD` for an issuance, and the asset being redeemed for a redemption.
**Impact**: This is a non-breaking documentation change.
## Improved Staking Request Descriptions
**Improved** The descriptions for the `parameters` object and the `stakingProviderAddress` field for Solana staking requests have been updated for clarity.
**Category**: Transactions
**Endpoint Changed**:
* `POST /transactions/stake`: The description for the `parameters` object was updated, and within `SOLStakingParameters`, `stakingProviderAddress` now describes "the validator's vote account address" instead of "the validator's staking address".
**Impact**: This is a non-breaking documentation change to provide better clarity for clients creating Solana (SOL) staking requests.
## Added Endpoint for Consolidating Stakes
**Added** a new endpoint to create a consolidate stake request.
**Category**: Transactions
**Endpoint Added**:
* `POST /transactions/consolidate-stake`: Initiates a request to consolidate staking positions.
**Impact**: This feature enhances staking management by allowing users to consolidate stakes directly through the API. See the [staking guide](https://developers.anchorage.com/docs/ethereum-pectra-staking-api#consolidate-pectra-to-pectra-validator) for instructions on use.
## Improved Backward Compatibility by Re-introducing the VAULT Resource Type
**Improved** backward compatibility by re-introducing the `VAULT` enum value for source and destination resources; it's accepted but deprecated in favor of `WALLET`.
**Category**: Transfers, Wallets, and Transactions
**Endpoints Changed**:
* `POST /transactions/withdrawal`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`.
* `POST /transfers`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`.
* `GET /transfers`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`.
* `GET /transfers/{transferId}`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`.
* `GET /vaults/{vaultId}/wallets`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`.
* `POST /vaults/{vaultId}/wallets`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`.
* `GET /wallets`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`.
* `GET /wallets/{walletId}`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`.
**Impact**: This restores backward compatibility for integrations still using the `VAULT` resource type. We strongly recommend updating existing code to use `WALLET` instead, since support for `VAULT` will be removed in a future release.
## Fixed AML Questionnaire Requirement by Organization Type
**Fixed** The `trustedDestinationAmlQuestionnaire` field is now conditionally required based on the organization type.
**Category**: Trusted Destinations
**Endpoint Changed**:
* `POST /trusted_destinations`: The `trustedDestinationAmlQuestionnaire` field is now required for Anchorage Digital organizations and must be omitted for Porto organizations.
**Impact**: Requests to create a trusted destination will now fail if `trustedDestinationAmlQuestionnaire` is included for a Porto organization or omitted for an Anchorage Digital organization.
## Added Endpoints for Tax Account Management
**Added** new endpoints to the Tax API for managing tax accounts and their associated transactions.
**Category**: Tax
**Endpoints Added**:
* `GET /tax/accounts`: Lists tax accounts.
* `GET /tax/accounts/{accountId}/transactions`: Retrieves transactions for a specific tax account.
* `PATCH /tax/accounts/{accountId}/transactions/{transactionId}`: Updates the cost basis of a transaction for tax reporting.
**Impact**: These new endpoints let you list tax accounts, retrieve transactions for a specific account, and update the cost basis of a transaction for tax reporting purposes.
## Removed TRUSTED\_DESTINATION as a Resource Type
**Removed** The `TRUSTED_DESTINATION` value as a valid enum for the resource `type` field.
**Category**: Transfers, Withdrawals, Wallets
**Endpoints Changed**:
* `POST /transactions/withdrawal`: The `destination.type` field no longer accepts `TRUSTED_DESTINATION`.
* `POST /transfers`: The `destination.type` field no longer accepts `TRUSTED_DESTINATION`.
* `GET /transfers`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `GET /transfers/{transferId}`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `GET /vaults/{vaultId}/wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `POST /vaults/{vaultId}/wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `GET /wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
* `GET /wallets/{walletId}`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`.
**Impact**: This is a breaking change. API calls using `destination.type: TRUSTED_DESTINATION` will now fail. Specify the underlying `ADDRESS` or `WALLET` directly when creating transfers or withdrawals.
## Improved Tax Transaction Tagging with IRS Combination Codes
**Improved** The `distributionCode` field for tagging tax transactions now supports IRS combination codes.
**Category**: Tax
**Endpoint Changed**:
* `POST /tax/transaction/{transactionId}/tag`: The `distributionCode` field now accepts combination codes (for example, `1B`, `4G`, `7B`) as valid enum values.
**Impact**: This allows for more accurate tax reporting when a distribution has multiple applicable IRS classifications, such as using `4G` for a death-related direct rollover.
## Improved Collateral Management Operations with Liquidation Details
**Improved** The response for Collateral Management Operations now includes liquidation details and an update timestamp.
**Category**: Collateral Management
**Endpoints Changed**:
* `PATCH /collateral_management/operations/{operationId}`: The `CMOperation` model now includes `updatedAt`, `liquidationCollateralPackageId`, `liquidationProceedAsset`, and `liquidationProceedQuantity`.
* `GET /collateral_management/operations`: The `CMOperation` model now includes `updatedAt`, `liquidationCollateralPackageId`, `liquidationProceedAsset`, and `liquidationProceedQuantity`.
**Impact**: This provides more comprehensive data on operations, particularly those involving liquidations.
## Improved API Key Info Response with WRITE\_TAX Permission
**Improved** Added the new `WRITE_TAX` permission type, which now appears in the response for the get API key info endpoint.
**Category**: API Key
**Endpoint Changed**:
* `GET /apikey`: The `permissions` array in the response now includes `WRITE_TAX` for API keys that have this permission.
**Impact**: This is a non-breaking change.
**Example**:
```json theme={null}
{
"data": {
"id": "b5a58566763e77e2d87a53463013981be7c0b048c1c0dd39ba44e77c99bc1351",
"permissions": [
{
"permission": "READ",
"vaultIds": [
"1c920f4241b78a1d483a29f3c24b6c4c"
]
},
{
"permission": "WRITE_TAX"
}
]
}
}
```
## Added AML Questionnaire to Trusted Destination Creation
**Added** an optional `trustedDestinationAmlQuestionnaire` object to the request body for creating trusted destinations, so Anti-Money Laundering information can be submitted upfront.
**Category**: Trusted Destinations
**Endpoint Changed**:
* `POST /trusted_destinations`: Accepts an optional `trustedDestinationAmlQuestionnaire` object within each item of the `trustedDestinations` array.
**Impact**: This is a non-breaking change. Providing AML information when creating a trusted destination can streamline the approval process for future withdrawals to that address.
**Example**:
```json theme={null}
{
"idempotentId": "1ca86e65-4340-4876-85f4-8334852b9c43",
"owner": {
"type": "CUSTOMER",
"id": "your-customer-id"
},
"trustedDestinations": [
{
"assetType": "BTC",
"address": "2N19AcihQ1a4MxQW658UFHTioUNnMkiHPkw",
"name": "My Exchange Wallet",
"description": "BTC wallet at Example Exchange",
"trustedDestinationAmlQuestionnaire": {
"destinationType": "FINANCIAL_INSTITUTION",
"institutionName": "Example Exchange",
"institutionCountry": "US",
"recipientType": "DESTINATION_INSTITUTION"
}
}
]
}
```
## Improved Deposit Address Security with V2 Signatures
**Improved** security by introducing a V2 signature scheme for deposit addresses.
**Category**: Addresses, Wallets
**Endpoints Changed**:
* `GET /vaults/{vaultId}/addresses`: Signed address responses can now include `signatureVersion` and `certChain` fields.
* `POST /wallets/{walletId}/addresses`: Signed address responses can now include `signatureVersion` and `certChain` fields.
* `GET /vaults/{vaultId}/wallets`: Signed address responses can now include `signatureVersion` and `certChain` fields.
* `POST /vaults/{vaultId}/wallets`: Signed address responses can now include `signatureVersion` and `certChain` fields.
* `GET /wallets`: Signed address responses can now include `signatureVersion` and `certChain` fields.
* `GET /wallets/{walletId}`: Signed address responses can now include `signatureVersion` and `certChain` fields.
**Impact**: This is a backward-compatible change that gives clients a more robust, certificate-based way to verify deposit address authenticity. When `signatureVersion` is `V2`, the `certChain` field contains an x509 certificate chain for verification against a trusted Anchorage Digital Root CA; if `certChain` is absent, use the existing V1 signature verification method. See the [Address Verification guide](https://developers.anchorage.com/docs/address-verification) for instructions.
## Added MINT Transaction Type
**Added** `MINT` as a new transaction type to represent assets minted or created on the blockchain.
**Category**: Transactions
**Endpoints Changed**:
* `GET /transactions`: The `types` query parameter now accepts `MINT` to filter transactions, and the `transactionType` field in the response can now return `MINT`.
* `GET /transactions/{transactionId}`: The `transactionType` field in the response can now return `MINT`.
**Impact**: You can now filter for and identify `MINT` transactions across both the list and single-transaction endpoints.
## Improved Error Handling for Collateral Package Updates
**Improved** error handling by adding a new `422 Unprocessable Entity` error response to the update collateral package endpoint.
**Category**: Collateral Management
**Endpoint Changed**:
* `PATCH /collateral_management/packages/{packageId}`: Now returns `422 Unprocessable Entity` for requests that are syntactically correct but semantically invalid.
**Impact**: This lets clients differentiate between a bad request (`400`), a resource not found (`404`), and an unprocessable entity (`422`).
## Improved Pricing Options for Collateral Management
**Improved** Added new options for price strategy and price source to provide more flexibility in Collateral Management configurations.
**Category**: Collateral Management
**Endpoints Changed**:
* `POST /collateral_management/packages`: The `priceStrategy` field now accepts `VWAP`, and the `priceSource` field now accepts `KAMINO`.
* `PATCH /collateral_management/packages/{packageId}`: The `priceStrategy` field now accepts `VWAP`, and the `priceSource` field now accepts `KAMINO`.
* `POST /collateral_management/exposures`: The `priceStrategy` field now accepts `VWAP`, and the `priceSource` field now accepts `KAMINO`.
**Impact**: You can now specify `VWAP` (Volume-Weighted Average Price) as a pricing strategy and `KAMINO` as a price source when creating or updating collateral packages and exposures.
## Added BURN Transaction Type
**Added** a new `BURN` transaction type to represent assets that are burned or destroyed on the blockchain.
**Category**: Transactions
**Endpoints Changed**:
* `GET /transactions`: The `types` query parameter now accepts `BURN` to filter transactions, and the `transactionType` field in the response can now return `BURN`.
* `GET /transactions/{transactionId}`: The `transactionType` field in the response can now return `BURN`.
**Impact**: This helps with clearer categorization of on-chain asset destruction events.
## Removed priceSourceProvider from Collateral Management Endpoints
**Removed** the `priceSourceProvider` field from the request bodies of several Collateral Management endpoints.
**Category**: Collateral Management
**Endpoints Changed**:
* `POST /collateral_management/packages`: The `priceSourceProvider` field is no longer available in `collateralAssetsConfig`.
* `PATCH /collateral_management/packages/{packageId}`: The `priceSourceProvider` field is no longer available in `collateralAssetsConfig`.
* `POST /collateral_management/exposures`: The `priceSourceProvider` field is no longer available in `assetTrackingConfig`.
**Impact**: API requests that include the `priceSourceProvider` field will now result in an error. Update your integrations to remove this field to ensure successful requests.
## Improved Collateral Management Operations with GAS\_FEE Action
**Improved** the `CMOperation` model to include a new `GAS_FEE` action type.
**Category**: Collateral Management
**Endpoints Changed**:
* `PATCH /collateral_management/operations/{operationId}`: The `action` field in the response can now include `GAS_FEE`.
* `GET /collateral_management/operations`: The `action` field in the response can now include `GAS_FEE`.
**Impact**: This provides more granular detail on operation types.
## Improved Fiat Deposit Instructions with Memo Field
**Improved** A `memoField` has been added to the `depositInstruction` object returned for fiat wallets.
**Category**: Wallets
**Endpoints Changed**:
* `GET /vaults/{vaultId}/wallets`: The `depositInstruction` object for fiat wallets now includes `memoField`.
* `POST /vaults/{vaultId}/wallets`: The `depositInstruction` object for fiat wallets now includes `memoField`.
* `GET /wallets`: The `depositInstruction` object for fiat wallets now includes `memoField`.
* `GET /wallets/{walletId}`: The `depositInstruction` object for fiat wallets now includes `memoField`.
**Impact**: This is a non-breaking, additive change. Include this memo on wire deposits to ensure funds are attributed correctly to the wallet.
**Example**:
```json theme={null}
"depositInstruction": {
"memoField": "123456789",
"bankName": "Example Bank",
"bankRoutingNumber": "123456789",
"bankAddress": "123 Main Street, Anytown, USA 12345",
"bankSwiftCode": "12345678",
"beneficiaryName": "John Doe",
"beneficiaryAddress": "123 Main Street, Anytown, USA 12345",
"beneficiaryAccountNumber": "12345678"
}
```
## Improved Wallet Details with Fiat Deposit Instructions
**Improved** Wallet-related endpoints now include a `depositInstruction` object with banking details for fiat wallets, distinct from crypto wallet addresses.
**Category**: Wallets
**Endpoints Changed**:
* `GET /vaults/{vaultId}/wallets`: The response now conditionally includes the `depositInstruction` object for fiat wallets.
* `POST /vaults/{vaultId}/wallets`: The response now conditionally includes the `depositInstruction` object for fiat wallets.
* `GET /wallets`: The response now conditionally includes the `depositInstruction` object for fiat wallets.
* `GET /wallets/{walletId}`: The response now conditionally includes the `depositInstruction` object for fiat wallets.
**Impact**: The `depositAddress` object remains for crypto wallets. The description for the `assets` array has also been clarified to state that it may be empty.
**Example**:
```json theme={null}
"depositInstruction": {
"bankName": "Example Bank",
"bankAddress": "123 Finance St, New York, NY",
"bankRoutingNumber": "123456789",
"bankSwiftCode": "EXMPUS33",
"beneficiaryName": "Anchorage Digital Bank, N.A.",
"beneficiaryAddress": "456 Custody Ave, Sioux Falls, SD",
"beneficiaryAccountNumber": "987654321",
"memoField": "For further credit to [Your Org Name]"
}
```
## Improved Collateral Management Package Updates and API Refinements
**Improved** the Collateral Management API for more comprehensive control and clarity, including support for partial updates to a package's entire configuration.
**Category**: Collateral Management
**Endpoints Changed**:
* `PATCH /collateral_management/packages/{packageId}`: You can now update nearly all configuration details of a package, including `clientReferenceId`, `collateralAssetsConfig`, `ltvRoundingPrecision`, `priceStrategy`, and settings for `critical`, `marginCall`, `marginReturn`, and `autoDeleveraging` levels; omitted fields remain unchanged.
* `PATCH /collateral_management/operations/{operationId}`: The `type` field no longer accepts the `LIQUIDATION` enum value, and the `typeId` description was improved for clarity.
* `POST /collateral_management/operations`: The `type` field no longer accepts the `LIQUIDATION` enum value, and the `typeId` description was improved for clarity.
* `GET /collateral_management/exposures`: Field descriptions were updated for accuracy and clarity.
* `POST /collateral_management/packages`: Field descriptions were updated for accuracy and clarity.
* `GET /collateral_management/packages`: Field descriptions were updated for accuracy and clarity.
**Impact**: These changes provide significantly more flexibility for programmatically managing collateral packages and improve the overall clarity and usability of the Collateral Management API.
## Added Collateral Management Operation Actions
**Added** new `action` types for creating and updating Collateral Management operations.
**Category**: Collateral Management
**Endpoints Changed**:
* `POST /collateral_management/operations`: The `action` field now supports `CLOSE_RETURN`, `REHYPE_IN`, and `REHYPE_OUT`.
* `PATCH /collateral_management/operations/{operationId}`: The `action` field now supports `CLOSE_RETURN`, `REHYPE_IN`, and `REHYPE_OUT`.
**Impact**: You can now create and update operations to manage the closing of returns and rehypothecation for collateral packages.
## Added Fields for Tax Transaction Tagging
**Added** new conditional fields for tagging tax transactions to support more detailed reporting.
**Category**: Tax
**Endpoint Changed**:
* `POST /tax/transaction/{transactionId}/tag`: The request body now supports `distributionCode` (required when `tag` is `distribution`), `totalDistribution` (required when `tag` is `distribution`), and `postponedLateReason` (required when `tag` is `postponed` or `late-rollover`).
**Impact**: When tagging transactions with `distribution`, `postponed`, or `late-rollover`, you must now provide these additional details for more accurate tax reporting.
**Example**:
```json theme={null}
{
"accountId": "SubaccountID",
"tag": "distribution",
"taxYear": "2024",
"distributionCode": "1",
"totalDistribution": true
}
```
## Improved Collateral Management API Clarity and Field Support
**Improved** several Collateral Management endpoints for clarity and functionality, with updated field descriptions and examples throughout.
**Category**: Collateral Management
**Endpoints Changed**:
* `POST /collateral_management/packages`: Removed the `defaultGroupId` parameter from the request body.
* `GET /collateral_management/packages`: Removed `acceleratedMarginCall` from the response, and added `CURE_PERIOD_EXPIRED` and `DEFAULTED` to the `state` enum.
* `POST /collateral_management/exposures`: Descriptions improved for clarity.
* `GET /collateral_management/exposures`: Descriptions improved for clarity.
* `POST /collateral_management/operations`: Removed several unsupported enum values from the `action` field to reflect currently available actions.
* `GET /collateral_management/operations`: Descriptions improved for clarity.
* `PATCH /collateral_management/operations/{operationId}`: Removed several unsupported enum values from the `action` field to reflect currently available actions.
**Impact**: Descriptions were improved across all listed endpoints for parameters such as `clientReferenceId`, `pledgorId`, `curePeriod`, `ltv`, and `topUpType`, giving clearer guidance when configuring collateral packages, exposures, and operations.
## Improved Price Strategy Options with BID and ASK
**Improved** Added `BID` and `ASK` as valid options for the `priceStrategy` field when creating collateral packages and exposures.
**Category**: Collateral Management
**Endpoints Changed**:
* `POST /collateral_management/packages`: The `priceStrategy` field now accepts `BID` and `ASK`.
* `POST /collateral_management/exposures`: The `priceStrategy` field now accepts `BID` and `ASK`.
**Impact**: This provides more granular control over pricing strategy, letting you specify whether the bid or ask price should be used when creating new collateral packages and exposures.
## Improved Filtering for List Orders Endpoint
**Improved** order filtering capabilities by adding a new `orderTypes` parameter.
**Category**: Trading
**Endpoint Changed**:
* `GET /trading/orders`: Accepts a new optional `orderTypes` query parameter, an array of strings to filter by order type (`LIMIT`, `MARKET`, `STOP_LOSS`, `STOP_LIMIT`, `TAKE_PROFIT_LIMIT`, `TWAP`, `VWAP`, `PEGGED`, `POV`, `OTHER`).
**Impact**: This allows for more granular querying of orders, letting you retrieve only the specific order types you're interested in.
**Example**: `GET /v2/trading/orders?orderTypes=LIMIT,STOP_LIMIT`
## Improved Customer Onboarding with Single-Call Submission
**Improved** the customer onboarding workflow by adding an optional `submit` parameter.
**Category**: Onboarding
**Endpoint Changed**:
* `POST /onboarding/customers`: Accepts a new optional boolean `submit` parameter.
**Impact**: This is a non-breaking change. When `submit` is `true`, the application is created and submitted in a single call, eliminating the need for a separate submission request and reducing the number of required API calls.
## Improved Price Source Options with KRAKEN
**Improved** Added `KRAKEN` as a supported price source for collateral management.
**Category**: Collateral Management
**Endpoints Changed**:
* `POST /collateral_management/packages`: The `priceSource` field now accepts `KRAKEN`.
* `POST /collateral_management/exposures`: The `priceSource` field now accepts `KRAKEN`.
**Impact**: This provides more flexibility by letting you select Kraken as the data source for asset pricing when configuring collateral.