Cardano Wallet Security: How GeroWallet Is Hardened

Cardano wallet security comes down to four things: how your keys are encrypted on disk, what happens when a website asks your wallet to sign something, whether the signing key can be kept off your computer entirely, and whether anyone independent has actually checked the code. Most wallet security pages talk about the first and skip the rest. This article walks through all four, and covers what GeroWallet changed in version 2.7, released on 19 August 2026, which included two external audit rounds and an internal review completed before the source code was published.

TL;DR

Cardano wallet security rests on four things: how your keys are encrypted at rest, how signing requests from dApps are checked, whether the key can live on a hardware device, and whether anyone independent has read the code. GeroWallet 2.7, released on 19 August 2026, moved key encryption to Argon2id, locked dApp signing to the real request origin, passed two external audit rounds plus an internal review, and published the full source under Apache 2.0. Ledger, Trezor and Keystone are supported, and passkeys are an option next to your spending password, not a replacement for it.

Where GeroWallet fits: every claim above can be checked in the public repository, and the security page lists the current state. Install GeroWallet to use it.

What actually protects a non-custodial wallet

A non-custodial wallet holds a private key that only you control. That single design decision removes an enormous category of risk, because there is no company account to be drained, frozen or hacked in bulk. It also concentrates the remaining risk in a small number of places.

Your key at rest. The key lives, encrypted, on your device. The strength of that encryption, and specifically the function that turns your password into an encryption key, decides how long an attacker with a copy of your storage would need.

Your key in use. Every signature is a moment where something could be signed that you did not intend. The attack is rarely "steal the key" and usually "trick you into approving something".

The code itself. Bugs in the wallet are bugs in the thing holding your funds. This is where audits and public source code come in.

You. Phishing, fake support and malicious approvals cause more losses than cryptographic failures do, by a wide margin.

Everything below maps onto one of those four.

Key derivation: why Argon2id is the important change

When you set a spending password, the wallet does not use that password directly as an encryption key. It runs it through a key derivation function first. That function is the thing standing between an attacker who has copied your encrypted storage and an attacker who has your funds.

A weak key derivation function is fast, and fast is exactly wrong here. Speed lets an attacker try billions of candidate passwords against your encrypted data, using commodity graphics hardware, offline, with no rate limiting and no way for you to notice.

A strong one is deliberately slow and, in the modern designs, deliberately memory-hungry. Argon2id is memory-hard, which means each guess requires a meaningful chunk of RAM as well as time. That is what defeats cheap parallel hardware: an attacker can put thousands of cores on the problem, but they cannot cheaply give every core enough memory.

GeroWallet's hardening pass upgraded mnemonic, two-factor and MPC encryption from a weak key-derivation scheme to Argon2id. This was classified as a critical fix, and it was handled the way migrations should be: backward compatible, with existing wallets migrating transparently rather than being asked to do anything.

The legacy crypto-ts library was then removed entirely, including its weak wrapper around root-key, Bitcoin and Midnight key encryption. Removal is the part that matters. A weak code path that still exists is a weak code path that can still be reached, so regression tests were added specifically to guard the legacy decrypt path during migration.

This does not make a bad password safe. It makes a decent password dramatically more expensive to attack.

Two external audits and an internal review

Publishing source code and commissioning audits solve different problems, and doing both is the point.

An audit is a focused, adversarial review by people paid to break things, working with full access and a deadline. Public source code is unbounded, unpaid, and continuous. Neither substitutes for the other. Auditors have a scope and a cutoff date; the public has neither.

GeroWallet 2.7 went through two external audit rounds plus an internal pre-open-source review, on the sound assumption that publishing a wallet's source code is a good moment to have checked it thoroughly first.

The repository now also carries a SECURITY.md with a responsible disclosure process, including an email fallback for researchers who would rather report privately than open a public issue. This sounds administrative and it is genuinely load-bearing: a project with no private reporting route is a project that learns about its vulnerabilities from social media, at the same time as everybody else.

Closing the dApp attack surface

This is the part most users never see and the part where real losses happen.

When you connect a wallet to a dApp, you are giving a website the ability to ask your wallet to sign things. Every wallet does this, and the security question is how carefully the wallet checks what is asking and what it is asking for.

Several changes landed here.

Signing requests trust only the relay-set origin. Previously, a signature request could carry an origin claim from the page itself. Now signTx trusts only the origin set by the extension's own relay, which means a malicious page cannot pretend to be a dApp you trust. Origin spoofing is a well-worn technique, and this shuts it down.

CIP-30 reads validate frame sources. Read requests from embedded frames are checked against a server-side whitelist rather than being accepted on the strength of what the frame says about itself.

Sensitive cross-device calls are restricted to the extension's own pages, so an arbitrary web page cannot reach them.

OAuth flows moved to a cryptographically secure random number generator. Predictable randomness in an authentication flow is the kind of quiet bug that is invisible until someone exploits it.

API keys are no longer baked into the client bundle. Anything shipped in a browser extension is readable by anyone who installs it, so secrets do not belong there.

Changing your spending password invalidates the old one immediately, within the session, without forcing a re-login. If you change a password because you think it was exposed, a delay before it takes effect is precisely the wrong behaviour.

Alongside the code changes, dependency overrides and an npm audit pass cleared the production-critical vulnerabilities in third-party packages. Supply chain issues account for a large share of real-world extension compromises, and the continuous integration workflows were hardened to match, with fork pull request guards and GitHub Actions pinned to specific commit hashes.

Hardware wallets and passkeys

The strongest single improvement most people can make is keeping the signing key off their general-purpose computer.

GeroWallet supports Ledger, Trezor and Keystone. With a hardware wallet, the private key never touches the browser. Malware on your machine can request a signature, and it cannot produce one, because the transaction has to be confirmed on the device's own screen. That physical confirmation step is the whole security model, which is why it matters that you read what the device shows you rather than clicking through it.

Trezor support also improved: signing now works over WebUSB without needing the Bridge daemon, including transaction and data signing through a device-verified popup window. One fewer background service on your machine is a small security win as well as a convenience one.

Passkeys and WebAuthn are available as an option, letting you use hardware-backed platform authentication instead of typing a password for supported actions. Two clarifications, because this gets overstated. A passkey is an option layered onto the wallet, not a replacement for the entire authentication model, and a spending password still exists. Anyone telling you a wallet has "no password" is describing something else.

There is a practical caveat worth knowing: creating a PassKey wallet requires browser support for a feature called PRF, which some browsers do not implement. Where it is missing, such as in Brave, the wallet falls back gracefully rather than failing confusingly.

Is GeroWallet safe?

The honest answer to "is any wallet safe" is that safety is a property of the whole system, including you. Here is what can be stated factually.

It is non-custodial. Keys are generated and held on your device. Nobody at Gero can move your funds or freeze your wallet.

The code is public and checkable. The full source is at github.com/Gero-Labs/gerowallet, under the Apache 2.0 licence. You can read exactly how keys are handled instead of taking anyone's word for it, and the open source verification guide shows where to look.

It has been externally audited, in two rounds, with an internal review on top.

Key encryption uses Argon2id, with the legacy weak path removed rather than merely bypassed.

Hardware wallets are supported, all three of Ledger, Trezor and Keystone.

Scam detection is built in. Cardano Shield flags known scam patterns, and Xerberus risk ratings give token-level context before you interact with something unfamiliar.

What no wallet can do is protect you from approving a malicious transaction yourself, or from giving your recovery phrase to someone claiming to be support. Nobody at Gero, or at any legitimate wallet, will ever ask for your recovery phrase.

What we are not claiming

Not unhackable. No software is, and any wallet claiming otherwise is a warning sign.

Not audited into permanence. Audits have a scope and a date. Code changes after them.

Not "no password". Passkeys are an option; a spending password still exists.

Not proof that your installed build matches the repository. Reproducible builds remain unsolved across most of the browser extension ecosystem, and pretending otherwise would be dishonest.

Frequently asked questions

Is GeroWallet safe to use?

It is non-custodial, externally audited in two rounds, encrypts keys with Argon2id, supports Ledger, Trezor and Keystone hardware wallets, and publishes its full source code for inspection. No wallet can protect you from approving a malicious transaction or sharing your recovery phrase.

What is Argon2id and why does it matter?

Argon2id is a memory-hard key derivation function. It converts your password into an encryption key slowly and using significant memory, which makes large-scale offline password guessing expensive. GeroWallet moved mnemonic, two-factor and MPC encryption to it, migrating existing wallets transparently.

Has GeroWallet been audited?

Yes. Version 2.7, released on 19 August 2026, included two external audit rounds plus an internal review carried out before the source code was published.

Does GeroWallet support hardware wallets?

Yes, all three of Ledger, Trezor and Keystone. Trezor now signs over WebUSB without needing the Bridge daemon.

Can GeroWallet access my funds?

No. It is non-custodial. Keys are generated and stored on your device, and the recovery phrase is exportable, so you can move to another wallet at any time.

Use a wallet you can verify

Security claims are worth exactly as much as your ability to check them. GeroWallet is a non-custodial Cardano browser extension with hardware wallet support, optional passkeys, Cardano Shield scam detection, Xerberus risk ratings, ADA staking and governance, and a source repository you can read line by line.

Install GeroWallet, read more on the security page, or see the full feature set at gerowallet.io/features.