Interoperability & cross-chain

restaking

Restaking lets capital that is already staked do double duty. On Ethereum, validators lock 32 ETH to secure the chain; that ETH is productive but otherwise idle as far as other protocols are concerned. Restaking — pioneered by EigenLayer — lets a staker opt in to also back additional services with that same stake, so a single pool of ETH simultaneously secures Ethereum and, say, a new oracle, bridge, or data-availability layer. The staker earns extra rewards for taking on extra duties.

The mechanism is additional, opt-in slashing. By restaking, you agree that if you misbehave in one of these extra services, your stake can be slashed by that service's rules, on top of Ethereum's own slashing. New services therefore do not have to bootstrap their own token and validator set; they rent the trust of Ethereum's large, already-committed stake. This is how restaking became the engine of a marketplace for shared, programmable security — any project can spin up a service and pay restakers to secure it.

The power comes with genuinely new risks. The same stake now backs multiple slashing conditions, so a bug or attack in one service can destroy capital that was also securing Ethereum, raising the spectre of correlated or cascading slashing. Liquid restaking tokens add leverage and layering on top, and operators who restake across many services concentrate decision-making. Critics, including parts of the Ethereum core community, have warned that aggressive restaking could import the risk of fragile external services back into Ethereum's base security. It is best understood as renting out trust — lucrative, but the collateral is real and shared.

Restaking does not create new security from nothing — it re-pledges the same collateral against more obligations. The upside is capital efficiency; the danger is that one stake backing many slashing conditions can be wiped out by a failure in any of them.