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
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed Notional Exponent reports indexed on Coin Buggie. 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, 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
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: 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: User unable to migrate under certain edge case
Notional Exponent's Morpho lending router mishandles position migration for users who hold collateral but carry no debt. The router always passes type(uint256).max as the asset-to-repay amount when exiting a position, which the router converts into "repay all outstanding borrow shares" plus a zero asset amount. For a collateral-only borrower whose borrow shares total zero, this produces a request to repay zero assets and zero shares simultaneously, and Morpho Blue's exactlyOneZero invariant check rejects that input and reverts the entire migration. As a result, legitimate users with no debt cannot migrate from the old lending router to the new one, blocking a core protocol function. The protocol team fixed the issue by skipping repayment entirely when debt is zero.
Notional Exponent: Attacker can drain the entire suppliers on Morpho market by inflating collateral price
A Notional Exponent YieldStrategy integrates directly with Morpho as an oracle: its price() determines how much loan a depositor can borrow against YieldStrategy shares held as collateral. The flaw is that initiateWithdraw() escrows the user's shares (raising s_escrowedShares, collapsing effectiveSupply to the VIRTUAL_SHARES floor) without burning them, and because Morpho.borrow() bypasses the LendingRouter's transient-state override, the base convertToAssets() is used. An attacker who escrows nearly all shares and then donates a small amount of yield token to the strategy inflates price() to ~1e36, letting them borrow the entire Morpho market's supplier liquidity while still finalizing their withdrawal and reclaiming their original collateral. All funds supplied to the affected Morpho market are at risk.
Notional Exponent: Hard-Coded Mainnet WETH Address Breaks All Non-Mainnet Deployments
Notional Exponent hard-codes the Ethereum mainnet WETH9 address as a compile-time constant in Constants.sol and references it across strategies, routers and withdraw-request managers. Because the same bytecode is intended for future deployments on Arbitrum, Base and other L2s where wrapped ETH lives at a different address, deposit/withdraw calls against the constant would revert or no-op, stranding funds and corrupting accounting protocol-wide. The team acknowledged the issue but deferred the fix until they actually deploy to those chains. The suggested fix is to make WETH an immutable constructor argument or pull it from AddressRegistry and to assert code-length at deployment.