Stream flow is meant to stream certain amount of tokens as defined by the ratePerSec
over time. However, the sender
can force the stream to send all the tokens at once to the recipient
, Which is not what was intended by the protocol.
This is at no cost to to the sender
and the recipient
only pays the protocolFee
once on withdraw. Which means the protocol loses as as they would have earned more in a case of multiple withdraws.
This is an issue as this can be used to bypass paying protocol fees by planning ahead.
flow creation does not require an immediate deposit of tokens, which means that the sender can create a stream and then deposit all the tokens at once, forcing the stream to send all the tokens at once to the recipient.
The elaspsedTime
is multiplied by the ratePerSeconds
the streamId
the rate is calculated from the time of creation not when the tokens are deposited.
-First create
a stream with a specific ratePerSec
-Wait for a certain amount of time to pass so that the stream ratePerSec
had accumulated all token debt
-Deposit to the streamId
the amount the recipient
is expecting
-recipient
can then withdraw all the tokens at once while paying the fees only once.
Instead of bob
withdrawing 100 tokens at a rate of 1 token per second, bob
can withdraw all if the sender
creates the stream, waits a while, and deposits.This means if users can create pending streams they can bypass paying the protocol fee multiple times and just pay once.
Streaming platforms usually rely on gradual disbursement over time to ensure predictable payouts and fees earning for the protocols. Allowing instant withdrawals defeats the purpose of time-based streaming.
start the rate only when deposits have been made.
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.