> ## 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/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. ## Updated Response Structure for List Tags Endpoint * **Improved**: The response body for the `GET /tags` endpoint has been updated to nest the `tags` array within a `data` object for consistency with other API endpoints. * **Category**: Tagging * **Endpoint Changed**: `GET /tags` * **Impact**: This is a structural change. Integrations that consume this endpoint must be updated to access 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 Response Structure for Listing Tags * **Improved**: The response body for the `GET /tags` endpoint has been updated to nest the results within a `data` object for improved consistency with other API endpoints. * **Category**: Tagging * **Endpoint Changed**: `GET /tags` * **Impact**: This is a breaking change. You will need to update your integration to access the array of tags from `response.data.tags` instead of directly from `response.tags`. * **Example**: * **Old Response:** ```json theme={null} { "tags": [ { "name": "urgent", "tagType": "client" } ] } ``` * **New Response:** ```json theme={null} { "data": { "tags": [ { "name": "urgent", "tagType": "client" } ] } } ``` ## Standardized Response Structure for the List Tags Endpoint * **Improved** * **Description**: The response body for the `GET /tags` endpoint has been updated to a standardized format. The list of tags is now nested under a new `data` object. * **Category**: Tagging * **Endpoint Changed**: `GET /tags` * **Impact**: This is a structural change that requires clients to update their response parsing logic. The array of tags is no longer at the root level of the response. * **Example**: **Before**: ```json theme={null} { "tags": [ { "name": "urgent", "tagType": "client" } ] } ``` **After**: ```json theme={null} { "data": { "tags": [ { "name": "urgent", "tagType": "client" } ] } } ``` * **Additional Information**: This change aligns the `GET /tags` endpoint with the standard data object wrapper used across the API, improving consistency. ## Standardized Response for List Tags Endpoint * **Improved** * **Description**: The response for `GET /tags` has been updated to nest the tag list within a `data` object for standardization. * **Category**: Tagging * **Endpoint Changed**: `listTags` * **Method**: `GET` * **Path**: `/tags` * **Impact**: This is a breaking change. Integrations must be updated to parse the new response structure. The array of tags, previously at the root level, is now located inside the `data` object. * **Example**: * **Old Response Structure**: ```json theme={null} { "tags": [ { "name": "urgent", "tagType": "client" } ] } ``` * **New Response Structure**: ```json theme={null} { "data": { "tags": [ { "name": "urgent", "tagType": "client" } ] } } ``` ## Updated Response Structure for List Tags Endpoint * **Improved**: The response structure for the `GET /tags` endpoint has been updated to improve consistency across the API. * **Category**: Tagging * **Endpoints Changed**: * `GET /tags` * **Impact**: This is a breaking change. The `tags` array is no longer at the root level of the response. Integrations parsing this endpoint must be updated to access the list of tags from the new `data.tags` path. * **Example**: * **Old Response:** ```json theme={null} { "tags": [ { "name": "urgent", "tagType": "client" } ] } ``` * **New Response:** ```json theme={null} { "data": { "tags": [ { "name": "urgent", "tagType": "client" } ] } } ``` ## Standardized Response Structure for the List Tags Endpoint * **Improved** * **Description**: The response body for the `GET /tags` endpoint has been updated. The array of tags, previously at the top level of the response, is now nested within a `data` object. * **Category**: Tagging * **Endpoint Changed**: `GET /tags` * **Impact**: This is a breaking change. You will need to update your integration to access the list of tags from `response.data.tags` instead of the previous `response.tags`. * **Example**: *Before:* ```json theme={null} { "tags": [ { "name": "urgent", "tagType": "client" } ] } ``` *After:* ```json theme={null} { "data": { "tags": [ { "name": "urgent", "tagType": "client" } ] } } ``` * **Additional Information**: This change aligns the response structure with our other paginated endpoints for better consistency across the API. ## Standardized Response for List Tags Endpoint * **Improved**: The response structure for the `GET /tags` endpoint has been updated to standardize its structure. The list of tags is now nested within a `data` object. * **Category**: Tagging * **Endpoint Changed**: `GET /tags` * **Impact**: This is a **breaking change**. Integrations will need to be updated to access the array of tags from the `data.tags` field instead of the top-level `tags` field. * **Example**: * **Before**: ```json theme={null} { "tags": [ { "name": "urgent", "tagType": "client" } ] } ``` * **After**: ```json theme={null} { "data": { "tags": [ { "name": "urgent", "tagType": "client" } ] } } ``` * **Additional Information**: This change aligns the response format with other list endpoints across the API for better consistency. ## Updated Response Structure for List Tags Endpoint * **Improved** * The response body for the `GET /tags` endpoint has been restructured for consistency. The `tags` array is now nested within a `data` object. * **Category**: Tagging * **Endpoint Changed**: `GET /tags` * **Impact**: This is a breaking change. Integrations that parse the response from this endpoint must be updated to access the list of tags from the `data.tags` field instead of the previous top-level `tags` field. * **Example**: * **Previous Response:** ```json theme={null} { "tags": [ { "name": "urgent", "tagType": "client" } ] } ``` * **New Response:** ```json theme={null} { "data": { "tags": [ { "name": "urgent", "tagType": "client" } ] } } ``` ## Updated Response Structure for List Tags Endpoint * **Improved** * **Description**: The response structure for the `GET /tags` endpoint has been updated. The list of tags is now nested within a `data` object to align with the standard API response format. * **Category**: Tagging * **Endpoint**: `GET /tags` * **Impact**: This is a structural change. Client integrations must be updated to access the list of tags from the `data.tags` field instead of the previous top-level `tags` field. * **Example**: *Previous Response Structure:* ```json theme={null} { "tags": [ { "name": "urgent", "tagType": "client" } ] } ``` *New Response Structure:* ```json theme={null} { "data": { "tags": [ { "name": "urgent", "tagType": "client" } ] } } ``` ## Renamed Field for Creating Wallets on Compatible Networks * **Improved**: The `createOnAllCompatibleNetworks` field has been renamed to `activateAllCompatibleNetworks`. * **Category**: Wallets * **Endpoint Changed**: * `POST /vaults/{vaultId}/wallets` * **Request Body**: The `createOnAllCompatibleNetworks` boolean property was removed and replaced by `activateAllCompatibleNetworks`. * **Impact**: This is a breaking change. Integrations using the `createOnAllCompatibleNetworks` field must be updated to use the new `activateAllCompatibleNetworks` field to avoid request failures. * **Additional Information**: The functionality of the field remains the same: 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. ## Streamlined 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` * `POST /wallets/{walletId}/activate` * **Request Body**: * The `POST /vaults/{vaultId}/wallets` endpoint now includes a new optional boolean parameter, `createOnAllCompatibleNetworks`. * The `POST /wallets/{walletId}/activate` endpoint now includes a new optional boolean parameter, `activateAllCompatibleNetworks`. * **Impact**: These changes provide a more efficient way to manage wallets across multiple networks. Instead of listing every compatible network ID, you can now use a single boolean flag to create or activate a wallet on all available compatible networks for your organization. * **Additional Information**: The new `...AllCompatibleNetworks` parameters are mutually exclusive with the existing `compatibleNetworkIds` parameter. You must provide exactly one of these parameters in your request. ## Added New Endpoints for Tag Management * **Added a new "Tags" API to create, list, and manage tags for entities.** * **Type**: Added * **Category**: Tags * **Endpoints Added**: * `GET /tags` to list tags. * `POST /tags` to create a tag. * `POST /tags/apply` to apply tags to an entity. * `DELETE /tags/apply/{entityId}/{tagName}` to remove a tag from an entity. * `GET /tags/search` to search for entities by tag. * **Impact**: This introduces a new feature for users to programmatically organize, categorize, and search for their resources using tags. ## Enhanced Asset Type Information with Compatible Networks * **Improved**: The `GET /asset-types` endpoint response now includes a list of compatible network IDs. * **Category**: Asset Types * **Endpoint Changed**: `GET /asset-types` * **Impact**: The `AssetTypeDetails` object in the response now contains `compatibleNetworkIds`, an array of network IDs that share wallet key derivation with the asset's primary network. 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 Specific Lot ID for Tax Reporting in 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` * `POST /trading/async-order/cancel` * **Changes**: * **Added**: A new optional `specLotId` field has been introduced in the request body for the `POST /trading/async-order` endpoint. This allows you to specify a tax lot to retire for `SELL` orders with a `timeInForce` of `FOK`. * **Improved**: The `rejectReason` field in the responses for both `POST /trading/async-order` and `POST /trading/async-order/cancel` now includes two new enum values to provide more specific error feedback: `InvalidSideForSpecLotID` and `InvalidTimeInForceForSpecLotID`. * **Impact**: You can now programmatically manage tax lot retirement for specific `SELL` orders, enhancing tax reporting capabilities. ## Enhanced Collateral Package Endpoint with Value and Price Details * **Improved** * **Description**: The response for the `GET /collateral_management/packages` endpoint has been enhanced to include additional value and pricing details for each collateral package and its underlying assets. * **Category**: Collateral Management * **Endpoint Changed**: * `GET /collateral_management/packages` * **Impact**: This is a non-breaking change. The `200 OK` response now includes the following new optional fields: * `exposureValue` and `packageValue` at the top level of each package object. * `price`, `quantity`, and `weightedValue` for each asset within the `collateralAssets` array. These additions provide a more comprehensive 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 New Endpoint to Request Collateral Decrease * **Added** a new endpoint that allows users to request a collateral decrease for a specified collateral package. This initiates a two-way Atlas settlement to return assets from the secured party's collateral wallets to the pledgor's return wallets. * **Category**: Collateral Management * **Endpoint Changed**: `POST /collateral_management/packages/{packageId}/collateral-decrease` * **Impact**: This new functionality enables either the pledgor or the secured party to programmatically initiate the return of collateral assets. The successful API call creates an Atlas settlement, and the `settlementId` is returned in the response for tracking. * **Example Request Body**: ```json theme={null} { "assetAmounts": [ { "assetTypeID": "BTC", "value": "1.1" }, { "assetTypeID": "ETH", "value": "20.62" } ], "idempotencyKey": "decrease-2024-01-15-pkg-abc", "useGasStation": false } ``` ## Added Wallet Activation on Additional Networks * **Added** * Added a new endpoint to activate an existing wallet on additional compatible networks. * **Category**: Wallets * **Endpoint Changed**: `POST /wallets/{walletId}/activate` * **Impact**: This allows users to 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` * `GET /transactions/{transactionId}` * **Impact**: When fetching a list of transactions or a single transaction, the response will now contain a `fiatDetails` object for any fiat-related transactions. 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**: `GET /subaccounts/customers/accounts` * **Description**: This endpoint allows users to list all subaccounts for their organization, with options for filtering and pagination. * **Parameters**: * `subaccountIds` (query): Filter results by a list of subaccount IDs. * `externalIds` (query): Filter results by a list of IDs from an external system. * `endDate` (query): Filter for subaccounts created up to and including the specified date. * `statuses` (query): Filter subaccounts by their status. * `afterId` (query): Paginate to the next page of results. * `limit` (query): Specify the maximum number of results to return. * **Impact**: This new endpoint provides a comprehensive, organization-level view of all subaccounts, enabling more efficient and complete data retrieval compared to fetching subaccounts on a per-customer basis. ## Enhanced Transfers and Withdrawals with Trusted Destinations * **Improved**: Added the ability to use `TRUSTED_DESTINATION` as a destination type for transfers and withdrawals, streamlining the process for sending assets to pre-approved addresses. * **Category**: Transfers, Transactions, Wallets * **Endpoints Changed**: * `POST /transactions/withdrawal` * `POST /transfers` * `GET /transfers` * `GET /transfers/{transferId}` * `GET /vaults/{vaultId}/wallets` * `POST /vaults/{vaultId}/wallets` * `GET /wallets` * `GET /wallets/{walletId}` * **Request Body**: * The `destination.type` field in the request body for `POST /transfers` and `POST /transactions/withdrawal` now accepts `TRUSTED_DESTINATION` as a valid enum value. * Descriptions for asset-specific parameters (e.g., `assetParametersXRP`, `assetParametersCosmos`) have been updated to clarify that they should not be provided when sending to a `TRUSTED_DESTINATION`, as the relevant information (like memo or destination tag) is inherited from the trusted destination's configuration. * **Responses**: * The `destination.type` field in responses for `GET /transfers` and `GET /transfers/{transferId}` can now return `TRUSTED_DESTINATION`. * The `type` field in wallet-related responses (`GET /wallets`, `GET /vaults/{vaultId}/wallets`, etc.) can now also include `TRUSTED_DESTINATION`. * **Impact**: This change simplifies withdrawal and transfer workflows. Users can now send funds to a pre-configured Trusted Destination by simply providing its ID, without needing to re-specify address details, memos, or destination tags in each API call. * **Example**: To withdraw funds to a trusted destination, you can now structure your request body as follows: ```json theme={null} { "assetType": "XRP", "amount": "100.00", "source": { "id": "1c920f4241b78a1d483a29f3c24b6c4c", "type": "WALLET" }, "destination": { "id": "your_trusted_destination_id", "type": "TRUSTED_DESTINATION" } } ``` * **Additional Information**: Using Trusted Destinations reduces the risk of sending funds to an incorrect address and streamlines recurring transactions. ## Enhanced Transfers and Withdrawals with Trusted Destination Support * **Improved** * You can now send funds to pre-approved Trusted Destinations when creating transfers and withdrawals. This simplifies the process by allowing you to use a `TRUSTED_DESTINATION` as the `destination.type` in your request. When a Trusted Destination is used, asset-specific parameters like memos or destination tags are automatically inherited from its configuration and should no longer be provided in the API call. * **Category**: Transfers & Transactions * **Endpoints Changed**: * `POST /transfers` * `POST /transactions/withdrawal` * `GET /transfers` * `GET /transfers/{transferId}` * **Impact**: * The `destination.type` field in the request body for creating transfers and withdrawals now accepts `TRUSTED_DESTINATION` as a value. * When sending to a `TRUSTED_DESTINATION`, you no longer need to include asset-specific parameter objects (e.g., `assetParametersXRP`, `assetParametersXLM`, `assetParametersCosmos`). * Responses for `GET /transfers` and `GET /transfers/{transferId}` will now also reflect when a `TRUSTED_DESTINATION` was used as the destination. * **Example**: To create a withdrawal to a Trusted Destination, set the `destination` object in the request body like this: ```json theme={null} { "assetType": "XRP", "amount": "100", "source": { "id": "your-source-wallet-id", "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**: Users 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` * **Impact**: This allows users to programmatically activate an existing wallet on additional networks that share the same key family. This streamlines asset management across multiple networks by reusing a single wallet, rather than creating a new one for each network. ## Added Endpoint to Activate Wallets on Additional Networks * **Added a new endpoint to activate an existing wallet on additional compatible networks.** * **Category**: Wallets * **Endpoint Changed**: `POST /wallets/{walletId}/activate` * **Impact**: This new endpoint allows users to make an existing wallet functional on other compatible networks after its initial creation. This provides more flexibility than only being able to specify compatible networks at the time of wallet creation. ## Added Endpoint for Collateral Decrease Requests * **Added** a new endpoint to allow users to request a collateral decrease. * **Category**: Collateral Management * **Endpoint**: `POST /collateral_management/packages/{packageId}/collateral-decrease` * **Description**: This new endpoint enables programmatic requests to decrease collateral for a specified package. ## Added Support for Compatible Networks on Wallet Creation * **Added** an optional `compatibleNetworkIds` field to the `POST /vaults/{vaultId}/wallets` endpoint. This allows for activating a new wallet on additional compatible networks at the time of creation. * **Category**: Wallets * **Endpoint Changed**: `POST /vaults/{vaultId}/wallets` * **Request Body**: A new optional field `compatibleNetworkIds` (an array of strings) has been added. * **Impact**: This change allows you to create a wallet and simultaneously activate it on multiple compatible networks in a single API call, streamlining the setup process. * **Additional Information**: All specified networks must share the same key family as the primary `networkId`. The activation on these compatible networks occurs synchronously after the initial wallet creation. * **Example Request Body**: ```json theme={null} { "networkId": "ETH", "walletName": "My EVM Wallet", "compatibleNetworkIds": [ "POLYGON", "AVAX" ] } ``` ## Clarified 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` * `POST /transfers` * `GET /trusted_destinations` * **Impact**: * For withdrawal and transfer requests (`POST /transactions/withdrawal`, `POST /transfers`), the `memo` field within `assetParametersFiatTrustedDestination` is now optional. If it's not provided in the request, the default memo from the saved Trusted Destination will be used. * The response for `GET /trusted_destinations` now specifies that the `memo` for a fiat destination has a maximum length of 140 characters. * **Additional Information**: This enhancement simplifies API calls by allowing you to rely on the pre-configured memo on a Trusted Destination, reducing the need to specify it in every withdrawal or transfer request. ## Updated Stablecoin History Response Field * **Improved** * **Description**: In the response for `GET /stablecoins/history`, the `issueRedeemId` field has been renamed to `id`. * **Category**: Stablecoins * **Endpoint Changed**: `GET /stablecoins/history` * **Impact**: This is a breaking change. Integrations that parse the `issueRedeemId` field must be updated to use the new `id` field to get the unique identifier for an issue/redeem operation. * **Example**: *Before:* ```json theme={null} { "data": [ { "issueRedeemId": "b1a1c1...", "operationType": "ISSUE", ... } ] } ``` *After:* ```json theme={null} { "data": [ { "id": "b1a1c1...", "operationType": "ISSUE", ... } ] } ``` ## Standardized and Enhanced Stablecoin History Endpoint Response * **Improved** The response for the Stablecoin History endpoint has been updated to align with our standard paginated format and now includes more detailed status information. * **Category**: Stablecoins * **Endpoint Changed**: `GET /stablecoins/history` * **Impact**: This is a breaking change. The response body has been restructured. The `conversions` array is now nested under a `data` field, and pagination is handled by a `page` object with a `next` URL, replacing the previous `hasNextPage` boolean. * **Changes**: * The response now returns a `data` array containing the list of conversions and a `page` object for pagination. * Added `destinationOperationId` and `sourceOperationId` to link to the corresponding transaction details. * Added a `status` field with possible values: `INITIATED`, `EXECUTING`, `COMPLETED`, `FAILED`, `UNKNOWN`. * Added an optional `subStatus` field to provide more context on the `status`, such as `REJECTED_BY_CUSTOMER`. * The `operationType` enum is expanded to include `BRIDGE` and `SWAP`. * **Example (New Response Structure)**: ```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?..." } } ``` * **Additional Information**: Integrations using this endpoint must be updated to parse the new response structure. ## Added LIMIT\_ALL\_IN Order Type to Trading Endpoints * **Improved** * **Description**: 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` * `GET /trading/orders/{orderId}` * **Impact**: Responses from the "List orders" and "Get order by ID" endpoints may now include `LIMIT_ALL_IN` as an `orderType`. Ensure your client can handle this new value. ## Enhanced Statements with Correction Timestamps and Filtering * **Improved** * Added filtering and timestamp information for corrected statements. This allows for better tracking and querying of statements that have been updated after their initial generation. * **Category**: Statements * **Endpoints Changed**: * `GET /statements` * `GET /statements/{statementId}` * **Parameters**: * For `GET /statements`, two new optional query parameters have been added: * `correctedAfter`: Filters for statements corrected at or after this time. * `correctedBefore`: Filters for statements corrected at or before this time. * **Impact**: Users can now programmatically identify and filter for statements that have been corrected, improving audit and reconciliation workflows. The `correctedAt` field in the response indicates precisely when a correction was made. * **Example**: A response for a corrected statement will now include the `correctedAt` field. ```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` * **Parameter**: A new query parameter, `subaccountIds`, has been added. * **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` ## Updated Permissions for Stablecoin History Endpoint * **Improved** permission requirements for the Stablecoin History endpoint. * **Category**: Stablecoins * **Endpoint Changed**: `GET /stablecoins/history` * **Impact**: The primary permission required for this endpoint has been updated from `Read vault activity` to the more specific `Read Stablecoin Conversions`. For backward compatibility, the endpoint will continue to accept the `Read vault activity` permission, 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**: `GET /stablecoins/history` * **Description**: This new endpoint allows users to get a historical list of their stablecoin issuance and redemption operations. * **Impact**: Clients can now programmatically access their 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` * `POST /collateral_management/packages` * `PATCH /collateral_management/packages/{packageId}` * `POST /collateral_management/exposures` * **Impact**: The `priceSource` field in various Collateral Management endpoints now accepts `BINANCE` as a valid enum value. This allows for more flexible pricing options when creating and managing collateral packages and exposures. The `GET /collateral_management/price_sources` endpoint now also returns `BINANCE` as an available source and can be used as a filter in the `exchange` query parameter. * **Example**: When creating or updating a collateral package, you can now specify Binance as the price source for an asset: ```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 has been introduced for collateral packages. This allows for setting up an additional margin call threshold with a specific LTV, cure period, and action. * **Category**: Collateral Management * **Endpoints Changed**: * `POST /collateral_management/packages` * `PATCH /collateral_management/packages/{packageId}` * `GET /collateral_management/packages` * **Impact**: Users can now define and monitor an additional, accelerated margin call level for their collateral packages, providing more granular risk management. * **Details**: * The `acceleratedMarginCall` object has been added to the request body for creating (`POST`) and updating (`PATCH`) collateral packages. * The `acceleratedMarginCall` object is now included in the response body when retrieving (`GET`) collateral package details. ## Updated Transfer and Withdrawal Destination Handling * **Removed `TRUSTED_DESTINATION` as a resource type and updated asset parameter descriptions** * **Type**: Removed * **Description**: The enum value `TRUSTED_DESTINATION` has been removed from the `destination.type` field for transfer and withdrawal requests. This value has also been removed from the `type` field in responses for several Wallet and Transfer endpoints. Additionally, descriptions for various asset-specific parameters have been updated to clarify their usage and deprecate `assetParametersATOM`. * **Category**: Transfers, Transactions, and Wallets * **Endpoints Changed**: * `POST /transactions/withdrawal` * `POST /transfers` * `GET /transfers` * `GET /transfers/{transferId}` * `GET /vaults/{vaultId}/wallets` * `POST /vaults/{vaultId}/wallets` * `GET /wallets` * `GET /wallets/{walletId}` * **Request Body**: * In `POST /transactions/withdrawal` and `POST /transfers`: * The `destination.type` field no longer accepts `TRUSTED_DESTINATION`. * The `assetParametersATOM` field is now deprecated in favor of `assetParametersCosmos`. * Descriptions for `assetParametersCosmos`, `assetParametersXLM`, `assetParametersXRP`, and `assetParametersExtra` have been updated to clarify that they are not needed when using a trusted destination. * **Impact**: This is a breaking change. API requests that specify `destination.type` as `TRUSTED_DESTINATION` will now fail. To send funds to a trusted destination, you must now use `destination.type: 'ADDRESS'` and provide the specific blockchain address associated with that trusted destination. Clients should also update any logic that parses the `type` field in Wallet and Transfer-related responses. * **Additional Information**: Users are encouraged to migrate from using the deprecated `assetParametersATOM` to the more general `assetParametersCosmos` for Cosmos-based assets. ## Improved Documentation for Order Filtering * **Improved** the description for the `orderTypes` query parameter to enhance clarity. * **Category**: Trading * **Endpoint**: `GET /trading/orders` * **Parameters**: 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.** * **Type**: Improved * **Category**: Statements * **Endpoints Changed**: * `GET /statements` * `GET /statements/{statementId}` * **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. * **Changes**: * The `GET /statements` endpoint has new query parameters for filtering: * **Removed**: `statementIds`, `statementTypes`, `accountIds`, `affiliateIds`, `vaultGroupIds`, `subaccountIds`. * **Added**: `ids`, `typeIds`, `customerIds`. * The response bodies for both `GET /statements` and `GET /statements/{statementId}` have been updated: * **Removed Fields**: `accountId`, `affiliateId`, `subaccountId`, `vaultGroupId`, and the required `type` field. * **Added Fields**: `customerId` and the new required field `typeId`. The `type` field is now optional. ## Added MANUAL Order Type to Trading Endpoints * **Improved**: Added support for a new `MANUAL` order type. * **Category**: Trading * **Endpoints Changed**: * `GET /trading/orders` * `GET /trading/orders/{orderId}` * **Impact**: The `orderType` field in the responses for listing and retrieving orders can now include the value `MANUAL`. Clients should update their integrations to handle this new enum value. ## Refactored Fiat Trusted Destination Response Structure * **Improved** * **Description**: The structure of the `fiat` object in the response for listing trusted destinations has been refactored for clarity. Beneficiary and financial institution details are now grouped into nested `beneficiary` and `beneficiaryBank` objects. Additionally, new `intermediaryBank` and `usage` fields have been added. * **Category**: Trusted Destinations * **Endpoint Changed**: `GET /trusted_destinations` * **Impact**: This is a **breaking change**. Integrations that previously parsed the flat properties within the `fiat` object must be updated to handle the new nested structure. * **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" } } ``` * **Additional Information**: * The new `usage` field indicates if the recipient account is owned by your organization or a third party. * All previous properties like `beneficiaryName`, `institutionName`, etc., are now nested within the `beneficiary` and `beneficiaryBank` objects. ## Added Fiat Support for Trusted Destinations * **Added support for fiat (bank account) trusted destinations** * **Category**: Trusted Destinations * **Endpoint Changed**: `GET /trusted_destinations` * **Description**: The `GET /trusted_destinations` endpoint response has been updated to include details for fiat-based trusted destinations. * **Impact**: When listing trusted destinations, the response for a fiat destination will now have a `type` of `fiat` and contain 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 } ] } ``` ## Enhanced Order Allocation Details with Filled Quantity * **Improved** * **Description**: 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` * `GET /trading/orders` * `GET /trading/orders/{orderId}` * `POST /trading/async-order` * `POST /trading/async-order/cancel` * **Impact**: This is a non-breaking change that provides more granular data on order fills at the subaccount level. The `cumQty` field is now a required property within the `allocation` object in the responses for the affected endpoints. * **Example**: The `allocation` object in the response will now include `cumQty`: ```json theme={null} "allocation": [ { "subaccountId": "905272f0-52f9-404e-b6cd-ad879e671790", "quantity": "10000", "cumQty": "10000", "counterQtyAllIn": "10000", "counterQtyAllInToSettle": "10000", "fee": "10000" } ] ``` ## Updated Collateral Management Price Sources Endpoint * **Improved**: * Added a new `501 Not Implemented` response to the `getCMPriceSources` endpoint. * Clarified the description for the `exchange` query parameter. * **Category**: Collateral Management * **Endpoint Changed**: `GET /collateral_management/price_sources` * **Impact**: API consumers will now receive a `501 Not Implemented` error if the price sources feature is disabled. The `exchange` parameter description has been simplified. ## Improved Clarity for Tax Reporting Deposit Transaction Endpoints * **Improved** * **Description**: We've updated our Tax Reporting API to clarify that the endpoints for managing transaction cost basis are specific to deposit transactions. The descriptions for the endpoints and the `hasCostBasis` parameter have been improved for better accuracy. * **Category**: Tax Reporting * **Endpoints Changed**: * `PATCH /tax/accounts/{accountId}/transactions/{transactionId}` * `GET /tax/accounts/{accountId}/transactions` * **Impact**: This is a documentation-only change to improve clarity. The functionality of the endpoints remains unchanged. ## Enhanced Async Order Responses with Counter Currency Details * **Improved** * **Description**: Added `counterCurrency`, `counterQty`, and `counterQtyAllIn` fields to the responses for placing and canceling async orders. This provides more detailed information about the counter currency involved in the transaction. * **Category**: Trading * **Endpoints Changed**: * `POST /trading/async-order` * `POST /trading/async-order/cancel` * **Impact**: The responses for placing and canceling an async order will 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` * **Impact**: This allows clients to programmatically retrieve a list of supported price sources and the specific assets available for each source, which can be used to validate configurations for collateral packages. ## Updated Price Strategy Options for Collateral Management * **Improved**: The `priceStrategy` options have been updated for creating and managing collateral packages and exposures. The `MID` and `LAST` options have been added, and `VWAP` has been removed. * **Category**: Collateral Management * **Endpoints Changed**: * `POST /collateral_management/packages` * `PATCH /collateral_management/packages/{packageId}` * `POST /collateral_management/exposures` * **Request Body**: The `priceStrategy` field within the request body for these endpoints now accepts `MID` and `LAST` as enum values. The `VWAP` value is no longer supported. * **Impact**: Integrations that use the `priceStrategy` field must be updated to use the new `MID` or `LAST` values instead of `VWAP`. ## 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` * `POST /transfers` * **Request Body**: The request bodies for both endpoints now include the optional `assetParametersFiatTrustedDestination` object. This object contains two new fields: * `memo`: A note to the beneficiary. * `purpose`: The purpose of the transaction (e.g., `TRADING_SETTLEMENT`, `INVESTMENT`). * **Impact**: This change allows you to provide additional context and details when sending fiat assets to a Trusted Destination. This is particularly useful for record-keeping and compliance. * **Example**: When making a fiat withdrawal to a Trusted Destination, you can now include the purpose of the transaction. ```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" } ``` ## Enhanced Offchain Vesting Schedule Information * **Improved the response for listing offchain vesting schedules** * **Category**: Vesting * **Endpoint Changed**: * `GET /offchainvesting/schedules` * **Description**: The response for `GET /offchainvesting/schedules` has been updated to include the `assetType` field in each schedule object within the `data` array. This new field specifies the asset abbreviation (e.g., BTC, ETH) for the vesting schedule. * **Impact**: This is a non-breaking, additive change. It allows for easier identification of 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. This simplifies the process by allowing you to send funds to a `TRUSTED_DESTINATION` ID instead of a full address, automatically inheriting necessary details like memos or destination tags. * **Category**: Transfers & Withdrawals * **Endpoints Changed**: * `POST /transfers` * `POST /transactions/withdrawal` * `GET /transfers` * `GET /transfers/{transferId}` * **Request Body**: * For `POST /transfers` and `POST /transactions/withdrawal`, the `destination.type` field now accepts `TRUSTED_DESTINATION`. * **Impact**: When initiating a transfer or withdrawal to a `TRUSTED_DESTINATION`, you no longer need to include asset-specific parameters like `assetParametersXRP` or `assetParametersXLM`. The required destination tag or memo is automatically inherited 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" } ``` * **Additional Information**: The responses for `GET /transfers` and `GET /transfers/{transferId}` will also now reflect `TRUSTED_DESTINATION` as a possible destination type. ## Enhanced Market Data Endpoint with Amount-Based Depth * **Improved** * **Description**: The `GET /trading/marketdata` endpoint has been enhanced to support returning market depth by notional value (e.g., in terms of the quote currency like USD) in addition to asset size. * **Category**: Trading * **Endpoint**: `GET /trading/marketdata` * **Impact**: A new `amount` field has been added to the `bids` and `offers` objects in the response. This field is returned when using the `amountBuckets` query parameter and represents the notional value available at a given price level. The existing `size` field is now returned when using the `sizeBuckets` parameter. This is a non-breaking change. * **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 `POST /atlas/directory/counterparties` has been introduced to allow for the proposal of a new trusted counterparty. * **Category**: Atlas Settlement Network * **Endpoint**: `POST /atlas/directory/counterparties` * **Impact**: Users can now programmatically propose new trusted counterparties, streamlining the process of adding new settlement partners. ## Improved Market Data Parameter Descriptions * **Improved** * **Description**: The descriptions for the `sizeBuckets` and `amountBuckets` query parameters have been updated to provide more clarity on their usage and impact on the response. * **Category**: Trading * **Endpoint Changed**: `GET /trading/marketdata` * **Parameters Changed**: * `sizeBuckets`: Clarified that the value is a comma-separated list. * `amountBuckets`: Clarified that the value is a comma-separated list representing USD values and added a note that using this parameter affects how the `size` field is represented in the response. * **Impact**: This is a non-breaking documentation change that provides better guidance for users querying market depth. ## Improved Cost Basis Reporting with Tax Lots * **Improved** * Updated the Tax Reporting endpoints to support lot-level cost basis management, providing more granular and accurate tax data. * **Category**: Tax Reporting * **Endpoints Changed**: * `PATCH /tax/accounts/{accountId}/transactions/{transactionId}` * `GET /tax/accounts/{accountId}/transactions` * **Changes**: * **`PATCH /tax/accounts/{accountId}/transactions/{transactionId}`**: * **Request Body**: The request body for updating a transaction's cost basis has been updated to support multiple tax lots. * Replaced the `data`, `acquisitionDatetime`, and `assetType` fields with a new required `lots` array. Each object in the `lots` array represents a tax lot and must include `lotId`, `quantity`, and `costBasis`. * **`GET /tax/accounts/{accountId}/transactions`**: * **Response Body**: The response for listing transactions has been enhanced to include more detailed lot information. * Added a required top-level `assetType` field to each transaction object. * Added an `acquisitionDatetime` field to each lot object within the `receivedAssets` array. * **Impact**: These changes transition our cost basis reporting from a per-transaction model to a more detailed per-lot model. Users can now specify and retrieve cost basis information for individual lots within a single transaction, enabling more precise tax reporting. ## Added Market Data Endpoint * **Added** a new endpoint to retrieve a snapshot of market data. * **Category**: Trading * **Endpoint**: `GET /trading/marketdata` * **Description**: This new endpoint allows users to get a snapshot of current market data. * **Impact**: Users can now programmatically access market data for pricing, analysis, and other trading-related activities. See [Market Data Guide](https://developers.anchorage.com/docs/websocket-api-market-data) for more information. ## Added FIAT\_INTEREST Transaction Type and Improved Settlement Documentation * **Improved**: Added the `FIAT_INTEREST` transaction type and clarified the `applyPostLock` parameter description. * A new `FIAT_INTEREST` value has been added to the `transactionType` enum to represent fiat interest payments. * **Category**: Transactions * **Endpoints Changed**: * `GET /transactions` * `GET /transactions/{transactionId}` * **Impact**: The `transactionType` field in the response for these endpoints can now include `FIAT_INTEREST`. Clients should update their systems to handle this new transaction type. * The description for the `applyPostLock` parameter has been updated for clarity. * **Category**: Atlas Settlement Network * **Endpoint Changed**: `POST /atlas/settlements` * **Request Body**: The description for the `applyPostLock` parameter now specifies that it is a conditional field applicable only to clients using Atlas settlements integrated with Anchorage Vesting. ## Deprecated `totalDistribution` Field in Tax Tagging * **Deprecated** the `totalDistribution` field for tagging tax transactions. * **Category**: Tax * **Endpoint Changed**: `POST /tax/transaction/{transactionId}/tag` * **Request Body**: The `totalDistribution` field is now deprecated and will be ignored if provided. * **Impact**: Any value passed in the `totalDistribution` field will be disregarded. The total distribution status is now automatically calculated from account balances. * **Additional Information**: Users should remove the `totalDistribution` field from their requests as 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` * **Request Body**: * A new optional boolean parameter `applyPostLock` has been added. When set to `true`, indefinite holds will be placed on the acceptor's destination wallets after a successful settlement. * **Impact**: This feature enables the automatic creation of post-settlement vesting schedules on received funds, streamlining workflows that require funds to be locked after settlement. ## New Vesting Schedules Endpoint and Tax Transaction Filtering * **Added a new endpoint for listing offchain vesting schedules and a new filter for tax transactions.** * **Added**: * **Description**: A new endpoint, `GET /offchainvesting/schedules`, has been introduced to allow users to list all offchain vesting schedules for their organization. * **Category**: Vesting * **Endpoint Changed**: `GET /offchainvesting/schedules` * **Impact**: This provides programmatic access to view vesting schedules, enhancing transparency and management of vested assets. * **Added**: * **Description**: The `GET /tax/accounts/{accountId}/transactions` endpoint now includes a new `hasCostBasis` query parameter. * **Category**: Tax Reporting * **Endpoint Changed**: `GET /tax/accounts/{accountId}/transactions` * **Parameters**: Added `hasCostBasis` in `query`. * **Impact**: Users can now filter transactions to easily identify which ones have or are missing a cost basis. Set to `true` to list only transactions with a cost basis, `false` for those without, or omit the parameter to list all transactions. ## Added Priority Fee Reward Transaction Type * **Improved**: The `transactionType` field in transaction-related endpoints now includes `PRIORITY_FEE_REWARD` to represent priority fee rewards. * **Category**: Transactions * **Endpoints Changed**: * `GET /transactions` * `GET /transactions/{transactionId}` * **Impact**: When listing or retrieving individual transactions, you may now see `PRIORITY_FEE_REWARD` in the `transactionType` field of the response. 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` * **Request Body**: The description for the `assetType` field within the `trustedDestinations` array now clarifies what an asset type is and directs users to the `/v2/asset-types` endpoint to find a list of supported types. * **Impact**: This is a non-breaking documentation change. The endpoint's functionality remains the same. ## Added Signature Requirements for Collateral Management Write Operations * **Improved**: To enhance security, `Api-Signature` and `Api-Timestamp` headers are now required for write operations on Collateral Management endpoints. * **Category**: Collateral Management * **Endpoints Changed**: * `PATCH /collateral_management/operations/{operationId}` * `PATCH /collateral_management/packages/{packageId}` * `POST /collateral_management/exposures` * `POST /collateral_management/operations` * `POST /collateral_management/packages` * **Parameters Added**: The `Api-Signature` and `Api-Timestamp` headers have been added as required parameters for the listed endpoints. * **Impact**: This is a breaking change. Requests to these endpoints will now fail if they do not include valid signature and timestamp headers. * **Additional Information**: For instructions on how to generate a valid request signature, please see the [Request Signatures](#section/Authentication-and-Security/Request-Signatures) section of our documentation. ## Added Unvested and Unstakeable Balances to Wallet Responses * **Improved**: Wallet-related endpoints now include more detailed balance information for offchain vesting. * **Category**: Wallets * **Endpoints Changed**: * `GET /vaults/{vaultId}/wallets` * `POST /vaults/{vaultId}/wallets` * `GET /wallets` * `GET /wallets/{walletId}` * **Response Body Changes**: The `assets` object within the response bodies for these endpoints now includes two new `Amount` object fields: `unvestedBalance` and `unvestedUnstakeableBalance`. * **Impact**: This is a non-breaking change. API responses will now contain additional balance details for assets in offchain vesting contracts, where applicable. ## New Vesting Endpoint * **Added** * **Description**: A new endpoint has been added to retrieve vesting balances for multiple allocations in a single request. * **Category**: Vesting * **Endpoint Changed**: `POST /vesting/balances` * **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. ## Added Request Signing to Atlas Settlement Endpoints * **Improved**: Added request signing to enhance security for key Atlas Settlement Network endpoints. These endpoints now require an `Api-Signature` and `Api-Timestamp` header for all requests. * **Category**: Atlas Settlement Network * **Endpoints Changed**: * `POST /atlas/settlements` * `POST /atlas/settlements/{settlementId}/accept` * `POST /atlas/settlements/{settlementId}/authorize` * `POST /atlas/settlements/{settlementId}/reject` * **Parameters added**: `Api-Signature`, `Api-Timestamp` (header). * **Impact**: This is a breaking change. Requests made to the listed endpoints will now fail if they do not include the required signature headers. * **Additional Information**: Please refer to the [Request Signatures](#section/Authentication-and-Security/Request-Signatures) section in the documentation for detailed instructions on generating the required signatures. ## Improved Stablecoin Conversion Documentation * **Improved**: Updated the description for the `sourceAssetType` field in the stablecoin conversion request body to provide more clarity. * **Category**: Stablecoins * **Endpoint Changed**: `POST /stablecoins/conversion` * **Impact**: This is a non-breaking documentation change. The new description clarifies that for an issuance, the `sourceAssetType` must be `USD`, and for a redemption, it must be the asset being redeemed. ## Improved Staking Request Descriptions * **Type**: Improved * **Brief description of the change**: The descriptions for the `parameters` object and the `stakingProviderAddress` field for Solana staking requests have been updated for clarity. * **Category of API endpoints that changed**: Transactions * **The endpoint that changed**: Create a stake request * **The method of the endpoint that changed**: `POST` * **The path of the endpoint that changed**: `/transactions/stake` * **The request body of the endpoint that changed**: * The description for the `parameters` object was updated. * In the `SOLStakingParameters` object, the description for the `stakingProviderAddress` field was changed from "The validator's staking address" to "The validator's vote account 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` * **Description**: This new endpoint enables users to programmatically initiate a request to consolidate their staking positions. * **Impact**: This feature enhances staking management by allowing users to consolidate stakes directly through the API. See [staking guide](https://developers.anchorage.com/docs/ethereum-pectra-staking-api#consolidate-pectra-to-pectra-validator) for instructions on use ## Re-introduced VAULT Resource Type for Backward Compatibility * **Improved**: The `VAULT` enum value has been re-introduced to the `type` field for source and destination resources in various endpoints. While `VAULT` is now an accepted value, it is considered deprecated, and developers should use `WALLET` instead. * **Category**: Transfers, Wallets, and Transactions * **Endpoints Changed**: * `POST /transactions/withdrawal` * `POST /transfers` * `GET /transfers` * `GET /transfers/{transferId}` * `GET /vaults/{vaultId}/wallets` * `POST /vaults/{vaultId}/wallets` * `GET /wallets` * `GET /wallets/{walletId}` * **Impact**: This change ensures backward compatibility for integrations that may still be using the `VAULT` resource type. For all new and updated integrations, `WALLET` should be used as the resource type. * **Additional Information**: We strongly recommend updating any existing code to use the `WALLET` resource type to ensure future compatibility, as support for the `VAULT` type will be removed in a future release. ## Updated AML Requirements for Creating Trusted Destinations * **Improved** The `trustedDestinationAmlQuestionnaire` field is now conditionally required based on the organization type. * **Category**: Trusted Destinations * **Endpoint Changed**: `POST /trusted_destinations` * **Request Body**: The `trustedDestinationAmlQuestionnaire` field is now required for Anchorage Digital organizations and must be omitted for Porto organizations. * **Impact**: API requests to create a trusted destination will fail if the `trustedDestinationAmlQuestionnaire` is included for a Porto organization or omitted for an Anchorage Digital organization. ## Added New Endpoints for Tax Account Management * **Added** * **Description**: Introduced new endpoints to the Tax API for managing tax accounts and their associated transactions. * **Category**: Tax * **Endpoints Changed**: * `GET /tax/accounts` * `GET /tax/accounts/{accountId}/transactions` * `PATCH /tax/accounts/{accountId}/transactions/{transactionId}` * **Impact**: These new endpoints provide functionality to list tax accounts, retrieve transactions for a specific account, and update the cost basis of a transaction for tax reporting purposes. ## Removal of TRUSTED\_DESTINATION as a Resource Type * **Removed**: The `TRUSTED_DESTINATION` value has been removed as a valid enum for the resource `type` field. * **Category**: Transfers, Withdrawals, Wallets * **Endpoints Changed**: * `POST /transactions/withdrawal` * `POST /transfers` * `GET /transfers` * `GET /transfers/{transferId}` * `GET /vaults/{vaultId}/wallets` * `POST /vaults/{vaultId}/wallets` * `GET /wallets` * `GET /wallets/{walletId}` * **Impact**: * **Requests**: For `POST /transactions/withdrawal` and `POST /transfers`, the `destination.type` field in the request body no longer accepts `TRUSTED_DESTINATION`. API calls using this value will now fail. * **Responses**: For `GET /transfers`, `GET /transfers/{transferId}`, `GET /wallets`, `GET /wallets/{walletId}`, `GET /vaults/{vaultId}/wallets`, and `POST /vaults/{vaultId}/wallets`, the `type` field within various response objects will no longer return `TRUSTED_DESTINATION`. * **Additional Information**: This change standardizes resource types. Users should now specify the underlying `ADDRESS` or `WALLET` directly when creating transfers or withdrawals. ## Expanded IRS Distribution Codes for Tax Transaction Tagging * **Improved**: The `distributionCode` field for tagging tax transactions now supports IRS combination codes. * **Category**: Tax * **Endpoint Changed**: `POST /tax/transaction/{transactionId}/tag` * **Request Body**: The `distributionCode` field within the request body for the "Add Tag to Transaction" endpoint has been updated to include combination codes as valid enum values. * **Impact**: This allows for more accurate tax reporting by enabling the use of combination codes (e.g., `1B`, `4G`, `7B`) for distributions that have multiple applicable IRS classifications. * **Example**: When tagging a distribution transaction, you can now provide a `distributionCode` of `4G` to represent a death-related direct rollover. ## Enhanced Collateral Management Operations with Liquidation Details * **Improved**: The response for Collateral Management Operations has been enhanced to include liquidation details and an update timestamp. * **Category**: Collateral Management * **Endpoints Changed**: * `PATCH /collateral_management/operations/{operationId}` * `GET /collateral_management/operations` * **Impact**: The `CMOperation` model returned by these endpoints now includes the following new fields, providing more comprehensive data on operations, particularly those involving liquidations: * `updatedAt` (string): The timestamp of when the operation was last updated. * `liquidationCollateralPackageId` (string): The unique identifier of the collateral package being liquidated. * `liquidationProceedAsset` (object): The asset symbol or ticker for the proceeds of the liquidation. * `liquidationProceedQuantity` (string): The decimal quantity of the proceeds received from the liquidation. ## Added New WRITE\_TAX Permission * **Improved** * Added the new `WRITE_TAX` permission type. This will now appear in the response for the Get API Key Info endpoint. * **Category**: API Key * **Endpoint Changed**: `GET /apikey` * **Impact**: The response for the `GET /apikey` endpoint will now include `WRITE_TAX` in the `permissions` array for API keys that have this permission. This is a non-breaking change. * **Example**: ```json theme={null} { "data": { "id": "b5a58566763e77e2d87a53463013981be7c0b048c1c0dd39ba44e77c99bc1351", "permissions": [ { "permission": "READ", "vaultIds": [ "1c920f4241b78a1d483a29f3c24b6c4c" ] }, { "permission": "WRITE_TAX" } ] } } ``` ## Enhanced Trusted Destination Creation with AML Questionnaire * **Improved**: Added an optional `trustedDestinationAmlQuestionnaire` object to the request body for creating trusted destinations. This allows for the submission of Anti-Money Laundering (AML) information upfront when creating a new destination. * **Category**: Trusted Destinations * **Endpoint Changed**: `POST /trusted_destinations` * **Request Body**: Each object within the `trustedDestinations` array in the request body now accepts the optional `trustedDestinationAmlQuestionnaire` field. * **Impact**: This is a non-breaking change. Providing AML information during the creation of a trusted destination can help streamline the approval process for future withdrawals to that address. ## Added AML Questionnaire to Trusted Destination Creation * **Added an optional `trustedDestinationAmlQuestionnaire` object to streamline the creation of trusted destinations.** * **Category**: Trusted Destinations * **Endpoint Changed**: `POST /trusted_destinations` * **Request Body**: The request body for creating a trusted destination now accepts an optional `trustedDestinationAmlQuestionnaire` object within each item of the `trustedDestinations` array. * **Impact**: This is a non-breaking change. You can now provide Anti-Money Laundering (AML) information directly when creating a new trusted destination, which can help streamline the approval process. * **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" } } ] } ``` ## Added AML Questionnaire to Trusted Destination Creation * **Added**: An optional `trustedDestinationAmlQuestionnaire` object can now be included when creating a new trusted destination. * **Category**: Trusted Destinations * **Endpoint Changed**: `POST /trusted_destinations` * **Request Body**: The objects within the `trustedDestinations` array now accept a new optional `trustedDestinationAmlQuestionnaire` field. * **Impact**: This is a non-breaking change. It allows users to provide required Anti-Money Laundering (AML) information upfront when creating a destination, which can streamline future withdrawal requests. * **Example**: ```json theme={null} { "idempotentId": "1ca86e65-4340-4876-85f4-8334852b9c43", "trustedDestinations": [ { "assetType": "BTC", "address": "2N19AcihQ1a4MxQW658UFHTioUNnMkiHPkw", "name": "My Exchange Wallet", "description": "BTC wallet at MyExchange", "trustedDestinationAmlQuestionnaire": { "destinationType": "FINANCIAL_INSTITUTION", "institutionName": "MyExchange", "institutionCountry": "US", "recipientType": "MY_ORGANIZATION" } } ] } ``` ## Enhanced Deposit Address Security with V2 Signatures * **Improved** * **Description**: Introduced a V2 signature scheme for deposit addresses to provide an enhanced security model. Responses that include signed address information will now contain two new fields: `signatureVersion` and `certChain`. The `signatureVersion` field indicates the signature scheme in use. When `V2` is present, the `certChain` field will contain an x509 certificate chain for verification against a trusted Anchorage Digital Root CA. * **Category**: Addresses, Wallets * **Endpoints Changed**: * `GET /vaults/{vaultId}/addresses` * `POST /wallets/{walletId}/addresses` * `GET /vaults/{vaultId}/wallets` * `POST /vaults/{vaultId}/wallets` * `GET /wallets` * `GET /wallets/{walletId}` * **Impact**: This change provides clients with a more robust, certificate-based method for verifying the authenticity of deposit addresses. The change is backward-compatible; if the `certChain` field is absent, the existing V1 signature verification method (using the Organization Public Key) should be used. * See instructions in [Address Verification guide](https://developers.anchorage.com/docs/address-verification) ## 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` * `GET /transactions/{transactionId}` * **Methods**: GET * **Paths**: * `/transactions` * `/transactions/{transactionId}` * **Parameters**: The `types` query parameter for the `GET /transactions` endpoint now accepts `MINT` as a value to filter transactions. * **Impact**: The `transactionType` field in the responses for the transaction endpoints can now return `MINT`. ## New Error Response for Collateral Package Updates * **Improved** * **Description**: Added a new `422 Unprocessable Entity` error response to the `Update a collateral package` endpoint. This provides more specific feedback for requests that are syntactically correct but semantically invalid and cannot be processed. * **Category**: Collateral Management * **Endpoint Changed**: * `PATCH /collateral_management/packages/{packageId}` * **Impact**: This enhances error handling by allowing clients to differentiate between a bad request (`400`), a resource not found (`404`), and an unprocessable entity (`422`). ## New 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` * `PATCH /collateral_management/packages/{packageId}` * `POST /collateral_management/exposures` * **Request Body**: * The `priceStrategy` field now accepts the enum value `VWAP`. * The `priceSource` field now accepts the enum value `KAMINO`. * **Impact**: Users 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** * **Type**: Added * **Description**: We have introduced a new `transactionType` called `BURN` to represent assets that are burned or destroyed on the blockchain. This helps in the clearer categorization of on-chain asset destruction events. * **Category**: Transactions * **Endpoints Changed**: * `GET /transactions` * `GET /transactions/{transactionId}` * **Impact**: You can now filter for `BURN` transactions by including it in the `types` query parameter of the `GET /transactions` endpoint. The `BURN` type will also appear in the `transactionType` field in the responses for both `GET /transactions` and `GET /transactions/{transactionId}`. ## Removed priceSourceProvider from Collateral Management Endpoints * **Removed** * **Description**: Removed the `priceSourceProvider` field from the request bodies of several Collateral Management endpoints. * **Category**: Collateral Management * **Endpoints Changed**: * `POST /collateral_management/packages` * `PATCH /collateral_management/packages/{packageId}` * `POST /collateral_management/exposures` * **Request Body**: The `priceSourceProvider` field is no longer available in the `collateralAssetsConfig` object when creating or updating a collateral package, nor in the `assetTrackingConfig` object when creating an exposure. * **Impact**: API requests to these endpoints that include the `priceSourceProvider` field will now result in an error. Integrations must be updated to remove this field to ensure successful requests. ## Added GAS\_FEE Action for Collateral Management Operations * **Improved** the `CMOperation` model to include a new `GAS_FEE` action type. * **Category**: Collateral Management * **Endpoints Changed**: * `PATCH /collateral_management/operations/{operationId}` * `GET /collateral_management/operations` * **Impact**: The `action` field in the responses for these endpoints can now include the value `GAS_FEE`, providing more granular detail on operation types. ## Enhanced Fiat Deposit Instructions with Memo Field * **Improved**: A `memoField` has been added to the `depositInstruction` object, which is returned for fiat wallets in several wallet-related endpoints. * **Category**: Wallets * **Endpoints Changed**: * `GET /vaults/{vaultId}/wallets` * `POST /vaults/{vaultId}/wallets` * `GET /wallets` * `GET /wallets/{walletId}` * **Impact**: This is a non-breaking, additive change. Responses for the affected endpoints will now include a `memoField` within the `depositInstruction` object for fiat wallets. * **Additional Information**: This memo should be included on wire deposits to ensure funds are attributed correctly to the wallet. * **Example**: The `depositInstruction` object in the response for a fiat wallet will now include the new field. ```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" } ``` ## Enhanced Wallet Details with Fiat Deposit Instructions * **Improved** * **Description**: Wallet-related endpoints have been updated to include specific deposit instructions for fiat wallets, distinguishing them from crypto wallet addresses. The response for these endpoints now includes a new `depositInstruction` object for fiat wallets. * **Category**: Wallets * **Endpoints Changed**: * `GET /vaults/{vaultId}/wallets` * `POST /vaults/{vaultId}/wallets` * `GET /wallets` * `GET /wallets/{walletId}` * **Impact**: Responses for the listed endpoints will now conditionally include the `depositInstruction` object for fiat wallets, containing banking details for deposits. 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**: A fiat wallet in the response will now contain a `depositInstruction` object. ```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]" } ``` ## Enhanced Collateral Management Package Updates and API Refinements * **Improved** * The Collateral Management API has been updated to provide more comprehensive control and clarity. The endpoint for updating a collateral package now supports partial updates to its entire configuration, and several other endpoints have been refined. * **Category**: Collateral Management * **Endpoints Changed**: * `PATCH /collateral_management/packages/{packageId}` * `PATCH /collateral_management/operations/{operationId}` * `POST /collateral_management/operations` * `GET /collateral_management/exposures` * `POST /collateral_management/packages` * `GET /collateral_management/packages` * **Changes**: * **`PATCH /collateral_management/packages/{packageId}`**: This endpoint has been significantly enhanced. 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. Fields that are omitted in the request will remain unchanged. * **`POST & PATCH /collateral_management/operations`**: The `type` field in the request body has been refined; the `LIQUIDATION` enum value has been removed to clarify the available operation types. The description for `typeId` was also improved for clarity. * **Other Endpoints**: Descriptions for various fields across `GET /collateral_management/exposures`, `POST /collateral_management/packages`, and `GET /collateral_management/packages` have been updated to provide more accurate and clear documentation. * **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 New Collateral Management Operation Actions * **Added** new `action` types for creating and updating Collateral Management operations. * **Category**: Collateral Management * **Endpoints Changed**: * `POST /collateral_management/operations` * `PATCH /collateral_management/operations/{operationId}` * **Request Body**: The `action` field in the request body for both endpoints now supports the following new enum values for collateral packages: * `CLOSE_RETURN` * `REHYPE_IN` * `REHYPE_OUT` * **Impact**: Users can now create and update operations to manage the closing of returns and rehypothecation for collateral packages. ## Enhanced Tax Transaction Tagging with New Fields * **Added new conditional fields for tagging tax transactions** to support more detailed reporting. * **Type**: Added * **Category**: Tax * **Endpoint Changed**: `POST /tax/transaction/{transactionId}/tag` * **Request Body**: The following fields have been added to the request body for the `tagTaxTransaction` operation: * `distributionCode` (string): Now required when the `tag` is `distribution`. This field is for the IRS distribution code for Form 1099-R. * `totalDistribution` (boolean): Now required when the `tag` is `distribution`. Indicates if this is a total distribution of the account. * `postponedLateReason` (string): Now required when the `tag` is `postponed` or `late-rollover` to provide a reason. * **Impact**: When tagging transactions with `distribution`, `postponed`, or `late-rollover`, users 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 } ``` ## Updates to Collateral Management API * **Improved**: We've enhanced several endpoints in the **Collateral Management API** to improve clarity and functionality. Descriptions for numerous fields have been updated to provide more context and examples. * **Category**: Collateral Management * **Endpoints Changed**: * `POST /collateral_management/packages` * `GET /collateral_management/packages` * `POST /collateral_management/exposures` * `GET /collateral_management/exposures` * `POST /collateral_management/operations` * `GET /collateral_management/operations` * `PATCH /collateral_management/operations/{operationId}` * **Key Changes**: * For the `Create a new collateral package` endpoint (`POST /collateral_management/packages`), the `defaultGroupId` parameter has been removed from the request body. * For the `List packages` endpoint (`GET /collateral_management/packages`), the `acceleratedMarginCall` property has been removed from the response. Additionally, two new states have been added to the `state` enum: `CURE_PERIOD_EXPIRED` and `DEFAULTED`. * For the `Create a new operation` (`POST /collateral_management/operations`) and `Update an operation` (`PATCH /collateral_management/operations/{operationId}`) endpoints, several unsupported enum values for the `action` field have been removed to reflect currently available actions. * Descriptions have been improved across all listed endpoints for parameters such as `clientReferenceId`, `pledgorId`, `curePeriod`, `ltv`, `topUpType`, and more to provide better guidance. ## Added BID and ASK options for Price Strategy * **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` * `POST /collateral_management/exposures` * **Request Body**: The `priceStrategy` field in the request body for both endpoints now accepts `BID` and `ASK` as enum values. * **Impact**: This provides users with more granular control over the pricing strategy, allowing them to 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` * **Method**: GET * **Path**: * `/trading/orders` * **Parameters**: Added the optional `orderTypes` query parameter. This parameter accepts an array of strings to filter orders by their type. Possible values include `LIMIT`, `MARKET`, `STOP_LOSS`, `STOP_LIMIT`, `TAKE_PROFIT_LIMIT`, `TWAP`, `VWAP`, `PEGGED`, `POV`, and `OTHER`. * **Impact**: This change allows for more granular querying of orders, enabling users to retrieve only the specific order types they are interested in. * **Example**: A request to retrieve only `LIMIT` and `STOP_LIMIT` orders would look like this: `GET /v2/trading/orders?orderTypes=LIMIT,STOP_LIMIT`. ## Streamlined Customer Onboarding Submission * **Improved** the customer onboarding workflow by adding an optional `submit` parameter. * **Category**: Onboarding * **Endpoint Changed**: `POST /onboarding/customers` * **Request Body**: Added the optional `submit` (boolean) parameter to the request body. * **Impact**: This is a non-breaking change. When `submit` is set to `true`, the application is created and submitted in a single call, eliminating the need for a separate submission request. * **Additional Information**: Using this new parameter can help streamline the onboarding process by reducing the number of required API calls. ## Added KRAKEN as a Price Source for Collateral Management * **Improved**: Added `KRAKEN` as a supported price source for collateral management. * **Category**: Collateral Management * **Endpoints Changed**: * `POST /collateral_management/packages` * `POST /collateral_management/exposures` * **Request Body**: The `priceSource` field within the request bodies for creating collateral packages and exposures now accepts `KRAKEN` as a value. * **Impact**: This provides more flexibility by allowing you to select Kraken as the data source for asset pricing when configuring collateral.