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...)
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’sWalletConnectTransport 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 (whereprimary === 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
ledgerApimethod acts as a transparent proxy — the wallet handles authentication with the Canton Ledger API. OnlyGETandPOSTare supported; other HTTP methods will return a5001error. - Party IDs in CAIP-10 accounts are URL-encoded (e.g.
operator::1220abc...becomesoperator%3A%3A1220abc...). - The
canton_prepareSignExecutemethod 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 thenetworkIdin wallet/network records (e.g.canton:production). ThechainIdidentifies the chain at pairing time, whilenetworkIdreflects the wallet’s internal network configuration.