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
- 5
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 5 closed, publicly disclosed Notional Leveraged Vaults: Pendle PT and Vault Incentives 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, 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 Leveraged Vaults: Pendle PT and Vault Incentives
- Front-running / MEV 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.
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 Incentives: Lack of slippage control on `_redeemPT` function
Notional's PendlePrincipalToken vault redeems PT tokens with slippage protection disabled: line 137 passes a hardcoded minTokenOut of zero to the underlying SY.redeem call. Because not every Pendle SY contract redeems one-for-one — some withdraw from external staking protocols or perform internal swaps that can suffer slippage — users' redemption proceeds may be less than expected, and the vault accepts those reduced amounts outright. The lack of a slippage floor makes redemption value-suppressive for the vault, and exposes it to natural on-chain price drift or active MEV sandwiching during the swap. The finding is reachable through both the instant redemption path and the initiate-withdraw path, and the protocol team fixed it in a follow-up PR that the lead senior Watson signed off on.
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 Incentives: `_splitWithdrawRequest` will make invalid withdraw requests in an edge case
Notional's leveraged-vault withdraw path has a Solidity storage-pointer aliasing bug in _splitWithdrawRequest. When an account is fully liquidated, the function deletes the from-account's WithdrawRequest mapping entry, but the local storage pointer `w` still references that slot, so `w.requestId` gets reset to 0 before it is copied into the liquidator's new withdraw request. A requestId of 0 is the default/empty value, which the finalization functions skip, permanently stranding the liquidator's vault shares.
Notional Leveraged Vaults: Pendle PT and Vault Incentives: After a liquidator liquidates someone else’s position, it could cause a Denial of Service (DoS) when their own position also needs to be liquidated.
A liquidator who runs their own leveraged vault position and also liquidates another user's position can end up holding more vaultShares than their pending withdrawal request covers. The internal _splitWithdrawRequest helper assumes the vaultShares being transferred are never greater than the liquidator's own recorded withdrawal vaultShares. When the liquidator's own position later falls into liquidation territory and Notional attempts to liquidate a share amount that exceeds their withdrawRequest vaultShares, the subtraction w.vaultShares - vaultShares underflows and reverts. This permanently blocks liquidation of that position, leaving the protocol unable to recover the bad debt, and the revert window can also affect regular users who accumulate extra vaultShares.