فا
← BACK TO THE WIRE
N°0222Chain Fusion2 MIN3 SOURCES

Chain Fusion’s Next Transparency Problem: Making Canister-Controlled Addresses Discoverable

A community proposal identifies a practical gap in Chain Fusion: external addresses controlled by canisters are difficult to discover and aggregate, limiting reliable TVL dashboards and cross-chain monitoring.

Chain Fusion’s Next Transparency Problem: Making Canister-Controlled Addresses Discoverable
IMAGE: AI-GENERATED

Chain Fusion can already let an ICP canister control accounts on Bitcoin, Ethereum, Solana, and other networks through threshold signatures. The next challenge is less about signing and more about proving which external addresses belong to which canisters.

A December 2025 proposal on the Internet Computer Developer Forum describes the problem directly: canister-controlled addresses are derived from a canister’s identity, signing key, and derivation path. Because developers can define paths dynamically, outside services cannot reliably reconstruct every address by inspecting ICP activity alone.

That creates an observability gap. Portfolio trackers, explorers, and TVL dashboards may see an address on an external chain without knowing that it is controlled by an ICP canister. The proposal evaluates five approaches: an ICP-side derivation-path indexer, changes to the management canister, a developer-adopted interface standard, a registry canister, and an off-chain API.

The most important design distinction is between exposing an address and exposing the data needed to derive it. A canister could publish its derivation path, key identifier, and external chain identifier. An indexer could then reconstruct the public key and address. ICP’s current documentation confirms that this reconstruction is deterministic and can be performed offline from the subnet public key, canister principal, and derivation path, without secret material or a live canister call.

The proposal recommends an off-chain API as the simplest implementation and a registry canister as the more decentralized option. Both would require canister developers to publish or submit their address metadata. That means adoption, not cryptography, is the immediate bottleneck.

For builders, the practical lesson is clear: treat derivation paths as part of your public integration interface. Document the key scheme, path format, and target chain, and expose them through a stable query or registration flow. Doing so makes balances indexable, simplifies audits, and gives users a clearer way to verify where a Chain Fusion application’s external assets reside.

Important caveat: this remains a community proposal, not an approved protocol change. The official documentation currently supports deterministic offline derivation, but it does not establish a universal address registry or require every canister to publish its paths.

TAGSChain FusionICPThreshold SignaturesDerivation Paths
Grounded sources3 REFS
  1. [01]ChainFusion derivation path standardforum.dfinity.org
  2. [02]Offline public key derivationdocs.internetcomputer.org
  3. [03]Chain Fusiondocs.internetcomputer.org
Read next

Get the wire in your inbox

Every new signal, straight from the generator. No noise, unsubscribe anytime.

RSS AVAILABLE · NO SPAM