Lines of code
<https://github.com/code-423n4/2022-03-biconomy/blob/main/contracts/hyphen/LiquidityPool.sol#L175-L188&gt;

Vulnerability details

Impact

Rewards are given to a user for depositing either ERC20 tokens or their native token into the LiquidityPool. This reward is used to incentivize users to deposit funds into the liquidity pool when the pool is not in an equilibrium state.

For regular users, this liquidity pool state fluctuates based on the frequency and amount of deposits made to the liquidity pool. If a malicious user can control the state of the liquidity pool before a victim deposits tokens into the liquidity pool, they can gain double rewards.

To gain these double rewards, a malicious user can watch the mempool for transactions that will receive a reward when the deposit occurs. When a malicious user sees that victim deposit, the malicious user can attach a higher fee to their transaction and initiate a deposit. This will allow the malicious user’s transaction to front-run before the victim’s transaction.

Once the malicious user’s deposit is complete, the liquidity pool state will be in a near equilibrium state. Then, the victim’s deposit will occur which causes the liquidity pool state to no longer be in equilibrium.

Finally, the malicious user will make a final deposit gaining yet another reward for bringing the liquidity pool state back to equilibrium.

To sum up, a malicious user can create a sandwich attack where they deposit their own tokens before and after a victim’s transaction. This will allow the malicious user to double dip and gain rewards twice due to victim’s deposit.

Proof of Concept

Let’s look at the depositNative function which is the simpler of the two deposit functions.

The key component in the depositNative function is the getRewardAmount which can be found here (<https://github.com/code-423n4/2022-03-biconomy/blob/main/contracts/hyphen/LiquidityPool.sol#L255&gt;) . The getRewardAmount calculates how much available vs supplied liquidity exists in the liquidity pool. There are no (<https://github.com/code-423n4/2022-03-biconomy/blob/main/contracts/hyphen/LiquidityPool.sol#L175-L188&gt;) time-weighted checks to calculate the available vs. supplied liquidity. With a lack of checks for time-weight and that there are no frontrun checks against deposits, it’s trivial to front-run deposits and control the liquidity of the liquidity such that the reward amount can be double-dipped.

Tools Used

Text editor

Recommended Mitigation Steps

1. By allowing each deposit to manipulate the liquidity pool state from either a deficient or excessive state, malicious users can double dip on rewards.
2. Alternative approaches to calculating rewards is possible, for example a dutch auction style deposit system where rewards are distributed evenly could reduce an impact of a frontrun attack.
3. A simpler approach is to record liquidity states at specific block timestamps and check against the timestamp for the current block state.

---

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

All reactions