Overview
Pera Wallet, an affiliate of Algorand, engaged Hacken to assess its Algorand wallet application and the key-custody and passkey infrastructure beneath it. The white-box review covered four repositories: 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.
About Pera Wallet
Pera Wallet is a non-custodial wallet for the Algorand blockchain. Users create or import accounts and manage ALGO, Algorand Standard Assets and NFTs entirely from their own device. It supports legacy 25-word Algorand mnemonics, BIP-39 hierarchical deterministic wallets, watch-only and Ledger-backed accounts, multisignature accounts, WalletConnect connectivity to third-party Algorand applications, and a rekeying system that changes an account's signing authority without changing its address.
Because the wallet is non-custodial, every property a user depends on is enforced on the device. There is no server-side control to compensate for a weakness in how keys are derived, encrypted, stored or presented for signing.
Audit Approach
Hacken reviewed the wallet as one system rather than four separate codebases. The passkey module and the wallet keystore share storage namespaces and derivation paths, so each repository was assessed individually and then the interactions between them were examined.
The assessment covered:
- Private-key custody, derivation and encryption
- Passkey creation, assertion and credential storage
- WalletConnect session management and signing requests
- PIN, biometric and duress-PIN gating
- Platform storage, logging and build configuration
The work followed NIST SP 800-115, the Penetration Testing Execution Standard and the OWASP Testing Guide.
Key Findings
Key custody and encryption. The highest-rated finding concerned an unused keystore helper - not active in Pera Wallet's production workflows - that derived its symmetric encryption key from a public key. A public key is not secret, so any party holding it could reproduce the key and decrypt. Related findings covered passkey private keys stored in encoded plaintext when the mirrored master key was unavailable, and an enumeration path that decrypted every stored passkey key before authentication.
Passkey and WebAuthn ceremony integrity. On Android, the WebAuthn user-verified flag was set unconditionally, so a relying party could be told verification had occurred when no biometric prompt had run. Credential enumeration did not filter by the requested relying-party identifier, and deterministic derivation used the display name rather than the stable user handle, so two accounts sharing a name converged on the same key material.
Destructive scope and partial state. A routine exposed as passkey cleanup cleared the storage namespace shared with the wallet's primary keystore, removing seed, account and identity records rather than only passkey-owned entries. Keystore hydration dropped records that failed to decode while reporting success.
Session and origin handling. A WalletConnect disconnect callback captured stale connection state, so a later disconnect event could restore a session that had already been revoked, including its session key. Session secrets were persisted without application-layer encryption, and connection and signing identity badges were derived from peer-asserted URLs rather than the authenticated origin.
"As a non-custodial wallet provider, the security and safety of our app is central to everything we do. That's why having an independent review of our most critical security surfaces was important to us, to ensure that our code is vetted, not just by our own security engineers, but by external experts also." - said Will Beaumont, Head of Engineering at Pera Wallet
Audit Results
Following the audit and remediation process, 16 findings were resolved, 4 were accepted and 1 was mitigated.
Pera Wallet treated the remediation window as a starting point, not a deadline. The first High-severity finding was escalated to the package maintainer the same day we raised it, and the team had remediating pull requests linked to every finding in our portal about two weeks before the window closed. Each fix came with a description of the change, and the findings they chose to accept came with a written rationale. When we added further findings later in the process, those were addressed within a day. For a non-custodial wallet, where every security property is enforced on the device, that kind of response is what turns an audit into an actual improvement in the product.
The fixes prevent:
- Decryption of keystore ciphertext by any party holding the corresponding public key
- Passkey cleanup removing seed, account and identity records from the shared keystore namespace
- WebAuthn responses asserting user verification that did not take place
- Restoration of revoked WalletConnect sessions, and persistence of session secrets outside protected storage
The review also recorded branch coverage across the four repositories between 80% and 97% for most security-relevant packages, with dedicated tests for fail-safe behaviours such as master-key-unavailable handling and relying-party-ID scoping.
Read the full audit report: https://hacken.io/audits/perawallet/dapp-perawallet-code-review-aug2026/
Request a dApp Security Assessment
Hacken provides security assessments for wallets, decentralised applications and the native modules and key-management infrastructure beneath them, across mobile and web environments.
Each engagement combines automated analysis, manual security review and proof-of-concept development, performed by Hacken's in-house security team.
