Restaking and the stacked slashing question

Restaking is the practice of pledging capital that is already staked on a base network as security for additional services, each of which defines its own conditions under which the capital can be taken away. The capital efficiency and the correlated risk are the same fact seen from two directions: one bond now backs several promises. Whether that is sound depends on arithmetic that is rarely presented alongside the rate.

The mechanism, stated plainly

A holder of a staked asset, or of a liquid staking receipt for one, deposits it into a contract that grants a third party the right to penalize it. The holder then delegates to an operator, who opts in to run software for one or more services. Each service specifies a fault it can prove on chain and a fraction of the bond that a proven fault costs. The base network's own slashing conditions continue to apply throughout, unchanged.

What the services buy is a bond posted by someone with something to lose, which lets a new network start with economic security it has not had to bootstrap by issuing and distributing its own token first. What the depositor receives is a payment from those services. The delegation step matters more than it appears: the operator decides which services to secure, and the depositor is exposed to every one of those choices while typically having only the blunt instrument of withdrawal in response.

Why one bond securing many services is not the same as many bonds

Consider a bond of size B and a set of services, each of which an attacker could corrupt for a profit of P. If the services could only be attacked one at a time, each is secured by the full B and the arrangement is sound whenever B exceeds P. But an operator who is willing to lose the bond can misbehave on every service it secures within the same window, collecting the sum of the profits while paying the penalty at most once, because the bond can only be confiscated once.

The security of the arrangement is therefore governed by the total profit available from a simultaneous attack, not by the largest single one. A bond of 100 backing ten services each corruptible for 15 is not ten instances of comfortable over-collateralization; it is a bond of 100 standing against 150 of combined profit from corruption. The arithmetic is not an argument against restaking. It is the calculation that has to be done, and it requires knowing which services share which operators, which is not always published.

Stacked slashing and the path back into lending markets

A penalty applied at the restaking layer reduces the assets behind whatever represents the position. When the restaked asset is a liquid staking receipt, and that receipt has been accepted as collateral by a lending protocol, the sequence is mechanical: a fault is proven, the bond is cut, the receipt's redemption rate falls, the oracle reports the lower rate, and every borrower whose health factor was resting near one becomes liquidatable at the same instant. The forced selling then hits the receipt's own market price, which can push the discount further than the slashing itself justified, triggering the next round. That is a cascade liquidation originating in a system most of the affected borrowers were not consciously using.

Two mitigations are common and neither is complete. Unbonding delays mean a slashable position cannot be exited quickly, which prevents a bank run but also guarantees that holders cannot react to news about a service they are securing. Veto or committee review of large slashing events limits the damage from a buggy service, at the cost of making the penalty a decision by identified people rather than a property of the code, which is a governance dependency that has to be counted as one.

The fault types are not equally provable

The base layer's slashing conditions are narrow by design: signing two conflicting messages is objectively verifiable by anyone, at any time, from the chain's own data. Many services want to penalize things that are harder to establish, such as failing to make data available, quoting a price outside a band, or being unresponsive when needed. These require either a challenge protocol with a defined window, or a committee that adjudicates, and the difference matters because a fault that cannot be proven from chain data alone reintroduces a trusted party into a system whose value proposition was the absence of one.

The payments deserve the same scrutiny as any other rate. A large share of restaking rewards has historically been paid in tokens issued by the services themselves, which puts them squarely in the emissions column described in the yield article rather than the earnings column. A rate quoted as the sum of a base staking return and several service tokens is adding a flow funded by network issuance to flows funded by other projects' issuance, and calling the total a yield.

What can be observed

• The share of a network's staked supply that has been committed to a restaking layer, against the staking ratio as a whole.
• How much of that comes through liquid staking receipts rather than natively staked positions, since receipts carry the exposure onward into collateral markets.
• Operator concentration, since shared operators are the channel through which separate services fail together. Nakamoto coefficient and validator count describe the base layer, and the restaking layer needs its own version of the same question.
• Whether a reward is denominated in the asset staked or in a service's own token, which determines whether real yield is even the right frame.

The staking pages carry participation and concentration data for the base networks, the risk section lays out dependency chains of the kind described here, and the incident record is where correlated failures get documented after the fact. The article on composability at the end of this track generalizes the pattern: shared collateral is shared risk, whatever it is called.