The Review Surface Expands: OISY Brings Bitcoin WalletConnect Into Chain Fusion

OISY Wallet’s v2.5.4 release, published on August 18, adds a meaningful new layer to ICP’s Chain Fusion story: Bitcoin WalletConnect is enabled in beta and production. The change lets external applications request Bitcoin wallet actions through OISY while keeping approval inside the wallet’s review flow.

That distinction matters. Chain Fusion is often described as the ability for an ICP canister to control an address on another network. ICP’s Bitcoin integration supports the underlying mechanics: canisters can derive Bitcoin addresses, read UTXOs, construct transactions, request threshold signatures, and broadcast signed transactions through the Bitcoin canister. But a usable wallet must also decide what the user is actually approving.

The OISY release notes show that this interface is becoming a first-class engineering surface. The release includes Bitcoin WalletConnect enablement for production, Bitcoin network recognition for WalletConnect sessions, and a fix that derives Bitcoin PSBT review figures from the signed previous output. In practical terms, the wallet is not treating a PSBT as an opaque blob. It is attempting to show transaction values from the data that will actually be signed.

The same release also records broader review work across Chain Fusion-connected networks: Solana WalletConnect reviews expose sources and destinations, Solana transactions can be simulated before approval, and Ethereum fee information is surfaced in the review. These changes point to a common design principle for multichain wallets: the signing primitive may be shared, but the safety explanation cannot be chain-agnostic.

For builders, the lesson is architectural. A Chain Fusion application needs at least three separable layers:

1. Address and key control: ICP’s threshold-signing APIs let canisters or signer canisters authorize compatible external-chain messages without reconstructing a private key.
2. Transaction construction: the application must select UTXOs, fees, outputs, and serialization rules appropriate to Bitcoin or another target chain.
3. Human-readable authorization: the wallet must translate the final payload into recipients, amounts, fees, and network context before signing.

The third layer is where many cross-chain systems become fragile. A signature can be cryptographically valid while the user’s understanding of the transaction is wrong. Bitcoin’s UTXO model makes this especially visible because fee calculation, change outputs, and previous-output data affect what the transaction means.

The release therefore marks more than a compatibility checkbox. It moves Chain Fusion toward an application model in which ICP supplies decentralized signing infrastructure, while wallet software owns the user-facing interpretation and consent boundary. That division can make multichain apps easier to compose, but it also gives developers a clear audit target: verify the exact bytes reviewed by the user are the bytes sent to the signer.

One caveat is important: OISY’s release notes document shipped functionality, but they are not an independent security audit; builders should still review the signing and transaction-review paths before relying on them.