Lines of code
<https://github.com/code-423n4/2022-04-mimo/blob/b18670f44d595483df2c0f76d1c57a7bfbfbc083/core/contracts/liquidityMining/PARMiner.sol#L257-L279&gt;

Vulnerability details

Impact

For the PARMiner and DemandMiner contracts, arbitrage bots could harvest significant portion of rewards by monitoring MEV, and front run any reward token (either a.mimo() or par) being transferred to the liquidityMining contract (i.e. call the deposit() function with very high gas limit, so it gets included in a block before reward token gets sent to the contract), and call withdraw() shortly after reward token gets sent to take profit.

Proof of Concept

The GenericMiner contract and all contracts that inherit GenericMiner have a _refresh() function that updates _accAmountPerShare which is used to calculate reward payment. The PARMiner contract also has an additional _refreshPAR() function that uses a similar concept to calculate par reward payment.

The variables _accAmountPerShare or _accParAmountPerShare only get updated if there’s reward token being sent to the miner contract, given how reward and parReward are calculated. And a user only gets reward when _accAmountPerShare or _accParAmountPerShare increases relative to the value of the same variables when the user called deposit(). In other words, the amount of reward a user gets by depositing to the miner contract has nothing to do with the amount of time that has passed since the user deposited to the contract, but has everything to do with the amount of reward token being sent to the miner contract after the user has deposited.

Given this design, a MEV arbitrage bot could monitor reward token transfer into the miner contracts, and front run any such transfer of significant size and calls deposit() right before, and after the reward token transfer is complete, calls withdraw() to harvest reward. The existence and power of such arbitrage bots are well documented. for example in this article published by Paradigm: <https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest&gt;

This greatly reduces incentive for regular users to participate in the project, knowing that powerful MEV bots could essentially time the market, and harvest significant portion of the reward.

Tools Used

Manual review, Remix

Recommended Mitigation Steps

There are several ways to mitigate this risk:

1. allow only EOAs to call the deposit() and withdraw() functions of the miner contracts. This would make it much more difficult for MEV arbitrage bots to front run reward token transfers into the miner contracts. This could be done by adding an onlyEOA modifier, such as the below

modifier onlyEOA() {
    require(msg.sender == tx.origin, "Must use EOA");
    _;    
}

2. modify the reward calculation logic to include the amount of time that a user has deposited in the miner contract

---

The text was updated successfully, but these errors were encountered:

All reactions