The _handleWethRewardDistribution
function unfairly allocates 100% of leftover rewards to vaults instead of distributing them proportionally between the protocol and vaults based on their predefined shares (feeRecipientsSharesX18
and Constants.MAX_SHARES
). This will destruct the receiving of collateral fees on the receiveMarketFee
function and also on how the reward will be distributed to the market and protocol on the ConvertAccumulatedFeesToWeth
function.
Fixed-point arithmetic (UD60x18
) can cause tiny rounding discrepancies, resulting in a leftover
after initial reward distribution
The current implementation assigns the entire leftover
to vaults
This ignores the protocol’s proportional claim to the leftover based on feeRecipientsSharesX18
Parameters:
Constants.MAX_SHARES = 1e18
(UD60x18).
feeRecipientsSharesX18 = 0.3e18
(protocol’s 30% share).
receivedWethX18 = 1000e18
.
Initial rewards:
Protocol: 1000e18 * 0.3e18 / 1e18 = 300e18
.
Vaults: 1000e18 * (1e18 - 0.3e18) / 1e18 = 700e18
.
Due to rounding, actual rewards might be:
Protocol: 299.999e18
.
Vaults: 699.999e18
.
leftover = 1000e18 - 299.999e18 - 699.999e18 = 2e18
.
Current Outcome:
Vaults receive 699.999e18 + 2e18 = 701.999e18
(70.1999% of total).
Protocol receives 299.999e18
(29.9999% of total).
Expected Fair Distribution:
Protocol’s share of leftover: 2e18 * 0.3e18 / 1e18 = 0.6e18
.
Vaults’ share of leftover: 2e18 - 0.6e18 = 1.4e18
.
Final rewards:
Protocol: 299.999e18 + 0.6e18 = 300.599e18
(30.0599%).
Vaults: 699.999e18 + 1.4e18 = 701.399e18
(70.1399%).
Over time, the protocol loses its fair share of rewards, reducing its income.
Manual Code Review
Distribute the leftover proportionally using the original shares
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.