Root + Impact

Description

The contract utilizes block.number to calculate launch phases (phase1Duration, phase2Duration) and user cooldown periods (phase1Cooldown, phase2Cooldown).

While this approach works on Ethereum Mainnet (where block times are relatively stable at ~12s), Uniswap V4 hooks are primarily intended for deployment on Layer 2 (L2) solutions such as Arbitrum, Optimism, and Base. On these networks, block.number does not represent a reliable measure of time:

1. Arbitrum: The sequencer can produce blocks at a much higher frequency than L1, or block numbers might represent the L1 block height synced by the sequencer, causing significant drift.

2. Optimism/Base: Each transaction often results in a new block, making block-based durations nearly impossible to predict accurately.

Risk

1. Subversion of Anti-Bot Throttling

The primary purpose of this hook is to mitigate bot activity via cooldowns and phase-based limits. If deployed on an L2 like Optimism or Base, where block production is significantly faster (e.g., 2 seconds per block), a cooldown intended to last 1 hour (calculated as 300 blocks on L1) would expire in only 10 minutes. This allows bots to trade much more frequently than the protocol designers intended.

2. Phase Duration Inconsistency

The phase transition logic:

blocksSinceLaunch≤phase1Duration+phase2Duration

becomes non-deterministic across different chains. On Arbitrum, the block.number reported to the EVM often stays constant for several minutes while the sequencer batches transactions, and then jumps suddenly. This could cause the hook to skip Phase 1 or Phase 2 entirely for a large batch of transactions, or trap users in a phase for much longer than expected.

3. Operational Denial of Service (DoS)

If the network undergoes an upgrade or a sequencer pause (common in early-stage L2s), the block production rate can change. This unpredictability can lead to a "Locked State" where user limits (maxSwapAmount) are not reset because the expected block height hasn't been reached, effectively halting legitimate trading activity.

Impact:

The anti-bot mechanisms (cooldowns and phase limits) may not function as intended. Cooldowns could expire significantly faster or slower than the project's parameters, allowing bots to bypass the intended throttling.

Recommendation: Transition to Timestamp-Based Timing

To ensure robust and deterministic behavior across all EVM-compatible networks—especially Layer 2 solutions like Arbitrum and Optimism—it is highly recommended to migrate the contract's timing logic from block.number to block.timestamp.

Proposed Remediation

The following adjustments should be implemented to align with industry best practices for cross-chain compatibility:

1. State Initialization: Replace launchStartBlock with a launchStartTime variable initialized via block.timestamp.

2. Phase Logic: Update the phase transition conditions to evaluate the elapsed time in seconds rather than block height.

3. Cooldown Mechanism: Refactor the user cooldown checks to compare the current block.timestamp against a stored expiration timestamp.

Example Code Adjustment:

Solidity

By adopting block.timestamp, the protocol ensures that anti-bot measures remain consistent and predictable regardless of the underlying network's block production rate.