The depletionTimeOf
function in SablierFlow serves as a critical timing oracle, calculating when a token stream will become insolvent. Its early exit condition uses a >=
comparison with balanceScaled + oneMVTScaled
to determine stream depletion, returning 0 for both already-depleted streams and streams exactly at their depletion point. This comparison exists as a pre-check before performing more complex depletion time calculations, but its handling of edge cases impacts the protocol's ability to maintain precise stream state information.
The issue centers around this comparison:
https://github.com/Cyfrin/2024-10-sablier/blob/main/src/SablierFlow.sol#L57
The problem lies in the >=
comparison and returning 0
. This creates ambiguity between two distinct states:
Stream that is already depleted:
Stream that is exactly at its depletion point:
This becomes problematic when integrating systems need to differentiate between these states.
The situation gets more complex when you consider how it interacts with other contract functions:
The edge case becomes particularly tricky because:
The snapshot debt and ongoing debt calculations use different scales
The exact depletion point comparison includes the MVT (Minimum Value Transferable)
Block timestamp variations can affect the ongoing debt calculation
The early exit condition's inability to distinguish between depleted and exactly-depleting streams creates a critical ambiguity in the protocol's stream state management. When depletionTimeOf
returns 0 for both conditions, it forces downstream contracts and integrations to operate with incomplete information about stream status. This state confusion compromises the precision of automatic settlement systems and can lead to missed final settlements or incorrect stream lifecycle handling, particularly in time-sensitive DeFi operations where exact depletion timing affects financial outcomes. The collapse of distinct states into a single return value effectively breaks the stream status determinism that integrated protocols rely on for accurate financial operations.
A better implementation might look like:
This would solve the ambiguity by:
Clearly differentiating between states
Providing more information to calling contracts
Making the exact depletion point detectable
Maintaining backward compatibility through careful state handling
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.