Perpetual — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Perpetual, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 13
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 13 closed, publicly disclosed Perpetual 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 Oracle manipulation, Logic error, Reentrancy, across EVM-Solidity, Move. 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
- Oracle manipulation findings disclosed against Perpetual
- Logic error findings disclosed against Perpetual
- Reentrancy findings disclosed against Perpetual
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Perpetual: Two Pyth prices can be used in the same transaction to attack the LP pools
Perpetual's Pyth-integrated OracleMaker and SpotHedgeBaseMaker price LP share minting and redemption using whichever signed Pyth price is most recently stored, subject only to a loose maxAge window rather than any true freshness guarantee. Because Pyth publishes multiple updates per block while a block carries a single timestamp, an attacker can assemble one transaction that deposits at a lower stale price and withdraws at a higher fresh price, converting the price gap into risk-free value that a flash loan can amplify. Neither maker levies deposit/withdraw fees or requires an active whitelist, so the arbitrage is reachable by any address. The sponsor acknowledged the finding and plans to address it before moving from allowlisted to permissionless LPs.
Perpetual: Price band caps apply to decreasing orders, but not to liquidations
Perpetual's ClearingHouse enforces a price-band check when positions are opened or modified, but the liquidate() entry point applies no such check and can be called directly without passing through the order gateways and relayers. Because borrowing fees, funding fees and liquidation penalties are computed from opening notional rather than current position value, the bands exist to stop extreme-priced trades that would suppress fees and liquidator incentive. The asymmetry allows a scenario where a trader who has repeatedly hit one side of the OracleMaker's order book gets its quoted price pushed outside the band while the Pyth oracle midpoint stays in-band, so an emergency reducing order is rejected while a liquidation remains permitted at the in-band price. The finding was confirmed as a valid medium and fixed in perp-contract-v3 PR 17.
Perpetual: In certain cases, users are unable to settle their orders with the PartialFill trade type.
Perpetual v3's order gateway allows ReduceOnly orders to be filled partially, but the position-size validation in _verifyOrder does not subtract the already-filled amount from the order's gross open size. After a first partial fill sinks the user's position below the original order size, the remaining tranche can never be settled because the code re-checks the full gross order size against the shrunken position. That permanently strands the remainder and forces users to burn gas on reverting attempts, a denial of service with a small direct economic cost.
Perpetual: Attackers can sandwich their own trades up to the price bands
Perpetual V3's SpotHedgeBaseMaker hedges user positions by settling trades against a UniswapV3 pool, assuming the pool reflects fair value. Because SHBM's isValidSender accepts any caller, an attacker can open a position directly through the ClearingHouse and sandwich their own trade, skewing the spot pool, trading against the SHBM at the skewed price, and rebalancing within one transaction. Combined with a stale Pyth oracle whose price has already diverged from the moved pool, the short passes the margin check at an inflated valuation and leaves bad debt once the oracle catches up, while the attacker keeps the swap rebalancing profit. The judge upheld the finding as Medium after rejecting an invalidity escalation, noting the attack requires a large oracle-to-pool price gap to be economically meaningful.
Perpetual: No slippage control on maker LP `deposit()`/`withdraw()`
Perpetual's OracleMaker exposes whitelisted-LP deposit()/withdraw() functions that take only an input quantity (amountXCD or shares) and no slippage parameter, with no preview functions, so the collateral returned is decided entirely by the Pyth oracle price at execution. An LP redeeming shares during a volatile swing can receive materially less collateral than expected, and by the time the user observes the shortfall the flash crash has been arbitraged back so the loss is permanent. The protocol acknowledged the missing volatility protection as a known, non-urgent limitation given deposit/withdraw is initially whitelisted. The judge ultimately ruled the issue Invalid (escalation rejected), so no payout was awarded.
Perpetual: Withdrawal caps can be bypassed by opening positions against the SpotHedgeBaseMaker
Perpetual's CircuitBreaker tracks only quote-token flows through the vault, so base-token deposits to the SpotHedgeBaseMaker remain unaccounted until a short position forces the maker to swap them into quote tokens and deposit them. Because the withdrawal threshold is evaluated against a stale TVL snapshot, an attacker controlling an artificially inflated 'fund' balance can open large short base positions to push that swapped collateral into the vault, raising recorded TVL and thereby raising the ceiling on what can be withdrawn before the sync interval resets. Combined with a flash-loan-skewed swap that yields more quote tokens than normal, the attacker can evade the cap and potentially drain the entire vault. The contest judges validated the issue as Medium but the protocol team acknowledged it and declined to fix it early, citing dependency on maker liquidity and swap price bands.
All reports in this group
- Perpetual: There may be excess funds in the PnL pool or bad debt due to the funding fee.Logic error$0
- Perpetual: Incorrect premium calculation in OracleMakerLogic error$0
- Perpetual: Borrow fees can be arbitrarily increased without the maker providing any valueLogic error$0
- Perpetual: OracleMaker's price with spread does not take into account the new positionLogic error$0
- Perpetual: Funding Fee Rate is calculated based only on the Oracle Maker's skew but applied across the entire market, which enables an attacker to generate an extreme funding rate for a low cost and leverage that to their benefitReentrancy$0
- Perpetual: SpotHedgeBaseMaker LPs will be able to extract value during a USDT/USDC de-pegLogic error$0
- Perpetual: Attackers can create positions that have no incentive to be liquidatedLogic error$0