Notional Leveraged Vaults: Pendle PT and Vault Incentives — disclosed vulnerability reports and payouts

Every publicly disclosed and closed bug bounty report we hold for Notional Leveraged Vaults: Pendle PT and Vault Incentives, with our own summary of each finding and a link to the original disclosure.

Reports indexed
17
Total paid
$0
Critical
0
Largest payout
$0

This page collects the 17 closed, publicly disclosed Notional Leveraged Vaults: Pendle PT and Vault Incentives 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, Front-running / MEV, Oracle manipulation, Reentrancy, 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 Leveraged Vaults: Pendle PT and Vault Incentives
  • Front-running / MEV findings disclosed against Notional Leveraged Vaults: Pendle PT and Vault Incentives
  • Oracle manipulation findings disclosed against Notional Leveraged Vaults: Pendle PT and Vault Incentives
  • Reentrancy findings disclosed against Notional Leveraged Vaults: Pendle PT and Vault Incentives

Curated highlights

The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.

mediumLogic errorEVM-Solidity$0

Notional Leveraged Vaults: Pendle PT and Vault Incentives: _claimRewardToken() will update accountRewardDebt even when there is a failure during reward claiming, as a result, a user might lose rewards.

In Notional's leveraged vault reward accounting, the internal _claimRewardToken() helper advances an account's reward debt before it confirms the reward token transfer actually succeeded. When a transfer quietly fails — from a token balance shortfall or a temporary blacklist on the recipient — the debt is still written as if the user received the tokens, so those rewards are permanently lost to the user. A user claiming via claimAccountRewards() -> _claimAccountRewards() -> _claimRewardToken() therefore loses accrued Pendle PT and vault incentives with no path to recover them. The protocol acknowledged the issue and proposed moving the debt update inside the successful-transfer branch, but ultimately declined to fix it.

Notional Leveraged Vaults: Pendle PT and Vault IncentivessherlockJul 3, 2024Open
highLogic errorEVM-Solidity$0

Notional Leveraged Vaults: Pendle PT and Vault Incentives: `EtherFiLib::_initiateWithdrawImpl` will revert because rebase tokens transfer 1-2 less wei

Notional's leveraged-vault EtherFi integration trusts the eETH amount returned by weETH.unwrap() and then forwards that same amount to LiquidityPool.requestWithdraw(). Because eETH rebases via an internal share mechanism, the actual eETH balance credited to the vault after an unwrap can be 1-2 wei lower than the nominal amount, so the follow-up transfer from the contract to the EtherFi protocol reverts for lack of funds. Since this rounding applies on every unwrap-withdraw path, every EtherFi withdrawal from the vault is permanently blocked (denial of service). The finding was escalated and validated as High and Unique by the Sherlock lead judge, and the protocol fixed it by measuring the delivered balance with a balance-before/after diff instead of trusting the unwrap return value.

Notional Leveraged Vaults: Pendle PT and Vault IncentivessherlockJul 3, 2024Open
highFront-running / MEVEVM-Solidity$0

Notional Leveraged Vaults: Pendle PT and Vault Incentives: Selling sUSDe is vulnerable to sandwich attack when staked token is DAI

Notional's Ethena leveraged-vault redemption path sells sUSDe through a two-leg swap: the first leg trades sUSDe to sDAI on a Curve V2 pool with a hardcoded zero slippage limit, and the second leg (which carries the user's minPurchaseAmount check) only runs when the borrow token is not DAI. Because DAI is the borrow token for the Ethena vault, the second leg is skipped entirely, so the completed exit executes with no minimum-output enforcement. An MEV bot can sandwich the redemption to force a manipulated price on the sUSDe/sDAI swap and extract the user's funds. Sherlock validated the finding, the protocol fixed it in a pull request, and the Lead Senior Watson signed off on the fix.

Notional Leveraged Vaults: Pendle PT and Vault IncentivessherlockJul 3, 2024Open
highLogic errorEVM-Solidity$0

Notional Leveraged Vaults: Pendle PT and Vault Incentives: Lido withdraw limitation will brick the withdraw process in an edge case

Notional's leveraged vault integration with Kelp/Lido ignored Lido's documented withdrawal constraints in the `triggerExtraStep` path. When a user's stETH amount falls outside Lido's MIN_STETH_WITHDRAWAL_AMOUNT / MAX_STETH_WITHDRAWAL_AMOUNT bounds, the withdrawal request can be initiated but can never be finalized, permanently locking the user's funds and preventing further deposits or liquidations. The finding was escalated, validated as High severity, and resolved by replacing the Lido stETH withdrawal with an ETH withdrawal.

Notional Leveraged Vaults: Pendle PT and Vault IncentivessherlockJul 3, 2024Open
mediumLogic errorEVM-Solidity$0

Notional Leveraged Vaults: Pendle PT and Vault Incentives: Protocol could be DOS by transfer error due to lack of code length check

Notional's VaultRewarderLib tries to make reward transfers non-blocking by wrapping them in a Solidity try-catch, so any reverting transfer is swallowed and normal vault operations continue. That mitigation is defeated when the configured reward token address holds no code: a call to a codeless address triggers an intrinsic revert that Solidity does not route into the catch branch, so the entire transaction reverts. Since deposit, redemption and liquidation all flow through this reward-claim path, a self-destructed reward token would brick the protocol's core operations and strand assets. The report was escalated from a low-severity callout, accepted as a unique Medium, and fixed by guarding the transfer with a code-length check in PR notional-finance/leveraged-vaults#101.

Notional Leveraged Vaults: Pendle PT and Vault IncentivessherlockJul 3, 2024Open
highLogic errorEVM-Solidity$0

Notional Leveraged Vaults: Pendle PT and Vault Incentives: Users can deny the vault from claiming reward tokens

Notional's leveraged vault reward claimer in VaultRewarderLib computes secondary rewards (from Convex/Aura pools) by snapshotting the token balance before and after calling the external getReward function. Because both Convex and Aura reward pools expose an unguarded, public getReward(account) that anyone may invoke for any account, an attacker can front-run the vault's claim transaction and have the rewards sent to the vault contract before the vault's own claim runs. The subsequent before/after delta then computes to zero, so the already-received tokens are never accrued, distributed, or recoverable — permanently stranding the rewards that were intended for Notional and its users. The finding was escalated and adjudicated as High severity, and the recommended fix is to base the claim on the entire resulting balance rather than the balance delta.

Notional Leveraged Vaults: Pendle PT and Vault IncentivessherlockJul 3, 2024Open

All reports in this group

Vulnerability classes disclosed here

Related protocol pages