Although the protocol intentionally applies new fees retroactively to all pending withdrawals as a business strategy, this mechanism can be circumvented through front-running by attackers. Users monitoring the mempool can detect fee increase transactions and quickly withdraw their funds before the new fee takes effect.
MEDIUM - While no funds are at risk, this edge case:
Reduces protocol revenue
Creates unfair advantage for tech-savvy users
Makes fee changes unpredictable
Undermines intended business model, so basically protocol loses the expected fees.
The fee is determined at withdrawal time rather than when tokens were streamed, making it vulnerable to front-running when fees are increased.
LOW-MED - This attack is:
Easy to execute
Highly profitable
Requires only mempool monitoring
Can be automated
Most likely during significant fee increases which will be not frequent ( so low likelihood )
front-running Scenario ( where user avoids high fees ):
Admin: Let say initial fee is set to 0 % and then admin changed it to setProtocolFee(token, 10%), now transaction is in mempool
User: Spots this transaction in mempool
User: Quickly submits withdrawal with higher gas
withdraw(streamId, fullAmount) // Front-runs with higher gas
Admin's fee change executes after
User gets funds with original lower fee (0%)
There can be many solutions for mitigating these kinda frontrunning issues, the one I have in mind is to use Flashbots or any private memepool service for updating fees like this.
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.