Summary
stake()
calls near the end of epoch are vulnerable to attacks.
Whenever stake()
gets called during end of epoch are vulnerable to DOS.
However, this design opens the door for very unpleasant for the victims' attack scenario -> block stuffing.
Block stuffing -> malicious actor spams the network with some transaction with a gas fee higher than the victim so that he can delay the execution of victims transaction. In the current situation, the chance of such a scenario is big, because stakers benefit from waiting until the last moment, and if a malicious party delays their execution of stake()
, he could force them to stake()
in next epoch. Which is very inconvenient for the victim having in mind he wanted to stake() in the end of epoch to gain maximum advantage.
So whenever a user stake()
near end of epoch malicious actor can block stuff their transaction or the transaction may get mined in next epoch without any external approach of malicious .
So user's will have to wait for 7 days more (1 epoch) to unstake his tokens.
User's have to wait 7 days more before they can unstake() due to attack perfoormed by malicious attacker.
Manual review
I am not sure how to mitigate this concern and have system constraint the same as now.
But we can try to calculate stake timestamp of individual users when they stake() instead of directly assigning them to epoch.
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.