Common mistakes with Arbitrum’s BOLD challenge period

The Bounded Liquidity Delay protocol launched on February 12, replacing the previous allowlisted validator system with permissionless validation. This upgrade allows anyone to verify transactions and challenge fraud, aiming to resolve disputes within a maximum of 12 days. While the design promises greater decentralization, the implementation contains specific technical pitfalls that can trap honest validators in financial loss or allow malicious actors to confirm invalid state transitions. Understanding these mechanics is essential for anyone participating in the dispute resolution process.

Stake management and insolvency risks

A critical vulnerability exists in how the protocol handles stake updates when the required bond amount decreases. If an admin lowers the stake requirement from 1000 ETH to 700 ETH, a dishonest actor can exploit this change to drain liquidity from the rollup contract. The attacker creates an invalid assertion using the old higher stake, then has a friend create a child assertion under the new lower stake. Because the original staker is no longer considered active once their last assertion has a child, they withdraw their full 1000 ETH. The contract is left holding only 700 ETH, making it insolvent and preventing honest validators from retrieving their funds. This scenario was identified by security researchers who noted that a staker should be considered inactive only if their last staked assertion is confirmed.

The fix requires strict rules on when a staker can exit. A staker must only be able to stake on descendants of their last staked assertion. This prevents switching to a correct branch to trigger a withdrawal while leaving the dishonest branch unresolved. Without this constraint, the economic incentive structure breaks down, as the system relies on confiscated bonds from failed attackers to reimburse honest defenders. The initial parameter values for the delay buffer include a threshold of 150 L1 blocks, which is well above typical posting frequencies. These parameters are designed to ensure that the force inclusion window gradually replenishes over weeks, assuming the sequencer maintains good behavior.

Timer inheritance across challenge trees

Another severe issue involves the inheritance of timers between different levels of a challenge tree. The function updateTimerCacheByClaim allows timers to propagate from one edge to another, but it lacks sufficient validation on the claiming edge. Rival edges share the same mutual ID by definition, meaning a dishonest edge can inherit the accumulated unrivalled time from an honest edge. If an honest edge accumulates enough time for confirmation, a malicious actor can frontrun this confirmation to validate a dishonest challenge. This effectively confirms an incorrect assertion without the dishonest party having to engage in the full bisection process.

This attack vector is particularly dangerous because it allows a single dishonest child edge to inherit a sufficient timer via claim. Since challenges between two assertions follow a unique bisection path, other rival edges remain unrivalled. The only way to deny this is to create another assertion that rivals the dishonest child, which would require the honest party to lose their stake. The recommended mitigation involves allowing child edges to inherit the claim ID of their parent and checking that this matches the edge ID of the inheriting edge. This ensures that timers cannot leak across incompatible branches of the dispute tree.

Sequencer outages and delay buffers

The delay buffer feature aims to mitigate negative effects from prolonged sequencer censorship or unexpected outages. However, there is an inconsistency in how the buffer decreases when multiple messages are force-included during a sequencer downtime. If the sequencer is down and users submit messages at different block numbers, the buffer reduction depends on the order in which these messages are processed. If the newest message is force-included first, the buffer does not decrease because the previous sequenced block number matches the previous block number. Users must wait longer for subsequent force inclusions.

If the oldest message is included first, the buffer correctly decreases based on the time elapsed since the sequencer went offline. This discrepancy harms users who want to force-include messages quickly, as the buffer remains larger than it should be. The initial delay buffer value is set to 14400 L1 blocks, equivalent to two days. The replenish rate is 5%, meaning one day of buffer is replenished every 20 days, corresponding to roughly 95% uptime. Under reasonable parameterization, the sequencer could be offline for 24 hours twice before the force inclusion window drops from 24 hours to a minimum inclusion time.

Does the current buffer logic adequately protect against coordinated sequencer censorship?