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

# Build on Walley

> Three ways to transact on the Canton Network through Walley; the TypeScript dApp SDK, the Python SDK, and the gRPC API.

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.

<CardGroup cols={3}>
  <Card title="TypeScript dApp SDK" icon="square-code" href="/build/overview">
    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.
  </Card>

  <Card title="Python SDK" icon="python" href="/python-sdk/overview">
    For servers and automation. Your process holds the Ed25519 key and prepares, signs, and submits transactions directly — no popup.
  </Card>

  <Card title="gRPC API" icon="network-wired" href="/grpc/overview">
    For advanced integrations. Build and sign interactive submissions yourself and submit them straight to Walley's fee-charging Ledger API endpoint.
  </Card>
</CardGroup>

## Which one?

| If your code…                              | Use                                    | The key lives                                |
| ------------------------------------------ | -------------------------------------- | -------------------------------------------- |
| runs in a user's browser                   | [TypeScript dApp SDK](/build/overview) | in the user's Walley wallet (popup approval) |
| runs on a server / bot                     | [Python SDK](/python-sdk/overview)     | in your process                              |
| speaks gRPC and signs its own transactions | [gRPC API](/grpc/overview)             | wherever you keep it                         |

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.