Bitpay Wallet (Copay) on GitHub: a multisig Bitcoin wallet that is no longer maintained

What Bitpay Wallet solves, and for whom

Bitpay Wallet is a client for multisignature cryptocurrency wallets, not a single-key spending app. The README describes it as a Bitcoin, Bitcoin Cash, Ethereum and ERC20 wallet platform for desktop and mobile, and the About section states that it implements a multisig wallet using p2sh addresses, with configurations such as 3-of-5 or 2-of-3. That design targets shared control: a company treasury, a family wallet, or any group that does not want one person holding the only key.

The second problem it addresses is key custody. The README says device-based security stores all private keys locally, not in the cloud, while peer synchronization and network interfacing go through Bitcore Wallet Service (BWS). That split is the whole architecture in one sentence: keys on the device, coordination on a server.

Who is it for? Two audiences, and they are different. The first is end users who want a multisig wallet with BIP32 HD address generation, BIP39 mnemonic backups and BIP70-BIP73 payment protocol support. The second is developers reading a mature Ionic and TypeScript codebase that already solved wallet creation, spending proposals and hardware wallet integration. For the second group the repository still has value. For the first, the maintenance notice at the top of the README changes the answer.

How the client, Bitcore Wallet Service and the device keys fit together

The data flow is client-server, with the server deliberately kept ignorant of private keys. Bitpay Wallet holds the keys; BWS holds wallet metadata and coordinates the participants so that all devices see the same wallet state. The README describes this as peer synchronization and network interfacing through BWS.

Multisig creation follows from that model. To create a shared wallet, the README states that Bitpay Wallet requires the extended public keys of all participants, and those public keys are incorporated into the wallet configuration. The server can therefore assemble a p2sh address and track proposals without ever holding a spending key. The README also describes an easy spending proposal flow for shared wallets and group payments, which is what the server side is really for: collecting signatures from people who are not in the same room.

Coin-specific behaviour is handled in the client. For Bitcoin the README lists Segwit and native Segwit (BECH32) addresses, CPFP transaction acceleration available after four hours of unconfirmed transactions, and fee adjustment using four preset levels derived from bitcoin-core estimations or a custom fee rate. For Ethereum it lists WalletConnect, a Gnosis multisig contract with a mainnet address of 0x6e95C8E8557AbC08b46F3c347bA06F8dC012763f, and gas price adjustment using four preset levels or a custom setting. Bitcoin Cash gets Schnorr signature support.

The dependency chain is worth noting before adopting anything. The package.json postinstall script runs patch:all, which patches bitcore-wallet-client, walletconnect and web3 after install. A wallet that must rewrite files inside node_modules to work is a wallet whose upgrade path is coupled to those libraries.

Running Bitpay Wallet in a browser for development

The README is explicit that the browser method is for development only, because browser extensions and other code may reach internal data and private keys. Production use should go through the official releases. With that warning stated, the steps are short.

Clone the repository and open the directory:

git clone https://github.com/bitpay/wallet.git
cd wallet

Install dependencies and choose a distribution. The README gives the BitPay variant:

npm install
npm run apply:bitpay
npm run start

After npm run start, the README says to visit localhost:8100 to view the app. The apply step matters: the postinstall prompt tells you to choose a distribution with npm run apply:copay or npm run apply:bitpay, so the distribution you apply determines which configuration the app uses.

For a real device the README gives separate scripts. Android and iOS both run npm run apply:bitpay and then npm run prepare:bitpay before npm run start:android or npm run start:ios, and both require the corresponding Cordova platform guide to be followed first. The desktop build uses Electron: install Electron, then run npm run apply:wallet followed by npm run start:desktop. Tests run with npm run test, which the README labels Karma and Protractor.

External services are configured through an environment variable set before the apply task:

BITPAY_EXTERNAL_SERVICES_CONFIG_LOCATION="~/.bitpay/externalServices.json" npm run apply:bitpay

On desktop, the README lists the per-user application data directory for the BitPay distribution as "~/Library/Containers/com.bitpay.wallet.desktop/Data/.bitpay".

The maintenance notice is the first thing to read

The README opens with a blockquote stating that the repository and wallet versions 12 and below are no longer actively being maintained, and directs readers to a new BitPay wallet at github.com/bitpay/bitpay-app. That single line overrides most feature comparisons. The repository is not archived, and the last push to master was on 2026-09-01, but the project's own documentation says the version line is out of maintenance. A recent commit date is not a maintenance promise.

The release history reinforces the point. The most recent release listed is v12.12.2 on 2022-07-28, followed by v12.12.0 and v12.11.7 earlier in 2022. Anyone building from master is building on top of a 12.x line that the README has already declared finished.

There is a second, sharper failure mode for a wallet of this type. Because synchronization runs through Bitcore Wallet Service, a self-hosted or third-party BWS instance is part of your trust and availability model. The README describes BWS as the peer synchronization and network interfacing layer but does not document what happens when that service is unavailable, nor does it document rollback of a wallet configuration change. If the BWS endpoint you rely on goes away, the client cannot coordinate multisig participants on its own. That is the operational risk to weigh, and the README is silent on it.

Where Bitpay Wallet is the wrong tool

If you want a wallet to hold funds today, this is the wrong repository, and the reason is stated by the project itself rather than inferred. The README says versions up to 12 are no longer actively maintained and points elsewhere. Adopting an unmaintained wallet client means accepting that dependency patches, fee estimation behaviour and protocol updates stop arriving from the original authors.

It is also the wrong tool when you do not want a server in the loop. A single-device wallet with no coordination requirement gains nothing from BWS and takes on its availability assumptions. The multisig machinery, the extended public key exchange and the spending proposal flow are costs you pay for shared control; if one person signs, they are overhead.

Finally, the build itself is a constraint. The README's browser instructions are development-only, and the production path runs through platform-specific bundles with Cordova for mobile and Electron for desktop. If your requirement is a small dependency footprint or a headless integration, this is a full application with a patched node_modules tree, not a library you import. The project's own warning about fake Copay wallets on the Google Play Store is a reminder that distribution for this class of software is part of the problem, not an afterthought.

Bitpay Wallet versus a single-key wallet such as Electrum

The useful comparison is not another multisig app but a standard single-key wallet, because that is where most users actually are. Electrum-style wallets assume one seed controls the funds and talk directly to servers or your own node. Bitpay Wallet assumes the opposite: the README states that creating a shared wallet requires the extended public keys of all participants, which are then folded into the wallet configuration.

That difference shows up everywhere. In a single-key wallet, recovery is a mnemonic and nothing else. Here, the README supports BIP39 mnemonics for backups, but a participant in a 2-of-3 wallet cannot reconstruct spending ability from their mnemonic alone; the wallet configuration and the other participants' extended public keys are part of the picture. The backupRecovery.md file at the repository root exists precisely because recovery is not a one-step story.

The practical consequence is that Bitpay Wallet is heavier to operate and harder to recover, and in exchange it removes single points of failure in signing. If your threat model does not include a compromised single key, the extra machinery buys you nothing, and a simpler wallet is the better choice.

Licence and the cost of keeping a fork alive

The repository is MIT licensed, and the package.json repeats that licence field. MIT is permissive: it allows modification, redistribution and commercial use, and it imposes no copyleft obligation on your changes. This article does not give legal advice, and the LICENSE file at the repository root is the authoritative text.

The practical implication for a fork is that you inherit the patching burden. The postinstall script runs npm run patch:all, which in turn runs patch:bwc, patch:walletconnect and patch:web3. Those scripts edit files inside node_modules, including a sed against bitcore-wallet-client's key.d.ts and a patch applied through utils/walletconnect-patch.sh. Any dependency bump that changes those files can break the patches, and the maintenance notice means upstream is not going to fix that for you.

Upgrade cost, then, is not measured in release cadence. It is measured in how much of the stack you are willing to own: the client, the BWS endpoint it depends on, and the patched third-party libraries underneath. The README's build instructions also begin with npm run clean-all to delete untracked files before a release build, which tells you the maintainers treated build reproducibility as something that required a clean tree. A fork inherits that requirement.

Editorial conclusion

This repository suits engineers who need to read or fork a multisig wallet built on Bitcore Wallet Service, and researchers comparing HD wallet implementations. It does not suit anyone who wants a wallet to hold funds today: the README states versions up to 12 are no longer actively maintained and points to bitpay/bitpay-app instead. Before doing anything else, read that notice at the top of the README, check whether the Bitcore Wallet Service instance the app talks to is still operated, and confirm the release you would build predates the newer app, since the latest release listed is v12.12.2.

Frequently asked questions

Official sources

1. bitpay/wallet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases