The protocol charges a management fee based on the feePerSecond variable, which dictates the rate at which new vault tokens are minted as fees via the mintFee function. An administrative function updateFeePerSecond allows the owner to alter this fee rate. However, the current implementation does not account for accrued fees before the update, potentially leading to incorrect fee calculation.
The contract's logic fails to account for outstanding fees at the old rate prior to updating the feePerSecond. As it stands, the updateFeePerSecond function changes the fee rate without triggering a mintFee, which would update the lastFeeCollected timestamp and mint the correct amount of fees owed up until that point.
Scenario Illustration:
User A deposits, triggering mintFee and setting lastFeeCollected to the current block.timestamp.
After two hours without transactions, no additional mintFee calls occur.
The owner invokes updateFeePerSecond to increase the fee by 10%.
User B deposits, and mintFee now calculates fees since lastFeeCollected using the new, higher rate, incorrectly applying it to the period before the rate change.
The impact is twofold:
An increased feePerSecond results in excessively high fees charged for the period before the update.
A decreased feePerSecond leads to lower-than-expected fees for the same duration.
Manual Analysis
Ensure the fees are accurately accounted for at their respective rates by updating lastFeeCollected to the current timestamp prior to altering the feePerSecond. This can be achieved by invoking mintFee within the updateFeePerSecond function to settle all pending fees first:
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.