contracts/core/governance/boost/BoostController.sol
The BoostController
contract follows Curve-style boost mechanics, with the delegateBoost
function handling the delegation of boosts from the caller to another address. However, this function allows a user to delegate their total boost amount to multiple addresses simultaneously.
Boosts are calculated based on the total veRAAC
delegated to a specific liquidity provider (pool). If the same veCRV
could be delegated to multiple providers, it would result in double-counting and unfair reward distribution.
In Curve’s boost delegation model, if a user holds 100 veCRV
, they can delegate the full amount to one address at a time and later reassign it to another. Alternatively, they can split their veCRV
proportionally across multiple addresses—for instance, if Alice has two separate lock-ups of 50 veCRV
each, she can delegate them independently.
However, in the RAAC protocol's BoostController
, a user can delegate their entire veCRV
balance to multiple addresses simultaneously, leading to incorrect reward allocation.
Allowing the same veRAAC balance to be delegated to multiple addresses would create conflicts in how the boost is applied to liquidity providers' rewards, leading to double-counting or unfair reward distributions.
Manual Review
Refactor the boost delegation logic to ensure that boosts are non-divisible when delegated. This means that the full boost associated with a user’s veRAAC balance can only be delegated to one address at a time.
Add the test script below to : test/unit/core/governance/boost/BoostController.test.js
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.