DESCRIPTION
The target of this audit is the code repository of smart-wallet-recovery && groth16-solana of OKX. This project is a smart account recovery system deployed on Solana. It combines ZK-Email zero-knowledge proofs, ECDSA signature verification, and a DKIM registry to provide scalable, low-interaction account recovery. Smart wallet providers can pre-register their DKIM public keys via the DKIM registry, eliminating the need to trust third-party DNS providers. When a user needs to recover an account, they submit proofs to the recovery-manager contract, which consist of an off-chain generated ZK-Email proof demonstrating ownership of a specific email and an off-chain 2FA-verified ECDSA signature. After verification, the smart account’s owner key can be updated, completing the account recovery process.
Please refer to the report for the detailed audit scope.
Our audit methodology employs automated vulnerability scans, manual verification, and business logic analysis to uncover potential security issues coupled with gas and code quality optimization recommendations.
In summary, we did not find any critical issues within the audited codebase. However, we have identified some non-critical issues that should be addressed. Additionally, we have put forth recommendations to further strengthen the code logic, along with notes that should be taken into consideration. It is important to note that the scope of our audit was strictly limited to the specific code versions mentioned in the report. Any updates made subsequent to our review would require a re-evaluation.
KEY FINDINGS
In total, we find 2 potential issues in the smart contract. We also have 1 recommendations and 6 notes, as follows:
| ID | Severity | Description | Status |
|---|---|---|---|
| 1 | Low | Lack of binding check for smart_account_program in function recover() |
Fixed |
| 2 | Low | Potential DoS during submitting proofs | Fixed |
| 3 | - | Applying global index in the function pack_bytes_2fields() |
Fixed |
| 4 | - | Execution ordering of concurrent proposals with identical identifiers | - |
| 5 | - | Ensure off-chain negation of proof_a before submission in Groth16 verification |
- |
| 6 | - | Ensure timestamp consistency for multiverifier proofs | - |
| 7 | - | Potential centralization risks | - |
| 8 | - | Ensure consistency between user-provided recovery methods and smart_account configured recovery methods |
- |
| 9 | - | Verifier program initialization consistency are not enforced | - |
More details are provided in the audit report.