Perennial V2 Update #2 — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Perennial V2 Update #2, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 2
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 2 closed, publicly disclosed Perennial V2 Update #2 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 Oracle manipulation, 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
- Oracle manipulation findings disclosed against Perennial V2 Update #2
- Logic error findings disclosed against Perennial V2 Update #2
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Perennial V2 Update #2: ChainlinkFactory will pay non-requested versions keeper fees
Perennial's ChainlinkFactory oracle adapter computes keeper fees in `_applicableValue()` by summing the fee for every price payload in a batched commit, ignoring the `numRequested` argument even though the protocol spec states only requested versions should be reimbursed. Because all payloads are billed unconditionally, an attacker who wins the commit for a single requested version can pad the batched update with many unrequested reports and drain the factory's fee balance. The Lead Judge upheld this as a valid medium and Perennial fixed it in PR #293 by pro-rating the total fee by `numRequested / payloads.length`.
Perennial V2 Update #2: Vault global shares and assets change will mismatch local shares and assets change during settlement due to incorrect `_withoutSettlementFeeGlobal` formula
Perennial V2's vault settlement computes per-oracle-version accounting fees differently at the global versus local (per-user) level. The global `_withoutSettlementFeeGlobal` path deducts the full settlement fee for both a deposit and a redeem within the same oracle version, whereas the local path apportions a single settlement fee across all orders. This asymmetry credits individual depositors and redeemers with more shares and claimable assets than the vault's global totals can cover, and the gap compounds with every mixed deposit/redeem version. Eventually the global balances become too small to back the users' local claims and the `Vault._update` subtraction underflows, leaving the last redeemers and claimers unable to withdraw — a bank-run-style loss-of-funds failure.