Zilliqa warns Ledger app flaw can expose private keys from onchain signatures
Users who signed 5+ native Zilliqa transactions on Ledger are considered compromised as a coordinated fix is prepared.
Zilliqa disclosed a vulnerability in its Ledger app that it says can allow attackers to reconstruct private keys using publicly available onchain signature data. The team told users who signed at least five native Zilliqa transactions on Ledger to wait for further guidance while a corrected app is prepared with Ledger.
Key Takeaways
- A flaw in the Zilliqa Ledger app can allow private keys to be recovered from publicly visible onchain signatures, Zilliqa warned.
- The issue stems from signatures produced with predictably weakened ephemeral nonces, a condition that can make key recovery feasible from multiple signatures.
- Zilliqa labeled any user who signed at least five native Zilliqa transactions with a Ledger device as compromised and told them to await further guidance.
- EVM-compatible tooling for transacting ZIL was not affected, and a corrected Ledger app version is being prepared in coordination with Ledger.
Zilliqa Flags Ledger App Signing Flaw That Can Expose Private Keys
Zilliqa put a very specific kind of custody risk on the table. The network said a vulnerability in the Zilliqa Ledger app can enable attackers to recover users’ private keys using publicly available onchain data.
That framing matters because it is not the usual “your device was compromised” or “you clicked a bad link” incident. If the private key can be reconstructed from signatures that are already onchain, the attack surface becomes historical. The signatures are public, and the analysis can be done without touching the victim’s hardware.
Zilliqa also said “protective measures are in place to prevent further losses” and that “a coordinated remediation plan is being finalized.” The urgency here is obvious. If key recovery is possible from past activity, time becomes a variable, and the defender’s job is to reduce the window where an attacker can act on already-available data.
This disclosure also lands immediately after Zilliqa asked exchanges to temporarily pause ZIL deposits and withdrawals following a separate security vulnerability that resulted in theft of an undisclosed amount of ZIL from a cold wallet. That sequencing keeps operational risk front and center for anyone trading ZIL or managing settlement flows.
How Predictable Ephemeral Nonces Turn Public Signatures Into Key-Recovery Risk
Zilliqa attributed the root cause to a signing weakness inside the app: “The vulnerability causes signatures to be generated with predictably weakened ephemeral nonces, from which an attacker can recover the signer’s private key.”
At a high level, an ephemeral nonce is a one-time random value used during cryptographic signing. The whole point is that it should be unpredictable and effectively unique per signature. When that nonce is weakened in a predictable way, the signature can leak information about the private key.
The second-order effect is the part traders should internalize. Because signatures are embedded in transactions, and transactions are public, the raw material for the attack is already sitting in onchain data. That means the risk is not limited to a single compromised endpoint or a one-off phishing event. It can be exploited by analyzing prior signatures at scale, and the attacker’s cost is mostly computation and targeting.
Zilliqa’s own language implies the exploitability is tied to the signature set, not to a live interaction with the user. That is why this reads like a custody shock rather than a typical “patch your app” bug report.
Who Is Considered Compromised: The 5+ Native Ledger Transaction Threshold
Zilliqa drew a hard line around who it considers exposed. Users who signed at least five native Zilliqa transactions with a Ledger device are considered compromised, and they were advised to “await further guidance before taking any action.”
That “five transactions” threshold is doing a lot of work. It suggests the attack needs multiple signatures to analyze, which creates a clean segmentation between potentially exposed Ledger-native users and everyone else. If you never used the Ledger app for native Zilliqa signing, the disclosure is not describing you.
Zilliqa also narrowed the blast radius by stating that users transacting ZIL through EVM-compatible tooling were not affected. Practically, that means any immediate behavioral shift should concentrate in native Zilliqa transaction activity and among Ledger-native users, rather than across every route ZIL can move.
The instruction to wait is also a signal. When a team tells potentially compromised users not to take action yet, it usually means they are trying to manage the response centrally, likely to avoid chaotic key moves, missteps, or a rush of transactions that could create new failure modes. Zilliqa paired that guidance with the statement that protective measures are already in place, reinforcing that they are attempting to control the timeline.
Near-Term Signals: Fix Timing, Exchange Rails, and Any Follow-On Loss Disclosures
The next market-relevant inputs are operational, not philosophical.
First is release timing and version detail for the corrected Zilliqa Ledger app, which Zilliqa said will be published in coordination with Ledger. Coordination is a dependency, and until there is a shipped version, the market is trading uncertainty.
Second is updated guidance for the cohort Zilliqa labeled compromised. The key question is whether Zilliqa ultimately recommends key rotation or migration steps, and what sequence it wants users to follow. The current instruction is explicit: wait.
Third is exchange rail status. Zilliqa’s earlier request that exchanges pause ZIL deposits and withdrawals after the cold-wallet theft is a direct liquidity constraint if it persists. Re-enablement would relieve friction. Further restrictions would tighten it.
Fourth is loss disclosure. The amount of ZIL stolen from the cold wallet remains undisclosed, and there has been no quantified disclosure of any additional confirmed losses tied to the Ledger app vulnerability. Any hard number here changes how desks model supply overhang and counterparty behavior.
Price action is already soft into the disclosure. At publication, ZIL traded above $0.0024, down 1.5% over 24 hours and down 17% over the past week, per CoinMarketCap. In that context, incremental security updates can act as volatility catalysts because positioning is already fragile.
This Is a Custody Shock With Liquidity Side-Effects, Not Just a Bug Report
I’m treating this as a custody event first and a software issue second, because Zilliqa’s own claim is that private keys can be recovered using publicly available onchain data. That is the line that changes the risk model. If the attacker can work from historical signatures, the threat is not gated by compromising a device today. It is gated by whether enough signatures exist to make recovery feasible.
The “five native transactions” threshold is the other tell. It implies a multi-signature requirement, which is consistent with why Zilliqa can segment users into “compromised” and not. For markets, segmentation matters because it shapes flow. If only a subset of holders are at immediate risk, you get concentrated behavior, not a uniform bank run.
Scenario one is the contained remediation path. A corrected app ships quickly, Zilliqa issues clear next steps for the 5+ transaction cohort, and exchange rails normalize after the earlier pause request. In that case, the shock is mostly about trust and near-term activity disruption in native Zilliqa signing, not a broad impairment of ZIL transferability. Confirmation would be a released app version coordinated with Ledger plus updated guidance that is actionable and consistent with “protective measures” already being in place.
Scenario two is the messy middle. The fix timeline drifts, guidance remains “wait,” and exchanges keep deposits and withdrawals constrained because operational risk stays elevated. That is where liquidity side-effects show up. Even without new theft disclosures, constrained rails can widen spreads, increase slippage, and make price discovery more jumpy because fewer venues can warehouse flow. Confirmation would be continued uncertainty on release timing and no clear statement on when users should rotate keys or migrate.
Scenario three is escalation via loss disclosure. If Zilliqa later quantifies the cold-wallet theft or confirms additional losses tied to the Ledger app vulnerability, the market will reprice the incident from “potential exposure” to “realized damage.” The invalidation point for escalation is simple: no additional losses disclosed and a fix shipped with clear user instructions.
The core thesis is that Zilliqa’s onchain-signature key recovery warning turns this into a time-sensitive custody shock that can spill into liquidity if exchange rails and remediation timing stay constrained, and it will be confirmed if the fix and guidance lag while deposit and withdrawal access remains restricted.
