> ## 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. # List trades > Permissions required: **Execute trades** or **Read trade activity** List all trades. With the permission **Read trade activity** all trades of the organization may be read. With the permission **Execute trades** only the trades created by this API key may be read. Trades are sorted in a descending order by their timestamp, i.e. the most recent trade or the trade with a timestamp closest to `endDate` is listed first. #### Filters You may optionally supply the following filters: - Specify a `tradingPair` to filter by the trading pair of the trade, for example `BTC-USD`. - Specify one or multiple `status` to filter trades. Multiple statuses should be separated by commas. - Specify a `side` to filter by the side of the trade. ## OpenAPI ````yaml /knowledge-base/openapi/v2.yaml get /trading/trades openapi: 3.0.0 info: version: 2.0.0 title: Anchorage Digital API Reference contact: email: api@anchorage.com description: >- # Introduction *CONFIDENTIAL: Please do not distribute this documentation externally without prior Anchorage Digital approval.* The Anchorage Digital REST API v2.0 provides a set of operations and resources that allow Anchorage Digital clients and partners to: - Programmatically transfer funds from an Anchorage Digital vault or wallet without human intervention - Create and list deposit addresses in a vault - Read and monitor vault balances - Query transaction history including deposits - Request quotes from and execute trades with the Anchorage Digital trading desk Want help or to share your opinion on how this API works for you? Please contact api@anchorage.com. # Authentication and Security The Anchorage Digital API performs authentication and authorization via a combination of: * An API key, which is a bearer token * A permission group signed by the user's organization, which is linked to the API key * An Ed25519 Signature, which comes from a user-generated key and is required for certain requests ## Permission Groups A permission group acts as a set of rules for how an organization and its resources can be accessed. Permission groups are created independently of API keys, and new permission groups must be created prior to making an API key. Each permission group has a name, a description and a set of permissions which can be applied to your organization's vaults. Updating, creating and deleting permissions groups require a quorum of approvals. After creation, a permission group can be freely assigned to an unlimited number of API keys. Each API key inherits its permissions from the associated permission group. When the permission group is updated, all API keys associated with it will inherit the updated permission set. If a permission group is deleted, all associated API keys will no longer work. Each organization is created with a default permission group that allows read-only access. This permission group may be modified or deleted at any time, and no API keys are created by default with this permission group. ### Permissions Possible vault permissions include the following:
Read vault activity (READ) See an overview of your vault(s) and wallets. Read vault details, balances, asset types, transaction history and deposit addresses.
Create address (CREATE_DEPOSIT_ADDRESS) Receive deposits in the vault from external sources. Create and read deposit addresses.
Transfer funds (TRANSFER) This permission is configurable to enable an API key endowed with this permission to either 1) Transfer funds to any Anchorage Digital institutional account, including those outside of your organization or 2) Transfer funds to any blockchain address not custodied by Anchorage Digital that has gone through quorum approval.
Propose and accept settlements (PROPOSE_ACCEPT_SETTLEMENTS) This is an Atlas specific permission for initiating settlements.
Authorize settlements (AUTHORIZE_SETTLEMENTS) This is an Atlas specific permission for authorizing settlements after they've been proposed or accepted.
There are also special vault permissions for enabled by Anchorage Digital on a per-organization basis: Additionally, there are global permissions which apply to the entire organization:
Initiate withdrawals (INITIATE_WITHDRAWAL) Initiate withdrawals to external destinations. All withdrawals require quorum approval through the Anchorage Digital mobile app.
Execute trades (TRADE) Request for quotes (RFQ) from the Anchorage Digital trading desk. Create and accept quotes. Read data of trades and settlements created by this key.
Read trade activity (READ_TRADE) Read trade activity and trade settlements data of your organization.
Read lending activity (LENDER_READ) Read lending activity of your organization.
Read facility data (FACILITY_ONLY) Read lending facility data.
Read deposit attribution activity (READ_DEPOSIT_ATTRIBUTION) Read deposit attribution activity of your organization.
Manage deposit attributions (DEPOSIT_ATTRIBUTION) Read deposit attribution activity of your organization. Perform deposit attributions.
Initiate Staking and Unstaking (STAKE) Initiate staking or unstaking operation. All operations require quorum approval through the Anchorage Digital mobile app.
### Example Workflow - Allow transfers from specific vaults To create an API key with the ability to transfer funds from an Anchorage Digital vaults or wallet, a permission group must first be created with the **Transfer funds** permission for the desired source vaults. Creating this permission group requires a quorum of approvals on the Anchorage Digital iOS app. Once the creation is confirmed, any number of API keys may be created with this permission group in the Anchorage Digital Web Dashboard under the API 2.0 section. To add additional permissions to the API key, update the associated permission group through the Anchorage Digital Web Dashboard. To revoke any permissions, the individual API key may be revoked, or the permission group may be updated or deleted to remove Transfer access. ## API Keys All API requests must be made over HTTPS and must include authentication using the following scheme. ### Generating an API Key In order to make a valid API request, you must first create an API key. API keys can be created and managed in the Anchorage Digital Web Dashboard under the [API 2.0 tab](https://anchoragelogin.com/api). When you create an API key, there are 3 pieces of information you will need to remember: - API access key - Ed25519 public key (optional for read-only requests) - Ed25519 private/signing key (optional for read-only requests) You must generate an Ed25519 signing key pair and save the public portion in the Anchorage Digital Web Dashboard when creating the API access key. The signing key pair is used for added security with sensitive requests. Please note, Anchorage Digital cannot recover your API access key or private signing key if you forget them. You may generate a new access key and signing key at any time if you lose access. ### API Key Permissions Each API key is associated with a permission group. This permission group specifies the permitted actions for all associated API keys. Read more about permission groups [here](#section/Authentication-and-Security/Permission-Groups). ### Creating a request All requests must include the `Api-Access-Key` header, which contains your API access key as a string. Endpoints that require a signature must include the `Api-Signature` and `Api-Timestamp` headers. Read more about signatures [here](#section/Authentication-and-Security/Signatures). All request bodies must be valid JSON and have the content type `application/json`. ## Request Signatures Certain endpoints require an Ed25519 signature to be provided alongside the API key. These endpoints will specify the `Api-Signature` and `Api-Timestamp` headers as additional parameters. Signatures are optional unless explicitly required, but are encouraged for all requests. If a signature is provided, it will be verified. ### Signing Keys A signing key pair is generated by the user and the corresponding public key must be provided when creating an API key. When creating an API key, you will be prompted to provide an Ed25519 public key. You must use the associated Ed25519 signing key (private key) when creating signatures for requests from this API key. Please note that signing keys (Ed25519 private keys) should be stored securely by the user. The signing key should only be used to derive request signatures and should never be sent in a request. Anchorage Digital will never request you share your private key. ### Generating a Signing Key The user must securely generate an Ed25519 key pair on their own hardware and retain both the public and private portions. The Anchorage Digital API accepts a 64-character (32 bytes) hex-encoded Ed25519 public key when creating an API access key. #### Code sample (Python) *Generate a new signing key pair* ```python # https://pypi.org/project/PyNaCl/ import nacl import nacl.signing import secrets seed = secrets.token_bytes(32) # Generate a new random signing key signing_key = nacl.signing.SigningKey(seed) # Obtain the hex-encoded signing key print('Signing key:') print(signing_key.encode().hex()) # Obtain the hex-encoded verify key for the given signing key # Use this in the Anchorage Digital Web Dashboard when creating an API key print('Public key:') print(signing_key.verify_key.encode().hex()) ``` ### Signing a Request To sign a request, generate a request signature using the Ed25519 private (signing) key and provide it alongside the request in the `Api-Signature` header. To create a request signature, first concatenate the `timestamp`, `method`, `request path`, and `body` into a string. Then, create a signature of this message using the Ed25519 private key and hex-encode the output. Use this value as the `Api-Signature` header and use the `timestamp` value as the `Api-Timestamp` header. - The `method` is an uppercase HTTP method (ex. `GET`, `POST`, `DELETE`) - The `request path` should contain all query parameters (ex. `/v2/transfers?foo=bar&baz=bang`) - The `body` is a stringified HTTP request body - The `body` should be omitted if the request does not contain a body (ex. a `GET` or `DELETE` request) - The `timestamp` is the same as the `Api-Timestamp` header - The `timestamp` is a number of seconds since the Unix Epoch in UTC, and must be within one minute of the API service's time when the request is received ### Reference signature To verify your signature generation code is correct, generate a signature for the following request and timestamp using the provided signing key. If the generated signature matches the signature below, your signature generation code is correct.
Timestamp 1577880000
HTTP Method (Uppercase) POST
HTTP Path + query /v2/transfers?foo=bar&baz=bang
HTTP Body {"source": {"id": "1c920f4241b78a1d483a29f3c24b6c4c", "type": "VAULT"}, "assetType": "ETH", "destination": {"id": "55e89d4a644d736b01533a2ea9b32a20", "type": "VAULT"}, "amount": "1000.00000000"}
Signing Key (Ed25519 Private Key Seed) 0101010101010101010101010101010101010101010101010101010101010101
Public Key 8a88e3dd7409f195fd52db2d3cba5d72ca6709bf1d94121bf3748801b40f6f5c
Signature 4bf42054bf7db1f8a2a2bc83d2a108502ee7a9d2ac7a2738adc2f932922446786fb9be1bd1eb475023296c6cba4ddbe28b04baca4b7521b1f1840a4ffd2b4d0d
## Reference clients ### Python (with `requests` library) *Authorize and sign requests* ```python # https://pypi.org/project/PyNaCl/ from nacl import signing import time import requests class AnchorageAuth(requests.auth.AuthBase): ACCESS_KEY_HEADER = "Api-Access-Key" SIGNATURE_HEADER = "Api-Signature" TIMESTAMP_HEADER = "Api-Timestamp" access_key: str signing_key: signing.SigningKey def __init__(self, access_key: str, signing_key_seed: bytes): self.access_key = access_key self.signing_key = signing.SigningKey(signing_key_seed) def __call__(self, r: requests.PreparedRequest): r.headers[self.ACCESS_KEY_HEADER] = self.access_key timestamp = str(int(time.time())) method = r.method.upper() if r.method else "GET" body: bytes = bytes() if r.body and isinstance(r.body, bytes): body = r.body elif r.body and isinstance(r.body, str): body = bytearray(r.body, "utf-8") message = b"".join( [bytearray(timestamp, "utf-8"), bytearray(method, "utf-8"), bytearray(r.path_url, "utf-8"), body] ) signature = self.signing_key.sign(message).signature.hex() r.headers[self.SIGNATURE_HEADER] = signature r.headers[self.TIMESTAMP_HEADER] = timestamp return r # load secrets # Use the API key generated in the Anchorage Digital Web Dashboard access_key = ... # Use the Ed25519 signing private key signing_key_str = ... # load the raw string signing_key = bytes(bytearray.fromhex(signing_key_str)) data = {} anchorage_auth = AnchorageAuth(access_key, signing_key) r = requests.post("https://api.anchorage.com/v2/transfers", data=data, auth=anchorage_auth) ``` ### Ruby - Reproduce reference signature ```ruby require "ed25519" require "net/http" require "time" def hex_to_bin(s) [s].pack('H*') end def bin_to_hex(s) s.unpack('H*').first end private_key_seed_hex = '0101010101010101010101010101010101010101010101010101010101010101' public_key_hex = '8a88e3dd7409f195fd52db2d3cba5d72ca6709bf1d94121bf3748801b40f6f5c' key_pair_hex = private_key_seed_hex + public_key_hex key_pair = hex_to_bin(key_pair_hex) signing_key = Ed25519::SigningKey.from_keypair(key_pair) timestamp = '1577880000' # Time.now.to_i.to_s req = Net::HTTP::Post.new('/v2/transfers?foo=bar&baz=bang') req.body = '{"source": {"id": "1c920f4241b78a1d483a29f3c24b6c4c", "type": "VAULT"}, "assetType": "ETH", "destination": {"id": "55e89d4a644d736b01533a2ea9b32a20", "type": VAULT"}, "amount": "1000.00000000"}' signature = signing_key.sign(timestamp + req.method + req.path + req.body) req['Api-Access-Key'] = 'YOUR_ACCESS_KEY' req['Api-Timestamp'] = timestamp req['Api-Signature'] = bin_to_hex(signature) puts bin_to_hex(signature) ``` # Errors The Anchorage Digital API returns standard HTTP error codes for each API request.
Response Code Description
200 OK The request was successful.
400 Bad Request The request was improperly formed and could not be understood by the server, often due to invalid syntax, insufficient funds, or a missing required parameter.
401 Unauthorized The request was missing a valid API key.
403 Forbidden The provided API key does not have permission to perform the requested action.
404 Not Found The requested resource does not exist.
409 Conflict The requested resource cannot proceed with the requested action because it is not in the required state.
429 Too Many Requests Too many requests have been sent in a given amount of time.
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout 		Something went wrong on Anchorage’s side. We have been alerted and are working on it.
In addition to returning HTTP error codes for failed requests, the Anchorage Digital API includes a readable error message describing what went wrong in the response body. # Idempotency Certain endpoints support idempotent requests so that a given request can be safely retried without performing the same operation twice. For example, if a request to transfer funds does not respond due to network issues, you can retry the request using the same idempotent ID to ensure that only one transfer is created. Endpoints that support idempotent requests have an optional `idempotentId` field that can be included in the body of the `POST` request. Provide a unique string using your method of choice (such as a v4 UUID). If a request is valid, Anchorage Digital will save the request indefinitely. If a subsequent request is received with the same `idempotentId` we will return the previously saved response for that `idempotentId`. # Rate Limits Keys provisioned by an Organization share one common rate limit. API requests are limited to 20 requests per second per Organization, allowing for bursts of up to 100 requests within a single second. # Pagination Cursor pagination is used for REST endpoints which return multiple data points. Pagination allows for fetching data after the current page and specifying how many records to return. The `next` cursor is available in responses with the `page` attribute. Requests should use the `next` cursor URL to query subsequent data. Query parameter `afterId` specifies the last record previously retrieved. Some endpoints instead use the `endDate` parameter to specify the end date and older for records to retrieve. Query parameter `limit` specifies the maximum number of records in a response. ## Parameters
Parameter Description
afterId Request page after (older than) this pagination id.
endDate Request records older than this date (YYYY-MM-DD format). Used for /trading/trades and /trading/settlements resources.
limit Maximum number of results requested. Default usually 25, but varies depending on resource.
## Example `GET /v2/transfers?afterId=1968b94b09b8a1a8a381775d1f04978c424d891d50e517774bf984297985b471&limit=100` ## Next cursor The `next` cursor is a URL which references the last record in a set of records. When queried, the `next` cursor URL will return subsequent records, but otherwise using the same query parameters. servers: - url: https://api.anchorage-staging.com/v2 security: - Api-Access-Key: [] tags: - description: > These endpoints allow querying information about the current API key in use. name: API Key - description: Descriptions of supported asset types name: Asset Types - description: "These endpoints allow the user to create and retrieve deposit addresses for specific assets.\n\n# Verifying Deposit Addresses\n\nThe addresses REST API endpoints return signatures of the address strings and other metadata that prove the address was generated by Anchorage Digital for your organization. \n\nIt is critical that clients verify the address signature and any accompanying metadata before the address is used, to confirm the address authenticity and integrity.\n\n## Address Signature Schemes\n\nThe API supports two address verification schemes:\n\n- **V1 Address Signatures** - The original scheme involves verifying a signature against a public key that is unique to each organization. This public key remains fixed for the lifetime of the organization and is distributed on request by Anchorage Digital out-of-band. While the public key does not need to be kept confidential, it must be kept tamper-proof.\n- **V2 Address Signatures** - The newer scheme involves verifying a signature against the public key of the leaf certificate of a X509 certificate chain returned alongside the signature, and verifying the certificate chain itself against the Anchorage Digital Address Signing Root CA, provided below, which must be hard-coded by API clients.\n\nYou can determine which scheme an address uses by checking the `signatureVersion` field.\n\n## V1 Address Signature Verification\n\nThe steps for verifying V1 address signatures are as follows:\n\n1. Check the validity of the signature:\n a. Decode the `addressSignaturePayload` field from hex to bytes.\n b. Decode the `signature` field from hex to bytes.\n c. Using the fixed public key for this organization, verify that `signatureBytes` is a valid Ed25519 signature of the `addressSignaturePayloadBytes`.\n2. Verify the signed address matches the address to be used:\n a. Decode the `addressSignaturePayload` field from hex to bytes.\n b. Parse the bytes as a JSON object.\n c. Verify the address to be used matches the value of the `TextAddress` property from the JSON object.\n\n**Note: It is not sufficient to validate the signature without also validating that the address contained in the JSON decoded from the `addressSignaturePayload` matches the address to be used.**\n\n### V1 Signed Payload Fields\n\n- `TextAddress` — The text format of the on-chain address.\n\n```json\n{\n \"TextAddress\": \"2N19AcihQ1a4MxQW658UFHTioUNnMkiHPkw\"\n}\n```\n\n### Sample V1 validation code:\n\n```go\npackage main\n\nimport (\n\t\"crypto/ed25519\"\n\t\"encoding/hex\"\n\t\"encoding/json\"\n\t\"fmt\"\n)\n\n// V1SignedPayload represents the JSON structure in the addressSignaturePayload for V1 signatures\ntype V1SignedPayload struct {\n\tTextAddress string `json:\"TextAddress\"`\n}\n\n// verifyV1AddressSignature verifies a V1 address signature.\n//\n// Parameters:\n// - address: The address string from the API response\n// - addressSignaturePayload: Hex-encoded bytes that were signed\n// - signature: Hex-encoded Ed25519 signature\n// - orgPublicKeyHex: Hex-encoded Ed25519 public key for your organization (obtained out-of-band)\n//\n// Returns an error if verification fails.\nfunc verifyV1AddressSignature(address, addressSignaturePayload, signature, orgPublicKeyHex string) error {\n\t// Step 1: Check the validity of the signature\n\n\t// Decode the addressSignaturePayload from hex to bytes\n\tpayloadBytes, err := hex.DecodeString(addressSignaturePayload)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to decode addressSignaturePayload: %w\", err)\n\t}\n\n\t// Decode the signature from hex to bytes\n\tsignatureBytes, err := hex.DecodeString(signature)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to decode signature: %w\", err)\n\t}\n\n\t// Decode the organization public key from hex\n\tpublicKeyBytes, err := hex.DecodeString(orgPublicKeyHex)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to decode organization public key: %w\", err)\n\t}\n\n\tif len(publicKeyBytes) != ed25519.PublicKeySize {\n\t\treturn fmt.Errorf(\"invalid public key size: got %d bytes, expected %d\", len(publicKeyBytes), ed25519.PublicKeySize)\n\t}\n\n\tpublicKey := ed25519.PublicKey(publicKeyBytes)\n\n\t// Verify the Ed25519 signature\n\tif !ed25519.Verify(publicKey, payloadBytes, signatureBytes) {\n\t\treturn fmt.Errorf(\"signature verification failed\")\n\t}\n\n\t// Step 2: Verify the signed address matches the address to be used\n\n\t// Parse the payload bytes as JSON\n\tvar signedPayload V1SignedPayload\n\tif err := json.Unmarshal(payloadBytes, &signedPayload); err != nil {\n\t\treturn fmt.Errorf(\"failed to parse signed payload: %w\", err)\n\t}\n\n\t// Verify the TextAddress matches\n\tif signedPayload.TextAddress != address {\n\t\treturn fmt.Errorf(\"signed TextAddress does not match: signed=%q, expected=%q\", signedPayload.TextAddress, address)\n\t}\n\n\treturn nil\n}\n\nfunc main() {\n\t// Sample API response data\n\taddress := \"2N19AcihQ1a4MxQW658UFHTioUNnMkiHPkw\"\n\taddressSignaturePayload := \"7b225465787441646472657373223a22324e313941636968513161344d78515736353855464854696f554e6e4d6b6948506b77227d\"\n\tsignature := \"b18f6848dc0fef01a069e7ac26046383bf5cd130203994dc2d72b5a9097351b1e8b67115b63124fbc8c16673566416a635913c670b676089339c62a7824baa03\"\n\n\t// Organization public key - obtained out-of-band from Anchorage Digital beforehand\n\t// Unique per Organization, fixed for the lifetime of that Organization\n\t// Must be kept tamper-proof\n\torgPublicKeyHex := \"8a88e3dd7409f195fd52db2d3cba5d72ca6709bf1d94121bf3748801b40f6f5c\"\n\n\t// Verify the signature\n\tif err := verifyV1AddressSignature(address, addressSignaturePayload, signature, orgPublicKeyHex); err != nil {\n\t\tfmt.Printf(\"✗ V1 Address signature verification failed: %v\\n\", err)\n\t\treturn\n\t}\n\n\tfmt.Println(\"✓ V1 Address signature verified successfully!\")\n\tfmt.Printf(\" Address: %s\\n\", address)\n\tfmt.Println(\"\\nYou may now safely use this address for deposits.\")\n}\n```\n\n## V2 Address Signature Verification\n\nAddresses returned with `signatureVersion` set to `V2` also include a `certChain` field containing an x509 certificate chain in PEM format.\n\nThe steps for verifying V2 address signatures are as follows:\n\n1. Verify the certificate chain:\n a. Parse the `certChain` field as PEM-encoded x509 certificates \n \n **Note: The leaf certificate is at the 0th index, followed by zero or more intermediate certificates. The root cert is excluded from this response. The number of certificates in the chain is subject to change.**\n \n b. Verify the certificate chain from the leaf to the trusted Anchorage Digital Root CA.\n c. Verify all certificates are valid at the current time (both notAfter and notBefore).\n d. Verify the leaf certificate's Subject Alternative Names include `address-provider.anchorage.internal`.\n e. Verify the leaf certificate's KeyUsage includes both `digitalSignature` and `nonRepudiation` (also known as `contentCommitment`).\n f. Extract the public key from the leaf certificate. Currently, we only support ed25519 keys, however this is subject to change the future.\n2. Verify the signature:\n a. Decode the `addressSignaturePayload` field from hex to bytes\n b. Decode the `signature` field from hex to bytes\n c. Using the public key from the leaf certificate, verify that `signatureBytes` is a valid signature of the `addressSignaturePayload` bytes.\n3. Verify the signed details:\n a. Parse the `addressSignaturePayload` bytes as a JSON object\n b. Verify `SignatureExpiresAt` is greater or equal to the current UTC Unix Timestamp\n c. Verify `TextAddress` matches the address to be used\n d. Verify `VaultId` matches your expected Vault ID\n e. Verify `NetworkId` matches the expected network for this address\n\n**Note: The signed payload also includes a `NetworkName` field for human-readable purposes, which does not need to be verified.**\n\n**Note: API clients must not use \"strict\" JSON parsers which will disallow extra properties, as future versions may introduce additional fields.**\n\n**Note: Anchorage Digital will periodically refresh V2 signatures and our Address Signing Root CA before expiration. The deposit address itself will not change. Only the signature, certificate chain and Root CA will be updated.**\n\n### V2 Signed Payload Fields\n\n- `TextAddress` — The text format of the on-chain address.\n- `VaultId` — Identifies the vault this address belongs to.\n- `NetworkId` — Identifies the network that this address can receive deposits on.\n- `NetworkName` — A human readable version of the `NetworkId`.\n- `SignatureExpiresAt` — The time after which the signature should not be trusted.\n\n```json\n{\n \"VaultId\": \"dae6089e7c0836705f0562af0f1e4e1f\",\n \"TextAddress\": \"bcrt1q709skemgf5skpsnysvgme2s3ztehkutl390yl0wp29lnmum5uw7qg0qrwm\",\n \"NetworkName\": \"Bitcoin Regnet\",\n \"NetworkId\": \"BTC_R\",\n \"SignatureExpiresAt\": 1769450713\n}\n```\n\n### Anchorage Digital Address Signing Root CAs\n\nClients are encouraged to hard-code the appropriate Root CA value for the environment they are making API requests against. It is essential that this value be tamper-proof.\n\n- Production Environment:\n\n```\n-----BEGIN CERTIFICATE-----\nMIIBXTCCAQ+gAwIBAgIUQZI+MSvYTXQHra+3OAKnwAMzotUwBQYDK2VwMCAxHjAcBgNVBAMMFWNhLmFuY2hvcmFnZS5pbnRlcm5hbDAeFw0yNjAxMjYwMDAwMDBaFw0yNzAxMjYwMDAwMDBaMCAxHjAcBgNVBAMMFWNhLmFuY2hvcmFnZS5pbnRlcm5hbDAqMAUGAytlcAMhADTh1nctgIHtAKNW8ww/bY606pJ3OP2dyZYcQrU2kG5jo1swWTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwICBDAUBgorBgEEAYaNHwEBBAYWBHJvb3QwIAYDVR0RBBkwF4IVY2EuYW5jaG9yYWdlLmludGVybmFsMAUGAytlcANBANkkdudEjH9RTKbRAxrRXyMSS/TgmdSrAVYOZzoRDJlyc+5oD+a0pmmwWVe86xZi37YbN1GzVlXcJAPpV6ceEQU=\n-----END CERTIFICATE-----\n```\n\n- Staging Environment:\n\n```\n-----BEGIN CERTIFICATE-----\nMIIBXDCCAQ6gAwIBAgITOfTQ4rYUsghgvdl8YCJSC67uGDAFBgMrZXAwIDEeMBwGA1UEAwwVY2EuYW5jaG9yYWdlLmludGVybmFsMB4XDTI2MDEyNDAwMDAwMFoXDTI3MDEyNDAwMDAwMFowIDEeMBwGA1UEAwwVY2EuYW5jaG9yYWdlLmludGVybmFsMCowBQYDK2VwAyEAPlBo2/+kPPL0WRpT+B/yHsU25AN/M6HP2bzC61yHb4ajWzBZMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgIEMBQGCisGAQQBho0fAQEEBhYEcm9vdDAgBgNVHREEGTAXghVjYS5hbmNob3JhZ2UuaW50ZXJuYWwwBQYDK2VwA0EAYsJxVI9n42liCF9f+Ou7uuC1QGFwaHwFsfOm0WFofSlE1trWqzj4ruzjPYSRJc8Ht2A7XCAfXkG0mzKpL/wQDg==\n-----END CERTIFICATE-----\n```\n\n### Sample V2 validation code:\n\n```go\npackage main\n\nimport (\n\t\"crypto/ed25519\"\n\t\"crypto/x509\"\n\t\"encoding/hex\"\n\t\"encoding/json\"\n\t\"encoding/pem\"\n\t\"fmt\"\n\t\"time\"\n)\n\n// V2SignedPayload represents the JSON structure in the addressSignaturePayload for V2 signatures\ntype V2SignedPayload struct {\n\tTextAddress string `json:\"TextAddress\"`\n\tVaultId string `json:\"VaultId\"`\n\tNetworkId string `json:\"NetworkId\"`\n\tNetworkName string `json:\"NetworkName\"`\n\tSignatureExpiresAt int64 `json:\"SignatureExpiresAt\"` // Unix timestamp\n}\n\n// verifyV2AddressSignature verifies a V2 address signature.\n//\n// Parameters:\n// - now: The \"current\" time. Note that conforming implementations must use\n// a trusted source for the current time.\n// - address: The address string from the API response\n// - addressSignaturePayload: Hex-encoded bytes that were signed\n// - signature: Hex-encoded signature\n// - certChainPEM: PEM-encoded certificate chain (leaf first, then intermediates)\n// - rootCAPEM: PEM-encoded Root CA certificate (hard-coded by client)\n// - expectedVaultId: Your Vault ID to verify against the signed VaultId\n// - expectedNetworkId: Expected network ID for this address (e.g., \"BTC\", \"ETH\")\n//\n// Returns an error if verification fails.\nfunc verifyV2AddressSignature(\n\tnow time.Time,\n\taddress, addressSignaturePayload, signature, certChainPEM, rootCAPEM, expectedVaultId, expectedNetworkId string,\n) error {\n\t// Step 1: Verify the certificate chain\n\n\t// Parse the certificate chain from PEM\n\tcerts, err := parsePEMCertificates([]byte(certChainPEM))\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to parse certificate chain: %w\", err)\n\t}\n\n\tif len(certs) == 0 {\n\t\treturn fmt.Errorf(\"certificate chain is empty\")\n\t}\n\n\tleafCert := certs[0]\n\tvar intermediateCerts []*x509.Certificate\n\tif len(certs) > 1 {\n\t\tintermediateCerts = certs[1:]\n\t}\n\n\t// Parse the Root CA\n\trootCACerts, err := parsePEMCertificates([]byte(rootCAPEM))\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to parse Root CA: %w\", err)\n\t}\n\tif len(rootCACerts) != 1 {\n\t\treturn fmt.Errorf(\"expected exactly one Root CA certificate, got %d\", len(rootCACerts))\n\t}\n\trootCA := rootCACerts[0]\n\n\t// Verify the leaf certificate's KeyUsage includes both\n\t// digitalSignature and nonRepudiation (AKA contentCommitment)\n\tif leafCert.KeyUsage&x509.KeyUsageDigitalSignature == 0 {\n\t\treturn fmt.Errorf(\"leaf certificate KeyUsage missing DigitalSignature\")\n\t}\n\tif leafCert.KeyUsage&x509.KeyUsageContentCommitment == 0 {\n\t\treturn fmt.Errorf(\"leaf certificate KeyUsage missing NonRepudiation (ContentCommitment)\")\n\t}\n\n\t// Verify the certificate chain from leaf to Root CA\n\troots := x509.NewCertPool()\n\troots.AddCert(rootCA)\n\n\tintermediates := x509.NewCertPool()\n\tfor _, cert := range intermediateCerts {\n\t\tintermediates.AddCert(cert)\n\t}\n\n\t// NOTE: Not all x509 libraries are created equal and are not\n\t// guaranteed to verify exactly the same things!\n\t//\n\t// Always review the library you plan to use and ensure it covers the\n\t// checks described in the User Guide!\n\t//\n\t// For example, the Go implementation checks all Certificates for\n\t// temporal validity (notBefore and notAfter against CurrentTime), for\n\t// valid signatures up the chain, and checks that the Subject\n\t// Alternative Names include the values in DNSNames below.\n\t//\n\t// However it does not check the KeyUsage bits, hence the additional\n\t// checks above.\n\topts := x509.VerifyOptions{\n\t\tDNSNames: []string{\"address-provider.anchorage.internal\"},\n\t\tRoots: roots,\n\t\tIntermediates: intermediates,\n\t\tCurrentTime: now,\n\t\t// NOTE: This allows for any Extended Key Usage, but does not\n\t\t// check the Key Usage bits, hence the additional checks above.\n\t\tKeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageAny},\n\t}\n\tif _, err := leafCert.Verify(opts); err != nil {\n\t\treturn fmt.Errorf(\"certificate chain verification failed: %w\", err)\n\t}\n\n\t// Extract the public key from the leaf certificate\n\tleafPublicKey, ok := leafCert.PublicKey.(ed25519.PublicKey)\n\tif !ok {\n\t\treturn fmt.Errorf(\"leaf certificate does not use Ed25519 (got type %T)\", leafCert.PublicKey)\n\t}\n\n\t// Step 2: Verify the signature\n\n\t// Decode the addressSignaturePayload from hex to bytes\n\tpayloadBytes, err := hex.DecodeString(addressSignaturePayload)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to decode addressSignaturePayload: %w\", err)\n\t}\n\n\t// Decode the signature from hex to bytes\n\tsignatureBytes, err := hex.DecodeString(signature)\n\tif err != nil {\n\t\treturn fmt.Errorf(\"failed to decode signature: %w\", err)\n\t}\n\n\t// Verify the signature using the leaf certificate's public key\n\tif !ed25519.Verify(leafPublicKey, payloadBytes, signatureBytes) {\n\t\treturn fmt.Errorf(\"signature verification failed\")\n\t}\n\n\t// Step 3: Verify the signed details\n\n\t// Parse the payload bytes as JSON\n\tvar signedPayload V2SignedPayload\n\tif err := json.Unmarshal(payloadBytes, &signedPayload); err != nil {\n\t\treturn fmt.Errorf(\"failed to parse signed payload: %w\", err)\n\t}\n\n\t// Verify SignatureExpiresAt is not in the past\n\tif now.Unix() > signedPayload.SignatureExpiresAt {\n\t\texpiryTime := time.Unix(signedPayload.SignatureExpiresAt, 0)\n\t\treturn fmt.Errorf(\"signature has expired at %s\", expiryTime)\n\t}\n\n\t// Verify TextAddress matches\n\tif signedPayload.TextAddress != address {\n\t\treturn fmt.Errorf(\"signed TextAddress does not match: signed=%q, expected=%q\",\n\t\t\tsignedPayload.TextAddress, address)\n\t}\n\n\t// Verify VaultId matches\n\tif signedPayload.VaultId != expectedVaultId {\n\t\treturn fmt.Errorf(\"signed VaultId does not match: signed=%q, expected=%q\",\n\t\t\tsignedPayload.VaultId, expectedVaultId)\n\t}\n\n\t// Verify NetworkId matches\n\tif signedPayload.NetworkId != expectedNetworkId {\n\t\treturn fmt.Errorf(\"signed NetworkId does not match: signed=%q, expected=%q\",\n\t\t\tsignedPayload.NetworkId, expectedNetworkId)\n\t}\n\n\treturn nil\n}\n\n// parsePEMCertificates parses PEM-encoded certificates and returns them as a slice\nfunc parsePEMCertificates(pemData []byte) ([]*x509.Certificate, error) {\n\tvar certs []*x509.Certificate\n\n\tfor {\n\t\tblock, rest := pem.Decode(pemData)\n\t\tif block == nil {\n\t\t\tbreak\n\t\t}\n\n\t\tif block.Type != \"CERTIFICATE\" {\n\t\t\tpemData = rest\n\t\t\tcontinue\n\t\t}\n\n\t\tcert, err := x509.ParseCertificate(block.Bytes)\n\t\tif err != nil {\n\t\t\treturn nil, fmt.Errorf(\"failed to parse certificate: %w\", err)\n\t\t}\n\n\t\tcerts = append(certs, cert)\n\t\tpemData = rest\n\t}\n\n\treturn certs, nil\n}\n\nfunc main() {\n\t// Sample API response data\n\taddress := \"bcrt1q709skemgf5skpsnysvgme2s3ztehkutl390yl0wp29lnmum5uw7qg0qrwm\"\n\taddressSignaturePayload := \"7b225661756c744964223a226461653630383965376330383336373035663035363261663066316534653166222c225465787441646472657373223a22626372743171373039736b656d676635736b70736e797376676d653273337a7465686b75746c333930796c30777032396c6e6d756d357577377167307172776d222c224e6574776f726b4e616d65223a22426974636f696e205265676e6574222c224e6574776f726b4964223a224254435f52222c225369676e6174757265457870697265734174223a313736393435303731337d\"\n\tsignature := \"951eb2fb560e660aa9c3d1ccd120d3ad1a19d90d8747347057e48bf174330eb386089e3232d822fd66b8183cce8059c91183afde299b920a0e0c05c5b167360e\"\n\tcertChainPEM := `-----BEGIN CERTIFICATE-----\nMIIBYTCCAROgAwIBAgIUMLKt+K9eFku+P7BbefE1xAHg0hcwBQYDK2VwMAAwHhcNMjYwMTI2MTcwNDEzWhcNMjcwMTI2MTcwNTEzWjAuMSwwKgYDVQQDEyNhZGRyZXNzLXByb3ZpZGVyLmFuY2hvcmFnZS5pbnRlcm5hbDAqMAUGAytlcAMhAPsgM70aWFYsZaLHawtYJpl42BkiTLyCq96+OXe4FxrVo3EwbzAOBgNVHQ8BAf8EBAMCBsAwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBS0usSFeB2gjC+wcowtxN3MeKSH7zAuBgNVHREEJzAlgiNhZGRyZXNzLXByb3ZpZGVyLmFuY2hvcmFnZS5pbnRlcm5hbDAFBgMrZXADQQCXmvIkuPnUgCHxWmFmzvgWdv9lUlt84oZCel+OeJW9n8PR88tGxAcD1E3+KDBXVpO0GcRA0W9+xqqICAo2ROEJ\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIBKDCB26ADAgECAhRGsD05KldIse+uIEa976AijTqlxjAFBgMrZXAwADAeFw0yNjAxMjYxNzA0MTNaFw0yNzAxMjYxNzA1MTNaMAAwKjAFBgMrZXADIQCNpyY5Sr21FHNvvLkBKG8AEMKdhqtajmV5d2QaZlmtAqNnMGUwDgYDVR0PAQH/BAQDAgIEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFLS6xIV4HaCML7ByjC3E3cx4pIfvMCAGA1UdEQEB/wQWMBSCEmFuY2hvcmFnZS5pbnRlcm5hbDAFBgMrZXADQQCIgw6kLMIwhd3ACjG03cJ5z/ZZp8aXXycFq2ZC9TLhieJ3rncyMH6ZdyJ3Ai1eVaHs4vnDCv54Vdh83vvSky4K\n-----END CERTIFICATE-----\n`\n\n\t// NOTE: This is a FAKE Root CA used just for this example.\n\t// NOTE: Conforming client implementations should hard-code the real\n\t// Anchorage Digital Address Signing Root CA for the environment they\n\t// are making requests to.\n\trootCAPEM := `-----BEGIN CERTIFICATE-----\nMIIBGzCBzqADAgECAhQ2qQwArneTuF0dbNDs8i/ExuyW2DAFBgMrZXAwADAeFw0yNjAxMjYxNzA0MTNaFw0yNzAxMjYxNzA1MTNaMAAwKjAFBgMrZXADIQB+gEnytXKnuAMonIWGWnB0qyTqa0aw3l9u5VRbu86UgaNaMFgwDgYDVR0PAQH/BAQDAgIEMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFOj64tL1teJHkojsiblnnK34Tw+EMBYGA1UdEQEB/wQMMAqCCGludGVybmFsMAUGAytlcANBAAg2IcVEXmWKSivhUNSatNfMmASxi83QscIuyP/sIW2sRIuCqQJoo9lN6TaxzyV62cQMzthFOCZcgRE+k0JV7Ao=\n-----END CERTIFICATE-----\n`\n\n\t// Your Vault ID - obtained from your application context\n\texpectedVaultId := \"dae6089e7c0836705f0562af0f1e4e1f\"\n\n\t// Expected network ID for this address\n\texpectedNetworkId := \"BTC_R\"\n\n\t// Implementations should use the actual current time\n\t// now := time.Now()\n\tnow := time.Unix(1769450600, 0) // Fake time so that this example passes.\n\n\t// Verify the signature\n\tif err := verifyV2AddressSignature(\n\t\tnow,\n\t\taddress,\n\t\taddressSignaturePayload,\n\t\tsignature,\n\t\tcertChainPEM,\n\t\trootCAPEM,\n\t\texpectedVaultId,\n\t\texpectedNetworkId,\n\t); err != nil {\n\t\tfmt.Printf(\"✗ V2 Address signature verification failed: %v\\n\", err)\n\t\treturn\n\t}\n\n\tfmt.Println(\"✓ V2 Address signature verified successfully!\")\n\tfmt.Printf(\" Address: %s\\n\", address)\n\tfmt.Printf(\" Vault ID: %s\\n\", expectedVaultId)\n\tfmt.Printf(\" Network: %s\\n\", expectedNetworkId)\n\tfmt.Println(\"\\nYou may now safely use this address for deposits.\")\n}\n```\n" name: Addresses - description: > Deposit Attribution is the process of gathering information about the originator of a given deposit. Once a deposit is initiated this process is automatically started being represented by a Deposit Attribution entity in `PENDING` status, so a deposit transaction has always an associated Deposit Attribution process and funds are not available until an attribution is performed. Once a deposit is confirmed on-chain, Anchorage Digital automatically initiates a new Deposit Attribution with a `PENDING` status. While in the `PENDING` status, funds are not available for movement or use for other purposes until the attribution process is complete. The attribution data is reviewed by Anchorage Digital, represented by the `UNDER_REVIEW` status. Upon successful completion of the review, the attribution status changes to `ATTRIBUTED`, making the funds available. If the review is unsuccessful, the status changes to `BLOCKED`. We do our best to automatically attribute deposits on behalf of our users, assuming the attribution for the specific address is known, but for those deposits where this is not possible, we enable the user to do so programmatically or via our Web Dashboard. Overall, these endpoints provide users with the capability to view, manage, and complete the deposit attribution process programmatically. name: Deposit Attribution - description: > An Anchorage Digital organization has one or more vaults. Each vault may contain one or more assets which are held in wallets. Each wallet may be comprised of one or more addresses depending on the type of the asset, i.e. UTXO-based assets and account-based assets. ### Balances Each asset in a vault has an `availableBalance` and a `totalBalance`. The `availableBalance` is the balance that is available to be withdrawn, held, or transferred. The `totalBalance` may contain funds that are held, in-progress, or locked for activities like voting. #### Vault IDs Each vault has an ID that is uniquely identifiable across the Anchorage Digital platform and can be used to reference this vault using the Anchorage Digital API. The vault ID is available as the `vaultId` field in the API response, or in the Vaults tab of the Anchorage Digital Web Dashboard. #### Allow API Access to a Vault By default, an Anchorage Digital vault does not allow API access. To allow programmatic management of addresses and transfers or read access to balances and transactions, create a [permission group](#section/Authentication-and-Security/Permission-Groups) with the desired permissions (read, transfer, etc.) for that vault. Any API key that is associated with this permission group will have API access to that vault. name: Vaults - description: > A vault has one or more wallets. Each wallet is a collection of one or more addresses depending on the asset type. A wallet is created for a particular blockchain network, e.g. Bitcoin, Ethereum, etc. ### Balances Depending on the blockchain network of the wallet, a wallet may hold one or more asset types. An asset in a wallet has an `availableBalance` and a `totalBalance`. The `availableBalance` is the balance that is available to be withdrawn, held, or transferred. The `totalBalance` may contain funds that are held, in-progress, or locked for activities like voting. ### Addresses A wallet is a collection of one or more addresses depending on the asset type. The `depositAddress` contains the last address to be provisioned to that wallet. For UTXO-based assets this address could change as new deposit addresses are provisioned. For account-based assets, this address will not change as only one address may be provisioned per wallet. To see all addresses for an asset, use the [Addresses endpoint](#tag/Addresses). ### Default Wallets Each asset type within a vault has a default wallet that is used for a particular asset when only the vault is specified. For example, a transfer between two vaults will take the asset from the default wallet for that asset in the sending vault and send it to the default wallet for that asset in the destination vault. Each wallet has a `isDefault` flag that indicates whether it is the default wallet. ### Maximum Allowed Wallets and Creation Constraints We have a constraint of 10,000 wallets per asset and defined a creation limit of 10 wallets per asset per 30 minutes interval. Theses contraints are imposed at the organization level. name: Wallets - description: > Transactions include all of the blockchain actions that affect your vault balances, such as withdrawals, deposits, transfers, and participation actions. Each transaction may have a corresponding blockchain transaction. Only transactions that are final will be returned. This includes all successful transactions as well as unsuccessful transactions where a blockchain fee was paid. Deposits, once confirmed on-chain, are subject to collection of originator data. Check the [Deposit Attribution](#tag/Deposit-Attribution) section for details. name: Transactions - description: >- These endpoints allow you to transfer assets from one of your API-enabled vaults to *another resource custodied by Anchorage Digital*. name: Transfers - description: > API endpoints for managing RFQ, Market or Limit orders [Anchorage Digital websocket API documentation.](https://anchorage-wsapi.netlify.app/) name: Trading - description: > Holds can be placed by an authorized partner on client assets to prevent withdrawal of those funds while they are being used for other purposes, such as trading. Holds are placed on a per-asset basis and may hold up to the entire balance of an asset. A hold may be indefinite or it may have an expiration date. Assets that are on hold cannot be withdrawn from their vault by the client. Holds may only be modified by the creator of the hold. For example, if a vault contains 200 BTC and an authorized partner places a hold on 50 BTC, the client's available balance becomes 150 BTC until the hold is executed or released. Additional holds could be placed on the remaining 150 BTC with different expiration dates. #### Execution A hold can be canceled or executed by the creator of the hold. If a hold is canceled or expires, the previously held funds will now be available to withdraw by the client. Executing a hold involves capturing some or all of the held funds and transferring them to the partner's Anchorage Digital vault. If a hold is partially executed, the remaining funds may either be released or continue to be held. Note that the amount withheld does not cover any network transaction fees required for transfers. #### Authorization A client can authorize a partner to place holds on their assets by creating an API key with hold and transfer permissions on specific vaults. The partner may generate and provide a public key at the time of key creation so that their private signing key remains secure. *NOTE: These endpoints are under active development and are subject to change.* name: Holds - description: > These endpoints allow clients/partner institutions to start the customer onboarding process for a B2B2B/B2B2C end customer who would not be using the Anchorage Digital applications directly. They collect the required data and documentation for Anchorage Digital to satisfy its regulatory obligations to perform KYB/KYC, CIP, CDD and EDD on its customers and related parties. Currently only B2B2B/B2B2C customer onboarding is supported. ### Payload Data The "customer" endpoints take a payload of `entries` in an array of key/value pairs. Details on the required and support key/value pairs is available in documentation provided by Anchorage Digital. Please contact your Customer Experience representative for details. Note that some of the keys are conditional depending on the presence or value of other key/value pairs. For example, the key `legalStructureOther` is only required if the `legalStructure` key has the Enum value `OTHER`. Also note that every `value` field accepts primitives, objects and collections, which makes the payload very flexible for the client's needs. For example, both of the following `entries` are accepted and interchangeable: ```json { "entries":[ { "key":"boolField", "value":true }, { "key":"numberField", "value":10 }, { "key":"stringField", "value":"stringFieldValue" }, { "key":"collectionField", "value":[ "collectionField0Value", "collectionField1Value" ] }, { "key":"objectField", "value":{ "field0":"field0Value", "field1":"field1Value", "field2":"field2Value" } }, { "key":"objectCollectionField", "value":[ { "field0":"field0AValue", "field1":"field1AValue", "field2":"field2AValue" }, { "field0":"field0BValue", "field1":"field1BValue", "field2":"field2BValue" } ] } ] } ``` ```json { "entries":[ { "key":"boolField", "value":true }, { "key":"numberField", "value":10 }, { "key":"stringField", "value":"stringFieldValue" }, { "key":"collectionField.0", "value":"collectionField0Value" }, { "key":"collectionField.1", "value":"collectionField1Value" }, { "key":"objectField.field0", "value":"field0Value" }, { "key":"objectField.field1", "value":"field1Value" }, { "key":"objectField.field2", "value":"field2Value" }, { "key":"objectCollectionField.0.field0", "value":"field0AValue" }, { "key":"objectCollectionField.0.field1", "value":"field1AValue" }, { "key":"objectCollectionField.0.field2", "value":"field2AValue" }, { "key":"objectCollectionField.1.field0", "value":"field0BValue" }, { "key":"objectCollectionField.1.field1", "value":"field1BValue" }, { "key":"objectCollectionField.1.field2", "value":"field2BValue" } ] } ``` name: Onboarding - description: > These endpoints allow creating, applying, removing, and searching tags on operations. name: Tagging - description: | These endpoints allow the organization to manage subaccounts. name: Subaccounts - description: > These endpoints allow access to vesting balance information for allocations. name: Vesting - description: | These endpoints allow the organization to manage tax. ** UNDER DEVELOPMENT ** name: Tax - description: '' name: Collateral Management - description: '' name: Atlas Settlement Network - description: '' name: Webhook Notifications - description: '' name: Statements - description: '' name: Trusted Destinations - description: >- Endpoints for stablecoin conversion operations including issuance and redemption name: Stablecoins - description: Operations for managing tax accounts and cost basis reporting name: Tax Reporting - description: > name: Transfer Model - description: > name: Transaction Model - description: > name: Vault Model - description: > A Deposit Attribution represents the current state of the deposit attribution process. name: Deposit Attribution Model paths: /trading/trades: get: tags: - Trading summary: List trades description: >- Permissions required: **Execute trades** or **Read trade activity** List all trades. With the permission **Read trade activity** all trades of the organization may be read. With the permission **Execute trades** only the trades created by this API key may be read. Trades are sorted in a descending order by their timestamp, i.e. the most recent trade or the trade with a timestamp closest to `endDate` is listed first. #### Filters You may optionally supply the following filters: - Specify a `tradingPair` to filter by the trading pair of the trade, for example `BTC-USD`. - Specify one or multiple `status` to filter trades. Multiple statuses should be separated by commas. - Specify a `side` to filter by the side of the trade. operationId: getTrades parameters: - name: startDate in: query description: >- The start date of the trades (inclusive) in `YYYY-MM-DD` format. The earliest valid start date is `2017-01-01`. The last valid start date is the current date. A `startDate` of '2021-01-10' is equivalent to a `startDateTime` of '2021-01-10.00:00:00.000000000'. Dates are always in UTC [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) 'full-date'. schema: type: string format: date - name: endDate in: query description: >- The end date of the trades (exclusive) in `YYYY-MM-DD` format. The latest valid end date is the current date. If not provided, defaults to the most recently closed day. An `endDate` of '2021-01-10' is equivalent to an `endDateTime` of '2021-01-10.00:00:00.000000000'. Dates are always in UTC [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) 'full-date'. schema: type: string format: date - name: startDateTime in: query description: >- The start date-time of the trades (exclusive) in `YYYY-MM-DDTHH:MM:SS.nnnnnnnnn` format. The earliest valid start date-time is '2017-01-01T00:00:00.000000000'. The last valid start date-time is the current date-time. `startDateTime` will be used if both `startDate` and `startDateTime` are specified. Date-times are always in UTC [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) 'date-time'. schema: type: string format: date-time - name: endDateTime in: query description: >- The end date-time of the trades (exclusive) in `YYYY-MM-DDTHH:MM:SS.nnnnnnnnn` format. The latest valid end date-time is the current date-time. The earliest valid end date-time is '2017-01-01T00:00:00.000000000'. `endDateTime` will be used if both `endDate` and `endDateTime` are specified. Date-times are always in UTC [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) 'date-time'. schema: type: string format: date-time - name: status in: query description: >- One or more statuses to filter trades. If provided, only trades matching these statuses will be returned. schema: type: array items: type: string enum: - PENDING - REJECTED - CANCELED - EXECUTED - SETTLING - SETTLED uniqueItems: true explode: false style: form - name: side in: query description: >- Filter by the side of a trade. If provided, only trades matching this side will be returned. schema: type: string enum: - BUY - SELL - name: tradingPair in: query description: >- Filter by the trading pair of a trade. If provided, only trades matching this pair of assets will be returned. schema: type: string - name: accountId in: query description: >- Filter by the trading account ID of a trade. If provided, only trades linked to this account ID will be returned. schema: type: string - name: subaccountId in: query description: >- Filter by the trading account ID of a trade. If provided, only trades linked to this account ID will be returned. schema: type: string - name: orderId in: query description: >- Filter by the order ID of a trade. The orderId is the anchorage orderId on execution report. If provided, only trades of the specified order will be returned. schema: type: string - name: vaultId in: query description: >- Filter by the vault ID of a trade. If provided, only trades linked to this vault ID will be returned. schema: type: string - name: tradeIds in: query description: >- A list of `tradeIds` to return. Invalid `tradeIds` will be ignored. A maximum number of unique 500 trade ids are enforced per call. schema: type: array items: type: string maxItems: 500 minItems: 1 uniqueItems: true explode: false style: form - name: limit in: query description: Maximum number of results to return per query schema: type: integer format: int64 default: 100 maximum: 2000 minimum: 1 responses: '200': description: A list of Trades and their metadata content: application/json: examples: response: value: data: - quantitySold: '1' currencySold: USD currencyBought: BTC price: '11681.67' quantityBought: '0.00008561' side: BUY timestamp: '2020-08-31T22:15:31.99999Z' tradeID: e0538774-ebd9-11ea-adc1-0242ac120002 quoteID: 06f71d1e-e7e8-11ea-adc1-0242ac120011 vault: vaultID: 1c920f4241b78a1d483a29f3c24b6c4c tradeStatus: EXECUTED tradingPair: BTC-USD fee: '0.01' feeCurrency: USD - quantitySold: '1' currencySold: USD currencyBought: ETH price: '435.16' quantityBought: '0.00230049' side: BUY timestamp: '2020-08-31T22:14:07.99999Z' tradeID: d1ae1416-ebd7-11ea-adc1-0242ac120002 quoteID: 06f71d1e-e7e8-11ea-adc1-0242ac120002 vault: vaultID: 1c920f4241b78a1d483a29f3c24b6c4c tradeStatus: EXECUTED tradingPair: ETH-USD fee: '0.01' feeCurrency: USD page: next: /v2/trading/trades?endDate=2020-08-31T22:14:07Z&limit=2 schema: $ref: '#/components/schemas/TradesResponse' '400': description: Bad Request content: application/json: schema: $ref: '#/components/schemas/ErrorDetails' '401': description: Unauthenticated content: application/json: schema: $ref: '#/components/schemas/ErrorDetails' '403': description: Forbidden content: application/json: schema: $ref: '#/components/schemas/ErrorDetails' '429': description: Too Many Requests content: application/json: schema: $ref: '#/components/schemas/ErrorDetails' '500': description: Internal Server Error content: application/json: schema: $ref: '#/components/schemas/ErrorDetails' components: schemas: TradesResponse: type: object properties: data: type: array items: $ref: '#/components/schemas/TradeDetails' page: $ref: '#/components/schemas/Page' required: - data - page title: TradesResponse ErrorDetails: type: object properties: errorType: $ref: '#/components/schemas/ErrorType' message: description: A human-readable message providing more details about the error. type: string example: Missing required field 'amount'. required: - errorType - message title: ErrorDetails TradeDetails: type: object properties: account: $ref: '#/components/schemas/TradeAccount' currencyBought: description: The bought currency. type: string currencySold: description: The sold currency. type: string fee: description: >- Amount of the trade fee. It is filled asynchronously and might take up to 2 minutes to become available. type: string feeCurrency: description: Currency of the trade fee. type: string orderId: description: Unique order ID for this trade. type: string price: description: > Price in counter currency for **one unit** of the base currency. For example, in the trading pair BTC-USD, this is the price in USD for one unit of BTC. It includes Anchorage Digital trade fees and represents the exchange rate at which the trade was executed. It is filled asynchronously and might take up to 2 minutes to become available. Once filled, the value will remain unchanged through all the other tradeStatus (`EXECUTED`, `SETTLING`, `SETTLED`, and `CANCELED`) type: string quantityBought: description: >- Quantity bought in units of currencyBought. It represents the quantity Anchorage Digital owes you. See "price" for details when this field is filled. type: string quantityBoughtToSettle: description: >- Rounded bought quantity that will considered at settlement. Filled out only in the context of a settlement. type: string x-omitempty: true quantitySold: description: >- Quantity sold in units of currencySold. It represents the quantity you owe Anchorage Digital. See "price" for details when this field is filled. type: string quantitySoldToSettle: description: >- Rounded sold quantity that will considered at settlement. Filled out only in the context of a settlement. type: string x-omitempty: true quoteID: description: Unique quote ID for this trade. type: string side: description: Side for the trade, either "BUY" or "SELL". type: string example: BUY enum: - BUY - SELL timestamp: description: >- The system timestamp when this trade was received, i.e. when the quote was accepted, as an ISO-8601 UTC string of the form 2019-02-13T05:17:32.000000Z. type: string tradeID: description: Unique ID for this trade. type: string tradeStatus: $ref: '#/components/schemas/TradeStatus' tradingPair: description: Pair of assets this trade is for. type: string vault: description: The vault into which this trade will be settled type: object properties: vaultID: description: An ID uniquely identifying the vault type: string example: 1c920f4241b78a1d483a29f3c24b6c4c title: Vault required: - timestamp - tradingPair - side - currencyBought - quantityBought - currencySold - quantitySold - tradeStatus - tradeID - quoteID title: TradeDetails Page: description: Pagination info type: object properties: next: description: >- URL to use to query for the next page or null if no additional results are available type: string example: nullable: true x-omitempty: false title: Page ErrorType: description: The type of error returned. type: string enum: - InternalError - InvalidRequest - Unauthenticated - Forbidden - NotFound - Conflict - UnprocessableEntity - TooManyRequests - ServiceUnavailable - QuoteExpired - InsufficientFunds - NotImplemented title: ErrorType TradeAccount: description: The account into which this trade will be settled type: object properties: accountId: description: An ID uniquely identifying the trading account type: string example: 6290d9bd-494f-11ed-975e-2e567b4c0e09 subaccountId: description: An ID uniquely identifying the subaccount where applicable type: string example: 5490d9bd-494f-11ed-975e-2e567b4c0e09 title: Account TradeStatus: description: > A string describing the status of the given trade * `PENDING` - The trade request has been placed and the trade is pending. * `EXECUTED` - This trade was executed and is waiting customer deposit. * `REJECTED` - This trade was rejected. * `CANCELED` - This trade was canceled by Anchorage Digital's trading team due to client legal/financial problems. * `SETTLING` - Anchorage Digital received the customer's deposit and the trade is in the process of settling. * `SETTLED` - Trade is settled and assets were sent to the customer. * `PENDINGALLOCATION` - Trade is executed and is awaiting client allocation. * `ALLOCATED` - Trade is fully allocated by the client. type: string enum: - PENDING - REJECTED - CANCELED - EXECUTED - SETTLING - SETTLED - PENDINGALLOCATION - ALLOCATED title: TradeStatus securitySchemes: Api-Access-Key: type: apiKey name: Api-Access-Key in: header description: An API key associated with a security role ````