wickie - Initializing a collection in `Locker.sol` does not refund unused native tokens.

[sherlock-admin4]

wickie

Medium

Initializing a collection in Locker.sol does not refund unused native tokens.

Summary

The initializeCollection() add collection tokens and native ETH equivalent tokens to pool and refund unused native tokens. However, it transfer the difference of balance of the Locker contract before and after initializing. This would results in none or incorrect refunds as the Locker does not hold the native tokens and the balance almost never changes.

Root Cause

In Locker.sol::383

        uint startBalance = nativeToken.balanceOf(address(this));

Get the balance before initializing collection.

In Locker.sol::395-398

        nativeToken.transfer(
            msg.sender,
            startBalance - nativeToken.balanceOf(address(this))

Transfer the difference in balance of native tokens after initialization.

This does not refund the tokens as both collection tokens and native ETH equivalent tokens are directly supplied to the pool before initializing it and the Locker contract is not involved in the transfer of funds.

Internal pre-conditions

The locker contract needs to initialize a collection.

External pre-conditions

None.

Attack Path

None.

Impact

This leads to funds getting stuck in the implementation contract since there is no refund of unused tokens. Liquidity providers would hesitate knowing it will cost them much more to provide liquidity without even getting all the benefits of their liquidity.

PoC

No response

Mitigation

Check the balance of the implementation to properly refund unused liquidity.

In line 383
-       uint startBalance = nativeToken.balanceOf(address(this));
+      uint startBalance = nativeToken.balanceOf(address(_implementation));

In line 395
-       nativeToken.transfer(msg.sender, startBalance - nativeToken.balanceOf(address(this)));
+      nativeToken.transfer(msg.sender, startBalance - nativeToken.balanceOf(address(_implementation)));