Upgraded Q -> 2 from #44 [1680620528235]

Judge has assessed an item in Issue 44 as 2 risk. The relevant finding follows: Low 1 RescueTokens doesn't have checks for fee0 & fee1 tokens. Admin might accidentally withdraw fee tokens that are supposed to be for the stakers: --- The text was updated successfully, but these errors were...

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: 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...

The sendToCosmos function does not check for transfer-on-fee/deflationary tokens

Lines of code Gravity.solL595-L609 Vulnerability details Impact The documentation describes the use of tokens other than CUDOS in the Gravity.sol contract; so it is assumed that the CUDOS token will not be the only supported token. The documentation also states that validators on the Tendermint...

Transfer-on-fee/deflationary tokens are not correctly accounted for

Handle shw Vulnerability details Impact When a user stakes or a protocol deposits a transfer-on-fee/deflationary token, the solution does not correctly handle the received amount, which could be less than what is accounted for. Proof of Concept Referenced code: PoolOpen.solL36-L38...