Peapods — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Peapods, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 23
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 23 closed, publicly disclosed Peapods 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, 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 Peapods
- Front-running / MEV findings disclosed against Peapods
- Oracle manipulation findings disclosed against Peapods
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Peapods: hardcoded V3_POS_MGR address won't be the same on every chain
Peapods' V3Locker contract hardcodes a single Uniswap V3 NonfungiblePositionManager address (0xC36442b4a4522E871399CD717aBDD847Ab11FE88) in its constructor, but that address is only valid on Ethereum Mainnet. Because the audit scope covers Arbitrum One, Base, Mode and Berachain, deploying V3Locker on those networks initializes it against the wrong contract, leaving the position locker unable to function properly outside Ethereum. The report classifies this as a deployment/operability defect rather than a demonstrated theft of funds. The proposed mitigation is to expose an administrative setter so the manager address can be configured per chain instead of being frozen at construction.
Peapods: LeverageManager removeLeverage does not support advanced self-lending pods with podded fTKN as pairedLpTKN.
Peapods' LeverageManager supports two self-lending pod modes: ordinary ones whose paired LP asset is a fraxlend fTKN, and an advanced mode where the paired asset is itself podded (a pfTKN), configured via the `_hasSelfLendingPairPod` flag. In the `removeLeverage` repayment path, `_acquireBorrowTokenForRepayment()` unconditionally treats the self-lending pair as a plain fraxlend fTKN, calling `convertToShares()` and `redeem()` on it. When the pair is a podded fTKN, those assumptions break, so the deleveraging flow cannot acquire the borrow token needed to repay the flash loan and the position cannot be unwound. This is a medium-severity functional failure of the leverage-exit feature for advanced self-lending positions.
Peapods: `addInterest` will not update the interest acurately which would enable users to claim rewards for time that they weren't staked inside `LendingAssetVault`
Peapods' LendingAssetVault accrues interest on its underlying Fraxlend pairs through an update loop that only calls addInterest when the utilization-rate change exceeds a 0.1% threshold. Because totalAsset and totalBorrow are cached snapshots from the last interaction while only the vault's own asset count is refreshed, the computed rate change routinely stays below that threshold even after long idle periods, so no interest is credited on deposit. A user can then deposit, force a second interest update via another small interaction, and withdraw, capturing interest for a window before their funds were actually staked. The recurring impact ranges from dust to small but MEV-extractable sums, leading the report to recommend deciding accrual from previewAddInterest's actual interest math rather than the stale rate-change comparison.
Peapods: Zapper `_swapV3Single()` has multiple integration issues with V3 swap.
Peapods' Zapper contract implements a Uniswap V3 swap route used when IndexUtils.addLPAndStake() zaps an LP token that differs from the index's paired token. That route is built on several hardcoded assumptions that break in real deployments: the single-hop TWAP oracle query forces a pool fee of 10000 regardless of the actual fee tier, _getPoolFee() returns 0 on Arbitrum which is incompatible with the DEX_ADAPTER, and the multihop path hardcodes the Ethereum-mainnet Uniswap V3 router address. As a result, the zap produces wrong outputs or fails entirely for tokens/pairs that deviate from the PEAS/pairedLpTKN setup, for Arbitrum users, and for any multihop V3 swap. Users calling addLPAndStake() are the impacted party.
Peapods: AutoCompoundingPodLp `_pairedLpTokenToPodLp()` does not correctly handle leftover pTKNs.
Peapods' AutoCompoundingPodLp contract runs an autocompounding cycle that swaps reward tokens into the paired LP token, converts roughly half of that into the pod token (pTKN), then adds both to a UniV2 pool and stakes the resulting LP. When the LP-add step reverts on slippage, the paired/token balances stay in the contract, but later epochs again swap a fresh ~half of the paired balance into pTKN without considering the leftover pTKN already present. This compounds the ratio each cycle (e.g. 10000 pairedLpTKN degrading to 2500 pairedLpTKN plus 7500 pTKN), eventually making every LP-add fail on slippage, permanently stranding pTKN and DoSing autocompounding LP additions. An attacker can kick off or accelerate the imbalance by simply donating pTKN to the contract, since `_getSwapAmt` ignores the current pTKN balance.
Peapods: MEV bots will steal from users due to an incorrectly manipulated value
Peapods' Zapper lets users swap tokens through Uniswap V3 while specifying a minimum output amount for slippage protection. In the DEX adapter's swap path, the user-provided minimum is silently multiplied by a protocol-side factor (1000 - _finalSlip)/1000, shrinking the enforced floor further before the swap executes. Because the user's actual minimum is lower than what they requested, MEV bots can sandwich the transaction and extract profit within the widened slippage band, so the user receives less than the stated guarantee. The finding was confirmed as a medium in the Sherlock contest and the recommended fix is to pass user-supplied minimums through unchanged rather than re-applying the protocol slippage percentage on top.
All reports in this group
- Peapods: spTKNMinimalOracle `_calculateSpTknPerBase()` does not calculate correct price for podded or fraxlend pair pairedLpTKNs.Oracle manipulation$0
- Peapods: Open fee is overcharged in `_addLeveragePostCallback` functionLogic error$0
- Peapods: Improper Handling of Paused Tokens in `TokenRewards._resetExcluded()` FunctionLogic error$0
- Peapods: LeverageManager closeFee is only collected for pTKN, which can be easily bypassed.Logic error$0
- Peapods: LendingAssetVault should also call `_updateInterestAndMdInAllVaults()` in multiple functions.Logic error$0
- Peapods: Liquidations will revert incorrectly due to an out-of-sync leftover collateral valueLogic error$0
- Peapods: LendingAssetVault incorrectly updates vaultUtilization if CBR for a single FraxlendPair decreases.Logic error$0
- Peapods: `spTKNMinimalOracle.sol` counts debond fee twice, which will make the end price (spTKN per base) higher than it should beOracle manipulation$0
- Peapods: Pod DoS if the LEAVE_AS_PAIRED_LP_TOKEN option is enabledLogic error$0
- Peapods: Transaction may revert unexpectedly due to missing allowance for the lending pair assetLogic error$0
- Peapods: `_protocolFees` can be applied multiple times in `AutoCompoundingPodLp` contractLogic error$0
- Peapods: Vault inflation attack in `AutoCompoundingPodLp` is possible due to incorrectly minting dead sharesLogic error$0
- Peapods: Incorrect `minAnswer` check doesn't protect the protocol from massive price dropsOracle manipulation$0
- Peapods: Malicious liquidator can intentionally leave dust amount of collateral and won't trigger bad debt handlingLogic error$0
- Peapods: The amount of shares needed for redemption of borrow tokens is underquoted during the removal of leverage process leading to reverting.Logic error$0
- Peapods: `PodUnwrapLocker` can be drained due to an arbitrary inputLogic error$0
- Peapods: Malicious actors can front-run setYieldConvEnabledFront-running / MEV$0