TokenManager - Unrecorded `msg.value`
Summary
In the tillIn function of the TokenManager contract, you can pass msg.value when a top up occurs using ERC20 tokens
Vulnerability Details
Since the tillIn function of the TokenManager contract is payable, it can receive the native currency needed for a single case. When topping up with ERC20 tokens, the user can still pass a non-zero msg.value, which simply won't be counted anywhere.
Since there are functions in the TokenManager contract to withdraw native currency, these tokens will not be lost, but will cause discomfort for the users and the protocol itself, as it will have to constantly return funds to the users.
Impact
Temporary loss of funds by users.
Additional resources spent by the protocol to return the locked funds.
Tools Used
The bug was discovered through a manual audit of the contract code. No third-party programs were used
Recommendations
Add msg.value == 0 check to the tillIn function of the TokenManager contract for the case when there is a top-up using ERC20 tokens
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.