A restaking LST can expose a "live, slash-aware" TVL view AND a separate lazily-updated rate scalar that the VALUE-BEARING paths actually read. Audit rule: confirm WHICH TVL the mint/deposit and redeem paths read - never assume they use the most correct-looking view.
- EtherFi: EtherFiRestaker.getTotalPooledEther / Liquifier.getTotalPooledEther DO query live EigenLayer slashing (getWithdrawableShares, EtherFiRestaker.sol:256-269) - but they are standalone views, NOT summed into the rate. The actual eETH<->ETH rate = LiquidityPool.getTotalPooledEther() = totalValueOutOfLp + totalValueInLp (LiquidityPool.sol:569-571), two stored scalars. totalValueOutOfLp reflects validator/restaking PnL ONLY via the oracle rebase chain (EtherFiAdmin._handleAccruedRewards -> MembershipManager.rebase -> LiquidityPool.rebase, signed int128 accruedRewards). So a slash hits the rate LAZILY (next consensus report), not when it happens on-chain.
- Generalize: grep for every reader of the rate in deposit/mint/redeem/previewRedeem; verify it reads the SAME TVL that incorporates slashing, and how promptly that TVL updates. A slash-aware view existing elsewhere is a decoy.
On any lazily-rebased LST, between an on-chain slash and the oracle's negative rebase the rate is stale-HIGH, so an unprivileged holder can instant-redeem at the pre-slash rate and socialize the loss onto stayers. This is the STANDARD rebasing-LST property (Lido/RocketPool share it) and is usually ACCEPTED/known design, not a payable Critical. Severity = (rate staleness fraction) x (redemption throughput available in the staleness window) - exit fee - low-watermark. EtherFi caps all three: 30 bps ETH exit fee, 1% TVL low watermark, and a per-second BucketLimiter on redemptions (EtherFiRedemptionManager.sol:365-368). Quantify all three caps BEFORE rating severity; a stale-high rate alone is not High if a bucket limiter throttles exit volume. The queued WithdrawRequestNFT path is finalized by the oracle AFTER the slash is reflected -> stayers aren't arbitraged on that path. -> WALK unless the bucket is huge / fees zero AND the disclosure-gate shows it's undisclosed-and-unaccepted (check the project's audit corpus first - this class is almost always known).
An absolute annualized-APR bound applied to NEGATIVE rebases (apr = 1e4*accruedRewards*365d/(TVL*elapsed); require(absApr <= acceptableRebaseAprInBps), EtherFiAdmin.sol:251-257) turns a large slash into a FULL report-processing DoS: an oversized negative rebase makes _handleAccruedRewards revert, reverting the entire executeTasks (rewards + withdrawal finalization all blocked) until the committee submits a report spanning enough elapsedTime to bring annualized APR under cap, or governance raises the cap. Bank: negative-rebase sanity caps couple rate-correctness to liveness - a big slash can stall withdrawals, not just misprice. Oracle/governance-controlled (not attacker-reachable here), but a real operational risk + an audit-question for any capped-rebase LST.
Across PriorityWithdrawalQueue / LiquidityPool / EtherFiRedemptionManager / restaker: (a) share-accounted (not balance) TVL in payouts - min(requested, amountForShare(shares)) (WithdrawRequestNFT.sol:121); (b) snapshot+postcondition guards everywhere (pre/post balance asserts, share-price-monotonicity if (share > _amountSharesToBurn) revert LiquidityPool.sol:509); (c) oracle-consensus binding of ALL TVL deltas (out-of-scope for attacker-input findings); (d) role-gated EigenLayer ops (onlyAdmin/onlyEtherFiNodesManager + allowlisted forwardExternalCall selectors). When these hold, the donation/inflation/double-count classes are closed - spend cycles on the DRIFT (new code that bypasses a house pattern) instead. Related: [[2026-06-10-cycle221-LST-exchange-rate-funding-clock-generalizes-balance-read-vs-price-quote]], [[seams-lst-selfrate-donation-empirical-test-2026-06-11]], [[2026-06-10-cycle213-restaking-slash-vs-withdrawal-epoch-union-bound]].