HWI freezes new device support; wallets must handle new hardware

On Aug. 18 the maintainer of the Hardware Wallet Interface (HWI) wrote that the project will no longer accept new devices or new features beyond work required to support MuSig2. After that work is complete, the maintainer plans to publish what is likely to be the project’s final release and keep the repository in minimal maintenance. The repository has not been archived, no retirement date was set, and there is no indication that users’ bitcoin funds are at risk.

HWI is a Python library and command-line tool that wallet software uses to discover hardware devices, retrieve public keys, display receive addresses and send partially signed Bitcoin transactions to devices such as Ledger, Trezor, Coldcard, BitBox and Blockstream Jade. The maintainer described the project as largely a solo effort and said HWI has been in maintenance mode for years. The maintainer cited Python’s inability to produce deterministic builds as a barrier to shipping HWI inside Bitcoin Core’s reproducible release binaries.

Under the new policy, only work required for MuSig2 will be accepted. Wallet teams that bundle HWI, invoke its command line, or rely on it to absorb changes in device firmware, operating systems and vendor protocols will need to repackage, test and possibly maintain their own integrations when new devices or firmware arrive. Specter Desktop pins a specific HWI release and would need to repackage and retest device discovery and signing. Wasabi’s hardware-wallet compatibility documentation references HWI. BTCPay Server Vault wraps HWI’s command-line interface and would need to adapt its local-device bridge. Sparrow Wallet already uses a Java descendant called Lark for its hardware path and will continue managing its separate stack.

A Rust project called BHWI is the leading successor candidate. BHWI uses a sans-I/O Rust core with separate transport and runtime layers and aims to provide an hwi-compatible command-line binary. The repository documents differential tests that run the unmodified HWI 3.2.0 device suite against BHWI for a subset of devices — BitBox02, Coldcard, Ledger and Jade. BHWI remains under development and has not been adopted as a production replacement by downstream wallets.

Practical packaging issues have already produced gaps between upstream support and downstream availability. HWI 3.2.0 added BitBox02 Nova support in February, yet a later report described a setup using HWI 2.4.0 that could not detect the Nova. A separate issue involved Apple Silicon builds that included an x86_64 HWI executable, raising the risk of detection and signing failures as reliance on Rosetta changes.

With contributions frozen, the usual upstream path for adding device support will not be available. Projects facing unsupported new models can maintain forks, build separate integrations, adopt an alternative interface such as BHWI when appropriate, or leave certain device-model combinations unsupported. Downstream teams must decide who will package, test and maintain the integrations they distribute.