Locked Profit Degradation

Locked Profit Degradation is a vault design pattern — popularized by Yearn V2 — that delays recognition of a strategy's reported gain, vesting it linearly over a configurable time window so that depositors who enter immediately after a profitable report() cannot capture the gain at the new, higher share price. It is a structural defense against a specific class of MEV: profit-harvest sandwich attacks.

The pattern emerged in response to a concrete problem. In naive vault designs, a strategy's report(gain, loss, debtPayment) atomically increases totalAssets, which atomically increases pricePerShare = totalAssets / totalSupply. A depositor who front-runs the report() transaction with a large deposit, then back-runs it with an equally large withdrawal one block later, captures the entire harvest gain with zero risk. Locked profit degradation breaks the attack by decoupling "gain reported" from "gain reflected in share price."

How the mechanism works

V2 scalar implementation

Yearn's V2 Vault.vy stores two values: lockedProfit (the raw gain from the most recent report()) and lockedProfitDegradation (the per-second degradation rate, default 46 * 1e18 / 1e6 ≈ ~6 hours to full unlock). On every share-price calculation, the vault computes:

1_calculateLockedProfit() = lockedProfit * (1 - (block.timestamp - lastReport) * lockedProfitDegradation / 1e18)

Share value uses free funds rather than totalAssets:

1_shareValue(shares) = shares * (totalAssets - _calculateLockedProfit()) / totalSupply

At the moment of report(), _calculateLockedProfit() equals the full gain, so share price does not change. Six hours later, _calculateLockedProfit() has decayed to zero and the gain is fully realized in share price. A depositor entering mid-window pays a deposit-unfavorable PPS, and any gain they capture is only the portion unlocked between their deposit and withdrawal.

Critically, a fresh report() replaces lockedProfit rather than adding to it — self.lockedProfit = gain - totalFees. Any residual locked profit from the previous report is dropped into realized PPS at that moment.

V3 mint-to-self implementation

Yearn V3 reimplements the same anti-sandwich property at share-level accounting. On process_report, the vault mints shares_to_lock = convertToShares(gain + refunds - fees) to itself (the vault contract address). These shares are then vested via an unlocking schedule:

1_unlocked_shares() = profit_unlocking_rate * (block.timestamp - last_profit_update) / MAX_BPS_EXTENDED
2_total_supply() = total_supply - _unlocked_shares()

Because the vault's own balance is excluded from the effective supply only as the unlock progresses, PPS increases monotonically over the unlock window. A fresh profit reweights the schedule rather than replacing it, producing smoother accounting than V2's scalar model.

Losses in V3 burn locked shares first before touching realized PPS — the invariant that prevents report-timing sandwich on losses up to the size of the locked buffer.

Security properties

Prevents profit sandwich. The primary design goal. A flash-loan-funded sandwich cannot extract the harvest gain because PPS does not change at report time.

Asymmetric deposit timing. Depositors entering late in the unlock window pay a higher PPS than those who held through the report. This is intentional — it rewards long-term depositors and disincentivizes short-term rotation timed around harvests.

Does not prevent loss sandwich in V2. V2's mechanism only locks profit, not loss. A strategy reporting a loss immediately reduces PPS, and a depositor who enters just before a known loss report is exposed to the full drop. V3's burn-locked-shares-first behavior partially mitigates this up to the size of the buffer.

Interacts with fee accrual. Management, strategist, and governance fees are minted as shares at pre-update PPS during _assessFees in V2, meaning fee recipients benefit from the reported gain even though depositors cannot capture it instantly. Auditors reviewing integrators should trace exactly when fee shares are minted and how they interact with lockedProfit.

Implementation considerations

Configurable unlock time. Yearn's default ~6 hours was tuned against observable MEV arbitrage windows. Protocols forking the pattern should pick a window long enough that a flash-loan sandwich is not profitable but short enough that long-term depositors see reported gains in a timely fashion. V3's profit_max_unlock_time is bounded by SECONDS_PER_YEAR = 31_556_952.

Deposit/withdraw invariant direction. Because totalAssets remains unchanged in deposit math (depositor pays for full assets) but _shareValue subtracts locked profit in withdraw math, the deposit path is deliberately unfavorable during an active unlock. Integrators building vaults-of-vaults must account for this when computing composite PPS.

Interaction with ERC-4626. The standard's totalAssets() function is the hook point for locked-profit accounting. A conforming implementation returns totalAssets - _calculateLockedProfit() from totalAssets() so that convertToShares() and convertToAssets() automatically reflect the unlocked portion. This is the cleanest integration path for new protocols adopting the pattern.

Related patterns

Share-lock period (Sommelier) applies a blanket lock on freshly minted shares for a fixed window (e.g., 2 days), preventing any withdrawal during the lock. Simpler than locked-profit degradation but blocks legitimate withdrawals, not just sandwichers.

Harvest-on-deposit (Beefy) collapses the attack window by running the harvest inside the deposit transaction, leaving no block boundary for a sandwicher to slip into. Effective on cheap chains but gas-prohibitive on mainnet for large vaults.

Virtual-shares-and-decimals-offset (OpenZeppelin ERC-4626) addresses inflation attacks rather than profit sandwiches. Different threat class — both may be needed in the same vault.

Understanding locked profit degradation is essential for auditing Yearn-based protocols and any yield aggregator adopting the pattern. The mechanism's subtlety — different PPS calculations for different code paths, the replacement-vs-addition semantic, the asymmetric treatment of profit and loss — is a recurring source of accounting bugs in integrator wrappers and in forks that attempt to simplify the model.