📈 economics

The Cost of Secure Restaking vs. Proof-of-Stake

This paper establishes that secure restaking offers significantly higher capital efficiency than separate Proof-of-Stake protocols, with potential savings that can asymptotically grow as the square root of the number of validators, by deriving precise bounds on the stake requirements for transforming between these two security models.

Original authors: Akaki Mamageishvili, Benny Sudakov

Published 2026-03-16

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Akaki Mamageishvili, Benny Sudakov

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Picture: The "Shared Security" Dilemma

Imagine you are running a neighborhood watch.

Traditional Proof-of-Stake (PoS): You have 100 houses. Each house hires its own private security guard. If a house wants to be safe, it must pay a guard. If you want 100 houses safe, you need 100 guards. It's safe, but expensive and inefficient.
Restaking: You realize all the guards are standing around doing nothing half the time. So, you tell Guard A: "You guard House 1, but while you're waiting, you also guard House 2 and House 3." Now, one guard protects three houses. This is Restaking. It sounds like a brilliant way to save money (capital efficiency).

The Paper's Question: Is this "Shared Security" actually cheaper? Or does the complexity of sharing guards create hidden risks that force you to hire even more guards to stay safe?

The authors (Akaki Mamageishvili and Benny Sudakov) ran the numbers to see if Restaking truly saves money compared to hiring separate guards for every single job.

Key Concept 1: The "Slashing" Rule

In crypto, security comes from a threat: Slashing.
If a guard (validator) tries to steal from a house (service), they lose their own money (stake).

The Rule: To successfully attack a house, the thieves need to control more than a certain percentage of the total guards watching that house (e.g., more than 50% or 33%).
The Goal: We want to arrange the guards so that no group of thieves can ever make a profit by attacking.

Key Concept 2: The Two Experiments

The authors looked at this problem from two directions.

Direction A: "Can we break the shared system into separate ones?"

Imagine you have a complex Restaking graph where guards are shared. The question is: If we forced everyone to go back to separate security teams (one guard per house), how much extra money would we need to add to the guards' pockets to keep them safe?

The Finding: Surprisingly, in many cases, you don't need much extra money. In fact, you can often rearrange the existing guards to protect the houses individually without adding much cost.
The "Square Root" Magic: The authors found that the maximum extra money needed grows very slowly. If you have $N$ $N$ guards, the extra cost needed is roughly the square root of $N$ .
- Analogy: If you have 100 guards, you might only need to add the equivalent of 10 extra guards to make the system work separately. If you have 10,000 guards, you only need about 100 extra.
- Conclusion: Restaking is very efficient. It saves a lot of capital compared to running separate systems, especially as the network gets huge.

Direction B: "Can we mash separate systems into one?"

Now, imagine you start with 100 separate security teams (each house has its own dedicated guard). You try to merge them into one big "Restaking" pool where guards watch multiple houses.

The Finding: This is dangerous. When you merge them, the guards become "overworked" in a security sense. A single bad actor might now have enough power to attack many houses at once.
The Cost: To fix this and make the merged system safe, you often have to add a massive amount of extra money (stake).
- Analogy: If you have 100 separate guards, and you tell them all to watch 100 different houses simultaneously, a single thief could bribe one guard to steal from 100 houses. To stop this, you might need to double or triple the total money locked up in the system.
- Conclusion: Merging separate secure systems into a shared one can be very expensive and inefficient.

The "Eigenlayer" Condition (The Safety Checklist)

The paper mentions a specific rule used by a popular project called EigenLayer. This rule is a "checklist" to see if a Restaking system is safe.

The Catch: The authors found that if a system follows this checklist strictly, it actually loses all its savings. It forces the system to act like separate security teams anyway.
The Lesson: To get the real savings of Restaking, you need to be more clever than just following the basic checklist. You need to find a "sweet spot" where the system is safe but doesn't require everyone to be over-insured.

Summary of Results

Scenario	The Analogy	The Result
Restaking (Shared)	One guard watching 10 houses.	High Efficiency. You save a lot of money. The "waste" is small (grows slowly with size).
Separate PoS	10 guards, each watching 1 house.	Low Efficiency. You pay for 10 guards even if they are idle.
Merging Separate to Shared	Taking 10 separate guards and forcing them to share.	High Risk/Cost. You often need to add more money to the system to prevent the shared guards from being bribed to attack everything at once.

The "So What?" for Regular People

Restaking is a good idea, but it's tricky. It allows you to get more security for less money, which is great for the crypto ecosystem.
Don't just mash things together. If you take secure, independent projects and try to force them to share security without careful planning, you might actually make them less secure or require way more money to fix the holes.
Scale matters. The bigger the network gets, the more efficient Restaking becomes compared to running separate systems.

The Final Takeaway:
Restaking is like a carpool. It's much cheaper than everyone driving their own car (Separate PoS). However, if you try to cram 10 people into a tiny sedan that was designed for 2 (Merging separate systems poorly), you'll crash. The paper proves that if you design the carpool route correctly, you can save a fortune. But if you just throw everyone in together, you'll need to buy a much bigger, more expensive bus to stay safe.

1. Problem Statement

The paper addresses the fundamental question of capital efficiency in blockchain security. Specifically, it investigates whether Restaking protocols (where validators reuse staked capital across multiple services) offer a genuine reduction in total staking requirements compared to running independent Proof-of-Stake (PoS) protocols for each service.

Context: Restaking (e.g., EigenLayer) allows validators to secure multiple services with a single stake, promising higher capital efficiency. However, it introduces complex interdependencies and security risks.
Core Question: Given a secure restaking graph, how much extra stake is required to "decompose" it into separate, secure PoS protocols? Conversely, if we aggregate secure PoS protocols into a restaking graph, how much extra stake is needed to restore security?
Metric: The authors define Restaking Savings (RS) and PoS Savings (PoSS) as the relative extra capital required to transform between these two states while maintaining security.

2. Methodology and Model

The authors formalize the problem using a bipartite graph $G = (S, V, E)$ :

Nodes: $S$ represents services (projects) with values $\pi_s$ and security parameters $\alpha_s$ (the fraction of stake needed to attack). $V$ represents validators with stakes $\sigma_v$ .
Edges: An edge $(s, v)$ exists if validator $v$ secures service $s$ .
Security Definition: A subset of validators $A$ can profitably attack a set of services $M(A)$ if the total value of the attacked services exceeds the total stake slashed from $A$ . A graph is secure if no such profitable attack exists.
Transformation Constraints:
- Decomposition (Restaking $\to$ PoS): Validators cannot lose their initial stake ( $\sigma'_v \geq \sigma_v$ ), but can increase it. The goal is to find a distribution of stakes such that every service is secure in its own isolated PoS protocol.
- Aggregation (PoS $\to$ Restaking): Validators aggregate stakes from separate PoS protocols. The goal is to determine the extra stake needed to make the combined graph secure.

The paper utilizes combinatorial graph theory (degrees, covers, greedy algorithms) and inequality analysis to derive bounds.

3. Key Contributions

A. Analysis of the EigenLayer Sufficient Condition

The paper analyzes the current polynomial-time checkable sufficient condition for restaking security (Condition 1 in the paper).

Finding: If a restaking graph satisfies this specific condition, it implies that the graph can be decomposed into secure PoS protocols without any extra stake.
Implication: Under this strict condition, restaking savings are effectively zero. To find non-zero savings, one must look beyond this specific sufficient condition to the general security definition.

B. Bounds on Restaking Savings (Decomposition)

The authors derive upper and lower bounds for the extra stake required to convert a secure restaking graph into secure PoS protocols.

Upper Bounds: They prove that the Restaking Savings $RS(G)$ are bounded by:
1. The maximum degree of a service node ( $\max_s d_G(s)$ ).
2. A parameter $K$ related to the minimum incidence in a vertex cover.
3. The inverse of the second-smallest security parameter ( $1/\alpha_2$ ).
4. $\Theta(\sqrt{n})$ , where $n$ is the number of validators. This is derived using a greedy covering technique.
Lower Bound: They construct a specific graph instance where $RS(G) \in \Omega(m)$ (where $m$ is the number of services). Since $n \approx m^2$ in this construction, this yields $RS(G) \in \Omega(\sqrt{n})$ .
Result: The bounds are asymptotically tight: $RS(G) = \Theta(\sqrt{n})$ . This proves that restaking can save capital, but the savings grow sub-linearly with the number of validators.

C. Bounds on PoS Savings (Aggregation)

The paper studies the reverse problem: aggregating independent secure PoS protocols into a restaking graph.

Lower Bound: They construct an instance where aggregating $m$ services and $m$ validators requires an extra stake proportional to $m-1$ . Thus, $PoSS(G) \geq m-1$ .
Upper Bound: They prove $PoSS(G) \leq \max_s d_G(s) - 1$ .
Result: The bounds are exactly matching (not just asymptotic). Aggregating protocols can incur a massive overhead, potentially linear in the number of services/validators, whereas decomposing a restaking graph only incurs a square-root overhead.

4. Key Results

Capital Efficiency is Asymmetric:
- Restaking $\to$ PoS: The cost to separate a secure restaking graph into PoS protocols is relatively low, scaling as $\sqrt{n}$ . This confirms that restaking offers genuine capital efficiency gains, but they are bounded.
- PoS $\to$ Restaking: The cost to aggregate secure PoS protocols into a restaking graph can be very high, scaling linearly with the number of services ( $m-1$ ). This highlights the significant risk and capital inefficiency introduced by naive aggregation.
Unbounded Savings:
- Both Restaking Savings and PoS Savings can grow unboundedly as the system scales (Corollaries 2 and 3). There is no constant factor limit on the efficiency gains or losses.
Role of Security Parameters:
- The upper bound on savings is heavily influenced by security parameters ( $\alpha$ ). For typical values ( $\alpha \in \{1/2, 1/3, 1/4\}$ ), the overhead is bounded by a small constant factor (2 to 4 times the original stake) in many practical cases.
Critique of Current Implementations:
- The authors note that recent updates to EigenLayer (restricting slashing to a single service per asset) effectively force validators to partition their stake. This constraint collapses the restaking graph into separate PoS protocols, eliminating the capital efficiency gains (savings $\to$ 0).

5. Significance and Implications

Theoretical Foundation: This is one of the first formal, mathematical frameworks to quantify the capital efficiency of restaking versus independent PoS. It moves the discussion from heuristic arguments to rigorous graph-theoretic bounds.
Design Guidance:
- For Protocol Designers: To maximize capital efficiency, protocols should aim for graph structures that allow for "dense" connections without triggering the high-overhead aggregation scenarios.
- For Validators: The results suggest that while restaking is efficient, the "savings" are not infinite; they scale with the square root of the network size.
- For Regulators/Analysts: The paper highlights that the security of a restaking network is not just about the total value locked (TVL) but the topology of the validator-service graph.
Open Question: The paper concludes by identifying a major open problem: designing a polynomial-time checkable sufficient condition for restaking security that allows for strictly positive savings (i.e., moving beyond the current EigenLayer condition which forces zero savings).

In summary, the paper demonstrates that restaking is a powerful tool for capital efficiency, offering savings that scale with $\sqrt{n}$ , but it also warns that aggregating security without careful structural design can lead to massive capital inefficiencies (linear overhead). The trade-off depends entirely on the underlying graph structure of the validator-service relationships.