Canton

Overview

Designed by Digital Asset, Canton enables a “network of networks” that supports secure, interoperable transactions between financial institutions while maintaining strict privacy controls. At its core, the Canton Protocol provides a decentralized infrastructure that connects previously siloed financial systems.

The protocol uses Daml, an open-source smart contract language, to define and execute agreements between parties in a secure, permissioned, and auditable manner. Daml specifies exactly who is authorized to view or modify any given contract.

The Canton Network—a public, permissioned blockchain—is the broader ecosystem of parties running Daml applications that communicate through the Canton blockchain protocol.

Canton Coin is the native asset of the Canton blockchain. It uses:

A UTXO model
The EdDSA signature algorithm

Canton Coin employs a burn-and-mint equilibrium model with the following characteristics:

Minting is inflationary: token supply increases over time until it reaches an equilibrium.
Synchronizer fees (e.g., those paid for using a Super Validator) are burned—permanently removed from circulation.
All synchronizer fees are denominated in USD.
Token price is denominated in USD and may fluctuate based on market value.

Explorer

https://ccview.io/

Wallets Types

BitGo enables holding Canton in the following wallet types:

	Multisig Cold	Multisig Hot	MPC Cold	MPC Hot
Custodial	❌	❌	✅	❌
Self Managed	❌	❌	✅	✅

Ticker Symbols

Mainnet	Testnet
canton	tcanton

Units

Canton is divisible to 10⁻¹⁰.

Balances may be represented as integers or strings. BitGo recommends using string format to avoid exceeding JavaScript numeric limits.

Tokens

Token support on Canton blockchain is coming soon

Fees

Canton has zero fees for Canton Coin transactions. This behavior is defined in CIP-0078.

Address Format

Canton addresses follow the format: <partyHint>::<fingerprint>. The fingerprint is exactly 68 characters in length and it has a human-readable part called partyHint. The partyHint can be set to anything and in BitGo we set the first 5 characters of the fingerprint as the partyHint. The fingerprint adheres to the following regular expression:

1
/^[a-fA-F0-9]{68}$/

Wallet Initialization

Canton network requires the wallet address to be initialized, meaning the address which was created during wallet creation needs to be registered on-chain. This is a transaction and requires to be signed using User keys. Before initializing the address, no activities can be done on-chain. User must be an Admin with spending rights to be able to initialize the request.

Note: User must have BitGo Offline Vault OVC 4.11.4 or above for self-custody cold wallet initialization.

2-Step Transfer

This is the default behavior of the chain where the receiver will have an option to either accept or reject the incoming transaction. The sender can set an expiry for this offer. The input UTXO will be merged & burned and two new UTXOs will be created:

UTXO with the intended transfer value — this will be locked on-chain (awaiting receiver acceptance)
UTXO with the change amount back to the sender — returned to the sender

In BitGo, we recommend all users enable 1-Step Transfer for Canton Coin.

1-Step Transfer

This is an enhancement on top of 2-step; when enabled, deposits are auto-accepted. Only Canton Coin supports 1-step transfers. Enabling this requires signing with User Keys (an on-chain update signed by the User).

Memo ID Support

Optionally, a ?memoId=<n> query parameter can be appended to the address for use cases such as identifying transaction metadata. Here, <n> can be any integer.
Using memoId-based addressing eliminates the need to generate multiple deposit addresses per user. A single static address can be reused safely across users and use cases, with the memoId serving as the unique identifier.
Since Canton uses memoId-based receive addresses, manual consolidation is not required.

Canton Transfers

Canton uses a UTXO-based transaction model, which affects how transfers are constructed, validated, and optimized on-chain.

Key Transfer Concepts

UTXO Model Canton operates on a UTXO (Unspent Transaction Output) model rather than an account-balance model. Each transfer consumes one or more UTXOs as inputs and produces new UTXOs as outputs.
Input Limits A single transfer can include up to 100 input Holding UTXOs. This prevents transactions from becoming excessively large or expensive to validate.
Holding Fees Every Holding UTXO continuously incurs a holding fee, denominated in USD. This fee causes UTXOs to self-deplete over time and discourages the creation of very small (“dust”) UTXOs.

Let:
- annualHoldingFeeUSD = the annual USD-denominated holding fee applied per UTXO
- dailyHoldingFeeUSD = annualHoldingFeeUSD / 365.25
- price = the CC/USD price from the current mining round (from /v0/scan-proxy/open-and-issuing-mining-rounds)
Minimum viable UTXO amount: minimumAmountCC = dailyHoldingFeeUSD / price

UTXO shelf life: lifetimeDays = (amountCC * price * 365.25) / annualHoldingFeeUSD
Key behaviors
- Smaller UTXOs have shorter lifetimes.
- When accrued fees exceed UTXO value, the UTXO is fully depleted and archived (effectively burned).
- It is best practice to merge small UTXOs regularly to minimize depletion.
Change Handling When multiple input UTXOs are used:
- They are merged internally.
- Any remaining balance is returned as a single new Holding UTXO, helping reduce UTXO fragmentation.

Transfer Workflows

Canton supports multiple transfer workflows depending on asset type and configuration.

1-Step Transfers Enables instant, direct transfers without receiver interaction. Requirements:
- The receiver must configure TransferPreapproval contracts.
- The sender should include the receiver's TransferPreapproval contract while building the transaction.
- Supported only for Canton Coin.
2-Step Transfers (Default) Used when TransferPreapproval is not configured or when transferring other token types. Workflow:
1. Sender creates a deposit offer.
2. Receiver must explicitly accept the offer.
3. Funds move only after the acceptance.
Self-Transfers Recommended for internal UTXO management:
- Merging small UTXOs
- Reducing holding fees
- Preparing for large withdrawals
- Avoiding dust accumulation Self-transfers follow the same UTXO rules but with sender = receiver.

BitGo-Specific Notes

Minimum withdrawal amount: 0.1 CANTON

Create Wallet

cURL
JavaScript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
export BITGO_EXPRESS_HOST="<YOUR_LOCALHOST>"
export COIN="tcanton"
export ACCESS_TOKEN="<YOUR_ACCESS_TOKEN>"
  export LABEL="<DESIRED_WALLET_NAME>"
    export PASSPHRASE="<YOUR_BITGO_LOGIN_PASSPHRASE>"
      export ENTERPRISE_ID="<YOUR_ENTERPRISE_ID>"

        curl -X POST \
        http://$BITGO_EXPRESS_HOST/api/v2/$COIN/wallet/generate \
        -H 'Content-Type: application/json' \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        -d '{
          "label": "'"$LABEL"'",
          "passphrase": "'"$PASSPHRASE"'",
          "enterprise": "'"$ENTERPRISE_ID"'",
          "disableTransactionNotifications": true,
          "disableKRSEmail": true
        }'

Create Address

cURL
JavaScript

1
2
3
4
5
6
7
8
export COIN="tcanton"
export WALLET_ID="<YOUR_WALLET_ID>"
export ACCESS_TOKEN="<YOUR_ACCESS_TOKEN>"

  curl -X POST \
  https://app.bitgo-test.com/api/v2/$COIN/wallet/$WALLET_ID/address \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Transact

You can use the sendMany function to send canton coin to a recipient in a transaction. Currently, we only support sending to a single recipient in a transaction.

cURL
JavaScript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
export BITGO_EXPRESS_HOST="<YOUR_LOCALHOST>"
export COIN="tcanton"
export WALLET_ID="<YOUR_WALLET_ID>"
export ACCESS_TOKEN="<YOUR_ACCESS_TOKEN>"
export ADDRESS="<DESTINATION_ADDRESS>"
export AMOUNT="<AMOUNT_IN_BASE_UNITS>"
export WALLET_PASSPHRASE="<YOUR_WALLET_PASSPHRASE>"

  curl -X POST \
  http://$BITGO_EXPRESS_HOST/api/v2/$COIN/wallet/$WALLET_ID/sendmany \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -d '{
  "recipients": [
    {
       "address": "'"$ADDRESS"'",
       "amount": "'"$AMOUNT"'"
    },
  ],
  "walletPassphrase": "'"$WALLET_PASSPHRASE"'",
  "type": "transfer",
  "isTss": "true"
  }'

2-Step Deposit Acceptance/Rejection

If you have not enabled 1-step deposits on your canton wallet, then for every deposit, an acknowledgement transaction request will be created and you will have to explicitly accept/reject.

Note: The below snippet creates the acceptance/rejection transaction request, you will still have sign it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
    export BITGO_EXPRESS_HOST="<YOUR_LOCALHOST>"
    export WALLET_ID="<YOUR_WALLET_ID>"
    export ACCESS_TOKEN="<YOUR_ACCESS_TOKEN>"
    export ACKNOWLEDGE_TXREQUEST_ID="<DEPOSIT_ACK_TXREQUEST_ID>"

    curl -X POST \
    http://$BITGO_EXPRESS_HOST/api/v2/wallet/$WALLET_ID/txrequests \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $ACCESS_TOKEN" \
    -d '{
      "intent": {
        "intentType": "transferAccept", // "transferReject"
        "txRequestId": "'"$ACKNOWLEDGE_TXREQUEST_ID"'"
      },
      "preview": false,
      "apiVersion": "full"
    }'

Is this page helpful?