EigenLayer AVS Slashing (WIP)

Independent research — not a commissioned audit. This is our own ongoing analysis of a public protocol, published for the community. Status: WIP, preliminary observations only.

Scope & motivation

EigenLayer's restaking model lets Ethereum stakers re-pledge already-staked ETH (or LSTs) to secure additional services — Actively Validated Services, or AVSs — in exchange for extra yield and extra risk. The mechanism that makes this more than a yield wrapper is slashing: an AVS can define conditions under which an operator's restaked collateral is destroyed for provable misbehavior. That's also the part of the system with the least battle-testing. Unlike consensus-layer slashing, where conditions are fixed and narrow (double-signing, surround votes), AVS slashing conditions are written by each AVS team, reviewed with varying rigor, and executed through a shared, permissionless framework that operators opt into per operator set.

We're looking at this because the trust model is unusual for Ethereum infra: a staker's capital can be forfeited by logic they didn't write and may not have read, triggered by an AVS they may only be indirectly exposed to through an operator's other commitments. That composability of slashing risk across otherwise-unrelated services is the crux of what we're examining. This writeup tracks where we are, not a conclusion — treat findings below as hypotheses under active verification, not audit results. Firms doing pre-launch review of an AVS's slashing contracts should treat this as a starting checklist, not a substitute for a scoped engagement; that kind of scoped review is what our smart contract audit practice does for AVS and restaking teams.

What we are checking

• Operator-set stake allocation and delay windows. Operators allocate portions of delegated stake to specific operator sets per AVS, with a configurable allocation/deallocation delay. We're checking whether the delay is long enough relative to an AVS's slashing window to prevent an operator from de-allocating stake after misbehavior is detected but before slashing finalizes.
• Cross-AVS correlation. An operator typically serves multiple AVSs from the same delegated stake pool. We're mapping realistic scenarios where a bug or dispute in AVS A's slashing logic destroys collateral that was also backing AVS B and AVS C, with no fault on the operator's part with respect to B or C.
• Withdrawal-queue interaction. Stakers queuing a withdrawal are still subject to slashing for infractions that occurred before the withdrawal was finalized. We're checking the practical window during which a staker believes they've exited but remains economically exposed, and whether AVS-specific reporting delays can exceed that window.
• Veto and dispute paths. Where an AVS uses an off-chain or committee-based dispute/veto step before slashing is final, we're checking who can trigger it, the quorum and timelock assumptions, and what happens if the committee is unavailable or compromised — this is a centralization vector independent of the AVS's own contract correctness.
• Slashing condition specification quality. Because each AVS writes its own slasher contract against a shared interface, we're reviewing how these conditions are typically expressed and whether common patterns (oracle-fed proofs, fraud-proof windows, multi-party attestation) introduce the same class of ambiguity we've flagged in other ecosystems when reviewing formally specifying trading-program invariants — slashing logic is exactly the kind of high-stakes, rarely-exercised code path formal methods are suited to, and rarely get that treatment before mainnet.

// simplified mental model of correlated slashing exposure
for operator in operators:
    stake = operator.delegatedStake
    for avs in operator.optedInAVSs:
        allocation = operator.allocationTo[avs]      // <= stake, configurable
        if avs.slasher.detectsFault(operator):
            burn(allocation)                          // only this AVS's slice, by design
    // risk isn't the burn logic itself — it's operators sizing
    // allocations to overlap near 100% of stake across correlated AVSs,
    // and stakers having no per-AVS visibility into that overlap

Preliminary observations

Nothing below is a confirmed vulnerability in deployed code — these are architectural risk areas we're still gathering evidence on.

1. Allocation overlap is opaque to stakers. A staker delegating to an operator generally sees aggregate exposure, not a live breakdown of how much allocated stake sits behind each AVS the operator has opted into. That's a disclosure gap more than a contract bug, but it directly affects how someone should price restaking yield.
2. Slasher contract heterogeneity. Because slashing logic lives in AVS-controlled contracts rather than a single audited core, the security ceiling for any given staker is the weakest AVS their operator serves, not the average. This mirrors the composability risk we've written about for cross-program invocation trust boundaries in DeFi, just expressed through delegation instead of a direct call.
3. Upgradeability of AVS-side contracts. Several AVSs retain upgrade keys on their slasher or middleware contracts during early bootstrapping. The same category of concern we've flagged around upgradeable program risk applies here in EVM form: an upgrade key is a slashing key, whether or not it's labeled that way in the docs.
4. Timelock/veto assumptions vary by AVS, and we haven't yet found a consistent public registry of which AVSs use which dispute model — this is slowing down our comparative pass.

Next steps

We're building a comparison matrix across live AVSs covering allocation delay length, veto/dispute model, and slasher upgradeability, then stress-testing the withdrawal-queue timing gap against real observed reporting latencies. We expect to publish a scored follow-up once that matrix is populated; until then, treat this page as scope notes, not a rating. Teams building or opting operators into an AVS who want a scoped review of slasher logic or delegation contracts before mainnet exposure can reach out through our audit services page, or start with a lighter code review pass if you're pre-mainnet and iterating fast.

Thinking about a review like this for your own contracts? Get a smart contract audit from an independent team.