Skip to main content
Walley gives your application three ways to transact on the Canton Network on a user’s behalf. Pick the one that fits where your code runs.

TypeScript dApp SDK

For browser dApps. The user’s Walley wallet holds the key; your dApp requests a connection and submits transactions through a popup the user approves.

Python SDK

For servers and automation. Your process holds the Ed25519 key and prepares, signs, and submits transactions directly — no popup.

gRPC API

For advanced integrations. Build and sign interactive submissions yourself and submit them straight to Walley’s fee-charging Ledger API endpoint.

​
Which one?

The two SDKs are convenience layers over the same interactive-submission flow: prepare a command batch, sign its hash, submit it. The gRPC API is that flow with nothing in between.

​
Network fees

Every path shares one fee model. Canton network traffic is charged in CC (Canton Coin) against a prepaid traffic balance: users buy traffic ahead of time and each transaction draws it down — there’s no per-transaction payment step. A single transaction can be fronted when the balance can’t cover its fee (the balance goes negative by that one transaction), after which transactions are refused until the balance is topped up. Where the fee surfaces differs by path:
  • dApp SDK — invisible to your integration; the user’s wallet balance covers it.
  • Python SDK — quoted on prepare, drawn from the balance you top up with client.traffic.purchase(...).
  • gRPC API — quoted at prepare, reserved at execute, and settled from the transaction’s completion.