Notional Exponent — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Notional Exponent, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 26
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 26 closed, publicly disclosed Notional Exponent reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Oracle manipulation, Integer overflow / underflow, Front-running / MEV, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Notional Exponent
- Oracle manipulation findings disclosed against Notional Exponent
- Integer overflow / underflow findings disclosed against Notional Exponent
- Front-running / MEV findings disclosed against Notional Exponent
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Notional Exponent: Funds stuck if one of the withdrawal requests cannot be finalized
Notional Exponent's single-sided LP withdrawal flow is not designed to handle partial finalization: `finalizeAndRedeemWithdrawRequest` iterates over every configured withdrawal token and reverts the entire call with `WithdrawRequestNotFinalized` if any single withdrawal request fails to clear. Consequently a user cannot redeem a position once one of its legs becomes stuck, even though the other legs are fully settled and immediately claimable. The failure can be triggered by draining external liquidity, an external protocol being paused or compromised, an ERC4626 redeem reverting to zero assets from rounding on a small share amount (no minimum position size is enforced), or an external minimum-withdrawal restriction. The reporter illustrates this with a Curve wstETH/WETH pool where a stuck LST leg strands the otherwise-immediately-withdrawable WETH, escalating a partial (~50%) loss into a 100% griefing of user funds. The team acknowledged the issue but declined to fix it, arguing the Lido-specific case is out of scope and that stuck funds remain recoverable via vault upgrades or `rescueTokens`.
Notional Exponent: Hardcoded `useEth = true` in `remove_liquidity_one_coin` or `remove_liquidity` lead to stuck fund
Notional Exponent's single-sided LP Yield Strategy vault enters Curve V2 two-token pools with use_eth derived from msg.value (false when the underlying is WETH), but hardcodes useEth=true on every exit. For pools whose Coin 0 (ETH_INDEX) is WETH — e.g. the t/ETH and cvxeth pools — the Curve pool therefore pays the vault in native ETH on withdrawal, while unstakeAndExitPool's wrap-back logic never fires because neither TOKEN_1 nor TOKEN_2 is the zero ETH address. The resulting stranded native ETH is invisible to the WETH-balance-based accounting in _burnShares, so withdrawing/redemption users receive zero assets while their funds sit inert in the vault. The protocol team fixed the issue in notional-v4 PR #26.
Notional Exponent: `migrateRewardPool` Fails Due to Incompatible Storage Design in `CurveConvexLib`
Notional Exponent's AbstractRewardManager exposes migrateRewardPool to relocate staked positions when Convex deprecates an old reward pool for a new one, but the CurveConvex2Token wrapper pins its deposit target through two immutable references: the token stores CurveConvexLib immutably, which in turn stores the Convex reward pool immutably. Consequently, even though migrateRewardPool rewrites the reward manager's storage slots via delegatecall, newly minted LP tokens are still deposited into the original pool, so a Convex migration cannot take effect without a full contract upgrade. This breaks the documented IRewardManager contract, and the team acknowledged the issue but declined to fix it at this time. Because there is no economic exploit path and the impact is a failure to migrate rather than a loss of funds, it is a design/availability limitation rather than a traditional high-severity vulnerability.
Notional Exponent: Malicious user can change the `TradeType` to steal funds from the vault or withdraw request manager
Notional Exponent's single-sided LP yield vault and withdraw request manager build DEX trades from caller-supplied TradeParams. Because the caller can set tradeType instead of the contract enforcing TradeType.EXACT_IN_SINGLE, an attacker passing EXACT_OUT_SINGLE inverts which side of the trade is fixed: the exact 'amount' becomes the exact output rather than the exact token quantity being sold. In a WBTC/DAI Curve redemption this turns a 10,000 DAI sale intended to yield ~0.1 WBTC into a trade that spends an arbitrary surplus of vault DAI to deliver exactly 10,000e18 WBTC, draining excess balances held on the vault contract. The same flaw appears in _preStakingTrade, letting a user buy staking tokens with excess USDC held on the withdraw request manager. Sherlock adjudicated the finding high and the Notional team fixed both locations by hardcoding TradeType.EXACT_IN_SINGLE.
Notional Exponent: Incorrect assumption that one (1) Pendle Standard Yield (SY) token is equal to one (1) Yield Token when computing the price in the oracle
Notional Exponent's Pendle PT oracle miscalculates PT asset values when a strategy is deployed with useSyOracleRate_ enabled, because it multiplies the Yield Token's Chainlink price by the SY-per-PT rate under the false assumption that 1 SY always equals 1 Yield Token. For Pendle SY contracts whose redemption performs swaps or external staking withdrawals subject to slippage and fees, 1 SY can be worth less than 1 Yield Token, so the computed price is inflated. That inflates collateral valuation, letting users over-borrow and raising bad-debt risk to the protocol. The team acknowledged the issue but elected to manage it via deployment parameters rather than a code fix.
Notional Exponent: Incorrect `tokensClaimed` calculation in `EthenaCooldownHolder::_finalizeCooldown()` blocks withdrawals
Notional Exponent's EthenaCooldownHolder locks user withdrawals whenever sUSDe.cooldownDuration() is set to 0. In that configuration the _startCooldown path redeems sUSDe for USDe immediately, so by the time _finalizeCooldown runs, USDe is already sitting in the holder and the balance-before/balance-after delta computes to zero. tokensClaimed resolves to 0, the manager never receives the funds, and the user's withdrawal can never complete, stranding their assets. The protocol fixed it in PR #19 by recording the balance change at initiation time and using that stored delta at finalization instead of recomputing it from the holder balance.
All reports in this group
- Notional Exponent: Rounding discrepancy between `MorphoLendingRouter::healthFactor` and `Morpho::repay` causes position migration failuresLogic error$0
- Notional Exponent: Attacker can drain the entire suppliers on Morpho market by inflating collateral priceOracle manipulation$0
- Notional Exponent: DoS might happen to `DineroWithdrawRequestManager#_initiateWithdrawImpl()` due to overflow on `++s_batchNonce`Integer overflow/underflow$0
- Notional Exponent: Users unable to claim rewards when Curve LP tokens are staked to Curve Gauge.Logic error$0
- Notional Exponent: Unable to support Curve Pool with Native ETHLogic error$0
- Notional Exponent: Hard-Coded Mainnet WETH Address Breaks All Non-Mainnet DeploymentsLogic error$0
- Notional Exponent: Missing Slippage Protection in Expired PT Redemption Causes User Fund LossFront-running / MEV$0
- Notional Exponent: Minting yield tokens single sided can be impossible if CURVE_V2 dexId is used on redemptionsLogic error$0
- Notional Exponent: Incorrect asset matching for ETH/WETH leads to potential DoS of exitPosition in CurveConvexStrategyLogic error$0
- Notional Exponent: Liquidations can be frontrunned to avoid by paying as little as 1 share.Logic error$0
- Notional Exponent: Single sided strategy cant do trades for ETH poolsLogic error$0
- Notional Exponent: Withdrawals ongoing for OETH, apxETH, weETH, and almost any LST are overpriced by the oracleLogic error$0
- Notional Exponent: Incompatibility of `ERC20::approve` function with USDT tokens on Ethereum Mainnet chainLogic error$0
- Notional Exponent: User unable to migrate under certain edge caseLogic error$0
- Notional Exponent: Emission rewards will keep accruing even the yield strategy is emptyLogic error$0
- Notional Exponent: Lack of minimum debt threshold enables unliquidatable small positionsLogic error$0
- Notional Exponent: Unable to deposit to Convex in ArbitrumLogic error$0
- Notional Exponent: OETH Strategy Broken as Rebasing Not EnabledLogic error$0
- Notional Exponent: `DineroWithdrawRequestManager` vulnerable to token overwithdrawal via batch ID overlapLogic error$0
- Notional Exponent: `initializeMarket` can be frontran, preventing markets from being configured in `MorphoLendingRouter `Logic error$0