Napier Finance - LST/LRT Integrations — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Napier Finance - LST/LRT Integrations, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 10
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 10 closed, publicly disclosed Napier Finance - LST/LRT Integrations 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 Front-running / MEV, Flash loan attack, Logic error, 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
- Front-running / MEV findings disclosed against Napier Finance - LST/LRT Integrations
- Flash loan attack findings disclosed against Napier Finance - LST/LRT Integrations
- Logic error findings disclosed against Napier Finance - LST/LRT Integrations
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Napier Finance - LST/LRT Integrations: Users can frontrun LSTs/LRTs tokens prices decrease in order to avoid losses
Napier Finance's instant prefunded redemption lets PT/YT holders withdraw into ETH at a price that does not yet reflect a pending devaluation of an underlying LST/LRT. Because the value drop only settles after the subsequent rebase, slashing-verification or swap-fee event, a user monitoring the mempool (eETH rebase) or the beacon chain (uniETH penalties/slashings) can frontrun the decline: redeem at the stale higher value, let the value drop, then re-deposit the same ETH for more PT/YT, shifting the loss onto honest stakers. The protocol acknowledged the behavior as known across LST/LRT integrations and recommended a withdraw queue.
Napier Finance - LST/LRT Integrations: Incorrect checking in `receiveFlashLoan` can cause `swapETHForYt` to fail unexpectedly.
Napier's MetapoolRouter validates the flash-loan repayment in receiveFlashLoan by comparing the repay amount against the user's remaining balance after subtracting WETH proceeds, rather than against the total ETH the user supplied. When a victim swaps ETH for YT and the PT/YT issuance path returns enough WETH value, the check spuriously reverts with MetapoolRouterInsufficientETHRepay even though the user's ETH fully covers the repayment. This makes swapETHForYt fail unexpectedly for legitimate callers, breaking a core router flow. It was confirmed by the Sherlock judges as a medium and fixed in metapool-router PR #28 with a one-line comparison change.
Napier Finance - LST/LRT Integrations: Less rsETH minted than intended in volatile conditions. due to zero slippage when staking ETH to mint rsETH
Napier's RsETHAdapter stakes WETH into Kelp DAO's rsETH deposit pool while passing a zero minimum-slippage threshold (`minRSETHAmountExpected = 0`). Because rsETH's price is set by an oracle that tracks live DEX markets that can spike during volatility or LRT depegs, the mint can land at a temporarily inflated rsETH price and return fewer rsETH tokens than the intended economic value. Since the adapter level has no out-of-bound slippage protection, these batches mint at an adverse price and the vault loses value relative to what it would have received under normal pricing.
Napier Finance - LST/LRT Integrations: `currentStakeLimit` depletes faster in some adapters, due to actual amount spent less than the input `stakeAmount`
Napier Finance's LST/LRT adapter layer maintains a `currentStakeLimit` that mirrors the underlying staking pool's buffer cap to prevent draining it. In `BaseLSTAdapterUpgradeable.prefundedDeposit()`, the limit is decremented by the requested `stakeAmount` before staking actually occurs. However, `_stake()` may spend fewer ETH than requested — in the Kelp `RsETHAdapter`, the input is explicitly capped to `stakeLimit` of the RsETH deposit pool — so the ledgered stake limit is reduced more than the real spend, causing the cap to deplete prematurely over successive calls. This is a pure accounting-drift logic error with no direct fund loss, only a degraded/stuck staking buffer, which is why Sherlock accepted it as medium. The fix was to record the stake limit using the actual spent amount returned by `_stake()`, merged in napier-v1 PR #219 and napier-uups-adapters PR #9 with Lead Senior Watson sign-off.
Napier Finance - LST/LRT Integrations: DOS in the claimWithdraw function due to an incorrect check of the lastFinalizedRequestId in the EEtherAdapter.sol
Napier's EEtherAdapter contains an inverted comparison in its claimWithdraw gate. Where EtherFi's WithdrawRequestNFT only allows claiming a request whose tokenId is at or below the admin's last finalized ID, the adapter reverts any request whose ID is strictly below the last finalized ID. Because the EtherFi admin advances lastFinalizedRequestId as new batches finalize, users whose requests were finalized early are permanently blocked from claiming once a later ID is finalized. This denies them their ETH and permanently inflates the adapter's totalQueueEth accounting, stranding funds since the adapter is non-upgradeable.
Napier Finance - LST/LRT Integrations: Adapters revert when 0 shares are minted, making it impossible to deposit under certain conditions
Napier's LST/LRT adapters route deposits through prefundedDeposit(), which computes a stakeAmount bounded by the adapter's availableEth and forwards it to each protocol's _stake() implementation. When that stakeAmount is positive but too small for the target LRT/LST to mint at least one share, all six in-scope adapters throw an InvariantViolation revert and the deposit call fails outright. Because stakeAmount can collapse to such tiny values from lingering leftover balances, deposit becomes impossible even though the protocol intends to allow deposits at zero stakeAmount or at the target protocol's max deposit cap. The team fixed it in adapters PR #16 and napier-v1 PR #220, then closed a related edge case in PR #23, which the Lead Senior Watson signed off on.
All reports in this group
- Napier Finance - LST/LRT Integrations: Missing stake limit validation on `RenzoAdapter._stake`Logic error$0
- Napier Finance - LST/LRT Integrations: Depositing `stETH` to puffer finance will revert due to wrong implementation of `PufETHAdapter._stake` callLogic error$0
- Napier Finance - LST/LRT Integrations: Kelp adapter won't allow users to deposit if `getAssetCurrentLimit` returns `0`Logic error$0
- Napier Finance - LST/LRT Integrations: Slippage on `MetapoolRouter.addLiquidityOneETHKeepYt`Logic error$0