Security you can verify, today, and a wallet migration feature we're building for the future
Trust in crypto shouldn't be something you're just asked to take on faith. It should be something you can check for yourself. That's the thinking behind everything we do at Lace, and it's exactly why we want to talk openly about our recent security audit, what was found, what we did about it, and where you can go to read every detail yourself.
Why we invite outside scrutiny
We take pride to say that Lace is open source, and it's a foundational choice. Every line of code we ship is public, which means anyone, anywhere, can look under the hood, ask questions, and hold us accountable. But open source is only half the picture. The other half is actively inviting security experts to try to break what we've built, before anyone else can.
That's why we commissioned three independent security audits from No Witness Labs (NWL), covering our browser extension and our mobile app. Between them, these audits produced 50 findings across our codebase.
What "transparent" actually means here
Regular, independent audits have been part of how we operate at Lace since the very first release of Lace 1.0. It's not a box we check once and forget, it's a habit built into how we ship. Our latest three audit reports look at the Lace 2.0 platform.
You can read the complete disposition in our audit response document, and download the original signed audit reports themselves from our audit reports repository.
Every finding, resolved or explained
Of the 50 findings across all three audits, every single one now falls into one of two categories:
- Fixed: remediated in our current codebase, with the fix pointing to the exact file or function that carries it, so anyone can verify it directly against our public repository.
- Accepted with a documented rationale: a small number of findings where, after careful review, we made a deliberate decision not to change the code, and we explain precisely why.
And here's the part we want to be unambiguous about: not one accepted finding represents a reachable path to loss of funds, private keys, or recovery material. That distinction matters enormously, and it's one our team, and the security engineers who reviewed each acceptance, take seriously.
A few highlights of what changed
Some of the fixes worth calling out, in plain terms:
- Stronger key protection for new wallets. New wallets created use Argon2id, a modern, OWASP-aligned method for deriving encryption keys, replacing an older, less sophisticated approach.
- Safer image handling. Token and NFT metadata images can no longer be used to attempt to execute malicious code.
- Password attempt limits. Unlock attempts are now tracked with an escalating lockout, so brute-force guessing isn't a viable strategy.
- Stronger password requirements. New wallets are guided toward genuinely strong passwords, not just technically-valid ones.
- API keys moved server-side. The risk of API abuse is mitigated by routing all remaining API calls through server-side proxies.
- Memory hygiene. We've tightened up how Lace handles sensitive information like your recovery phrase and encryption password. In practice, this means Lace only accesses this data for the brief moment it's needed to complete your request, then clears it from memory right away. That way, there's no lingering trace left behind for anyone to find.
And where we chose not to change something
Good security isn't about reflexively "fixing" everything a report flags, it's about understanding real risk and making informed, defensible calls. A few examples of decisions we stand behind:
- We don't currently pin SSL certificates on mobile, because doing so would trade a narrow security gain for a real risk of breaking the app during routine certificate rotations, and no funds or session credentials ever travel over that network connection in the first place.
- We don't build Tor support directly into Lace, as a deliberate choice to leave networking and anonymity decisions in your hands, not ours. How you route your traffic is a personal preference, not something a wallet should decide for you. If you want that extra layer, you're free to run Lace behind your own VPN or Tor setup. And to be clear: using Lace without one doesn't put your funds or keys at risk, this is a privacy preference, not a security gap.
- We don't do jailbreak/root detection, because these checks are trivially bypassed by the exact attackers they're meant to catch, and we'd rather rely on the hardware-backed protections your device actually enforces.
Every one of these decisions is documented with the reasoning behind it, and each includes clear conditions under which we'd revisit the call. Nothing is set in stone but it's just where the evidence points today.
Read it yourself
We could tell you our wallet is secure. We'd rather show you the receipts.
- Full audit response - every finding, fixed or explained
- Download the original signed audit reports
What's next: making moving to Lace even easier
Trust doesn't stop at the code, it extends to how easy we make it for you to actually get here. That's why we're working on a wallet migration feature, coming in a near-future release, designed to let you bring your existing wallet over to Lace smoothly and securely, without the friction that usually comes with switching. We'll have more to share soon, stay tuned.