When the protocol want a deposit to happen it calls the tillIn function, it does not reject extra eth which is more than the value sent or eth sent when the tokenAddress is an erc-20 token, which may have unintended consequences
This snippet of code from the tillIn
function checks if the msg.value is enough to cover the amount being deposited, but it does not check if it is more and also if the token address is an erc token and a msg.value is also sent together, in both cases, eth are lost and it is imperative that users don't loose funds when trying to deposit
Since deposit may occur by users sending tx directly to the smart contract, extra eth sent along or incorrect eth sent with erc20 tokens should either be refunded or should be prevented from outright being able to deposit
manual review
A check to make sure the exact amount of eth required should be deposited , and a check inside the else statement that checks if you are sending eth if the tokenAddress is a erc20 tokens, to revert or to refund the amount back to the caller
Invalid, these are by default, invalid based on codehawks [general guidelines](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#findings-that-may-be-invalid). The check implemented is simply a sufficiency check, it is users responsibility to only send an appropriate amount of native tokens where amount == msg.value when native token is intended to be used as collateral (which will subsequently be deposited as wrapped token). All excess ETH can be rescued using the `Rescuable.sol` contract. > Users sending ETH/native tokens > If contracts allow users to send tokens acc111identally.
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.