Skip to main content
These are the methods that wallets should implement to handle Canton transactions and messages via WalletConnect.

Network / Chain Information

  • Namespace: canton
  • CAIP-2: canton:<network-id> (e.g. canton:devnet, canton:production)
  • CAIP-10 Account: canton:<network-id>:<url-encoded-party-id> (e.g. canton:devnet:operator%3A%3A1220abc...)
Unlike most chains, Canton does not have fixed mainnet/testnet identifiers. Network IDs are operator-defined — each wallet is configured with one or more networks, and the network-id used in CAIP-2 identifiers comes from that configuration. dApps should not hardcode specific chain IDs in the session proposal. Instead, request the canton namespace without specifying chains, and work with whatever network the wallet provides in the approved session. The network ID and party ID are available directly from the session’s canton.accounts array as CAIP-10 strings (e.g. canton:production:operator%3A%3A1220abc...). For full network details, use canton_getActiveNetwork.

Registered Methods & Events

Auto-Approve vs Manual-Approve

Read-only methods are auto-approved by the wallet. Methods that mutate the ledger or perform sensitive operations require explicit user approval.

Method Name Mapping (dApp SDK)

The dApp SDK’s WalletConnectTransport maps SDK method names before sending over WC: All other methods (canton_listAccounts, canton_status, canton_ledgerApi, etc.) are sent as-is. Both SDK methods resolve with the same response — over WalletConnect, every submission blocks until the transaction completes.

RPC Methods

canton_prepareSignExecute

Prepare, sign, and execute a Canton ledger transaction. This is the primary method for submitting commands that mutate ledger state. The wallet performs the full prepare → sign → execute cycle and responds when the transaction is complete.

Request

Example Request

Signing Providers

Wallets support multiple signing backends. The signing provider determines the Ledger API flow used:

Success Response

Error Response

User Rejected Response


canton_listAccounts

Retrieve all configured wallet accounts.

Request

Response

Wallet Type


canton_getPrimaryAccount

Retrieve the primary wallet account (where primary === true).

Request

Response


canton_getActiveNetwork

Retrieve the currently active network configuration.

Request

Response


canton_status

Check the wallet’s connectivity to the Canton ledger.

Request

Response (ledger reachable)

Response (ledger unreachable)


canton_ledgerApi

Proxy raw Canton Ledger API requests through the wallet. The wallet authenticates and forwards the request.

Request

Example Request

Response

The response field contains the raw Ledger API JSON response as-is.

canton_signMessage

Sign an arbitrary message with the wallet’s Ed25519 private key.

Request

Example Request

Success Response

Events

accountsChanged

Emitted when wallet accounts are added, removed, or modified.

statusChanged

Emitted when the wallet’s connectivity status changes.

chainChanged

Emitted when the wallet switches to a different network.

Session Lifecycle

Pairing

The dApp creates a pairing URI and delivers it to the wallet:

Session Approval

The wallet builds approved namespaces including the CAIP-10 account with the URL-encoded partyId:

Error Codes

Notes & Considerations

  • All requests and responses comply with JSON-RPC structure (id, jsonrpc, etc.).
  • Canton uses Ed25519 signing for transaction authentication.
  • The ledgerApi method acts as a transparent proxy — the wallet handles authentication with the Canton Ledger API. Only GET and POST are supported; other HTTP methods will return a 5001 error.
  • Party IDs in CAIP-10 accounts are URL-encoded (e.g. operator::1220abc... becomes operator%3A%3A1220abc...).
  • The canton_prepareSignExecute method always performs the full prepare → sign → execute cycle synchronously, responding only when the transaction is complete.
  • The WC session chainId (e.g. canton:devnet) may differ from the networkId in wallet/network records (e.g. canton:production). The chainId identifies the chain at pairing time, while networkId reflects the wallet’s internal network configuration.