The delegateBoost function does not prevent users from self-delegating their own boost (to == msg.sender). This could lead to unintended behavior, such as bypassing certain restrictions on delegation, exploiting reward mechanisms, or causing unnecessary storage writes.
Self-Delegation Not Restricted
The function allows users to delegate a boost to themselves (to == msg.sender).
There is no check ensuring to != msg.sender, which means users can delegate to their own address.
Potential Exploits
Reward Manipulation: If delegation affects voting power, rewards, or governance weight, a user could exploit self-delegation to artificially inflate influence.
Storage Bloat: Allowing self-delegation leads to unnecessary state updates, increasing storage costs and gas fees without meaningful changes.
Bypassing Delegation Restrictions: If delegation comes with cooldowns or other limitations, self-delegation could be used as a loophole to reset those restrictions.
Possible Miscalculation in External Reward Mechanisms : If there are reward systems or boost multipliers tied to delegated boosts, allowing users to delegate to themselves could: Trick the contract into thinking they have extra boost power. Inflate their personal stake or rewards without any real delegation.
Unnecessary Gas & Storage Usage: Self-delegation is redundant but still writes to storage, increasing contract execution costs.
Manual Review
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.