Chain-key cryptography and threshold signatures

Three signature schemes are exposed to canisters, and the choice between them is decided by the chain a canister wants to sign for. Threshold ECDSA over secp256k1 covers Bitcoin's legacy and SegWit addresses, Ethereum and the EVM chains. Threshold Schnorr over BIP340 secp256k1 covers Bitcoin Taproot, which is what Ordinals and Runes depend on. Threshold Schnorr over Ed25519 covers Solana, TON, Cardano, Polkadot and NEAR.

Each scheme is backed by a pair of management canister methods: one to retrieve a public key and one to request a signature. A canister derives its own key from a master key held by a dedicated signing subnet, using its principal and an optional derivation path as input. The derivation is deterministic and public, so the same canister and path always produce the same key, and the public key can be computed offline without calling the network.

The documentation is explicit about one property that surprises developers: a signature may be computed even when the requesting canister receives an error. If a signing request returns a reject with an unknown outcome, the signature may already exist in the system. Canisters are advised not to rely on the signature not existing in those cases, which is a real constraint on any protocol that treats a failed signing call as proof that nothing was signed.

The network's internal certification uses threshold BLS signatures, and BLS has a property that makes threshold signing straightforward: signature shares can be combined non-interactively. Each node signs independently and the shares are aggregated with no further communication. ECDSA has no such property, so producing a threshold ECDSA signature requires a multi-round interactive protocol among the signing nodes.

The documentation notes that existing threshold ECDSA protocols in the literature assume either a synchronous network or no robustness against node crashes, and that neither assumption is acceptable for the Internet Computer. The network therefore implements a protocol designed to hold security and liveness over an asynchronous network with up to one-third of nodes faulty, with the design and security analysis published in research papers. Threshold Schnorr and EdDSA are simplified variants of the same protocol and inherit its robustness properties.

This is the technical reason the capability is unusual rather than merely convenient. A network that could only sign with its own native scheme could not hold an address on a chain that expects ECDSA, and a network whose signing protocol assumed synchrony could not offer the guarantee under the conditions a public network actually experiences.

A Bitcoin address is a hash of a public key, and spending from it requires a signature that verifies against that key. Because a canister can obtain an ECDSA or Schnorr public key and request signatures for it, a canister can derive its own Bitcoin addresses and produce valid transactions that move bitcoin from them. The same reasoning applies to any chain whose transaction authentication uses one of the supported schemes.

The documentation presents this as the foundation of Chain Fusion, and the important word is direct. There is no wrapped token, no custodian holding the underlying asset, and no bridge contract that must be trusted to release funds. The canister holds the key material in the only sense that matters — it can authorise transactions — and the network's threshold protocol ensures no single node can do so alone. The Chain Fusion page works through the architecture, and the native Bitcoin integration page covers the Bitcoin case in detail.

The limits are worth stating plainly. A canister can sign for an address it controls, but it cannot sign for an address whose key it does not hold, and it cannot change the rules of the chain it signs for. Cross-chain signing gives a canister authority over its own assets on another chain; it does not give it authority over anyone else's.