Chain Fusion

An integration has two halves. The first is reading: a canister needs to know the state of the other chain — balances, transaction outputs, block headers, fee estimates. The second is writing: a canister needs to produce a transaction that the other chain will accept. The documentation describes both as services the network provides, with the reading side implemented by a dedicated canister or adapter that follows the other chain and the writing side implemented by threshold signing.

For Bitcoin, the documentation describes a Bitcoin canister running on a system subnet that maintains a view of the Bitcoin blockchain, and a Bitcoin adapter that connects the network to the Bitcoin peer-to-peer network. Canisters query the Bitcoin canister for balances, UTXOs, block headers and fee percentiles, and they submit transactions through it. The native Bitcoin integration page covers the methods and the trust model in detail.

For Ethereum, the documentation describes an integration that lets a canister read Ethereum state and submit signed transactions, using threshold ECDSA over secp256k1 for the signing. The same key type covers the EVM chains that share Ethereum's transaction format. The documentation also describes ckETH and ckERC-20 tokens, which are the network's representation of assets bridged from Ethereum through a canister-based mechanism rather than a third-party bridge.

The Bitcoin integration is deployed. The documentation describes the Bitcoin canister, the adapter, the management canister methods for balances and transactions, and ckBTC as a live asset. The Ethereum integration is likewise described as available, with threshold ECDSA signing and the ckETH and ckERC-20 assets. These are the two integrations a developer can build against today.

Other chains are described in the documentation as supported through threshold Schnorr and EdDSA signing, which is the capability that makes a chain reachable rather than a claim that every chain has a finished integration. Solana, for example, uses Ed25519, and the documentation describes the signing support as the foundation for interacting with it. A reader should treat the signing capability as deployed and the per-chain integration as the thing that varies.

The documentation is also clear about what Chain Fusion does not do. It does not make the other chain faster, it does not remove that chain's own fees, and it does not give a canister authority over addresses whose keys it does not hold. A canister that wants to receive bitcoin must derive an address and give it to the sender; the integration does not intercept transfers to arbitrary addresses.

A chain-key token is an ICRC-1 token on the Internet Computer that is backed one-to-one by an asset held on another chain. ckBTC is backed by bitcoin, ckETH by ether, and ckERC-20 tokens by the corresponding ERC-20 balances. The documentation describes the backing as held by a canister that controls the underlying address through threshold signing, which is what distinguishes a chain-key token from a bridged token issued by a custodian.

The documentation describes the minting and redemption flow as involving a minter canister and a KYT canister that checks the provenance of incoming funds. That check is a real part of the system rather than a formality: a deposit that fails it is not minted, and the documentation advises users to understand the policy before depositing. The chain-key cryptography page covers the signing capability that makes the backing possible.

The practical value of a chain-key token is that it can be used inside the network at network speed. A canister can accept ckBTC in a transaction that settles in seconds, while the underlying bitcoin sits in an address the network controls. The trade-off is that the holder is trusting the network's threshold protocol and the minter's policy rather than holding the bitcoin directly.