Refund logic of unused relative token in initializeCollection() in Locker.sol is wrongly Implemented.
Summary
Refund of any unused token to the user implemented in the initialize collection, is wrongly implemented.
Vulnerability Detail
the amount which is transfer from contract to msg.sender, is not calculated correctly, because starting balance is the balanceOf native token in the contract address. the amount which is to be transfer to the implementation is directly transfer from msg.sender to implementation address. If it would be more than it needed , then it might get back to contract address. and also if excess is passed and it is in contract address then also after balance of native token in contract would be more than the start balance. so refund would always be improper
for eg, 1118 _eth is passed as parameter, then from msg.sender 1118 will transfer. if 118 is unused then. after balance of contract would be plus 118 and excess should be transfer from contract address to msg.sender at the end of the function
Impact
due to improper calculation if current user unused token is not transfer to him, then he might lose it, as then when another user will come , initial balance will be there from starting, and it might transfer to another user, and loss to original user
Amount should be calculated in such a way that excess amount should be removed from the initial balacne then transfer that amount of native tokens to the msg.sender.
0xlucky
High
Refund logic of unused relative token in initializeCollection() in Locker.sol is wrongly Implemented.
Summary
Refund of any unused token to the user implemented in the initialize collection, is wrongly implemented.
Vulnerability Detail
the amount which is transfer from contract to msg.sender, is not calculated correctly, because starting balance is the balanceOf native token in the contract address. the amount which is to be transfer to the implementation is directly transfer from msg.sender to implementation address. If it would be more than it needed , then it might get back to contract address. and also if excess is passed and it is in contract address then also after balance of native token in contract would be more than the start balance. so refund would always be improper
for eg, 1118 _eth is passed as parameter, then from msg.sender 1118 will transfer. if 118 is unused then. after balance of contract would be plus 118 and excess should be transfer from contract address to msg.sender at the end of the function
Impact
due to improper calculation if current user unused token is not transfer to him, then he might lose it, as then when another user will come , initial balance will be there from starting, and it might transfer to another user, and loss to original user
Code Snippet
https://github.com/sherlock-audit/2024-08-flayer/blob/main/flayer/src/contracts/Locker.sol#L395C1-L398C11
Tool used
Manual Review
Recommendation
Amount should be calculated in such a way that excess amount should be removed from the initial balacne then transfer that amount of native tokens to the msg.sender.