Skip to main content

Wallet SDK Configuration

If you have already played around with the wallet SDK you might have come across snippets like:
This is the default config that can be used in combination with a non-altered Localnet running instance. However as soon as you need to migrate your script, code and deployment to a different environment these default configurations are no longer viable to use. In those cases creating custom factories for each controller is needed. Here is a template that you can use when setting up your own custom connectivity configuration:

How do I validate my configurations?

Knowing if you are using the correct url and port can be daunting, here is a few curl and gcurl commands you can use to validate against an expected output my-json-ledger-api can be identified with curl http://${my-json-ledger-api}/v2/version it should produce a json that looks like
the fields may vary based on your configuration. my-validator-app-api can be identified with curl ${api}/version it should produce an output like
my-scan-proxy-api is an api inside the validator api and can be defined as ${my-validator-app-api}/v0/scan-proxy. my-registry-api is the registry for the token you want to use, for Canton Coin you can use my-scan-proxy-api, however for any other token standard token it is required to source the api from a reputable source.

Configuring auth

The wallet-sdk can either take in a Provider (which will have auth bundled into it) or a LedgerClientUrl + TokenProviderConfig. In our examples, we have provided a default TokenProviderConfig for connecting to localnet, which uses a self-signed token.
The value for some of the audiences in localnet would have to be adjusted to match “https://canton.network.global”. This is specifically the LEDGER_API_AUTH_AUDIENCE & VALIDATOR_AUTH_AUDIENCE. When upgrading your setup from a localnet setup to a production or client facing environment then it might make more sense to add proper authentication to the ledger api and other services. The community contributions include okta and keycloak OIDC. These can easily be configured for the SDK using a different TokenProviderConfig. The following programmatic methods of token fetching are supported:
  1. `static`: a fixed, in-memory token. Only used for compatibility, it will totally break for expired tokens.
  2. `self_signed`: only for development purposes, used for Canton setups that accept HMAC256 self signed tokens.
  3. `client_credentials`: used to programmatically acquire tokens via oauth2, a.k.a “machine-to-machine” tokens

Environment-specific endpoints

Each non-LocalNet environment requires different connection endpoints. Configure the following connection parameters:
  • JSON Ledger API URL — The HTTP/JSON API endpoint for your validator’s participant
  • gRPC Admin API URL — The gRPC endpoint for participant administration
  • Validator API URL — The validator app’s REST API endpoint
  • Scan API URL — The Scan service endpoint (either direct or via the BFT scan proxy)
  • Auth token — A valid JWT token from your OIDC provider
The SDK accepts authentication tokens through factory functions. For remote environments, create custom factories for each controller with the correct URLs and an AuthTokenProvider:
See the config template in the Wallet SDK repository for a complete example.