Summary
On Sunday, July 27, 2025, a vulnerability in the EcPairing precompile was reported in a recent, audited code. The bug could have allowed a malicious validator to forge the precompile execution to accept invalid inputs as valid. An emergency protocol upgrade was prepared and deployed. The patch was rolled-out to Era mainnet and Gateway first, followed by upgrades across other ZK chains. No chains were attacked or exploited. The system remained secure thanks to ZKsync’ multi-layer defense-in-depth security architecture.
Details of the bug report
ZKsync proves transaction batches using ZK circuits. To make proving efficient, execution is decomposed across several circuits that are responsible for different components: precompiles, RAM, basic operations, etc. Each circuit provides input/output commitments for later aggregation. Final Scheduler circuit verifies the consistency of those commitments, and aggregates them into a single proof. Only when the commitments are consistent can the prover generate the final proof.
Per EIP-197, the precompiled contract verifies that the product of pairings equals one:
e(a1, b1) * ... * e(ak, bk) = 1
On ZK chains, there is a circuit type that computes a single pairing and stores it in a running accumulator — pairing_inner_state:
pairing_inner_state <- pairing_inner_state * e(x, y)
The bug was in the input/output commitments of the EcPairing circuit which omitted pairing_inner_state. As a result, witnesses that differ only in pairing_inner_state produced the same cryptographic commitment. The Scheduler only checks these commitments when aggregates circuits. A malicious prover could substitute pairing_inner_state, and so manipulate the EcPairing precompile result by verifying invalid inputs as valid.
Defense in depth: why the system remained secure
The ZKsync protocol is designed to be resilient to unexpected bugs and system flows. The security approach leverage two main principles: (1) prevent issues by correctness, and (2) detection & real-time response. While secure implementation remains important, the system minimizes the impact of potential issues and provide sufficient time for patching.
Where possible, components are designed to minimize the attack surface, keep isolation, and limit possible impact. Other parts are inherently complex and must rely more on implementation correctness. In both cases, secure design reduces the likelihood of defects but does not eliminate them. That is why implementation correctness remains important, and so ZKsync follows industry standard: internal code review, testing and external security audits. The EcPairing precompile went through all of mentioned stages.
But no code is perfectly safe; the last resort is always bug detection and incident response. To keep the latter practical, the system should not only detect issues but also react faster than an attacker. ZKsync has multiple layer of correction mechanisms that kept the system secure:
- Execution delay: Every ZK chains has enforced 3-hour execution delay between when a validator settles a batch and when that batch can be finalized. During the finalization window anyone can locally replay transactions and independently verify state correctness. If malicious chain validator produced incorrect state, the protocol can detect it and initiate correction measures.
- Protocol freeze: The Security Council may freeze any smart contracts which make up the ZKsync protocol, for differing periods of time. The freeze time may vary from 12 hours to 7 days depending on how much time is needed to prepare an Emergency Protocol Upgrade.
- Emergency Protocol Upgrade: Once the root cause is identified and a patch is prepared, the governance body can approve and execute an emergency upgrade. Chain admins then roll-out the fix to resume normal operations.
During the incident, no invalid state changes were observed. If any validator had produced an incorrect state, the enforced 3-hour execution delay would have allowed the Security Council to halt finalization and deploy an Emergency Protocol Upgrade before the state became irreversible.
Mitigation efforts
The issue was isolated to the EcPairing precompile, only malicious operator could have damaged the protocol. Any attack would be observable and reversible because of the 3-hour execution delay and ZK Governance Emergency Procedures.
ZKsync Gateway had been recently activated and relies on crypto precompiles to verify ZK proofs for chains that settle to it. At the moment the bug was discovered, only Era had settled to the Gateway, so Matter Labs team stopped proof production to further delay finalization. We were extra-cautious because the impact of forging a proof for chains that settle to the Gateway was higher than for chains that settle on Ethereum.
At any time the protocol could have been frozen with a 3-of-12 signature quorum from the Security Council, but that step was not necessary after the initial assessment.
On Friday, August 1, 2025, the patch was prepared, tested in developer testnet environment, and, after Security Council approval, deployed an emergency upgrade. The Emergency Upgrade proposed new protocol version that only differed on the verification keys. Era and Gateway chains upgraded their implementations to the patched protocol version. Other ZK chains were notified of the issue and they upgraded on their own timelines.
Resolution: Protocol Upgrade v28.1
Protocol Upgrade 28.1 included a single fix: it added the missing input to the circuit witness. The updated code was deployed to the provers:
Because this change required a new verification key, we performed a protocol upgrade to deploy the updated verifier. The upgrade consisted of three transactions executed sequentially:
- stage0
- Pause the ability of new chains to connect to ZK Gateway
- stage1
- Deploy v28.1 Protocol Upgrade on Ethereum/Gateway
- stage2
- Unpause the ability of new chains to connect to ZK Gateway
Closing statement
No funds were lost and there was no disruption to users during the incident. This incident is further proof that security is a multi-layered process and that all components matter: secure design, testing, external audits, bug bounty, and incident response.
We appreciate the support and quick actions of everyone involved and apologize for the disruption this incident caused. Thank you to the reporter, the Security Council, the Guardians, the ZK Foundation and the Matter Labs response team.