Hacken's Pera Wallet review finds no critical flaws, with one High in shared code
Hacken's review of Pera Wallet's rebuilt app, published November 10, found no critical issues among 21 findings; the single High sits in a shared keystore package outside Pera's app paths. Holders can update from the app store to the audited build.

Pera Wallet has published an independent security review of the mobile app it rebuilt this summer, and the auditor found no critical flaws. Hacken1 reviewed the app, its key custody and its passkeys over September and October 2026.
Pera Wallet2 is a self-custodial Algorand wallet: the user alone holds the private keys. Its 7.03 rebuild this summer replaced the separate Swift and Kotlin apps with one React Native codebase for both platforms.
The review is the check our August coverage of that rebuild noted was missing. It landed on the codebase both stores now run.
What was reviewed
Hacken's case study dates the review to September and October 2026 and names four repositories. They are the React Native wallet app, the shared wallet-provider base package, the keystore and account extensions built on it, and the native passkey autofill module for Android and iOS. Only the app repository is Pera's own. The other three are Algorand Foundation projects, which is what Pera's blog post4 describes when it says part of the scope covered shared open-source infrastructure maintained by Algorand, including components that power Rocca Wallet. Rocca is the Foundation's wallet framework that Pera says 7.0 is partly built on. The app repository is the one the rebuild produced, so a single review now covers both platforms.
The report5's changelog dates the preliminary version September 1, 2026 and the final report October 19, 2026. Pera's blog post and Hacken's case study both went up on November 10.
The audited list holds four repositories and no browser extension. Pera's home page promotes one anyway, billed 'Pera Is Now in Your Browser6'.
What was found
Hacken's case study reports 217 findings and states that no critical-severity issues were identified during the audit. Its remediation tally marks 168 of the findings resolved, 49 accepted and 110 mitigated. Hacken also records branch coverage across the four repositories from the high 60s to 100%11 per package, with most security-relevant packages between 80 and 97%12.
Pera's blog post, published the same day, says the audit 'wrapped up in October 202613' and that 'every identified finding has since been resolved14'. It adds: 'No Critical vulnerabilities were found, and all identified findings have been addressed.15' Pera's 'addressed' therefore covers fixes, one mitigation and four findings accepted as they stand.
The single High finding
One issue carried a High rating, and because the user alone holds the keys, a weakness in this layer has no server-side backstop. Hacken describes the finding as an unused helper in the shared keystore package, not active in Pera Wallet's production workflows. The helper derived its encryption key from a value that is not secret, so anyone holding that value could reproduce the key and decrypt. Projects other than Pera that build on the shared package can call the affected code, the report's note adds. Hacken says the issue was escalated to the package maintainer the same day it was raised. Pera had remediating pull requests linked to every finding about two weeks before the remediation window closed.
That description matters for anyone tempted to read the High rating as an app-wide alarm. The auditor places the flaw outside the paths Pera's app runs, in code other wallets and projects share.
Where the findings clustered
Hacken's summary groups much of the review around passkeys and WebAuthn handling. Its report lists an Android path that told a relying party a user had been verified when no biometric prompt had run. It lists cleanup code that could wipe the wallet's whole shared keystore namespace rather than only the entries passkeys own. And it lists a deterministic derivation keyed on an account's display name instead of its stable WebAuthn user handle, so two accounts sharing a name could land on the same key material. The last of those is among the four accepted findings, along with an observation about how the PIN retry lockout keeps time.
That surface belongs to the newest wallet type. Pera's passkey guide16, updated October 28, 2026, says passkeys are available only for Universal Wallets, not legacy Algo25 wallets. They are derived from the Universal Wallet and stored on the device, and the guide says Liquid Auth protocol support is 'coming soon'. A Universal Wallet draws up to 50 accounts from one 2417-word BIP-39 phrase. So the deepest part of the review concerns the wallet type that uses passkeys, and only those holders who have set them up.
Who did the review
Pera commissioned the work: Hacken's case study calls Pera Wallet an affiliate of Algorand that engaged Hacken to assess its wallet application and the key-custody and passkey infrastructure beneath it. 'Independent' describes who did the work, not who asked for it.
Will Beaumont, Pera's Head of Engineering, is quoted in the case study on why the review mattered. He said the code should be vetted by external experts as well as Pera's own security engineers.
What a reader does now
Pera says the audited build is the one on the stores, so the step for a holder is an app-store update. Anyone who wants to weigh the review itself can open the report, which lists each finding with its severity and its status.
- Findings identified: 21.
- Resolved: 16.
- Accepted: 4.
- Mitigated: 1.
12 figures in this story are checked.See every check