ICP’s Ed25519 Expansion Turns Chain Fusion Into a Wider Multichain Signing Layer
New ICP documentation shows Chain Fusion extending beyond Bitcoin and EVM networks through threshold Ed25519 signing, Solana RPC consensus, and the ckSOL asset path.

ICP’s Chain Fusion story is entering a broader phase: the Internet Computer’s current developer documentation now presents threshold Ed25519 signing as a route into several non-EVM ecosystems, including Solana, TON, Polkadot, Cardano, NEAR, and Stellar.
The technical shift is important because Ed25519 is not merely another wallet format. ICP canisters can request threshold Schnorr signatures using the Ed25519 variant, allowing subnet nodes to collectively authorize external-chain transactions without reconstructing a private key. The resulting address belongs to the canister, so application logic—not a user-held bridge key—can control the external account.
Solana is the clearest production-oriented example in the documentation. ICP’s SOL RPC canister queries multiple independent JSON-RPC providers and returns a result only when their responses meet the configured consensus strategy. Developers can then combine that read path with threshold signing. The architecture creates a programmable cross-chain backend: a canister can observe Solana state, decide what to do, sign a transaction, and submit it through the RPC layer.
The same design also supports ckSOL. The Solana guide describes ckSOL as an ICP token backed 1:1 by SOL held at a canister-controlled address. Deposits are detected through the SOL RPC canister and minted as ICRC-1/ICRC-2 tokens; withdrawals burn ckSOL and trigger a signed Solana transfer.
The practical constraint is latency and provider dependence. ICP’s replicated HTTPS outcalls require external providers to return sufficiently consistent data, while Solana changes state quickly. The open-source SOL RPC canister therefore documents workarounds such as durable nonces or retrieving a blockhash through a slot and block lookup. This is a reminder that Chain Fusion removes the bridge custodian, but it does not remove the engineering problem of reconciling a fast external chain with replicated execution.
A factual caveat matters: the current documentation distinguishes established integrations from community-built tooling, so its support table is not proof that every listed Ed25519 chain has a production deployment. The strongest verified path today is the combination of ICP threshold signing, the governed SOL RPC canister, and the documented ckSOL flow.
For builders, the new angle is architectural rather than promotional. Chain Fusion is becoming a signature-and-verification substrate that can be reused across chains with compatible cryptography. The opportunity is to move custody, automation, and policy into canisters while keeping each external asset native to its source network.
Get the wire in your inbox
Every new signal, straight from the generator. No noise, unsubscribe anytime.


