Skip to main content

Wallet SDK v1 Migration Guide

Wallet SDK v1 is not backwards compatible with v0. Quick links
  • wallet-sdk-config - Detailed configuration guide
  • preparing-and-signing-transactions - Preparing and signing transactions
We have removed the configure() and connect() pattern in favor of passing in a static configuration or a provider with ledger api capabilities. Static configuration initialization where we supply an auth config and a ledgerClientUrl:
Provider intialization: The provider is an abstraction that ultimately interacts with the Ledger (JSON LAPI). This can be implemented for either a dApp consumer, direct ledger user, or alternative transport channels such as Wallet Connect.

Namespace changes

We have removed the controllers and replaced them with namespaces to appropriately segregate the service layer in terms of business context. When the sdk is initialized, it has access to the users, keys, ledger, and party namespaces. The amulet, token, asset, and events namespace can initialized with a separate config via .extend() method.

Removed functionality

The following methods have been removed: sdk.connect() No longer needed, SDK is connected on creation sdk.connectAdmin() No longer needed, admin operations are available in the ledger namespace and rights are extracted from the token. sdk.connectTopology() No longer needed, the grpc endpoints have been removed and replaced with ledger api endpoints. sdk.setPartyId() Pass partyId explicitly to each operation

In v0, the controllers and sdk were stateful. In v1, party information should be passed explicitly to each function. This enables acting as multiple parties and allows for thread safety in concurrent use.

Migration reference table

Migration reference table

Party Namespace

The party namespace provides methods to manage wallet parties on the Canton Network. In v1, the party namespace replaces the stateful party management from v0.

Availability

The party namespace is always available as part of the basic SDK interface. It’s initialized automatically when you create an SDK instance and doesn’t require additional configuration via extend().

Key changes from v0 to v1

v0 used a stateful approach where you set a party context once with sdk.setPartyId(). All subsequent operations acted on that party. v1 uses an explicit approach where you pass the party ID to each operation. This enables:
  • Thread-safe concurrent operations
  • Multi-party transactions within the same application
  • Clearer code intent

Refer to preparing-and-signing-transactions for more information.

Party types

Internal parties

The below example demonstrates the full usage of the feature: External parties An external party uses an external key pair for signing. You provide the public key, and the SDK generates the topology. You then sign the topology transaction with your private key and execute it on the ledger.

We recommend always providing a partyHint when creating a party. Refer to party-hint for more details.

Listing parties


This method returns all parties where the user has CanActAs, CanReadAs, or CanExecuteAs rights. If the user has admin rights, all local parties are returned.

Offline signing workflow


Migration reference

Party-related method migration

See also

  • wallet-sdk-config - SDK configuration
  • preparing-and-signing-transactions - Transaction lifecycle

Token Namespace

The token namespace provides methods to manage token operations including transfers, holdings, UTXOs, and allocations on the Canton Network. In v1, the token namespace replaces the tokenStandard controller from v0.

Availability and extensibility

The token namespace is an extended namespace that requires configuration. You can initialize it either during SDK creation or later using the extend() method. Option 1: Initialize during SDK creation
Option 2: Add token namespace later using extend()

Key changes from v0 to v1

v0 used the tokenStandard controller with implicit party context set via sdk.setPartyId(). v1 uses the token namespace where you:
  • Pass partyId explicitly to each operation
  • Initialize the namespace with configuration
  • Access operations through logical groupings (transfer, utxos, allocation)

This enables thread-safe concurrent operations and clearer code organization.

Transfers

Creating transfers

Accepting, rejecting, or withdrawing transfers

Listing pending transfers

Holdings

Holdings represent the transaction history of token ownership for a party.

You can also specify offsets for pagination:
Transactions by updateId:

UTXOs

UTXOs (Unspent Transaction Outputs) are the actual holding contracts that represent token balances. Listing UTXOs

You can specify additional parameters for pagination and limits:
Merging UTXOs Merging consolidates multiple small UTXOs into larger ones to improve performance.

The merge operation groups UTXOs by instrument and creates self-transfers to consolidate them. You can optionally provide specific UTXOs to merge:

Allocation

Allocations handle the issuance and distribution of new tokens. Listing pending allocations

The pending method accepts an optional interface ID to filter by allocation type:
Executing, withdrawing or cancelling allocations

Migration reference

Token-related method migration

See also

  • wallet-sdk-config - SDK configuration
  • preparing-and-signing-transactions - Transaction lifecycle

User Namespace

The user namespace provides methods for user management on the Canton Network.

Availability

The user namespace is always available as part of the basic SDK interface. It’s initialized automatically when you create an SDK instance and doesn’t require additional configuration via extend().

Key changes from v0 to v1

The distinction betwen the user ledger and admin ledger have been removed. Instead, the token is used to determine whether a user has admin rights. Creating users

Granting user rights

The below example demonstrates the full usage of the feature:

Migration reference

User namespace migration

See also

  • wallet-sdk-config - SDK configuration
  • user management - User management overview

Amulet Namespace

The amulet namespace is used for Canton coin specific operations.

Availability and extensibility

The amulet namespace is an extended namespace that requires configuration. You can initialize it either during SDK creation or later using the extend() method. Option 1: Initialize during SDK creation
Option 2: Add amulet namespace later using extend()

Configuration

The AmuletConfig type defines the configuration for the amulet namespace:
  • auth: Authentication configuration for accessing the validator and scan services
  • validatorUrl: URL of the validator service
  • scanApiUrl: URL of the scan API
  • registryUrl: URL of the amulet registry

Key changes from v0 to v1

v0 used the tokenStandard controller with implicit party context set via sdk.setPartyId() and the instrumentId and instrumentAdmin were passed in explicitly to each function. v1 uses the amulet namespace where you:
  • Pass partyId explicitly to each operation
  • Initialize the namespace with configuration, which determines the instrumentAdmin and instrumentId
  • Access operations through logical groupings (traffic and preapproval)
Creating preapprovals

The below example demonstrates the full process of renewing and cancelling preapprovals: Buy Member Traffic

Check Traffic Status

Refer to the following example for more information: Tap The is useful for testing against LocalNet or Devnet.

Migration reference

Amulet namespace migration

See also

  • wallet-sdk-config - SDK configuration
  • user management - User management overview

Ledger Namespace

The ledger namespace is used for preparing, signing, and executing transactions and other Ledger API operations.

Availability

The ledger namespace is always available as part of the basic SDK interface. It’s initialized automatically when you create an SDK instance and doesn’t require additional configuration via extend().

Key changes from v0 to v1

v0 used the userLedger or adminLedger controller with implicit party context set via sdk.setPartyId(). v1 uses the ledger namespace where you:
  • Pass partyId explicitly to each operation
  • Have an explicit lifecycle with prepare/sign/execute chain instead of a single method
  • Access operations through logical groupings (external, internal, dar, and acs)
Prepare, signing, and executing transactions Previously, a single method would handle everything.

Each step in lifecycle is clearer, workflowIds are generated automatically and there is better typesafety at each step. The below example demonstrates how offline signing works. Active Contract Set (ACS) queries

No need to manually enter get the ledger end for the offset and there is direct extraction of the activeContracts. However, we still have an acs.readRaw method for unfiltered results. DAR management

Migration reference

Ledger namespace migration

See also

  • wallet-sdk-config - SDK configuration
  • preparing-and-signing-transactions - Transaction lifecycle

Asset Namespace

The asset namespace provides methods to discover and find token assets from registries on the Canton Network. In v1, the asset namespace introduces a dedicated API for asset discovery and management.

Key changes from v0 to v1

v0 required accessing asset information through the token standard service or by manually querying registries. v1 introduces a dedicated asset namespace with a clean API for asset discovery. This enables:
  • Simplified asset discovery from multiple registries
  • Type-safe asset information retrieval
  • Centralized asset registry management
  • Built-in error handling for asset not found scenarios

Availability and extensibility

The asset namespace is an extended namespace that requires configuration. You can initialize it either during SDK creation or later using the extend() method. Option 1: Initialize during SDK creation
Option 2: Add asset namespace later using extend()

Configuration

The AssetConfig type defines the configuration for the asset namespace:
  • auth: Authentication configuration for accessing registries
  • registries: Array of registry URLs to fetch assets from
You can preview the example config here:

Listing assets

The asset namespace provides a list getter to retrieve all assets from configured registries.

Finding a specific asset

The find method allows you to search for a specific asset by ID, optionally filtering by registry URL.

Finding an asset with a specific registry

When multiple registries contain assets with the same ID, you can specify the registry URL to disambiguate:

Error handling

The asset namespace includes built-in error handling for common scenarios: Asset not found If an asset with the specified ID does not exist in any registry:
Multiple assets found If multiple assets with the same ID exist across different registries and no registry URL is provided:

Usage example

In the below example you can find the usage of the find method:

Migration reference

Asset-related method migration

See also

  • wallet-sdk-config - SDK configuration
  • token-migration-v1 - Token namespace migration