Gem Wallet - open-source Bitcoin wallet with DEX | iOS, Android

[satscraper]

Gem Wallet completed its first CertiK security audit - April 8, 2026.

No critical, no high vulnerabilities found. Audited: iOS & Android.

Gem Wallet is a fully self-custody and 100% open-source wallet. CertiK independently confirmed:

- Private keys are securely generated
- Keys are stored locally - only on the user's device
- Mnemonic access is protected by biometrics

Your keys are securely created and stored - and pose no threat to your assets.

🔗 Full report:
https://static.gemwallet.com/audits/Gem-Wallet-CertiK-Security-Audit-April-2026.pdf

🔗 CertiK Skynet:
https://skynet.certik.com/projects/gem-wallet

Thanks for sharing this.

According to report all medium‑severity issues have been fixed, but four low‑severity ones ^{namely. GEW‑02, GEW‑03, GEW‑04, and GEW‑11} are still outstanding. GEW‑02, which leaves room for the potential MITM attack, is probably the most concerning, though the other three aren’t exactly gift for user. Are there any plans to address all of these remaining issues together?

 

[GemUtxo]

Thanks for sharing this.

According to report all medium-severity issues have been fixed, but four low-severity ones namely. GEW-02, GEW-03, GEW-04, and GEW-11 are still outstanding. GEW-02, which leaves room for the potential MITM attack, is probably the most concerning, though the other three aren’t exactly gift for user. Are there any plans to address all of these remaining issues together?

Appreciate you digging into the report. Pinged the team about the open items, here's what they came back with:

The remaining items are low-severity hardening recommendations. Transaction signing in Gem Wallet happens fully locally on the device and always requires explicit user approval. There is no remote signing flow, and transaction data cannot be externally injected into the signing process in the way described.

We still review these findings internally and may address them as part of ongoing security improvements.

[satscraper]

Two days ago Gem Wallet was updated to v.2.72

This update replaced the separate URL‑parsing implementations on iOS and Android with the unified GEM implementation shared through the Rust core, so "both platforms now use a single, consistent system".

In addition, several bug fixes were included.

[satscraper]

Gem developers are on a roll  

New releases are dropping every day ^virtually.

Today they shipped v2.73, which includes several fixes and an update to the wallet’s codebase  ^{particularly improvements to Android device authentication.}

What could be expected tomorrow?

[GemUtxo]

What could be expected tomorrow?

Thanks for your updates, here's a roundup from me =>

Over this period there were 17 version updates, with the main focus on improving Android and the general infrastructure.

The most important:

• Maya Protocol - a new DEX protocol: swap native BTC to ETH and many other assets. No wrapped tokens, on-chain and without KYC. Announcement
  
• New DEX route for Tron - Gem Wallet added Tron swaps via Chainflip right in the app.
  
• Bitcoin signing in Rust (v2.80) - all the logic moved into the shared Rust core, one tested implementation for both platforms instead of two (exactly what you mentioned earlier). Link
  
• Gem Keystore - updated encrypted storage: a new Rust keystore, and on Android a switch to Tink instead of EncryptedSharedPreferences.
  
• WalletConnect - single-origin check, chain persistence, and a QR scanning fix on Android. Link
  
• Perps - perpetual futures right in the wallet! Open long or short in a couple of taps. Under the hood it runs on HyperLiquid: fully on-chain, full DEX.
  
• In-app support - improved, especially on Android (it's been on iOS for a while): added an AI agent that quickly helps with the basics, and for tougher cases it works together with a human available 24/7.
  
• Address book (Contacts) - an Android improvement: save addresses of friends and exchange accounts so you don't send to the wrong place and stay protected from scams.
  
• Wallet avatar customization - set your own icons for wallets.
  
• Staking improvements - unlock date for pending unstaking, network icons.
  
• Network fee in fiat - the confirm screen now shows the USD equivalent.
  

Full list of releases on GitHub

[satscraper]

What could be expected tomorrow?

Over this period there were 17 version updates,

I don’t even know whether this is good or bad. On one hand it shows your commitment to making improvements to your product. On the other hand, it suggests that every one of your releases is ill-considered, so there’s no need to rush through testing ^{as it is virtually impossible to be engaged every day in update business} and it is better to wait for a more stable version. So, speaking for myself, I decided to wait.

[GemUtxo]

On the other hand, it suggests that every one of your releases is ill-considered <...> and it is better to wait for a more stable version. So, speaking for myself, I decided to wait.

I understand your doubts - not many wallets update this often. But most updates are new UI features and their polishing, while the security core doesn't need such frequent changes.

Meanwhile, some news:

Gem Wallet is now listed on F-Droid
https://f-droid.org/en/packages/com.gemwallet.android

F-Droid users - download and check it out.

The F-Droid build comes without WalletConnect - the platform has strict rules about Firebase, which the WC library depends on. If you need WalletConnect, just upgrade to the universal APK.

[satscraper]

On the other hand, it suggests that every one of your releases is ill-considered <...> and it is better to wait for a more stable version. So, speaking for myself, I decided to wait.

I understand your doubts - not many wallets update this often. But most updates are new UI features and their polishing, while the security core doesn't need such frequent changes.

Yeah, too often, the last v.2.98 release, which spans just two commits, appeared 3 hours ago. With such frequent releases, you will occupy all GitHub space.

The security audit Gem wallet passed speaks well for the wallet, but I will wait until it reaches maturity because updating the wallet every day would be too bothersome for me. ^{Polishing UI is work that may never stop. Everything should have its limit.}

[GemUtxo]

Yeah, too often, the last v.2.98 release, which spans just two commits, appeared 3 hours ago.

We prefer frequent updates - they help us improve the user experience faster.

Gem Wallet Update

The devs have added a new Reproducible Builds page:

https://gemwallet.com/security/reproducible-builds/

For now it only covers the F-Droid build, but more builds will be added over time. So anyone can now verify that the Bitcoin wallet they're running matches the open-source code.

And since Gem Wallet is a multichain wallet, there's news beyond Bitcoin too - starting from version 2.96, Gem Wallet supports Robinhood Chain.

[GemUtxo]

Gem Wallet added a custom network fee for Bitcoin, version 2.114.4.

Now you can set the fee for a Bitcoin transfer manually, from 0.1 sat/vB.

More details: https://gemwallet.com/learn/gem-wallet-adds-custom-network-fees-on-bitcoin-set-your-own-sat-vb-and-stop-overpaying/

[Pmalek]

It's a good thing that you have added support for sub 1 sat/vByte fees. It's often not necessary to pay 1 sat/vByte or higher for a quick blockchain confirmation. I have another question, though. Why have you placed an upper limit at 20 sat/vByte? I don't remember the last time the fees were that high, but in case it happens, Gem Wallet users wouldn't be able to spend more on fees than that limit. Is it some sort of protection against overpaying and entering something ridiculous like 200/2000 sat/vByte? 

[GemUtxo]

Hi Pmalek!

Why have you placed an upper limit at 20 sat/vByte? <...> Is it some sort of protection against overpaying

It's not a fixed 20. The maximum is 10x the current rate: if it's 5 sat/vB now, you can set up to 50, and so on. The rate is re-fetched every time you prepare a transaction. It does protect against an accidental 2000, but it grows with the network, so setting a high fee during a busy mempool won't be a problem.

[Pmalek]

It's not a fixed 20. The maximum is 10x the current rate: if it's 5 sat/vB now, you can set up to 50, and so on. The rate is re-fetched every time you prepare a transaction. It does protect against an accidental 2000, but it grows with the network, so setting a high fee during a busy mempool won't be a problem.

I am pretty sure the article you posted earlier mentioned a fixed 20 sat/vByte upper limit on transactions but it looks as if you edited and changed that part.
Thanks for the clarification, though. When you say that the maximum is 10x the current rate, what source do you use to determine the current rate? Something like Mempool Space's high priority fee or do you have your own fee estimator?

[GemUtxo]

I am pretty sure the article you posted earlier mentioned a fixed 20 sat/vByte upper limit on transactions but it looks as if you edited and changed that part.
Thanks for the clarification, though. When you say that the maximum is 10x the current rate, what source do you use to determine the current rate? Something like Mempool Space's high priority fee or do you have your own fee estimator?

No fee estimator. The rates come from Blockbook - an open-source indexer for Bitcoin, it estimates fees from the mempool.
Thanks for the questions - they helped, the team corrected the wording about the limit in the article.