Deep Review of EigenLayer's Restaking Journey
Written by: Kydo, Narrative Lead at EigenCloud
Translated by: Saoirse, Foresight News
From time to time, friends send me some mocking tweets about restaking, but these jabs miss the point. So I decided to write a reflective "complaint article" myself.
You might think that I am too close to this matter to remain objective; or perhaps too proud to admit that "we miscalculated." You may feel that even if everyone has deemed "restaking a failure," I would still write a lengthy argument to justify it, never willing to utter the word "failure."
These views are reasonable and many have some truth to them.
But this article aims to objectively present the facts: what exactly happened, what was accomplished, what was not achieved, and what lessons we learned from it.
I hope the experiences shared in this article can be universal and provide some reference for developers in other ecosystems.
After integrating all mainstream AVS (Autonomous Verification Services) on EigenLayer and designing EigenCloud for over two years, I want to candidly review where we went wrong, where we went right, and where we should head next.
What Exactly is Restaking?
The fact that I still need to explain "what restaking is" indicates that when restaking was still a focal point in the industry, we failed to communicate it clearly. This is "Lesson 0" — focus on a core narrative and communicate it repeatedly.
The goal of the Eigen team has always been "easy to say, hard to do": to enable people to build applications on-chain more securely by improving the verifiability of off-chain computation.
AVS is our first and clear attempt at this.
AVS (Autonomous Verification Services) is a proof-of-stake (PoS) network executed by a group of decentralized operators performing off-chain tasks. The actions of these operators are monitored, and any violations will result in punitive deductions from their staked assets. To implement a "punishment mechanism," there must be "staked capital" to support it.
This is precisely where the value of restaking lies: instead of each AVS building a security system from scratch, restaking allows the reuse of already staked ETH to provide security for multiple AVS. This not only reduces capital costs but also accelerates the ecosystem's launch speed.
Thus, the conceptual framework of restaking can be summarized as:
AVS: the "service layer," which is the carrier of a new type of PoS crypto-economic security system;
Restaking: the "capital layer," which provides security for these systems by reusing existing staked assets.
I still believe this concept is ingenious, but reality has not been as ideal as the diagram suggests — many things did not meet expectations.
Things That Did Not Meet Expectations
1. We Chose the Wrong Market: Too Niche
What we wanted was not "any verifiable computation," but a system that was "decentralized from day one, based on a punishment mechanism, and fully crypto-economically secure."
We hoped AVS could become "infrastructure services" — just as developers can build SaaS (Software as a Service), anyone should be able to build AVS.
This positioning seems principled but significantly narrowed the potential developer pool.
The end result is that we faced a market that was "small in scale, slow in progress, and high in barriers": few potential users, high implementation costs, and long timelines for both parties (teams and developers). Whether it was EigenLayer's infrastructure, development tools, or each AVS on top, it took months or even years to build.
Fast forward nearly three years: we currently have only two mainstream AVS operating in production environments — Infura's DIN (Decentralized Infrastructure Network) and LayerZero's EigenZero. Such an "adoption rate" is far from "widespread."
To be honest, the scenario we initially designed was "teams wanting crypto-economic security and decentralized operators from day one," but the actual market demand was for "more gradual, application-centric" solutions.
2. Limited by Regulatory Environment, We Were Forced to "Remain Silent"
When we launched the project, we were at the peak of the "Gary Gensler era" (Note: Gary Gensler is the chairman of the U.S. SEC, who has taken a strict regulatory stance towards the crypto industry). At that time, several staking companies were facing investigations and lawsuits.
As a "restaking project," almost every word we said in public could be interpreted as "investment commitments" or "yield advertisements," potentially leading to subpoenas.
This regulatory fog dictated our communication style: we could not speak freely, even when faced with overwhelming negative reports, being blamed by partners, or facing public attacks, we could not clarify misunderstandings in real-time.
We couldn't even casually say "that's not how it is" — because we had to weigh the legal risks first.
The result was that, in the absence of sufficient communication, we launched locked tokens. Looking back now, this was indeed somewhat risky.
If you ever felt that "the Eigen team was evasive or unusually silent on a matter," it was likely due to this regulatory environment — a single erroneous tweet could pose significant risks.
3. Early AVS Diluted Brand Value
Eigen's early brand influence largely stemmed from Sreeram (a core team member) — his energy, optimism, and belief that "both systems and people can improve" garnered a lot of goodwill for the team.
And the billions in staked capital further reinforced this trust.
However, our joint promotion of the first batch of AVS did not match this "brand height." Many early AVS were loud but only chased industry trends; they were neither the "most technically strong" nor the "most trustworthy" examples of AVS.
Over time, people began to associate "EigenLayer" with "the latest liquidity mining and airdrops." Much of the skepticism, fatigue, and even aversion we face today can be traced back to this phase.
If I could do it all over again, I would prefer to start with "fewer but higher-quality AVS," be more selective about "partners who can gain brand endorsement," and be willing to accept a "slower pace and lower heat" in promotional methods.
4. Overly Pursuing "Minimal Trust" in Technology Led to Design Redundancy
We attempted to build a "perfect universal punishment system" — it needed to be universal, flexible, and cover all punishment scenarios to achieve "minimal trust."
But in practice, this led to slow product iterations and required a lot of time to explain a set of mechanisms that "most people were not yet ready to understand." Even now, we still need to repeatedly educate about the punishment system that was launched nearly a year ago.
In hindsight, a more reasonable path would have been to first launch a simple punishment scheme, allowing different AVS to try more focused models, and then gradually increase the system's complexity. Instead, we placed "complex design" at the forefront, ultimately paying the price in "speed" and "clarity."
Things That Were Actually Accomplished
People often hastily label things as "failures," which is overly simplistic.
In the chapter of "restaking," there are many things that were actually done very well, and these achievements are crucial for our future direction.
1. We Proved: We Can Win Hard Battles in a Competitive Market
We prefer "win-win" scenarios, but we are not afraid of competition — as long as we choose to enter a market, we must lead.
In the restaking field, Paradigm and Lido once teamed up to support our direct competitors. At that time, EigenLayer's total value locked (TVL) was less than 1 billion.
Our competitors had narrative advantages, channel resources, capital support, and came with "default trust." Many people told me, "Their combination will execute better than yours and crush you." But that was not the case — today we hold 95% of the restaking capital market share and have attracted 100% of the top developers.
In the "Data Availability (DA)" field, we started later, had a smaller team, and less funding, while industry pioneers already had first-mover advantages and strong marketing systems. But now, regardless of which key metric is used, EigenDA (Eigen's data availability solution) occupies a significant share of the DA market; as our largest partners fully launch, this share will grow exponentially.
Both markets are fiercely competitive, but we ultimately stood out in both.
2. EigenDA Became a Mature Product That "Changes the Ecosystem"
Launching EigenDA on top of EigenLayer's infrastructure was a huge surprise.
It became the cornerstone of EigenCloud and provided Ethereum with something urgently needed — a massive DA channel. With it, Rollups can maintain high-speed operations without having to leave the Ethereum ecosystem for other new chains for "speed."
MegaETH was initiated because the team believed Sreeram could help them break through the DA bottleneck; Mantle initially proposed building L2 to BitDAO for the same reason.
EigenDA also became Ethereum's "defensive shield": when there is a high-throughput native DA solution within the Ethereum ecosystem, it becomes harder for external chains to "attract attention using the Ethereum narrative while siphoning off ecosystem value."
3. Promoting the Development of the Pre-confirmation Market
One of EigenLayer's early core topics was how to unlock Ethereum's pre-confirmation capabilities through EigenLayer.
Since then, pre-confirmation has gained significant attention through the Base network, but implementation still faces challenges.
To promote ecosystem development, we also jointly launched the Commit-Boost initiative — aimed at solving the "lock-in effect" of pre-confirmation clients and building a neutral platform that allows anyone to innovate through validator commitments.
Today, billions of dollars have flowed through Commit-Boost, and over 35% of validators have joined the program. As mainstream pre-confirmation services go live in the coming months, this percentage will further increase.
This is crucial for the "anti-fragility" of the Ethereum ecosystem and lays the foundation for ongoing innovation in the pre-confirmation market.
4. Always Ensuring Asset Security
Over the years, we have ensured the security of hundreds of billions of dollars in assets.
This statement may sound mundane, even somewhat "boring" — but just think about how many infrastructures in the crypto industry have "collapsed" in various ways, and you'll understand how rare this "mundanity" is. To avoid risks, we built a solid operational security system, recruited and trained a world-class security team, and integrated "adversarial thinking" into our team culture.
This culture is vital for any business involving user funds, AI, or real-world systems, and "cannot be made up later" — it must be built from the ground up from the very beginning.
5. Preventing Lido from Long-term Holding Over 33% of Staking Share
An underrated impact of the restaking era is that a large amount of ETH flowed to LRT providers, preventing Lido's staking share from consistently exceeding 33%.
This is of great significance for Ethereum's "social balance." If Lido were to maintain a stable stake of over 33% without reliable alternatives, it would inevitably lead to significant governance disputes and internal conflicts.
Restaking and LRT did not "magically achieve complete decentralization," but they did change the trend of staking centralization — this is by no means an insignificant achievement.
6. Clarified Where the "True Frontier" Lies
The biggest "gain" is actually at the conceptual level: we validated the core argument that "the world needs more verifiable systems," but we also recognized the "path to realization" — it turns out we had strayed from the previous direction.
The correct path is certainly not "starting from universal crypto-economic security, insisting on building a fully decentralized operator system from day one, and then waiting for all businesses to connect to this level."
The way to truly accelerate the expansion of the "frontier" is to provide developers with direct tools that allow them to achieve verifiability for their specific applications and match these tools with appropriate verification primitives. We need to "actively align with developers' needs," rather than expecting them to become "protocol designers" from day one.
To this end, we have begun to build internal modular services — EigenCompute (verifiable computing service) and EigenAI (verifiable AI service). Some functionalities that other teams need to raise hundreds of millions and spend years to achieve, we can launch in a few months.
Next Steps
So, in light of these experiences — timing, successful experiences, lessons from failures, and the "scars" on our brand — how should we respond?
Here’s a brief overview of our next steps and the logic behind them:
1. Make the EIGEN Token the Core of the System
In the future, the entire EigenCloud and all products built around it will center on the EIGEN token.
The positioning of the EIGEN token is:
The core economic security driver of EigenCloud;
An asset that underwrites various risks undertaken by the platform;
A core value capture tool covering all fee flows and economic activities of the platform.
In the early days, many people's expectations of "what value the EIGEN token can capture" differed from the "actual mechanism" — this caused quite a bit of confusion. In the next phase, we will bridge this gap through specific designs and implementation systems. More details will be announced later.
2. Enable Developers to Build "Verifiable Applications," Not Just Limit to AVS
Our core argument remains unchanged: by improving the verifiability of off-chain computation, we enable people to build applications on-chain more securely. However, the tools for achieving "verifiability" will no longer be limited to one type.
Sometimes, it may be crypto-economic security; other times, it may be ZK proofs, TEE (Trusted Execution Environment), or hybrid solutions. The key is not to "advocate for a specific technology," but to make "verifiability" a standard primitive that developers can directly integrate into their tech stack.
Our goal is to narrow the gap between "two states":
From "I have an application" to "I have an application that can be verified by a user, partner, or regulatory body."
From the current industry situation, "crypto-economics + TEE" is undoubtedly the best choice — it achieves the optimal balance between "developer programmability" (what developers can build) and "security" (not theoretical security, but practically implementable security).
In the future, when ZK proofs and other verification mechanisms mature enough to meet developers' needs, we will also integrate them into EigenCloud.
3. Deeply Layout in the AI Field
The biggest transformation in the global computing field is AI — especially AI agents. The crypto industry cannot remain aloof.
AI agents are essentially "language models wrapped around tools, executing operations in specific environments."
Currently, not only are language models "black boxes," but the operational logic of AI agents is also opaque — this has already led to hacking incidents due to the "need to trust developers."
However, if AI agents possess "verifiability," people will no longer need to rely on trust in developers.
To achieve the verifiability of AI agents, three conditions must be met: the reasoning process of LLMs (Large Language Models) must be verifiable, the computing environment for executing operations must be verifiable, and the data layer that can store, retrieve, and understand context must be verifiable.
EigenCloud is designed for such scenarios:
EigenAI: provides deterministic, verifiable LLM reasoning services;
EigenCompute: provides a verifiable operational execution environment;
EigenDA: provides verifiable data storage and retrieval services.
We believe that "verifiable AI agents" are one of the most competitive application scenarios for our "verifiable cloud services" — therefore, we have formed a dedicated team to delve into this field.
4. Reshape the Narrative Logic of "Staking and Yield"
To obtain real yield, one must bear real risk.
We are exploring broader "staking application scenarios" that allow staked capital to support the following risks:
Smart contract risks;
Risks of different types of computation;
Risks that can be clearly described and quantitatively priced.
Future yields will genuinely reflect "the transparent, understandable risks undertaken," rather than merely chasing "the currently popular liquidity mining models."
This logic will naturally integrate into the usage scenarios, underwriting scope, and value transfer mechanisms of the EIGEN token.
Final Words
Restaking did not become the "universal layer" that I (and others) once hoped for, but it has not disappeared either. In the long development process, it has become what most "first-generation products" tend to become:
An important chapter, a set of hard-earned lessons, and the infrastructure that now supports broader business.
We are still maintaining the restaking-related business and continue to value it — we just do not wish to be limited by the initial narrative.
If you are a community member, an AVS developer, or an investor still associating Eigen with "that restaking project," I hope this article helps you gain a clearer understanding of "what happened in the past" and "our current direction."
We are now entering a field with a "larger total addressable market (TAM)": on one side is cloud services, and on the other is direct application layer demands from developers. We are also exploring the "AI track that has not been fully developed" and will push these directions with our consistent high-intensity execution.
The team remains full of energy, and I can’t wait to prove to all the skeptics — we can do it.
I have never been as optimistic about Eigen as I am now, and I have been increasing my holdings of the EIGEN token, and I will continue to do so in the future.
We are still in the early stages.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
