jo13 - PoolTogether on Blast L2: Rebasing WETH Allows Malicious Users to Inflate Contributions and Manipulate Prize Odds

[sherlock-admin3]

jo13

medium

PoolTogether on Blast L2: Rebasing WETH Allows Malicious Users to Inflate Contributions and Manipulate Prize Odds

Summary

The PoolTogether protocol deployed on BlastL2 uses WETH as the prize token. WETH on Blast L2 is a rebasing token that automatically generates yield over time. This setup introduces a critical vulnerability where a malicious user can exploit the generated yield to artificially inflate their contributions, thereby increasing their chances of winning prizes and decreasing the chances for honest users.

Vulnerability Detail

WETH on Blast L2 is a rebasing token WETH and USDB accounts have Automatic yield by default for both EOAs and smart contracts. Users can change their WETH and USDB accounts' yield mode by calling the configured function on the relevant token address.

// Define yield modes
enum YieldMode { AUTOMATIC, VOID, CLAIMABLE }

// Interface for interacting with yield-generating ERC-20 tokens
interface IERC20Rebasing {
 >> function configure(YieldMode) external returns (uint256);
  function claim(address recipient, uint256 amount) external returns (uint256);
  function getClaimableAmount(address account) external view returns (uint256);
}

• This setup introduces an issue where a malicious user can exploit the generated yield to artificially inflate their contributions, thereby increasing their chances of winning prizes and decreasing the chances for honest users.

  Over time, the WETH balance in the PrizePool increases due to the automatic yield generation. This yield is reflected in the '_deltaBalance'. anyone can call contributePrizeTokens to contribute the recently generated yield to a designated vault.

• this action will affect the vault portion that this yield is contributed to, which will affect the winning probabilities for this and other vaults contributing to the prize pool.

  function contributePrizeTokens(address _prizeVault, uint256 _amount) public returns (uint256) {
  >>  uint256 _deltaBalance = prizeToken.balanceOf(address(this)) - accountedBalance();
  if (_deltaBalance < _amount) {
    revert ContributionGTDeltaBalance(_amount, _deltaBalance);
  }
  uint24 openDrawId_ = getOpenDrawId();
  >> _vaultAccumulator[_prizeVault].add(_amount, openDrawId_);
  >> _totalAccumulator.add(_amount, openDrawId_);
  emit ContributePrizeTokens(_prizeVault, openDrawId_, _amount);
  return _deltaBalance;
  }
  // ////////////////////////////////////////////////////////////////
  SD59x18 vaultPortion = getVaultPortion(
  _vault,
  startDrawIdInclusive,
  lastAwardedDrawId_
  )

• The idea is that this yield is generated from all vault contributions. However, a malicious user can exploit this feature to their advantage. While this might be considered a legitimate strategy in some contexts, within the PoolTogether on Blast L2 scenario, it has a detrimental effect. The malicious user's ability to exploit the yield generation artificially inflates their vault's portion compared to other vaults. This decrease in other users' vault portions consequently increases the malicious user's chances of winning prizes, as mentioned previously.

Impact

• Unfair Advantage: Malicious users can consistently win prizes by exploiting the rebasing yield.

• Decreased Chances for Honest Users: Honest participants have reduced odds of winning, leading to unfair prize distributions.

Code Snippet

• link
• link

  Tool used

Manual Review

Recommendation

change the yield mode of WETH and USDB accounts by calling the configure function and making it a claimable relevant token address, and send it to the donator.

Duplicate of #114