For AI agents: Documentation index at /llms.txt

Skip to content
docs.internetcomputer.org

Chain-Key Tokens

Chain-key tokens are ICP-native assets backed 1:1 by assets native to another chain. ckBTC represents bitcoin, ckETH represents ether, ckUSDC represents USDC on Ethereum, and so on. Each is fully backed by the underlying asset (held in a canister-controlled address on the origin chain), and all minting and burning happens entirely onchain, with no third-party custodian.

Why chain-key tokens instead of wrapped assets

Section titled “Why chain-key tokens instead of wrapped assets”

Traditional wrapped assets depend on an offchain custodian that holds the underlying asset and instructs a contract to mint or burn the wrapped version. If the custodian is compromised, hacked, or goes out of business, the backing can be lost entirely. Additionally, nothing prevents a dishonest custodian from using the custodied assets for other purposes, risking a depeg.

Chain-key tokens eliminate the custodian. The underlying assets are held by a minter canister at a network address derived from a chain-key key, an address no single party controls. Minting and burning are triggered by verifiable onchain events (confirmed Bitcoin UTXOs, Ethereum event logs), and the minter signs withdrawal transactions using threshold cryptography distributed across a subnet’s nodes.

Architecture

Section titled “Architecture”

Every chain-key token uses a set of canisters:

  1. Minter: manages the underlying asset on the origin chain. It controls the deposit address (or Ethereum helper contract), detects incoming deposits, instructs the ledger to mint tokens, and signs and submits withdrawals when tokens are burned.
  2. Ledger: an ICRC-1/ICRC-2 compliant ledger. It records all balances and executes mint, burn, and transfer operations.
  3. Index: provides indexed access to ledger transactions, enabling efficient lookup of an account’s transaction history.
  4. Archive (optional): stores historical transaction data that has been offloaded from the ledger to keep it compact.

All canisters in a chain-key token system are controlled by the NNS, making the asset governance fully decentralized.

Minting (getting chain-key tokens)

Section titled “Minting (getting chain-key tokens)”

The minting process differs slightly by chain:

Bitcoin-based tokens (ckBTC, ckDOGE). The user requests a deposit address from the minter. This is a chain-key ECDSA address controlled by the minter. The user sends the underlying asset to this address on the Bitcoin or Dogecoin network. Once the transaction reaches the required confirmation threshold (4 confirmations for ckBTC), the user calls update_balance on the minter. The minter verifies the deposit via the Bitcoin canister and mints the corresponding amount on the ledger.

EVM-based tokens (ckETH, ckERC20). A helper smart contract deployed on Ethereum receives deposits. When a user sends ETH or an ERC-20 asset to the helper contract, it emits an event. The minter periodically queries these event logs via the EVM RPC canister (see Ethereum integration) and mints the corresponding chain-key tokens on the ICP ledger.

Burning (redeeming underlying assets)

Section titled “Burning (redeeming underlying assets)”

All chain-key token redemptions use ICRC-2 approval:

  1. The user calls icrc2_approve on the ledger to authorize the minter to withdraw the desired amount.
  2. The user calls the minter’s withdrawal endpoint (for example, retrieve_btc_with_approval for ckBTC).
  3. The minter burns the chain-key tokens from the user’s account.
  4. The minter constructs a transaction on the origin chain, signs it using chain-key cryptography (threshold ECDSA for Bitcoin and Ethereum; threshold Ed25519 for Solana), and submits it.

For EVM-based tokens, the gas fee on Ethereum must be covered. ckETH acts as the fee currency: when redeeming ckERC20 tokens, the user also approves a small ckETH amount to cover the Ethereum gas cost.

Chain-key token security

Section titled “Chain-key token security”

The security of a chain-key token rests on two properties:

  • Supply bound. The minter never mints more chain-key tokens than the underlying assets it controls. The total ckBTC supply, for example, is always at most equal to the BTC held at minter-controlled Bitcoin addresses.
  • Threshold custody. The minter’s private key is never held by a single party. Withdrawal transactions are signed collectively by the subnet nodes through the chain-key protocol, so a single compromised node cannot authorize unauthorized withdrawals.

Deployed assets

Section titled “Deployed assets”
AssetUnderlyingOrigin chainIntegration method
ckBTCBTCBitcoinDirect
ckETHETHEthereumEVM RPC canister
ckERC20 (ckUSDC, ckUSDT, …)ERC-20 assetsEthereumEVM RPC canister
ckSOLSOLSolanaSOL RPC canister
ckDOGEDOGEDogecoinDirect

Next steps

Section titled “Next steps”