> For the complete documentation index, see [llms.txt](https://help.enterprise.ledger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.enterprise.ledger.com/help-center-v2/reference/networks/canton.md).

# Canton (CC)

Canton on Ledger Enterprise: accepting incoming transfers, automatic approval, how balances are held, and dual-validator signing.

Canton behaves differently from every other network here, in ways that affect daily operations. Read this page before using a Canton Account.

## How Canton differs

Canton is built for privacy between institutions. Each party sees only the transactions it takes part in. There is no public ledger for anyone to inspect.

Three consequences shape how this product behaves:

* A transfer needs the consent of both parties. That is why receiving is an action here, and not a wait.
* A balance is held as a set of individual coin contracts, not as a number. The model is closer to Bitcoin than to Ethereum.
* Two validators, Ledger and Kiln, co-sign every transaction.

For the network itself, see [canton.network](https://www.canton.network/).

## Token coverage

Ledger Enterprise supports **Canton Coin (CC)**.

Tokens that comply with the **Canton token standard**, [CIP-0056](https://github.com/canton-foundation/cips/blob/main/cip-0056/cip-0056.md), are supported on Request.

Support for a given token is enabled per Workspace. Ask your Ledger contact to enable one.

## Four things to know

<table><thead><tr><th width="257.3359375">Property</th><th>What it means for you</th></tr></thead><tbody><tr><td><strong>UTXO-based balance</strong></td><td>The balance is held as individual coin contracts. One transfer can draw on at most <strong>100</strong> of them. Idle contracts lose value over time, and expire if fees grow beyond what they hold</td></tr><tr><td><strong>Offer-based transfers</strong></td><td>Nothing settles automatically. Incoming transfers arrive as proposals. Somebody has to accept them, unless automatic approval is on. A sent transfer can be withdrawn, and a received one rejected, through the API only</td></tr><tr><td><strong>Dual-validator security</strong></td><td>Every transaction is co-signed by both Ledger and Kiln. Neither can act on your behalf alone</td></tr><tr><td><strong>Standard token liability</strong></td><td>If a token fails, recovering it is the responsibility of whoever issued it, not Ledger</td></tr></tbody></table>

These are shown as a disclaimer when a Canton Account is created. They are not warnings about Ledger Enterprise; they are properties of the network.

## Receiving is an action, not a wait

On most networks receiving is passive: someone sends, and the funds appear. **On Canton you have to accept.**

An incoming transfer arrives as a **transfer proposal**, listed in the **Transfer Proposals** section of the Account overview. Each row shows the amount with its countervalue, when the proposal expires, and what you can do about it.

Accepting is a governed Request. It follows the Account's **Receive** Rule, needs the approvals that Rule specifies, and is signed with your own key like any other operation.

### What you see on a proposal

<table><thead><tr><th width="143.22265625">State</th><th>What it means</th></tr></thead><tbody><tr><td><strong>Review</strong></td><td>You can act. If nobody has started, <strong>Review</strong> creates the acceptance Request. If an acceptance Request is pending and you can approve it, <strong>Review</strong> opens it for your approval</td></tr><tr><td><strong>Pending</strong></td><td>An acceptance Request is pending, and you cannot approve it. Select the arrow beside it to open the Request</td></tr><tr><td><strong>Not initiated</strong></td><td>Nobody has started, and you do not have permission to. Ask someone who does</td></tr><tr><td><strong>Expired</strong></td><td>The proposal lapsed before it was accepted. Nothing arrived</td></tr></tbody></table>

When the acceptance Request is in any other state, for example executed or rejected, the row shows no state and no action.

> **Important:** Proposals expire. An incoming transfer nobody accepts in time does not arrive, and the sender has to start again. Automatic approval, below, removes the need to watch for Canton Coin proposals.

The interface has no action to reject a transfer. To decline a transfer there, let the proposal expire. Over the API, you can reject a proposal. The rejection is a Request under the Account's Receive Rule. See the [API documentation](https://help.enterprise.ledger.com/api-documentation-v2).

> **Note:** A proposal can also disappear before you act on it. The sender can withdraw a transfer while it is still waiting. If a proposal you expected is no longer listed, ask the sender before you assume it failed.

## Automatic approval

Rather than accepting each transfer by hand, you can let incoming Canton Coin transfers be accepted automatically for a period. This is the **Receive approvals** section on the Account overview.

* **To turn it on, create a Request.** Select **Enable automatic approval**. The Request is approved under the Account's Receive Rule. Your governance makes this decision, not an individual.
* You need permission to receive on the Account to turn it on. Without it you see the current state and no action.
* Once active, the section shows the date and time it runs until.
* Automatic approval lasts **90 days**. While it is active, you cannot extend it in the interface.
* It covers incoming **Canton Coin** transfers only.

> **Warning:** Automatic approval **expires after 90 days and does not renew itself**. There is no reminder and no renewal button. When it lapses, incoming transfers go back to needing manual acceptance without notice. A proposal nobody notices then expires unaccepted.

Automatic approval is available on **main Canton Accounts only**, not on token Accounts. Token Accounts always require manual acceptance. After automatic approval ends, you can turn it on again with a new Request.

## Sending

Sending follows [**Sending assets**](/help-center-v2/guides/transactions/sending-assets.md), with these differences.

**A reason field.** The field reads **A reason may be required**. The interface accepts a reason of up to 128 characters, and the API sets no length limit. The reason travels with the transaction as additional information. Some recipients require one. Rules and Whitelists do not check the reason. Approvers see it in the Request details, under **Reason**.

**Your transfer waits for the recipient.** A transfer you send sits as a proposal on their side until they accept it. It has not settled until they do. If the recipient has automatic approval on, a Canton Coin transfer is accepted without manual action.

**The interface cannot take a sent transfer back.** It has no withdraw or cancel action for a transfer you have sent. In the interface, if a transfer should not go through, ask the recipient not to accept it. Then let the proposal expire. Over the API, you can withdraw a sent transfer that has not expired. The withdrawal is a Request under the Account's Send Rule. See the [API documentation](https://help.enterprise.ledger.com/api-documentation-v2).

> **Important:** Contact the recipient before the proposal expires. When a proposal lapses, nothing moves and nobody is notified. Both sides can be left expecting a payment that will never arrive.

**The 100-contract limit** matters on an Account that has received many small amounts. One transfer can draw on at most 100 coin contracts. If a payment needs more than that, send it in several transfers.

## Addresses

Canton identifies Accounts by a **party ID** rather than a conventional blockchain address. It is shared and verified the same way as any other address, described in [**Receiving assets**](/help-center-v2/guides/transactions/receiving-assets.md).

Sharing your party ID is what lets someone send to you. It is separate from accepting what they send.

## Related

* [**Receiving assets**](/help-center-v2/guides/transactions/receiving-assets.md)
* [**Sending assets**](/help-center-v2/guides/transactions/sending-assets.md)
* [**How governance works**](/help-center-v2/concepts/how-governance-works.md)
* [**Networks**](/help-center-v2/reference/networks.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.enterprise.ledger.com/help-center-v2/reference/networks/canton.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.