Flow

Sablier
FoundryDeFi
20,000 USDC
View results
Submission Details
Severity: low
Invalid

The main protocol functionalities are unavailable for smart contract senders and/or recipients address when Arbitrum L2 sequencer is down

Summary

The Sablier Flow compatibilities is defined in the Scope section as:

  • Flow is expected to work on any EVM based blockchain.

On the Arbitrum chain when the sequencer is down the 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 sender/recipient that initiates a transaction in the Sablier protocol are smart contracts, this aliasing prevents the stream sender/recipient from initiating and using the main functionalities of the protocol because the aliased address on the destination does not match expectations.

Vulnerability Details

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.

Impact

When the sequencer is down, the msg.sender address is aliased by the Delayed Inbox. The main functions like:

  • SablierFlow::adjustRatePerSecond (initiated by the sender)

  • SablierFlow::DepositAndPause (initiated by the sender)

  • SablierFlow::Pause (initiated by the sender)

  • SablierFlow::Refund (initiated by the sender)

  • SablierFlow::RefundAndPause i(nitiated by the sender)

  • SablierFlow::Restart (initiated by the sender)

  • SablierFlow::RestartAndDeposit (initiated by the sender)

  • SablierFlow::Void (initiated by the sender or recipient or authorized third Party)

  • SablierFlow::Withdraw and SablierFlow::WithdrawMax (initiated by the sender or recipient or authorized third Party)

are initiated by a smart contract, they are therefore blocked because the smart contract expects the original msg.sender for the check but it receives the aliased msg.sender and doesn't recognize it.

Tools Used

Manual review

Recommendations

Incorporating an uptime feed to mitigate issues arising from sequencer downtime.

Updates

Lead Judging Commences

inallhonesty Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Appeal created

kiteweb3 Submitter
10 months ago
inallhonesty Lead Judge
10 months ago
inallhonesty Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.