Upgraded Q -> 2 from #17 [1681332048307]

Judge has assessed an item in Issue 17 as 2 risk. The relevant finding follows: L-07 First user that stakes again after a period without stakers receives too many rewards The MuteAmplifier contract pays out rewards on a per second basis. Let's assume there is only 1 staker which is Bob. Say Bob...

Upgraded Q -> 2 from #17 [1680620718364]

Judge has assessed an item in Issue 17 as 2 risk. The relevant finding follows: L-05 Check that staking cannot occur when endTime is reached The MuteAmplifier.stake function should require that the current timestamp is smaller than endTime even when the call to stake is the first that ever...

Upgraded Q -> 2 from #17 [1680620822176]

Judge has assessed an item in Issue 17 as 2 risk. The relevant finding follows: L-10 It is possible in theory that stakes get locked due to call to LockTo with very small reward amount I pointed out and explained in my report 7 MuteBond.sol: deposit function reverts if remaining payout is very...

The first stake is possible after endTime

Lines of code Vulnerability details Impact Users can stake after endTime due to the wrong check. Proof of Concept When a user stakes LP tokens using MuteAmplifier.stake, stake is not allowed after endTime which is set in initializeDeposit by an admin. requireblock.timestamp endTime,...

Amplifier users might not get all the LP fees they are entitled to

Lines of code Vulnerability details Proof of Concept Observe that there is only one place that the amplifier is calling claimFees, and it's inside an if statement of the update modifier, requiring mostRecentValueCalcTime modifier update if mostRecentValueCalcTime == 0 mostRecentValueCalcTime =...

Logic for RescueTokens is incorrect for muteTokens

Lines of code Vulnerability details Proof of Concept The logic for RescueTokens doesn't take into account the reward remainders. I wanted to write a POC but I'm in a bit of a time crunch. So, imagine the following situation: totalRewards = 100, and staker A, B the only stakers staked for the firs...

MuteAmplifier.rescueTokens() should check conditions for fee tokens(token0/token1) as well

Lines of code Vulnerability details Impact rescueTokens can be used to withdraw fee tokens without any validations. As a result, the reward logic would be broken due to the lack of fee tokens. Proof of Concept rescueTokens doesn't validate anything for the fee tokens. So if some fee tokens were...

MuteAmplifier.sol: multiplier calculation is incorrect which leads to loss of rewards for almost all stakers

Lines of code Vulnerability details Impact This report deals with how the calculation of the multiplier in the MuteAmplifier contract is not only different from how it is displayed in the documentation on the website but it is also different in a very important way. The calculation on the website...

MuteAmplifier.sol: rescueTokens function does not prevent fee tokens from being transferred

Lines of code Vulnerability details Impact The MuteAmplifier.rescueTokens function allows the owner to withdraw tokens that are not meant to be in this contract. The contract does protect tokens that ARE meant to be in the contract by not allowing them to be transferred: Link function...