> ## Documentation Index
> Fetch the complete documentation index at: https://docs.walley.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# The gRPC API

> Submit signed interactive transactions straight to Walley's fee-charging Ledger API endpoint over gRPC.

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](https://docs.digitalasset.com/build/3.3/explanations/canton/interactive-submission.html), 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.

<Info>
  Most integrations should use the [Python SDK](/python-sdk/overview) or [TypeScript dApp SDK](/build/overview). 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.
</Info>

## What it's for

The endpoint proxies exactly one Ledger API service — `InteractiveSubmissionService` — and only its submission methods:

| Method                     | What Walley adds                                                               |
| -------------------------- | ------------------------------------------------------------------------------ |
| `PrepareSubmission`        | Quotes the traffic fee for the transaction                                     |
| `ExecuteSubmission`        | Reserves the fee, forwards the signed transaction, settles from the completion |
| `ExecuteSubmissionAndWait` | As above, blocking until the transaction commits                               |

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:

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](https://walley.cc) 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.

<Warning>
  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.
</Warning>

## 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.

| Network | Endpoint                   |
| ------- | -------------------------- |
| DevNet  | `ledger.dev.walley.cc:443` |

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.