Flow

Summary

On Arbitrum, relying on block.timestamp can lead to inaccurate calculations due to possible timestamp adjustments by the sequencer, potentially affecting the recipient's token withdrawal amounts from a stream.

Description:

According to the competition's documentation, "Flow is expected to work on any EVM based blockchain." However, one of the core aspects of the protocol's functionality depends on block.timestamp values, which could cause problems on certain layer 2 blockchains, such as Arbitrum.

According to Arbitrum's documentation, see [https://docs.arbitrum.io/build-decentralized-apps/arbitrum-vs-ethereum/block-numbers-and-time#block-timestamps-arbitrum-vs-ethereum], a sequencer has the capability to adjust timestamps, allowing them to be set up to 24 hours earlier or 1 hour in the future than the actual time. This means that block.timestamp values on Arbitrum may deviate by as much as 24 hours from the real time.

The described problem can occur in the SablierFlow::_ongoingDebtScaledOf function, as this function calculates the ongoing debt and relies heavily on the block.timestamp value. However, what happens if the sequencer is off and returns a timestamp that is, say, 24 hours in the past, but still greater than the last snapshotTime? This would result in fewer tokens available for the receiver to withdraw for the particular timeframe (less withdrawable amount).
Likelihood: Low / Impact: Low/Medium, resulting in an overall risk level of Low.

Impact:

The use of block.timestamp on Arbitrum can lead to inaccurate debt calculations as the sequencer can adjust timestamps by up to 24 hours in the past or 1 hour in the future. This can result in fewer tokens available for the recipient to withdraw for the particular timeframe, potentially disrupting regular payment flows and affecting users or systems who rely on accurate time-based streaming.

Tools Used:

VSCode, manual review

Recommended Mitigation:

To address the limitations of block.timestamp, consider implementing an off-chain oracle solution to provide reliable timekeeping. For instance, using Chainlink’s Time-Based Upkeeps or similar off-chain services can help ensure consistent and accurate time data across different networks. This would mitigate the potential discrepancies introduced by the sequencer’s control over block.timestamp on Arbitrum and other L2 networks.