Worked example · 2024-08

Penpie Finance yield-optimizer reward-accounting exploit — Ethereum + Arbitrum — 2024-09-03

Loss: approximately $27M (~11,113.6 ETH-equivalent) across Ethereum and Arbitrum. The Ethereum drain (~$26.7M) executed in three transactions between 18:23 and 18:42 UTC on 2024-09-03; a follow-on ~$621K gUSDC drain on Arbitrum executed at 19:14 UTC, after Pendle Finance (the upstream protocol Penpie integrates) had paused on Ethereum at 18:45 UTC but before the Arbitrum deployment was paused.
Recovery: none of material consequence. Penpie offered a 10% white-hat bounty (~$2.7M) on 2024-09-06; the attacker did not accept. Over the following days the attacker laundered proceeds through Tornado Cash — ~5,600 ETH in the first ~12 hours, the remainder in subsequent batches.
OAK Techniques observed: OAK-T9.001 (Oracle / Price-Curve Manipulation — reward-rate subclass): the attacker exploited a vulnerability in Penpie's yield-optimizer integration with Pendle Finance that allowed manipulation of the reward-token accounting rate; by registering a fake Pendle market and manipulating the reward-rate feed, the attacker inflated the PNP reward tokens claimable against Penpie's treasury. OAK-T9.004 (Access-Control Misconfiguration): the root cause was insufficient validation in Penpie's Pendle-market registration logic — the attacker registered a malicious market contract that Penpie's reward-distribution pipeline accepted as legitimate, and the reward-rate computation for that market was attacker-controllable rather than derived from Pendle's own oracle feed. The combined T9.001 + T9.004 classification reflects the dual character of the exploit: reward-rate manipulation (price-curve subclass) enabled by missing validation on the market-registration surface (access-control subclass).
Attribution: pseudonymous No public named-individual attribution. The attacker used the eXch mixer and Tornado Cash for pre-event funding and post-event laundering. No public OAK-G01 / state-actor attribution.
Key teaching point: yield-optimizer reward-rate feeds derived from upstream-protocol oracle outputs require their own validation at the consumer layer. Penpie's reward distribution consumed a reward-rate input that depended on a Pendle-market reference; Penpie's handler accepted the reward-rate value provided by the registered market without independently validating it against Pendle's own oracle output. The defender lesson is that yield-optimizer integrations should never treat downstream market-provided reward-rate values as authoritative without independent oracle-side validation — the upstream protocol's own oracle is the neutral reference, and the consumer-side handler should cross-check against it.

Summary

Penpie Finance is a yield-optimizer protocol built on top of Pendle Finance, the EigenLayer-aligned yield-tokenisation protocol. Penpie aggregates user deposits and optimises yield across Pendle's yield-token (YT/PT) markets; in exchange, Penpie distributes its native PNP token as a reward incentive to depositors. The reward-distribution pipeline calculates per-user PNP reward claims based on a reward-rate parameter that, by design, depends on the yield performance of the underlying Pendle markets Penpie integrates.

On 2024-09-03 an attacker exploited Penpie's Pendle-market registration logic to register a fake market contract. The fake market was accepted into Penpie's reward-distribution pipeline without sufficient validation; the market contract returned an attacker-controlled reward-rate value that massively inflated the PNP claims the attacker was entitled to. The attacker then claimed the inflated PNP rewards against Penpie's treasury and swapped the claimed PNP for ETH and other liquid assets via DEX venues.

The proximate cause — per SlowMist, BlockSec, and other post-incident analyses — was the missing validation step in Penpie's market-registration handler. Penpie accepted a new market registration based solely on the market contract's conformance to a basic interface check; it did not independently verify that the market was a legitimate Pendle-deployed market, that its reward-rate output was consistent with Pendle's own oracle-derived yield rates, or that the registered market had passed any protocol-side governance review. The attacker exploited this gap by deploying a custom contract that passed the interface check but returned an arbitrarily high reward rate.

For OAK's purposes the case sits at the intersection of T9.001 (reward-rate manipulation as a price-curve subclass) and T9.004 (missing validation on the market-registration surface). The novel OAK contribution is documenting the yield-optimizer consumer-side validation failure as a distinct sub-pattern under T9.001 — distinct from the thin-input oracle manipulation subclass (UwU Lend, Inverse Finance) and the PMM-curve manipulation subclass (WOOFi).

Timeline (UTC)

When	Event	OAK ref
Pre-event	Penpie Finance operates Pendle-integrated yield-optimizer on Ethereum and Arbitrum; reward-distribution pipeline accepts Pendle-market registrations with interface-level validation	T9.004 surface (latent)
Pre-event	Attacker identifies missing validation on market-registration handler; develops fake Pendle-market contract returning attacker-controlled reward-rate value	(off-OAK pre-event preparation)
2024-09-03 ~18:23 UTC	Attacker registers fake Pendle market on Ethereum deployment; Penpie's handler accepts the registration; attacker triggers inflated reward-claim against Penpie treasury	T9.001 + T9.004 extraction (first Ethereum tx)
2024-09-03 ~18:23–18:42 UTC	Attacker executes two additional extraction transactions on Ethereum, cumulative drain reaches ~$26.7M (~11,113.6 ETH-equivalent)	T9.001 extraction continued
2024-09-03 ~18:45 UTC	Pendle Finance detects anomalous activity linked to Penpie integration; pauses Pendle operations on Ethereum	(upstream protocol response)
2024-09-03 ~19:14 UTC	Before Penpie's Arbitrum deployment is paused, attacker executes follow-on extraction on Arbitrum: ~$621K gUSDC drained via the same reward-rate manipulation	T9.001 cross-chain follow-on
2024-09-03 (within hours)	Penpie pauses all deployments; publishes incident acknowledgement	(operator response)
2024-09-06	Penpie publicly offers 10% white-hat bounty (~$2.7M); attacker does not respond	(negotiation attempt, no engagement)
2024-09-03 onward	Attacker launches proceeds: ~5,600 ETH through Tornado Cash in first ~12 hours; remainder in subsequent batches over the following week	T7.001 (Mixer-Routed Hop)
Continuing	No material recovery achieved; Penpie winds down / restructures affected reward-distribution pipelines	(recovery state — nil)

What defenders observed

Market-registration is a distinct access-control surface for yield-optimizer protocols, not a routine integrator task. Penpie treated Pendle-market registration as an integrator-interface operation with basic interface validation; the incident demonstrates that market-registration is a security-critical surface that determines which external contracts' outputs will influence the protocol's reward-distribution accounting. Defender practice for yield-optimizer protocols should treat market-registration as a governance-gated surface — new markets should be registered only after explicit governance review, not via permissionless interface-conformance checks.
Consumer-side reward-rate validation is the structural control Penpie was missing. The fundamental defender mitigation is for the yield-optimizer's reward-distribution handler to independently validate the reward-rate parameter provided by the integrated market against the upstream protocol's own oracle output. For a Pendle-integrated yield optimizer, this means cross-checking the registered market's claimed reward rate against Pendle's own on-chain yield-rate oracle before accepting it as input to PNP reward-claim calculations.
Cross-chain pause synchronisation is a distributed-systems problem that the Penpie–Pendle surface did not solve. Pendle paused on Ethereum at 18:45 UTC; the attacker executed a follow-on drain on Arbitrum at 19:14 UTC, demonstrating a 29-minute cross-chain pause gap. The defender practice lesson is that cross-chain pause operations must be treated as atomic across all deployments — a pause on one chain without a corresponding pause on the other chains leaves the unpaused deployments as a continuing extraction surface.
Reward-rate manipulation is a distinct subclass of T9.001, structurally different from spot-price manipulation. Unlike UwU Lend 2024 (thin-input Sushiswap pair), Inverse Finance 2022 (Sushiswap INV/WETH pair), or WOOFi 2024 (PMM-curve parameter manipulation), the Penpie case involves manipulating a reward-rate rather than a spot price. The mechanism is different — registering a fake market rather than trading against a thin pool — but the OAK classification converges on T9.001 because both involve manipulating a numeric feed that the consumer protocol treats as an oracle input for accounting purposes.

What this example tells contributors writing future Technique pages

T9.001 (Oracle / Price-Curve Manipulation) should have a reward-rate subclass distinct from the spot-price subclasses. The spot-price subclasses (thin-input AMM manipulation, PMM-curve manipulation, liquidity-pool spot-price as oracle) are well-documented in the OAK corpus. Penpie 2024 is the canonical worked example for the reward-rate subclass — the reward-rate is a different type of oracle feed, and the manipulation mechanism (fake market registration) is structurally distinct, but the consumer-side failure pattern (trusting a manipulable numeric feed as authoritative) is the same.
T9.004 is the structural precondition for the T9.001 extraction in this case. The missing validation on market registration is the T9.004 surface; the reward-rate manipulation that inflated the PNP claims is downstream of it. Worked examples for T9.004 should include the Penpie case alongside the canonical cases (Compound vote-takeover, Onyx governance-misconfiguration, etc.) as evidence that access-control-on-market-registration is a distinct T9.004 sub-surface.
Cross-chain pause synchronisation is a cross-cutting Mitigations-layer entry that Penpie provides a clean 2024 worked example for. The 29-minute gap between the Ethereum pause and the Arbitrum follow-on drain is the concrete evidence. The Mitigations layer should include cross-chain pause coordination as a first-class defensive-design requirement for multi-chain deployments.

Public references

[penpiepostmortem2024] — Penpie Finance official post-incident statement covering the September 2024 exploit, the cross-chain drain pattern, and the 10% white-hat bounty offer.
[blocksecpenpie2024] — BlockSec forensic transaction-trace analysis of the Penpie exploit, including the fake-market registration and reward-rate manipulation sequence.
[slowmistpenpie2024] — SlowMist incident analysis covering the pre-event funding, the on-chain attack sequence, and the Tornado Cash laundering pattern.
[peckshieldpenpie2024] — PeckShield headline figures and on-chain analytics for the Penpie September 2024 drain.
[rektrpenpie2024] — Rekt News public-facing summary of the Penpie yield-optimizer exploit.
[cointelegraphpenpie2024] — CoinTelegraph / industry press coverage of the Penpie $27M exploit and the cross-chain follow-on.