Current implementation assume that all token are 18 decimal

Summary

Although most erc20 tokens are 18 decimals, some may still be able to make a token with different than 18 decimals, for some special reason. However, here the contract assumes all tokens are 18 decimal.

Vulnerability Detail

Dividing directly by 1e18 and assuming all tokens are 1e18 can cause the different result in mintAmount.

Impact

Code Snippet

https://github.com/sherlock-audit/2022-10-merit-circle/blob/main/merit-liquidity-mining/contracts/TimeLockPool.sol#L96

function deposit(uint256 _amount, uint256 _duration, address _receiver) external override {
        if (_amount == 0) {
            revert ZeroAmountError();
        }
        // Don't allow locking > maxLockDuration
        uint256 duration = _duration.min(maxLockDuration);
        // Enforce min lockup duration to prevent flash loan or MEV transaction ordering
        duration = duration.max(MIN_LOCK_DURATION);

        depositToken.safeTransferFrom(_msgSender(), address(this), _amount);

        uint256 mintAmount = _amount * getMultiplier(duration) / 1e18;

        depositsOf[_receiver].push(Deposit({
            amount: _amount,
            shareAmount: mintAmount,
            start: uint64(block.timestamp),
            end: uint64(block.timestamp) + uint64(duration)
        }));

        _mint(_receiver, mintAmount);
        emit Deposited(_amount, duration, _receiver, _msgSender());
    }

Tool used

Manual Review

Recommendation

Always while dividing use erc20(tokens).decimal() so you can get the real decimal for any token.

sherlock-audit / 2022-10-merit-circle-judging

ali_shehab - Current implementation assume that all token are 18 decimal #70