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?