unsafe `msg.value` validation in `TokenManager::tillIn`, might lead user to lose funds.
Summary
The tillIn function get called with the original msg.value the user sends, however, the math calculations and logic, are implemented with the user input parameters. due to wrong msg.value validation, if the user will send a larger msg.value, all the extra ETH will be transferred to the contract and will not count for the user as a collateral, therefore, the user might lose his funds.
Vulnerability Details
The function validate the msg.value :
since all the math logic are being calculated with the parameters, if the msg.value is bigger than _amount, the excessive ether will be transferred to the contract and the user will lose his funds.
Impact
users that will (for some reason) send extra eth as msg.value, will not be able to claim this excessive ether since there is no sweep/refund logic/functions implemented in the protocol (for the user)
Tools Used
Manual Review
Recommendations
implement different msg.value validation such as:
or consider adding a mechanism to claim / receive the excessive amount.
Lead Judging Commences
[invalid] finding-TokenManager-tillin-excess
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.
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.