The BoostController
implements the updateUserBoost()
and delegateBoost
to handle the pool
boost. However, there isn't a mechanism to ensure the order of calls.
According to protocol tests, the order should be delegateBoost()
-> updateUserBoost
.
The protocol doesn't enforce the order of function executions. So, any user could call updateUserBoost
first and then delegateBoost()
. By doing this, the boost functionality would be locked.
By calling the BoostController::updateUserBoost
first, the userBoosts
mapping will be updated adding the newBoost
to the userBoost.amount
and the userBoost.lasUpdateTime
. But it will not update userBoost.expiry
and userBoost.delegateTo
. So, it can't be used.
(storage update)[https://github.com/Cyfrin/2025-02-raac/blob/89ccb062e2b175374d40d824263a4c0b601bcb7f/contracts/core/governance/boost/BoostController.sol#L189-L190]
If you try to delegateBoost
it will revert because of this check if (delegation.amount > 0) revert BoostAlreadyDelegated();
implemented on the BoostController::delegateBoost
.
If you try to remove the boost and make adjustments, It will also revert because the BoostController::updateUserBoost
doesn't update the userBoost.delegateTo
, as mentioned before.
The boost system will be completely DoSed. It cannot update, delegate, or remove any information, making it useless.
Code Review
Ensure BoostController::updateUserBoost
can be called only after a delegation happens.
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.