> ## 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 Addresses

> Permissions required: **Read vault activity**

List all addresses across wallets in the organization.



## OpenAPI

````yaml /knowledge-base/openapi/v3.yaml get /addresses
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:



    <table>
      <tr>
        <td><b>Read vault activity (READ)</b></td>
        <td>See an overview of your vault(s) and wallets. Read vault details, balances, asset types, transaction history and deposit addresses.</td>
      </tr>
      <tr>
        <td><b>Create address (CREATE_DEPOSIT_ADDRESS)</b></td>
        <td>Receive deposits in the vault from external sources. Create and read deposit addresses.</td>
      </tr>
      <tr>
        <td><b>Transfer funds (TRANSFER)</b></td>
        <td>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.</td>
      </tr>
      <tr>
        <td><b>Propose and accept settlements (PROPOSE_ACCEPT_SETTLEMENTS)</b></td>
        <td>This is an Atlas specific permission for initiating settlements.</td>
      </tr>
      <tr>
        <td><b>Authorize settlements (AUTHORIZE_SETTLEMENTS)</b></td>
        <td>This is an Atlas specific permission for authorizing settlements after they've been proposed or accepted.</td>
      </tr>
    </table>



    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:



    <table>
      <tr>
        <td><b>Initiate withdrawals (INITIATE_WITHDRAWAL)</b></td>
        <td>Initiate withdrawals to external destinations. All withdrawals require quorum approval through the Anchorage Digital mobile app.</td>
      </tr>
      <tr>
        <td><b>Execute trades (TRADE)</b></td>
        <td>Request for quotes (RFQ) from the Anchorage Digital trading desk. Create and accept quotes. Read data of trades and settlements created by this key.</td>
      </tr>
      <tr>
        <td><b>Read trade activity (READ_TRADE)</b></td>
        <td>Read trade activity and trade settlements data of your organization.</td>
      </tr>
      <tr>
        <td><b>Read lending activity (LENDER_READ)</b></td>
        <td>Read lending activity of your organization.</td>
      </tr>
      <tr>
        <td><b>Read facility data (FACILITY_ONLY)</b></td>
        <td>Read lending facility data.</td>
      </tr>
      <tr>
        <td><b>Read deposit attribution activity (READ_DEPOSIT_ATTRIBUTION)</b></td>
        <td>Read deposit attribution activity of your organization.</td>
      </tr>
      <tr>
        <td><b>Manage deposit attributions (DEPOSIT_ATTRIBUTION)</b></td>
        <td>Read deposit attribution activity of your organization. Perform deposit attributions.</td>
      </tr>
      <tr>
        <td><b>Initiate Staking and Unstaking (STAKE)</b></td>
        <td>Initiate staking or unstaking operation. All operations require quorum approval through the Anchorage Digital mobile app.</td>
      </tr>
    </table>



    ### 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.


    <!-- ReDoc-Inject: <security-definitions> -->


    ### 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.



    <table>
      <tr>
        <td>Timestamp</td>
        <td>1577880000</td>
      </tr>
      <tr>
        <td>HTTP Method (Uppercase)</td>
        <td>POST</td>
      </tr>
      <tr>
        <td>HTTP Path + query</td>
        <td>/v2/transfers?foo=bar&baz=bang</td>
      </tr>
      <tr>
        <td>HTTP Body</td>
        <td>{"source": {"id": "1c920f4241b78a1d483a29f3c24b6c4c", "type": "VAULT"}, "assetType": "ETH", "destination": {"id": "55e89d4a644d736b01533a2ea9b32a20", "type": "VAULT"}, "amount": "1000.00000000"}</td>
      </tr>
      <tr>
        <td>Signing Key (Ed25519 Private Key Seed)</td>
        <td>0101010101010101010101010101010101010101010101010101010101010101</td>
      </tr>
      <tr>
        <td>Public Key</td>
        <td>8a88e3dd7409f195fd52db2d3cba5d72ca6709bf1d94121bf3748801b40f6f5c</td>
      </tr>
      <tr>
        <td>Signature</td>
        <td>4bf42054bf7db1f8a2a2bc83d2a108502ee7a9d2ac7a2738adc2f932922446786fb9be1bd1eb475023296c6cba4ddbe28b04baca4b7521b1f1840a4ffd2b4d0d</td>
      </tr>
    </table>


    ## 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.



    <table>
      <tr>
        <th style="width: 30%;">Response Code</th>
        <th>Description</th>
      <tr>
      <tr>
        <td>200 OK</td>
        <td>The request was successful.</td>
      </tr>
      <tr>
        <td>400 Bad Request</td>
        <td>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.</td>
      </tr>
      <tr>
        <td>401 Unauthorized</td>
        <td>The request was missing a valid API key.</td>
      </tr>
      <tr>
        <td>403 Forbidden</td>
        <td>The provided API key does not have permission to perform the requested action.</td>
      </tr>
      <tr>
        <td>404 Not Found</td>
        <td>The requested resource does not exist.</td>
      </tr>
      <tr>
        <td>409 Conflict</td>
        <td>The requested resource cannot proceed with the requested action because it is not in the required state.</td>
      </tr>
       <tr>
        <td>429 Too Many Requests</td>
        <td>Too many requests have been sent in a given amount of time.</td>
      </tr>
      <tr>
        <td>
          500 Internal Server Error
          <br />
          502 Bad Gateway
          <br />
          503 Service Unavailable
          <br />
          504 Gateway Timeout
        </td>
        <td>Something went wrong on Anchorage’s side. We have been alerted and are working on it.</td>
      </tr>
    </table>



    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.



    <SchemaDefinition schemaRef="#/components/schemas/ErrorDetails"
    showReadOnly={true} showWriteOnly={true} />



    # 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


    <table>
      <tr>
        <th style="width: 30%;">Parameter</th>
        <th>Description</th
      </tr>
      <tr>
        <td>afterId</td>
        <td>Request page after (older than) this pagination id.</td>
      </tr>
      <tr>
        <td>endDate</td>
        <td>Request records older than this date (YYYY-MM-DD format). Used for /trading/trades and /trading/settlements resources.</td>
      </tr>
      <tr>
        <td>limit</td>
        <td>Maximum number of results requested. Default usually 25, but varies depending on resource.</td>
      </tr>
    </table>


    ## 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/v3
security:
  - Api-Access-Key: []
tags:
  - description: >-
      Operations for querying supported asset types, networks, and wallet key
      compatibility
    name: Asset Types & Networks
  - description: Operations for creating and managing wallets
    name: Wallets
  - description: Operations for creating and managing blockchain addresses
    name: Addresses
  - description: >-
      Operations for creating and signing transactions that your organization
      broadcasts on-chain
    name: Wallet Operations
  - description: >-
      Query on-chain activity detected by Anchorage Digital, including deposits,
      confirmations, fees, and rewards
    name: Blockchain Events
  - description: Operations for querying wallet balances and staking positions
    name: Balances
  - description: >-
      Operations for creating transactions with managed fees and replay
      protection
    name: Transaction Creation
  - description: Operations for constructing and signing transactions via the Construct API
    name: Transaction Construction
  - description: ''
    name: Atlas Settlement Network
  - description: Anti-Money Laundering compliance endpoints
    name: AML
  - description: >-
      Endpoints for stablecoin conversion operations including issuance and
      redemption
    name: Stablecoins
  - description: Operations for managing fiat bank payments and accounts
    name: Fiat Banking Operations
paths:
  /addresses:
    get:
      tags:
        - Addresses
      summary: List Addresses
      description: |-
        Permissions required: **Read vault activity**

        List all addresses across wallets in the organization.
      operationId: listAddresses
      parameters:
        - name: after
          in: query
          description: >-
            When paginating this is used to provide the starting point for the
            page to fetch (retrieved from the previous response body)
          schema:
            type: string
        - name: address
          in: query
          description: Filter by specific blockchain address
          required: false
          schema:
            type: string
        - name: networkId
          in: query
          description: >-
            A unique string identifying a combination of blockchain and
            environment (testnet, mainnet).
          required: false
          schema:
            type: string
        - name: vaultId
          in: query
          description: Filter by vault ID
          required: false
          schema:
            type: string
        - name: walletId
          in: query
          description: Filter by wallet ID
          required: false
          schema:
            type: string
        - name: batchId
          in: query
          description: Filter by batch creation ID
          required: false
          schema:
            type: string
        - name: publicKey
          in: query
          description: Filter by public key string
          required: false
          schema:
            type: string
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ListAddressesResponse'
        '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:
    ListAddressesResponse:
      type: object
      properties:
        data:
          type: array
          items:
            $ref: '#/components/schemas/WalletAddress'
        page:
          $ref: '#/components/schemas/Page'
      required:
        - data
        - page
    ErrorDetails:
      type: object
      properties:
        message:
          description: A human-readable message providing more details about the error.
          type: string
          example: Missing required field 'amount'.
      required:
        - message
      title: ErrorDetails
    WalletAddress:
      description: >-
        A blockchain address in a wallet. Each address includes a cryptographic
        signature that proves the address was generated by Anchorage Digital for
        your organization.


        ## Signature Verification


        The signature allows you to verify that an address string is authentic
        before using it for sensitive operations (like withdrawals to that
        address).


        Check the `signatureVersion` field to determine which verification
        scheme applies. For complete verification steps, sample code, and Root
        CA values, see the Address verification guide docs.


        ### V1 Address Signatures


        The steps for verifying V1 address signatures are as follows:

        1. Check the validity of the signature
           - Decode the `signedJson` field from hex to bytes
           - Decode the `signature` field from hex to bytes
           - Using your organization's verification public key (provided by Anchorage Digital), verify that the signature bytes are a valid Ed25519 signature of the signedJson bytes
        2. Verify the address that was signed matches the one that will be used
           - Decode the `signedJson` field from hex to bytes
           - Parse the bytes as a JSON object (e.g., `{"TextAddress":"0x123..."}`)
           - Verify the address to be used matches the value of the `TextAddress` property from the JSON object

        **Important**: It is not sufficient to validate the signature without
        also validating that the address signed matches the address to be used.


        **Note**: The JSON object may contain additional properties in future
        versions. API clients must not use strict JSON parsers which disallow
        extra, unknown properties.


        **Verification Public Key**: Contact your Anchorage Digital
        representative to obtain the verification public key for your
        organization. This key is unique per organization and fixed for the
        lifetime of that organization.


        ### V2 Address Signatures


        Addresses with `signatureVersion` set to `V2` also include a `certChain`
        field containing an X.509 certificate chain in PEM format.


        The steps for verifying V2 address signatures are as follows:

        1. Verify the certificate chain:
           - Parse the `certChain` field as PEM-encoded X.509 certificates (leaf at index 0, then intermediates)
           - Verify the chain up to the hard-coded Anchorage Digital Address Signing Root CA (see Address verification guide docs)
           - Verify all certificates are valid at the current time (both notAfter and notBefore)
           - Verify the leaf certificate's Subject Alternative Names include `address-provider.anchorage.internal`
           - Verify the leaf certificate's KeyUsage includes both `digitalSignature` and `nonRepudiation` (also known as `contentCommitment`)
           - Extract the public key from the leaf certificate
        2. Verify the signature:
           - Decode the `signedJson` field from hex to bytes
           - Decode the `signature` field from hex to bytes
           - Using the public key from the leaf certificate, verify that `signature` is a valid signature of the `signedJson` bytes
        3. Verify the signed details:
           - Parse the `signedJson` bytes as JSON
           - Verify `SignatureExpiresAt` is greater than or equal to the current UTC Unix timestamp
           - Verify `TextAddress` matches the address to be used
           - Verify `VaultId` matches your expected Vault ID
           - Verify `NetworkId` matches the expected network for this address

        **Note**: API clients must not use strict JSON parsers which disallow
        unknown properties, as future versions may add new fields to the signed
        payload.


        **Note**: Anchorage Digital periodically refreshes V2 signatures and the
        certificate chain before expiration. The address itself does not change.
      type: object
      properties:
        address:
          description: >-
            A unique string identifying an account on a blockchain. This is
            sometimes dervied from a public key and sometimes decided by the
            blockchain.
          type: string
        certChain:
          description: >-
            PEM-encoded X.509 certificate chain used for V2 signature
            verification. The leaf certificate is at index 0, followed by zero
            or more intermediate certificates. The root CA is excluded and must
            be hard-coded by clients. Only present when `signatureVersion` is
            `V2`.
          type: string
        networkId:
          description: >-
            A unique string identifying a combination of blockchain and
            environment (testnet, mainnet).
          type: string
        publicKey:
          description: >-
            The public key that the blockchain address is derived from. Note:
            This is NOT the key used to verify the signature field - that
            requires a separate organization-wide verification public key
            provided by Anchorage Digital.
          type: string
        signature:
          description: >-
            Hex-encoded Ed25519 signature of the `signedJson` bytes. For V1
            signatures, verify against your organization's fixed public key. For
            V2 signatures, verify against the leaf certificate's public key from
            the `certChain` field.
          type: string
          example: >-
            1642000aa9cca8e8610981aefbdb204b361c9dca3fa067b88fdacfba7a0f620d721378a33f4bbadad3923e633a4d712646d1e8e314e9fcb4aa4102c0581f6503
        signatureVersion:
          description: >-
            Version of the address signature scheme used. Check this field to
            determine how to verify the `signature` field.
          allOf:
            - $ref: '#/components/schemas/WalletAddressSignatureVersion'
        signedJson:
          description: >-
            Hex-encoded bytes that were signed to produce the `signature`.
            Decode from hex to get the signed content. For V1 signatures, the
            content is a JSON object with a `TextAddress` field. For V2
            signatures, the content is a JSON object with `TextAddress`,
            `VaultId`, `NetworkId`, `NetworkName`, and `SignatureExpiresAt`
            fields.
          type: string
          example: 7b225465787441646472657373223a22307831323334227d
        walletId:
          description: The wallet ID containing this address.
          type: string
      required:
        - address
        - networkId
        - publicKey
        - signedJson
        - signature
        - walletId
        - signatureVersion
    Page:
      description: Pagination info
      type: object
      properties:
        endCursor:
          description: Submit this parameter in the "after" field to fetch the next page.
          type: string
          nullable: true
      title: Page
    WalletAddressSignatureVersion:
      description: >-
        Version of the address signature scheme used.


        * `V1` - The original scheme. Verify the `signature` against your
        organization's fixed Ed25519 public key (provided by Anchorage Digital
        out-of-band).

        * `V2` - The newer scheme. Verify the `signature` against the leaf
        certificate's public key from the `certChain` field, and verify the
        certificate chain against the Anchorage Digital Address Signing Root CA.
      type: string
      enum:
        - V1
        - V2
  securitySchemes:
    Api-Access-Key:
      type: apiKey
      name: Api-Access-Key
      in: header
      description: An API key associated with a security role

````

## Related topics

- [Deposit](/knowledge-base/platform/developers/move-money/deposit.md)
- [List all addresses for an asset](/knowledge-base/porto/api-reference/v2/addresses/list-all-addresses-for-an-asset.md)
- [List supported delegation addresses](/knowledge-base/porto/api-reference/v2/transactions/list-supported-delegation-addresses.md)