Overview
Zilliqa engaged Hacken to assess the zero-knowledge system it built to let holders of legacy Zilliqa 1.0 accounts migrate to Zilliqa 2.0. The review covered the proving circuit, the key derivation beneath it, the escrow contract that releases funds, and the desktop application through which holders operate all three. The assessment was completed before the tool reached users.
About Zilliqa
Zilliqa is a high-performance public Layer 1 blockchain platform designed to solve scalability issues by processing transactions in parallel using a technique called sharding.
Zilliqa 1.0 was a Layer-1 that combined proof-of-work consensus with pBFT finality and EC-Schnorr transaction signing over secp256k1. It was retired in favour of Zilliqa 2.0, an EVM-compatible proof-of-stake chain that continues to support legacy Zilliqa 1.0 accounts and transaction formats. Holders of those legacy accounts need a route to EVM-compatible addresses, and that route has to work without exposing the underlying key material along the way. Because a migration proof can be submitted once and the payout cannot be reversed, correctness and recoverability carry equal weight.
Audit Approach
A July 2026 incident exposed the leaf keys of a section of users, so the migration route had to hold where a key was already compromised. The system proves ownership from the parent node one level up the BIP-32 derivation tree rather than from the leaf key: the seed holder can produce a proof, a stolen leaf key cannot.
Hacken assessed that design and everything carrying a holder's input into it:
- Groth16 circuit and in-circuit BIP-32 child key derivation
- Escrow contract deposit and claim paths
- Proving flow and key handling in the desktop client
- Mnemonic, passphrase and address validation
- Wallet derivation conventions in real-world use
Key Findings
Destination integrity. The address field validated shape alone, discarding the EIP-55 checksum, and never confirmed the destination back to the holder. A mistyped address would pass validation, bind into the proof, verify correctly and be paid out, with no recovery path. Checksum enforcement and a confirmation step were added.
Seed and passphrase handling. The BIP-39 passphrase was trimmed of surrounding whitespace before derivation, although BIP-39 treats it as significant. A passphrase beginning with a space — a common artefact of copying from a password manager — produced a different but equally valid wallet, and the tool reported the seed as underivable rather than naming the cause. Passphrases now reach derivation unmodified.
Wallet convention coverage. The circuit's final derivation step was fixed to a hardened index, matching Ledger's convention, with no non-hardened template anywhere in it. Holders using standard BIP-44 wallets could not produce a proof at all, and saw no diagnostic separating an unsupported path from a wrong seed. Both paths are now supported.
Mnemonic language support. Validation accepted ASCII only, rejecting six of the ten BIP-39 wordlists, and an unnormalised ideographic space rejected Japanese phrases typed with a regular space. All ten are now accepted, with Unicode normalisation applied.
"Security is a precondition for a migration tool, not a feature of one. Holders get one attempt and no way back. Independent assessment before release is how we satisfied ourselves the system was correct for people who did nothing wrong." – Alexander Zahnd, CEO at Zilliqa.
Audit Results
The final report records 20 findings:
Following the audit and remediation process, 18 findings were resolved, 1 was accepted and 1 was mitigated. The mitigated finding covers circom dependency vulnerabilities not exploitable in this configuration. The accepted finding records that the escrow's deposit entry point is unguarded, so a deposit sent by an arbitrary caller is permanently destroyed.
Key changes delivered:
- EIP-55 checksum enforcement and a destination confirmation step were added before proof submission
- Passphrases were passed to seed derivation unmodified
- Non-hardened BIP-44 derivation was added alongside the hardened Ledger path
- Mnemonic validation was extended to all ten BIP-39 wordlists with Unicode normalisation
The review also documented the tool's coverage boundary: the escrow handles native ZIL only, legacy multisig holders use a derivation scheme the circuit does not cover, and wallets that never exported a mnemonic or extended key cannot produce the required witness.
Full audit report: https://hacken.io/audits/zilliqa/sca-zilliqa-zilliqa-ownership-proof-aug2026/
Request a Smart Contract Audit
Hacken provides security assessments for zero-knowledge circuits, smart contracts and the client software that carries user input into them, across permissioned and permissionless environments.
Each engagement combines automated analysis, manual security review and proof-of-concept development, performed by Hacken's in-house security team.
