What happened to the restaking market? Reviewing the successes and failures of EigenLayer's design two years later

In-depth Review of EigenLayer’s Restaking Journey: The Pitfalls and Achievements of EigenDA, Paving the Way for the New Direction of EigenCloud

This article is sourced from Kydo, EigenCloud Narrative Lead, and has been organized, translated, and written by Saoirse of Foresight News.

(Prior Reading: 10,000-word Report: Comprehensive Understanding of Restaking Leader EigenLayer) (Background Supplement: What is EigenLayer’s Flagship Restaking Product EigenDA?)

From time to time, friends send me sarcastic tweets about restaking, but none of them really hit the mark. So I decided to write a reflective “rant” myself.

You might think I’m too close to this to be objective, or too proud to admit “we miscalculated.” Maybe you believe that even if everyone concludes “restaking failed,” I’ll still write a lengthy defense, never uttering the word “failure.”

These opinions are reasonable, and many have some truth to them.

But this article aims only to objectively present the facts: what happened, what was accomplished, what fell short, and what lessons we learned.

I hope the experiences shared here are universal enough to serve as reference for developers in other ecosystems.

Having integrated all major AVSs (Actively Validated Services) and designed EigenCloud for over two years, I want to honestly review where we went wrong, where we excelled, and where we’re headed next.

What exactly is Restaking?

The fact that I still need to explain “what restaking is” shows that, even when restaking was an industry focus, we failed to communicate it clearly. This is “Lesson 0”—focus on a core narrative and repeat it consistently.

The Eigen team’s goal has always been “simple to describe, hard to execute”: by increasing the verifiability of off-chain computation, enable people to build applications on-chain more securely.

AVS was our first and most clear-cut attempt at this.

AVS (Actively Validated Service) is a proof-of-stake (PoS) network, executed by a group of decentralized operators performing off-chain tasks. These operators are monitored, and if they misbehave, their staked assets are penalized. To enable such a “slashing mechanism,” there must be “staked capital” as backing.

That’s where the value of restaking lies: without requiring each AVS to build a security system from scratch, restaking allows existing staked ETH to be reused, providing security for multiple AVSs. This lowers capital costs and speeds up ecosystem bootstrapping.

So the conceptual framework of restaking can be summarized as: AVS: The “service layer,” hosting a new PoS crypto-economic security system; Restaking: The “capital layer,” reusing existing staked assets to secure these systems.

I still think this is an elegant idea, but reality hasn’t worked out as neatly as the diagrams—many things haven’t met expectations.

What Didn’t Meet Expectations

1. We Chose the Wrong Market: Too Niche

We didn’t want “just any kind of verifiable computation”—we insisted on systems with decentralization, slashing mechanisms, and full crypto-economic security from day one.

We hoped AVS could become “infrastructure services”—just like developers can build SaaS (Software-as-a-Service), anyone could build an AVS.

While this positioning seemed principled, it drastically narrowed our potential developer base.

The result: a market that is “small, slow, and high-barrier”—few potential users, high deployment costs, and long development cycles for both teams and developers. Whether it’s EigenLayer’s infrastructure, developer tools, or each AVS built on top, it takes months or even years to complete.

Fast forward nearly three years: we currently have only two major AVSs running in production—Infura’s DIN (Decentralized Infrastructure Network) and LayerZero’s EigenZero. Such “adoption” can hardly be called “widespread.”

Honestly, our initial scenario was that “teams want crypto-economic security and decentralized operators from day one,” but real market demand favors “more gradual, application-centric” solutions.

2. Regulatory Constraints Forced Us into “Silence”

When we launched the project, it was at the peak of the “Gary Gensler era” (note: Gary Gensler is the US SEC Chairman, known for his strict regulatory stance on crypto). At that time, several staking companies were under investigation and litigation.

As a “restaking project,” almost every public statement we made could be interpreted as an “investment promise” or “yield advertisement,” possibly even attracting subpoenas.

This regulatory uncertainty dictated our communication: we couldn’t speak freely. Even when faced with overwhelming negative press, partners passing the buck, and public criticism, we couldn’t clarify misunderstandings in real time.

We couldn’t even casually say, “That’s not the case”—because we had to weigh the legal risks first.

The outcome was that, lacking sufficient communication, we launched locked tokens. Looking back, that was indeed risky.

If you ever felt that “the Eigen team was evasive or unusually silent” on an issue, it was likely due to this regulatory environment—even a single wrong tweet could bring considerable risk.

3. Early AVSs Diluted Brand Value

Eigen’s early brand influence largely came from Sreeram (a core team member)—his energy, optimism, and belief that both systems and people can improve earned a lot of goodwill for the team.

Billions in staked capital further strengthened this trust.

But our co-promotion of the first batch of AVSs did not match this “brand stature.” Many early AVSs made a lot of noise, but merely chased industry hype—they were neither “technically strongest” nor “best exemplars of integrity.”

Over time, people began associating “EigenLayer” with “the latest liquidity mining and airdrops.” Much of the skepticism, fatigue, and even resentment we face today can be traced back to this phase.

If I could do it over, I’d want to start with “fewer, but higher-quality AVSs,” be more selective about partners who could get brand endorsement, and accept a “slower pace and lower hype” for promotion.

4. Over-Engineering for “Minimal Trust” Led to Design Bloat

We tried to build a “perfect universal slashing system”—it needed to be general, flexible, and cover every slashing scenario, achieving “minimal trust.”

But in practice, this led to slow product iterations and required us to spend massive time explaining a system “most people weren’t yet ready to understand.” Even now, nearly a year after launching the slashing system, we still have to explain it repeatedly.

In hindsight, a better path would have been: first launch a simple slashing solution, let different AVSs try more focused models, and gradually increase system complexity. But we put “complex design” first, ultimately paying the price in “speed” and “clarity.”