Abstract

This proposal deploys an updated Validator Timelock contract that allows each EraVM ZK Chain to increase its execution delay from 3 hours to 24 hours. This upgrade gives chains the flexibility to adopt longer security-response windows based on their own requirements, with a 24-hour delay recommended for all ZK Chains.

Motivation

Advances in AI are changing the security environment for blockchain software. AI-assisted tools can help defenders identify and address vulnerabilities, but they can also help attackers accelerate vulnerability discovery, exploit development, and attack execution. This may shorten the period between the discovery of a vulnerability and its exploitation, increasing the importance of giving security responders sufficient time to act before the consequences of an attack become irreversible.

The execution delay provides a response window between the commitment of a batch and its execution on Ethereum. During this period, monitoring systems and security responders can identify anomalous activity and, where necessary, use the protocol’s Instant Upgrade mechanisms before an affected batch becomes final.

This proposal introduces chain-specific control over execution-delay increases. Each EraVM ZK Chain will be able to adopt a longer delay independently without changing the delay for other chains. Chains that do not take action will retain the current 3-hour default.

Increasing the delay does not prevent vulnerabilities or replace audits, monitoring, incident-response procedures, or emergency governance powers. Instead, a longer delay makes those safeguards more effective by providing a more practical period in which responders can investigate an issue and take action.

Specification

This proposal deploys the updated ValidatorTimelock contract at 0x556DdC1617D7620f56317d2F2002FE440EA9Ad35.

Changes Proposed

Currently, ValidatorTimelock has a single execution delay that can be set by ZK Governance. The proposal changes the implementation of Validator Timelock. The new implementation keeps the core logic the same but adds functionality that allows each ChainAdmin to increase the execution delay for the chain it controls, up to a maximum of 30 days.

Governance Calldata

The execution delay is a minimum period before a committed batch can be executed. It does not guarantee that batches will always be finalized immediately after the configured period. Actual finality may take longer depending on network activity, proof generation, and batch aggregation.

Execution Impact

ZK Chains

Each ZK Chain may independently determine whether and when to increase its delay. A change made by one chain will not affect the delay applied to another chain.

Chains adopting a longer delay should communicate the change to users, applications, bridges, exchanges, liquidity providers, and other integrations that depend on L1 finality.

Backwards Compatibility

This proposal does not change transaction formats, application-facing smart contract interfaces, or the validity rules applied to existing transactions.

The existing 3-hour default remains in place, and chains that do not increase their delay will experience no change to their current timing.

For chains that adopt a longer delay, the time required for affected batches—and therefore withdrawals and other L2-to-L1 messages—to become final on Ethereum will increase.

Note that the new delay applies to all batches, including those already committed before the configuration change, meaning batches already in the queue will also be subject to the longer delay.

Security Considerations

Chain-specific delay increases strengthen defense in depth by allowing each ZK Chain to provide more time to:

• Detect anomalous state transitions, withdrawals, or asset movements;
• Investigate potential vulnerabilities or active exploitation;
• Distinguish genuine attacks from false positives;
• Coordinate among security and governance stakeholders; and
• Activate available emergency-response mechanisms.

The change does not itself detect or prevent malicious activity. Its effectiveness continues to depend on reliable monitoring, clear escalation procedures, responder availability, and the ability of relevant parties to act within the configured window.

A longer delay also increases the period during which users must wait for L1 finality. During periods of market stress or chain disruption, this may create additional liquidity and operational risks. Each chain should consider these costs when selecting its execution delay and clearly communicate any change to its users and integrators.