Skip to main content
The gRPC API is Walley’s thinnest integration surface: a fee-charging proxy that sits directly in front of the Canton participant’s Ledger API. If you already build and sign your own interactive submissions, you can point them at Walley’s gRPC endpoint instead of the participant and have the network fee metered automatically — no REST layer, no SDK.
Most integrations should use the Python SDK or TypeScript dApp SDK. Reach for raw gRPC only when you need to speak the Ledger API’s InteractiveSubmissionService directly — for example from a language without a Walley SDK, or from an existing Canton client you want to fee-meter.

​
What it’s for

The endpoint proxies exactly one Ledger API service — InteractiveSubmissionService — and only its submission methods: Every other Ledger API service — reads, command completion, party management, admin — returns UNIMPLEMENTED. The proxy is a write path only; use the participant’s own Ledger API (or the SDKs) for reads.

​
The flow

It’s the standard prepare-sign-execute loop, with Walley metering the fee around it:
1

Prepare

Send your Commands to PrepareSubmission. Walley forwards them to the participant, which returns the prepared transaction and the hash to sign. Walley computes the traffic fee for the transaction at this point.
2

Sign

Sign the participant-provided prepared_transaction_hash with your party’s Ed25519 key, exactly as you would against the participant directly. Walley never sees or holds your key.
3

Execute

Send the signed transaction to ExecuteSubmission (or ExecuteSubmissionAndWait). Walley reserves the quoted fee against your prepaid traffic balance, forwards the submission to the participant, and settles the fee from the transaction’s completion once it commits.

​
How fees work

The gRPC path draws on the same prepaid traffic balance as everything else at Walley — the one you top up on the dashboard or with the SDK. There is no separate billing.
  • Fees are charged in CC (Canton Coin) for the Canton network traffic your transaction consumes.
  • The fee is quoted at prepare and reserved at execute, then reconciled to the exact cost from the transaction’s completion stream.
  • A single transaction can be fronted when your balance can’t cover its fee: it goes through and the balance goes negative by that one transaction. While the balance is negative, further executes are refused with a gRPC RESOURCE_EXHAUSTED status until you top up.
  • Some transactions are fee-exempt (for example, buying traffic itself) and pass through without a charge.
You can only execute transactions you can sign for. The proxy forwards your signed payload as-is — it cannot author or sign commands on your behalf, so there is no Walley-signed submission path over gRPC.

​
Connecting

The endpoint speaks plain gRPC over HTTP/2 and carries the standard Ledger API protobuf service definitions, so any generated InteractiveSubmissionService client works against it. Authenticate the same way you authenticate to the participant’s Ledger API — the proxy passes your credentials through.

​
Latency

The fee bookkeeping is deliberately cheap: a couple of indexed balance checks and a reservation write around the submission. In a like-for-like benchmark — the same signed transfer submitted through the gRPC endpoint versus straight to the participant’s Ledger API — the fee path added about 11 ms (~3%) to end-to-end submission latency. The Canton ledger commit (~330 ms) dominates the total and is identical on both paths, so the metering is a rounding error on top of the transaction itself.