How Firepan found a ~$1,400 reward-skim in Stake DAO lending that a prior audit missed — principal untouched.

Reward accounting is where DeFi protocols hide their quiet bugs. The headline exploits — flash-loan price manipulations, reentrancy drains — get the attention and the checklists. But the per-user reward-checkpoint math that decides who is owed what, accruing silently every block across thousands of depositors, is exactly the kind of code that passes a review because it looks right and the obvious tests pass.

Stake DAO's StrategyWrapper family is that kind of code, and it had already been audited. So the bar was not "is this contract safe?" — someone had already answered that. The bar was: is there something true about this contract that a careful first pass would not have caught? A checklist re-run was never going to find it. The bug, if it existed, would be in a place a human reading line-by-line would skim past as obviously fine.

That is precisely the kind of bug a machine-checked invariant catches and a checklist does not — if you encode the right invariant, and if you are willing to chase its counterexample instead of explaining it away.

Firepan ran the reward-bearing wrappers through an invariant / conservation engine — an analysis that asserts economic conservation laws the contract must always satisfy. The law here is simple and load-bearing: the sum of reward payouts can never exceed the emissions the wrapper actually received. If that ever breaks, someone is being paid with rewards that belong to someone else.

The engine produced a counterexample: a sequence of operations under which payouts exceeded emissions. The honest, easy move at that point is to assume it is a harness artifact — invariant engines produce false alarms, and dismissing them is faster than chasing them. Firepan chased it.

It resolved to a single line. StrategyWrapper._claim advances a depositor's reward checkpoint only when their floored payout is non-zero. Deposit one wei, let a period pass so your tiny pending rounds to zero — your checkpoint never moves. Then deposit a large amount and claim: you apply the old period's per-token rate to your new, large balance, and skim the shared reward pot. Permissionless, profit-motivated, repeatable every period, with the capital fronted for a single block. Firepan wrote a deterministic mainnet-fork proof-of-concept, sized it against live state — 6,537 CRV drainable on one wrapper, with the same code on every deployment — and found the identical defect on the extra-reward path. Then disclosed it to Stake DAO the same day, with the PoC and a verified one-line fix.

One line of code, one line of fix — but a live, profit-motivated reward skim that the contract's prior audit did not surface.

Alongside REWARD-1, the review surfaced two Mediums, both with one-line or parameter fixes: DUST-1 — a permissionless 1-wei grief that bricks the live leverage-unwind path via Morpho's arbitrary-receiver withdrawCollateral (fork-bounded to a recoverable liveness denial-of-service, so Firepan and Stake DAO jointly locked it at Medium rather than inflating it), and M-1 — a thin depeg buffer on a synthetic-stable market. The full per-finding detail, bounds, and PoCs are in the technical report.

Two things about how REWARD-1 was handled matter as much as the finding itself.

Firepan reproduced before it rated. REWARD-1 shipped with a deterministic PoC and live on-chain sizing, and Stake DAO's own engineer reproduced it on a mainnet fork — so there was no severity argument to have. And when the next finding, DUST-1, turned out under fork-testing to be a recoverable griefing nuisance rather than a drain, Firepan locked it at Medium with the client instead of dressing it up as a second High. A report's credibility is its worst overstatement; there wasn't one.

A counterexample is a lead, not a verdict. The value was in chasing the one that turned out real — and not inflating the one that didn't.

That is the difference between a checklist and an adversary. The prior audit was not careless; reward-checkpoint bugs are genuinely easy to read past. What caught this was encoding the conservation law as a machine-checked invariant, and then doing the unglamorous work of running its counterexample to ground instead of assuming it was noise.

"Already audited" is not the same as "safe." A first audit narrows the field; it does not exhaust it — especially in the quiet accounting code where the obvious tests pass and the bug is one branch deep. A second set of eyes is only worth engaging if it can find what the first set missed. That is the bar Firepan holds itself to: not to match the incumbent, but to beat them.

For Stake DAO, that meant a live, profit-motivated reward skim caught before it was exploited, sized against real on-chain value, disclosed the same day with a verified fix, and reproduced by their own engineer — on contracts that had already been signed off. The fix was one line per reward path. The cost of not finding it was every depositor's rewards, every period, on every wrapper.

This is what Firepan was built for: encoding the invariants a checklist can't, chasing the counterexamples a human would explain away, and finding the bug the last audit didn't — in days, not months.

Fully remediated. Stake DAO adopted the one-line fix on both reward paths and has since upgraded every affected market to the corrected wrapper code — the finding is remediated protocol-wide as of publication.

The full technical report is published alongside this case study at firepan.com/reports/stakedao-lending-v1/ (FP-AUDT-2026-0006), with the per-finding detail, the mainnet-fork PoCs, the on-chain sizing, and the verified fixes.