Bitcoin HWI, a widely used interface for connecting wallet software to hardware signing devices, is moving toward retirement, while the Rust project its maintainer cited as a promising successor has not yet demonstrated a production handoff.
The maintainer of Bitcoin Core’s Hardware Wallet Interface, or HWI, said on Aug. 18 that the project had effectively been in maintenance mode for years and had largely been a solo effort. HWI will no longer accept new devices or features beyond work needed for MuSig2. Once that work is complete, the maintainer expects to make a release that will likely be the project’s last, then keep HWI in minimal maintenance until a suitable drop-in replacement is ready.
HWI is the bridge that wallet software can use to discover a hardware device, retrieve public keys, display a receive address and send a partially signed Bitcoin transaction to devices such as Ledger, Trezor, Coldcard, BitBox or Jade for approval and signing. The successor candidate named in the notice, BHWI, aims to preserve HWI-style command output with a Rust implementation.
Neither transition is complete. HWI is not archived, no retirement date has been set, and the notice does not say supported hardware wallets will stop working or that users’ bitcoin is at risk. The immediate pressure falls on teams that package HWI, invoke its command line or rely on it to absorb changes in devices, operating systems and vendor protocols.
Why HWI’s separate boundary matters
HWI is both a Python library and a command-line tool. It gives software one interface for common hardware-wallet operations instead of requiring a separate implementation for every vendor.
Its original goal was to bring hardware-wallet support to Bitcoin Core. The integration reached users through an external-signer boundary rather than by placing HWI inside Bitcoin Core. Bitcoin Core’s external-signer documentation describes a configurable command and uses HWI as its example, while HWI’s Bitcoin Core guide shows HWI being used for key retrieval and transaction signing alongside a Core wallet.
The HWI maintainer said Python prevents deterministic builds, the reproducible build process Bitcoin Core uses for release binaries, and therefore keeps HWI from being shipped with Bitcoin Core. That separation also makes HWI replaceable in principle: another program can implement Bitcoin Core’s external-signer contract. CryptoSlate’s coverage of Bitcoin Core 22.0 described the arrival of external-signer support in 2021.
A compatible command surface, however, is only one part of a migration. Applications still need to package a replacement, test the devices and operations they expose, and decide who owns fixes when firmware or operating-system behavior changes.
BHWI addresses the packaging constraint with a Rust core rather than a Python application. Its design could make reproducible distribution and use from multiple programming environments easier, but each downstream project still has to verify that the replacement covers its own command set, device matrix and release process. Bitcoin Core can test another conforming command behind its external-signer boundary; other software that consumes HWI’s command line must perform its own compatibility work.
That distinction turns the maintenance announcement into a succession problem rather than a simple repository-status change. HWI’s interface may be shared, but its consumers do not all use or distribute it in the same way.
The downstream map shows three types of exposure: direct Python dependencies, wrappers around HWI’s command line, and projects that already maintain a separate descendant implementation.
Specter Desktop, a coordinator for Bitcoin Core wallets, is the clearest direct dependency. Its project description explains its Bitcoin Core and hardware-wallet focus, while its source pins a specific HWI release. BTCPay Server Vault takes a different route: its local service exposes connected signing devices through a wrapper around HWI’s command-line requests. Both would need integration testing even if a replacement accepted familiar commands.
Wasabi, a privacy-focused wallet, presents a packaging example. A July project issue reported that Apple Silicon builds included an x86_64 HWI executable, raising a risk for HWI-backed device detection, enumeration, address display and signing in affected builds as reliance on Rosetta became less tenable. The issue concerned the packaged executable, not a failure of the signing devices.
Sparrow, a desktop wallet, shows why the transition may fragment instead of converging on a single successor. Lark began as a Java port of Python HWI and now supplies Sparrow’s hardware-wallet path. Sparrow is therefore not a direct Python-HWI migration case, but it remains responsible for a separate implementation descended from the same interface.
New hardware models are where HWI’s freeze can become visible. Its support matrix spans Ledger, Trezor, BitBox, KeepKey, Coldcard and Blockstream Jade models. Capabilities differ by device and firmware, including transaction types, address display and device-management operations. A replacement must match the required device-operation pairs, not merely reproduce command names.
The gap between upstream code and downstream availability already appears in support records. HWI released version 3.2.0 in February with BitBox02 Nova support. An April Specter user report involved a setup using HWI 2.4.0 that could not detect the Nova. The Specter issue did not identify whether the pinned version, packaging, firmware or local environment caused the failure, but the chronology shows that upstream support and downstream availability can diverge.
Under HWI’s new policy, a vendor or wallet team facing the next unsupported model can maintain a fork, build a separate integration, adopt another interface or leave that combination unsupported. What disappears is the normal path for landing the change in the shared upstream project.
BHWI has a testing lead, not a production handoff
BHWI tackles HWI’s architectural limitation with a Rust, sans-I/O core that leaves transport and runtime choices to the caller. Its workspace includes asynchronous, command-line and WebAssembly layers, and its command-line package builds an hwi binary intended to preserve Python-HWI-compatible output. The repository still labels the project work in progress.
The current project snapshot lists BitBox02, Coldcard, Jade and Ledger models. Its strongest published compatibility evidence is narrower. BHWI’s parity documentation describes differential tests and final gates that run the unmodified HWI 3.2.0 device suite against BHWI for BitBox02, Coldcard, Ledger and Jade.
Those tests reduce the risk that a replacement command returns different results for the covered devices. They do not demonstrate production behavior across HWI’s broader matrix, every host platform, each packaging format or complete downstream wallet flows. BHWI’s README and parity document also do not name a wallet already shipping it as a production replacement for HWI.
The remaining gap is organizational as well as technical. HWI’s maintainer made archival conditional on a suitable replacement, while BHWI has defined an architecture and a growing test surface. Wallet teams must still decide whether its covered device paths are sufficient, how to distribute it and who will maintain the integration they ship.
The likely final HWI release would establish a fixed upstream boundary. A new device, firmware behavior or host platform could then require a downstream patch without a normal path back into HWI. Projects that bundle Python HWI need packaging and release plans. Command-line consumers need compatibility tests for their own calls. Projects such as Sparrow and Lark face a separate decision about continuing their independent stack.
HWI’s repository may remain open until a successor is suitable, but its contribution freeze is already in effect. The succession risk begins when the next compatibility change arrives and the shared bridge no longer accepts it.
