|
1 | 1 | --- |
2 | | -title: "Chain-Key Tokens" |
3 | | -description: "Trustless 1:1 representations of external blockchain assets on ICP" |
| 2 | +title: "Chain-Key Digital Assets" |
| 3 | +description: "Trustless 1:1 representations of external chain assets on ICP" |
4 | 4 | --- |
5 | 5 |
|
6 | | -Chain-key tokens are ICP tokens backed 1:1 by assets native to another blockchain. ckBTC represents bitcoin, ckETH represents ether, ckUSDC represents USDC on Ethereum, and so on. Each token 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. |
| 6 | +Chain-key digital assets are ICP digital 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. |
7 | 7 |
|
8 | | -## Why chain-key tokens instead of wrapped tokens |
| 8 | +## Why chain-key digital assets instead of wrapped assets |
9 | 9 |
|
10 | | -Traditional wrapped tokens depend on an off-chain custodian that holds the underlying asset and instructs a token 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. |
| 10 | +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. |
11 | 11 |
|
12 | | -Chain-key tokens eliminate the custodian. The underlying assets are held by a minter canister at a blockchain 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. |
| 12 | +Chain-key digital assets 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. |
13 | 13 |
|
14 | 14 | ## Architecture |
15 | 15 |
|
16 | | -Every chain-key token uses a set of canisters: |
| 16 | +Every chain-key digital asset uses a set of canisters: |
17 | 17 |
|
18 | | -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. |
19 | | -2. **Ledger**: an ICRC-1/ICRC-2 compliant token ledger. It records all balances and executes mint, burn, and transfer operations. |
| 18 | +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 digital assets, and signs and submits withdrawals when digital assets are burned. |
| 19 | +2. **Ledger**: an ICRC-1/ICRC-2 compliant digital asset ledger. It records all balances and executes mint, burn, and transfer operations. |
20 | 20 | 3. **Index**: provides indexed access to ledger transactions, enabling efficient lookup of an account's transaction history. |
21 | 21 | 4. **Archive** (optional): stores historical transaction data that has been offloaded from the ledger to keep it compact. |
22 | 22 |
|
23 | | -All canisters in a chain-key token system are controlled by the NNS, making the token governance fully decentralized. |
| 23 | +All canisters in a chain-key digital asset system are controlled by the NNS, making the digital asset governance fully decentralized. |
24 | 24 |
|
25 | | -## Minting (getting chain-key tokens) |
| 25 | +## Minting (getting chain-key digital assets) |
26 | 26 |
|
27 | 27 | The minting process differs slightly by chain: |
28 | 28 |
|
29 | 29 | **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 (6 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. |
30 | 30 |
|
31 | | -**EVM-based tokens (ckETH, ckERC20).** A helper smart contract deployed on Ethereum receives deposits. When a user sends ETH or an ERC-20 token to the helper contract, it emits an event. The minter periodically queries these event logs via the [EVM RPC canister](ethereum.md) and mints the corresponding chain-key tokens on the ICP ledger. |
| 31 | +**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](ethereum.md) and mints the corresponding chain-key digital assets on the ICP ledger. |
32 | 32 |
|
33 | 33 | ## Burning (redeeming underlying assets) |
34 | 34 |
|
35 | | -All chain-key token redemptions use ICRC-2 approval: |
| 35 | +All chain-key digital asset redemptions use ICRC-2 approval: |
36 | 36 |
|
37 | 37 | 1. The user calls `icrc2_approve` on the ledger to authorize the minter to withdraw the desired amount. |
38 | 38 | 2. The user calls the minter's withdrawal endpoint (for example, `retrieve_btc_with_approval` for ckBTC). |
39 | | -3. The minter burns the chain-key tokens from the user's account. |
| 39 | +3. The minter burns the chain-key digital assets from the user's account. |
40 | 40 | 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. |
41 | 41 |
|
42 | 42 | 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. |
43 | 43 |
|
44 | | -## Chain-key token security |
| 44 | +## Chain-key digital asset security |
45 | 45 |
|
46 | | -The security of a chain-key token rests on two properties: |
| 46 | +The security of a chain-key digital asset rests on two properties: |
47 | 47 |
|
48 | | -- **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. |
| 48 | +- **Supply bound.** The minter never mints more chain-key digital assets 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. |
49 | 49 | - **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. |
50 | 50 |
|
51 | | -## Deployed tokens |
| 51 | +## Deployed digital assets |
52 | 52 |
|
53 | | -| Token | Underlying | Origin chain | Integration method | |
54 | | -|-------|------------|--------------|-------------------| |
| 53 | +| Digital asset | Underlying | Origin chain | Integration method | |
| 54 | +|---|---|---|---| |
55 | 55 | | ckBTC | BTC | Bitcoin | Direct | |
56 | 56 | | ckETH | ETH | Ethereum | EVM RPC canister | |
57 | | -| ckERC20 (ckUSDC, ckUSDT, ...) | ERC-20 tokens | Ethereum | EVM RPC canister | |
| 57 | +| ckERC20 (ckUSDC, ckUSDT, ...) | ERC-20 assets | Ethereum | EVM RPC canister | |
58 | 58 | | ckSOL | SOL | Solana | SOL RPC canister | |
59 | 59 | | ckDOGE | DOGE | Dogecoin | Direct | |
60 | 60 |
|
61 | 61 | ## Next steps |
62 | 62 |
|
63 | 63 | - [Bitcoin integration](bitcoin.md): ckBTC minter and ledger in detail |
64 | 64 | - [Ethereum integration](ethereum.md): ckETH and ckERC20 architecture |
65 | | -- [Chain Fusion overview](index.md): the full landscape of ICP cross-chain capabilities |
66 | | -- [Chain-key tokens guide](../../guides/digital-assets/chain-key-tokens.md): how to integrate chain-key tokens into an application |
67 | | -- [Chain-key cryptography](../chain-key-cryptography.md): the threshold signing that makes chain-key tokens possible |
| 65 | +- [Chain Fusion overview](index.md): the full landscape of ICP crosschain capabilities |
| 66 | +- [Chain-key digital assets guide](../../guides/digital-assets/chain-key-tokens.md): how to integrate chain-key digital assets into an application |
| 67 | +- [Chain-key cryptography](../chain-key-cryptography.md): the threshold signing that makes chain-key digital assets possible |
68 | 68 |
|
69 | 69 | <!-- Upstream: informed by Learn Hub articles "Chain-Key Tokens" (migrated, source retired) --> |
0 commit comments