Skip to main content

Assets and Wallet Clients

This guide covers how to configure assets and wallet clients in the Anchor Platform.

Assets Configuration​

Assets define the tokens and currencies that your Anchor Platform supports for deposits and withdrawals. In the "Getting Started" guide, assets are configured in the config/assets.yaml file by the ap_start.sh.

For the complete list of fields and defaults, see the asset configuration reference.

Example Asset Configuration​

items:
  - id: stellar:native
    distribution_account: "G...DIST"
    significant_decimals: 7
    sep6:
      enabled: true
      deposit:
        enabled: true
        min_amount: 0
        max_amount: 10
        methods:
          - SEPA
          - SWIFT
      withdraw:
        enabled: true
        min_amount: 0
        max_amount: 10
        methods:
          - bank_account
          - cash
    sep24:
      enabled: true
    sep31:
      enabled: true
    sep38:
      enabled: true
      exchangeable_assets:
        - iso4217:USD

Field Explanations​

  • id (Required) - The asset identifier in the format SCHEMA:CODE:(ISSUER) or stellar:native representing XLM, the native Stellar asset. For example, stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 represents Circle USD. For fiat currencies, use iso4217:CODE (e.g., iso4217:USD, iso4217:CAD).

  • distribution_account - The Stellar account address that holds the asset for distribution. Not needed for fiat assets (iso4217).

  • significant_decimals - The number of decimal places the asset supports.

  • sep6 - Enables SEP-6 and configures deposit/withdraw limits and methods per asset.

  • sep24 - Enables SEP-24 interactive flows and their per-asset settings.

  • sep31 - Enables SEP-31 cross-border payment support for the asset.

  • sep38 - Enables SEP-38 quotes and exchangeable_assets for supported currency pairs.

Wallet Clients Configuration​

Wallet clients are the wallet apps that connect to your Anchor Platform to perform transactions on behalf of users.

For the full list of client fields and defaults, see the client configuration reference.

Example Client Configuration​

items:
  - name: "referenceCustodial"
    type: custodial
    signing_keys:
      - GDJLB...KLTG
    callback_urls:
      sep6: https://client.example.com/callbacks/sep6
      sep24: https://client.example.com/callbacks/sep24
      sep31: https://client.example.com/callbacks/sep31
      sep12: https://client.example.com/callbacks/sep12
  - name: "reference"
    type: noncustodial
    domains:
      - wallet-server:8092
      - client.example.com
    callback_urls:
    ...

Field Explanations​

Custodial Client Configuration:

  • name (Required) - A unique identifier for the client.

  • type: custodial (Required) - The type of the client. Must be set to custodial for custodial clients.

  • signing_keys (Required) - A list of Stellar public keys used for client SEP-10 authentication. The anchor uses these keys to verify that requests are coming from the authorized client.

  • callback_urls (Optional) - URLs to which the service can send callbacks for different SEP types.

    • sep6 - Callback URL for SEP-6 (deposit/withdrawal) transaction status updates
    • sep24 - Callback URL for SEP-24 (interactive deposit/withdrawal) transaction status updates
    • sep31 - Callback URL for SEP-31 (cross-border payments) transaction status updates
    • sep12 - Callback URL for SEP-12 (KYC) customer information updates

Noncustodial Client Configuration:

  • name (Required) - A unique identifier for the client, similar to custodial clients. Typically a name that clearly represents the client entity.

  • type: noncustodial (Required) - The type of the client. Must be set to noncustodial for noncustodial clients. Noncustodial clients allow users to control their own private keys, and the wallet acts as an interface to user-controlled accounts.

  • domains (Required) - A list of domains associated with the client, used to verify the client's identity.

  • callback_urls (Optional) - URLs to which the service can send callbacks for different SEP types. Works the same way as for custodial clients (see above).