# Vulnerability: \_lpToken and Reward Token Confusion in Staking Contracts

**Overview:**

This vulnerability arises in staking contracts where both the staking token (`_lpToken`) and the reward token are treated similarly. If the **staking token** used in a new pool is the **same** as the **reward token**, the reward calculation becomes flawed. This is because the **balance of the staking token** is often used to calculate rewards, and if the staking token is the same as the reward token, the contract’s reward balance will incorrectly inflate the staking token balance, leading to improper reward distribution.

This flaw allows for rewards to be **under-allocated** to legitimate stakers, as the balance used for reward calculation will be artificially high due to the rewards being added to the same balance as the staking tokens. The incorrect calculation reduces the rewards that should have been distributed to stakers, leading to stakers receiving less than they are entitled to.

***

#### Impact:

If the staking token (`_lpToken`) is the **same** as the reward token, the following issues can arise:

1. **Inflated Staking Pool Balance**:
   * The staking pool’s balance is calculated using the balance of `_lpToken`. However, if the rewards (which are also in the form of the reward token) are deposited into the contract, they will inflate the total supply of `_lpToken`. This inflated balance will be used in reward calculations, skewing the results and reducing the reward-per-share for stakers.
2. **Under-rewarding Stakers**:
   * Since the balance used to calculate rewards (i.e., `lpSupply`) is inflated by the reward token itself, each staker’s rewards will be reduced. This is because the rewards will be distributed over a larger pool of tokens than should be considered, meaning that stakers receive **fewer rewards** than expected.
3. **Reduced Trust in the Protocol**:
   * If stakers realize that they are receiving fewer rewards than they should, the protocol's reputation could be damaged. This can lead to stakers withdrawing their tokens from the platform, reducing overall liquidity and trust in the staking mechanism.

***

#### Vulnerable Code Example (ConvexMasterChef):

```
function add(
    uint256 _allocPoint,
    IERC20 _lpToken,
    IRewarder _rewarder,
    bool _withUpdate
) public onlyOwner {
    if (_withUpdate) {
        massUpdatePools();
    }
    uint256 lastRewardBlock = block.number > startBlock ? block.number : startBlock;
    totalAllocPoint = totalAllocPoint.add(_allocPoint);
    poolInfo.push(
        PoolInfo({
            lpToken: _lpToken,
            allocPoint: _allocPoint,
            lastRewardBlock: lastRewardBlock,
            accCvxPerShare: 0,
            rewarder: _rewarder
        })
    );
}

```

**Flaw:**

* **No check** is made to ensure that `_lpToken` is not the same as the reward token (e.g., `cvx` in the case of Convex).
* If `_lpToken` is the same as `cvx`, the balance of `cvx` in the contract will be inflated by the rewards being added, leading to under-allocation of rewards for stakers.

```
function updatePool(uint256 _pid) public {
    PoolInfo storage pool = poolInfo[_pid];
    if (block.number <= pool.lastRewardBlock) {
        return;
    }
    uint256 lpSupply = pool.lpToken.balanceOf(address(this)); // Vulnerable: Includes reward tokens in balance
    if (lpSupply == 0) {
        pool.lastRewardBlock = block.number;
        return;
    }
    uint256 multiplier = getMultiplier(pool.lastRewardBlock, block.number);
    uint256 cvxReward = multiplier.mul(rewardPerBlock).mul(pool.allocPoint).div(totalAllocPoint);
    pool.accCvxPerShare = pool.accCvxPerShare.add(cvxReward.mul(1e12).div(lpSupply)); // lpSupply is inflated
    pool.lastRewardBlock = block.number;
}

```

**Flaw:**

* The `lpSupply` used in the reward calculation is inflated by the reward token itself (since the reward token and `_lpToken` are the same), leading to a **lower reward-per-share** for stakers.

#### Conclusion:

The lack of a check to ensure that the staking token `_lpToken` is not the same as the reward token introduces a significant vulnerability in staking contracts. This leads to **incorrect reward calculations**, under-rewarding legitimate stakers by diluting the reward-per-share due to inflated token balances. By implementing simple checks and keeping staking and reward tokens separate, developers can ensure that rewards are fairly and accurately distributed to stakers. This protects users from receiving fewer rewards than they are entitled to and maintains trust in the staking mechanism.