When the sequencer is down on Arbitrum state changes can still happen on L2 by passing them from L1 through the Delayed Inbox. During periods when the Arbitrum sequencer is unavailable, transactions are rerouted through the Delayed Inbox, which applies address aliasing to the sender's address.
If the recipient that initiates a transaction in the Sablier protocol is a smart contract, this aliasing prevents the streams or airstream recipient/sender from initiating and using the main functionalities of the protocol because the aliased address on the destination does not match expectations.
When the sequencer is down on Arbitrum, the msg.sender of a transaction from the Delayed Inbox is aliased:
L2_Alias = L1_Contract_Address + 0x1111000000000000000000000000000000001111
Some of the main functions of the Sablier protocol initiated by a smart contract as a recipient and/or as a sender are therefore blocked when the sequencer is down.
When the sequencer is down, the msg.sender address is aliased by the Delayed Inbox. The main functions (like SablierV2LockUp::withdrawMaxAndTransfer
, SablierV2LockUp::cancel
, SablierV2MerkleLL::claim
, SablierV2MerkleLT::claim
, etc.) initiated by a smart contract as a recipient and/or as a sender are therefore blocked because the lockup or airstream smart contract expect the original msg.sender for the check but it receives the aliased msg.sender and doesn't recognize it.
Manual review
Add a validation of the sender / recipient address considering the aliased address case.
https://github.com/Cyfrin/2024-05-Sablier/issues/1
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.