The BoostController implements the updateUserBoost() and delegateBoostto 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 updateUserBoostfirst and then delegateBoost(). By doing this, the boost functionality would be locked.
By calling the BoostController::updateUserBoostfirst, the userBoostsmapping will be updated adding the newBoostto the userBoost.amount and the userBoost.lasUpdateTime. But it will not update userBoost.expiryand 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::updateUserBoostcan 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.