feat: add bluewallet

[Overtorment]

Building on top of #3000

Submitting BlueWallet for review and addition to onchain wallets.

Full disclosure, this PR was created with help of cursor and opus 4.7

[crwatkins]

Thanks much for the submission! We don't use superlatives (such as "most trusted" in the screenshot) in listings. Also, the screenshots could be more consistent with other listings showing the full screen with no titles. Yeh, I just looked at pictures! Will check out the rest soon.

[Overtorment]

roger roger! @ncoelho is working on replacement images

[Overtorment]

images replaced

[devdavidejesus]

I have reviewed BlueWallet based on the current wallet requirements criteria and my evaluation is below. The summary is that the wallet passes on security, architecture, and overall design, however because the website does not yet support HSTS, I cannot at this time recommend it for listing. I will be glad to recommend BlueWallet for listing once this website issue is resolved.

A few additional notes:

• BlueWallet's Lightning component is non-custodial as of the LndHub sunset in April 2023. Previous BlueWallet submissions (#2642, #2787, #3000) were closed for various reasons including the previously custodial Lightning component discussed in add bluewallet to wallets list #3000; that concern no longer applies.
• The optional criteria around desktop encryption-by-default and KDF/key-stretching are noted below; these are likely to become requirements pending merge of PR #4724, so worth flagging now even though they don't block listing under the current criteria.
• A small number of open issues touching balance/refresh timing exist in the repository (e.g. #7269, #7796), but during hands-on testing the balance and refresh behavior was within acceptable bounds, with only minor caveats (initial post-creation sync needed a manual refresh; push notifications arrived batched ~5–10 minutes after broadcast rather than near-instant). None of these felt like the kind of issue that would mislead a user into thinking funds were lost.

---

BlueWallet

Version v7.2.6 (latest tagged release; master at v8.0.0)

Review Version 2026051501

The wallet list is based on the personal evaluation of the maintainer(s) and
regular contributors of this site, according to the criteria detailed below.

These requirements are meant to be updated and strengthened over time.
Innovative wallets are exciting and encouraged, so if your wallet has a good
reason for not following some of the rules below, please submit it anyway and
we'll consider updating the rules.

Basic requirements:

• Sufficient users and/or developers feedback can be found without concerning
  issues, or independent security audit(s) is available

  PASS 8-year-old project with 3.1k+ GitHub stars, ~1,000 forks, 114 contributors, and active community engagement across GitHub, X and the project's Telegram group. No independent audits were found, but user/developer feedback is mature and substantive.

• No indication that users have been harmed considerably by any issue in
  relation to the wallet

  PASS No recent indications of significant user harm. (A historical incident referenced in #3000 involving the previously custodial LndHub component is no longer applicable since the LndHub sunset in April 2023.)

• No indication that security issues have been concealed, ignored, or not
  addressed correctly in order to prevent new or similar issues from happening
  in the future

  PASS The previously custodial LndHub Lightning component was sunset in April 2023 and Lightning is now non-custodial. GitHub Security Advisories: 0 published. Repository documents a vulnerability disclosure policy (SECURITY.md) with bluewallet@bluewallet.io as the contact channel for critical bugs.

• No indication that the wallet uses unstable or unsecure libraries

  PASS Uses @noble/secp256k1 1.6.3, bitcoinjs-lib 7.0.1, bip32 5.0.1, bip39 3.1.0, bip38 for password protection. All current, widely audited libraries.

• No indication that changes to the code are not properly tested

  PASS Repository has active CI via GitHub Actions (Tests workflow, iOS/Android/macOS build workflows), CodeQL security scanning, and Dependabot dependency updates.

• Wallet was publicly announced and released since at least 3 months

  PASS First release in 2018 (project age ≈ 8 years); 112 tagged releases total, latest release v7.2.6 (Feb 2026), most recent push to master today (May 14, 2026).

• No concerning bug is found when testing the wallet

  PASS Hands-on testing on iOS with on-chain send/receive flows showed no concerning bugs. Balance and refresh behavior was within acceptable bounds, with the minor caveats noted above.

• Provides a bug reporting method on the website and/or in the app

  PASS README and SECURITY.md document bluewallet@bluewallet.io for critical bugs/vulnerabilities. Additional channels on https://bluewallet.io/contact/ include GitHub issues, X and Telegram.

• Website supports HTTPS and 301 redirects HTTP requests

  PASS http://bluewallet.io redirects to https://bluewallet.io/

• SSL certificate passes Qualys SSL Labs SSL
  test

  PASS SSL Labs report for bluewallet.io: Grade A on all four GitHub Pages CDN endpoints (185.199.108.153, .109.153, .110.153, .111.153).

• Website serving or linking to executable code or requiring authentication uses HSTS

  • Existing listings: With a max-age of at least 180 days
  • New listings: With a max-age of at least 1 year, and preload and includeSubDomains directives to qualify for browser preload list inclusion
    e.g. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

  FAIL No Strict-Transport-Security header was present on https://bluewallet.io/. The site is hosted on GitHub Pages and links to executable code (App Store, Play Store, macOS download), so HSTS applies. (Note: this same FAIL was raised during the #3000 review in 2019.)

• The identity of CEOs and/or developers is public

  PASS Project lead Igor Korsakov (@Overtorment, igorkorsakov.com) is publicly identifiable as a co-creator of BlueWallet through the GitHub organization and his personal site.

• Avoid address reuse by displaying a new receiving address for each transaction
  in the wallet UI

  PASS

• Avoid address reuse by using a new change address for each transaction

  PASS

• Uses deterministic ECDSA nonces (RFC 6979)

  PASS Via bitcoinjs-lib 7.0.1 and @noble/secp256k1, which implement RFC 6979 deterministic signing by default.

• User has access to private keys for all major components of the wallet

  PASS

• If private keys or encryption keys are stored online:

  N/A

  • Refuses weak passwords (short passwords and/or common passwords) used to
    secure access to any funds, or provides an aggressive account lock-out
    feature in response to failed login attempts along with a strict account
    recovery process.

• If user has exclusive access over its private keys:

  • Allows backup of the wallet

    PASS BIP39 mnemonic provided at wallet creation with confirmation step.

  • Restoring wallet from backup is working

    PASS BIP39 restore is a documented standard feature of the wallet, supported via bip39 3.1.0 and bip32 5.0.1. (A BIP84-to-BIP49 restore bug was flagged in the #3000 review in 2019; six years and many releases later, no equivalent issue was reproduced or surfaced in the open issues during this review.)

  • Source code is public and kept up to date under version control system

    PASS https://github.com/BlueWallet/BlueWallet is public, MIT licensed, and actively maintained. (Tagged-release coverage was raised in the #3000 review in 2019; current releases are tagged consistently — v7.1.8 through v7.2.6 are all present in the GitHub Releases page.)

• If user has no access to some of the private keys in a multi-signature wallet:

  N/A

  • Provides 2FA authentication feature
  • Reminds the user to enable 2FA by email or in the main UI of the wallet
  • User session is not persistent, or requires authentication for spending
  • Gives control to the user over moving their funds out of the multi-signature
    wallet

• For hardware wallets:

  N/A (BlueWallet supports pairing with hardware wallets via PSBT but is not itself a hardware wallet)

  • Uses the push model (computer malware cannot sign a transaction without user
    input)
  • Protects the seed against unsigned firmware upgrades
  • Has capability to prevent firmware downgrades
  • Supports importing custom seeds
  • Provides source code created for all open components and provides detailed specification for blackbox testing of
    any closed-source secure elements

Optional criteria (some could become requirements):

• Does not show "received from" Bitcoin addresses in the UI

  PASS Transaction detail view shows the wallet's own input/output addresses and transaction ID, but does not display a "received from" sender address.

• Website serving executable code or requiring authentication is included in the
  HSTS preload list

  FAIL Site sends no Strict-Transport-Security header so not eligible.

• If user has exclusive access over its private keys:

  • Supports HD wallets (BIP32)

    PASS BIP32 HD wallet support via bip32 5.0.1.

  • Provides users with step to print or write their wallet seed on setup

    PASS Mnemonic shown at wallet creation with confirmation step.

  • Uses a strong KDF and key stretching for wallet storage and backups

    PASS Uses BIP38 password protection (scrypt-based KDF).

  • On desktop platform:

    • Encrypt the wallet by default

    OPEN On desktop (macOS), wallet encryption ("Password Protected: Encrypted storage with password") is available in Settings → Security as a toggle. Whether the wallet creation flow itself offers password setup as part of onboarding was not specifically tested in this review and would need separate verification. The precise interpretation of this criterion ("encrypt by default" vs. "offers to encrypt at setup") is itself under discussion in PR #4724; this point can be re-evaluated once both the criterion wording and the setup-flow behavior are confirmed.

[crwatkins]

@devdavidejesus Review LGTM.

[Overtorment]

I looked into HSTS issue, and its not something we can fix easily, without introducing more intermediaries (like Cloudflare or Netlify). Currently the website sources are static and live on Github, and are directly published to Github Pages, which is quite elegant if you ask me.

Is it something we can disregard?

[crwatkins]

I looked into HSTS issue, and its not something we can fix easily, without introducing more intermediaries (like Cloudflare or Netlify). Currently the website sources are static and live on Github, and are directly published to Github Pages, which is quite elegant if you ask me.

Is it something we can disregard?

The history here is that this has been a listing criterion for over a decade and every wallet listed during that time period has complied. After a decade, HSTS still remains a "good idea" protecting sites against practical MITM attacks such as sslstrip.

To be direct here, a wavier based on choice of hosting platforms would seem to allow just about any excuse (it's a pretty low bar) and would be paramount to removing the criterion. That said, a potential path forward would be a proposal issue or PR for removing the criterion. As much I would like to see BlueWallet listed, I'm not sure that's a good step forward.

[Overtorment]

i was thinking for a few workarounds:

• use our backup domains (bluewallet.dev for exampe, we also have .app which is not yet set up) - even tho github is not sending hsts headers for them, they are in browsers hsts preload list and still enforced
• add exceptions list to hsts rule (e.g. everything hosted github pages - they still enforce SSL)

worst case scenario, i will set up deployment on Netlify

[devdavidejesus]

Since the backup-domain option came up above, I verified the three BlueWallet domains against the official HSTS preload list (hstspreload.org) and checked what each one currently serves.

HSTS preload status:

• bluewallet.io — not on the preload list. Server sends no Strict-Transport-Security header.
• bluewallet.dev — on the preload list, via the .dev TLD entry (the preload entry is the TLD itself, not the subdomain).
• bluewallet.app — on the preload list, via the .app TLD entry (same situation).

None of the three sends an HSTS header at the server level (verified today). .dev and .app are TLDs that are themselves on the preload list, so any domain under them — including bluewallet.dev and bluewallet.app — gets HSTS enforced by the browser regardless of server headers.

What the domains serve: bluewallet.dev and bluewallet.app currently serve the exact same site as bluewallet.io — identical content (same content hash, same byte count of 64,669 bytes, same GitHub Pages hosting). They aren't placeholders; they already host the live site today.

Posting this just so the verified facts are on the record.

[crwatkins]

The requirement is that any sites serving executable code pointed to in the listing be HSTS enabled. Switching the link to one of the "backup" sites would certainly satisfy this requirement.

[Nicknic1]

I will consult with s professional first then I'll get back to it thanks

[Overtorment]

pull request updated to use dot-app domain

[crwatkins]

LGTM. I recommend BlueWallet for listing. Thanks everyone.

[Cobra-Bitcoin]

LGTM. Will merge once the iOS and Android screenshots are resized to 250x350.

Thank you for adding this wallet!

[devdavidejesus]

Just checking if there’s any feedback on this. @Overtorment
Thanks

[Overtorment]

PR updated

[devdavidejesus]

@Overtorment thanks for updating the images —> the iOS and Android screenshots look good now (both 250×350, filling the frame). Two things before this is ready to go in:

1. Desktop screenshot (bluewalletmac.png) —> the screenshot only occupies the top third of the image; the lower ~46% is transparent empty space (the file is 250×350 as required, but the content sits at the top and the rest is alpha 0). On the site that empty area picks up the page background, so it renders with the app squeezed into the top and a blank gap below, unlike the other two. Could you regenerate it so the screenshot fills the 250×350 frame the way the iOS/Android ones do?

2. Taproot tag —> now that the taproot feature selector is merged (#4779), BlueWallet qualifies for it. I checked the v7.2.6 source: there's a dedicated HDTaprootWallet (BIP86) class that generates P2TR (bc1p) receive addresses via bitcoin.payments.p2tr(...) and signs Taproot inputs (signTaprootInput + TapTweak, Schnorr via noble_ecc), and it's offered as a wallet type in the Add screen, so it meets the send-and-receive criterion.

Could you add the taproot token to the features: line? It appears twice in _wallets/bluewallet.md (line 17 for mobile, line 46 for desktop), currently:

features: "bech32 hardware_wallet legacy_addresses multisig segwit"

→

features: "bech32 hardware_wallet legacy_addresses multisig segwit taproot"

(both lines, so mobile and desktop stay consistent, same codebase backs both.)

Once those two are in, this should be good for merge.

[Overtorment]

PR updated

[devdavidejesus]

PR updated

LGTM.

Both items resolved, verified on 6ee8e40: the desktop screenshot now fills the 250×350 frame with no transparent gap, and the taproot tag is in on both feature lines.

@Overtorment , thanks for the quick turnaround on the images and the Taproot verification.

cc @Cobra-Bitcoin @crwatkins

[crwatkins]

LGTM.