Was ist mit dem Restaking passiert?

Eine tiefgehende Rückschau auf den Restaking-Weg von EigenLayer: Die Stolpersteine, die Verdienste von EigenDA – alles ebnet den Weg für die neue Richtung von EigenCloud.

Autor: Kydo, Narrative Lead bei EigenCloud

Übersetzung: Saoirse, Foresight News

Hin und wieder schicken mir Freunde spöttische Tweets über Restaking, aber diese Spötteleien treffen selten den Kern. Deshalb habe ich beschlossen, selbst einen reflektierenden „Rant“ zu schreiben.

Vielleicht denkst du, ich bin zu nah dran, um objektiv zu bleiben; oder zu stolz, um zuzugeben, dass „wir uns verrechnet haben“. Vielleicht glaubst du, selbst wenn alle Restaking für gescheitert halten, würde ich einen langen Text schreiben, um zu argumentieren, ohne je das Wort „Scheitern“ zu benutzen.

Diese Ansichten sind nachvollziehbar und in vielerlei Hinsicht auch berechtigt.

Doch dieser Artikel will nur die Fakten objektiv darstellen: Was ist tatsächlich passiert, was wurde umgesetzt, was nicht – und welche Lehren haben wir daraus gezogen.

Ich hoffe, die Erfahrungen im Text sind universell und können anderen Entwicklern im Ökosystem als Referenz dienen.

Nachdem ich über zwei Jahre alle führenden AVS (Actively Validated Services) auf EigenLayer integriert und EigenCloud mitgestaltet habe, möchte ich ehrlich Bilanz ziehen: Wo haben wir Fehler gemacht, was lief gut und wohin geht unser Weg?

Was ist eigentlich Restaking?

Dass ich heute noch erklären muss, „was Restaking ist“, zeigt bereits: Als Restaking noch im Fokus der Branche stand, haben wir es nicht klar genug kommuniziert. Das ist die „Lesson Zero“ – Fokussiere dich auf eine Kern-Narrative und wiederhole sie immer wieder.

Das Ziel des Eigen-Teams war immer: „Einfach zu erklären, schwer umzusetzen“ – durch erhöhte Verifizierbarkeit von Off-Chain-Berechnungen sollen Menschen sicherere Anwendungen On-Chain bauen können.

AVS war unser erster, klar positionierter Versuch in diese Richtung.

AVS (Actively Validated Services) ist ein Proof-of-Stake (PoS) Netzwerk, in dem eine Gruppe dezentraler Operatoren Off-Chain-Aufgaben ausführt. Das Verhalten dieser Operatoren wird überwacht; bei Verstößen werden ihre gestakten Assets als Strafe einbehalten. Um einen solchen „Slashing-Mechanismus“ zu ermöglichen, braucht es gestaktes Kapital als Grundlage.

Genau hier liegt der Wert von Restaking: Nicht jeder AVS muss ein eigenes Sicherheitssystem von Grund auf bauen – Restaking ermöglicht die Wiederverwendung bereits gestakter ETH und bietet mehreren AVS Sicherheit. Das senkt die Kapitalkosten und beschleunigt den Start neuer Ökosysteme.

Das konzeptionelle Rahmenwerk von Restaking lässt sich so zusammenfassen:

• AVS: Die „Service-Schicht“, das Fundament neuer PoS-Kryptoökonomie-Sicherheitssysteme;
• Restaking: Die „Kapital-Schicht“, die durch Wiederverwendung bestehender Staking-Assets Sicherheit für diese Systeme bietet.

Ich halte diese Idee bis heute für elegant, doch die Realität war weniger ideal als das Schaubild – viele Dinge liefen nicht wie erwartet.

Was nicht wie erwartet lief

1. Wir haben den falschen Markt gewählt: Zu nischig

Wir wollten nicht „irgendeine verifizierbare Berechnung“, sondern bestanden darauf, dass das System von Tag eins an dezentral, mit Slashing-Mechanismus und vollständig kryptoökonomisch gesichert ist.

Wir wollten, dass AVS zu einer „Infrastruktur-Service“-Ebene wird – so wie Entwickler SaaS (Software as a Service) nutzen, sollte jeder AVS bauen können.

Diese Positionierung wirkt prinzipientreu, schränkt aber die potenzielle Entwicklerbasis stark ein.

Das Ergebnis: Unser Markt war „klein, langsam, mit hohen Eintrittsbarrieren“ – wenige potenzielle Nutzer, hohe Umsetzungskosten, lange Zyklen für beide Seiten (Team und Entwickler). Sowohl die EigenLayer-Infrastruktur, die Developer-Tools als auch jeder einzelne AVS auf der oberen Schicht brauchten Monate oder Jahre zur Fertigstellung.

Fast drei Jahre später: Aktuell laufen nur zwei führende AVS in der Produktion – Infuras DIN (Decentralized Infrastructure Network) und LayerZero’s EigenZero. Diese „Adoption Rate“ ist alles andere als „breit“.

Um ehrlich zu sein: Unser ursprüngliches Szenario war, dass Teams von Tag eins an kryptoökonomische Sicherheit und dezentrale Operatoren wollen – der Markt suchte aber nach „schrittweisen, anwendungszentrierten“ Lösungen.

2. Durch regulatorische Rahmenbedingungen waren wir gezwungen zu schweigen

Als wir das Projekt starteten, war die „Gary Gensler-Ära“ (Gary Gensler, Vorsitzender der US-SEC, bekannt für strenge Krypto-Regulierung) auf ihrem Höhepunkt. Mehrere Staking-Unternehmen standen unter Untersuchung und Klage.

Als „Restaking-Projekt“ konnte fast jedes öffentliche Statement von uns als „Investment-Versprechen“ oder „Rendite-Werbung“ ausgelegt werden – oder gar eine Vorladung nach sich ziehen.

Diese regulatorische Unsicherheit bestimmte unsere Kommunikation: Wir konnten nicht frei sprechen, selbst bei massiver negativer Berichterstattung, wenn Partner uns die Schuld zuschoben oder wir Ziel von Angriffen wurden, konnten wir Missverständnisse nicht in Echtzeit aufklären.

Wir konnten nicht einmal einfach sagen: „So ist es nicht“ – denn wir mussten immer erst das rechtliche Risiko abwägen.

Das Ergebnis: Ohne ausreichende Kommunikation haben wir Locked-Token eingeführt. Im Nachhinein war das durchaus riskant.

Falls du das Gefühl hattest, „das Eigen-Team ist bei bestimmten Themen ausweichend oder ungewöhnlich still“, lag das wahrscheinlich an diesem regulatorischen Umfeld – ein einziger falscher Tweet konnte erhebliche Risiken bergen.

3. Frühe AVS haben den Markenwert verwässert

Der frühe Markenwert von Eigen beruhte stark auf Sreeram (Kernmitglied des Teams) – seine Energie, sein Optimismus und der Glaube, dass Systeme und Menschen besser werden können, brachten dem Team viel Sympathie ein.

Und Milliarden an gestaktem Kapital verstärkten dieses Vertrauen weiter.

Doch die gemeinsame Promotion der ersten AVS wurde diesem „Marken-Niveau“ nicht gerecht. Viele frühe AVS waren laut, jagten aber nur Branchentrends hinterher – sie waren weder „technisch führend“ noch „beispielhaft integer“.

Mit der Zeit verbanden die Leute „EigenLayer“ mit „neuestem Liquidity Mining, Airdrops“. Die heutige Skepsis, Übersättigung und sogar Ablehnung gehen oft auf diese Phase zurück.

Könnte ich es wiederholen, würde ich mit „weniger, aber hochwertigeren AVS“ starten, wäre wählerischer bei Partnern, die unser Branding tragen dürfen, und würde ein „langsameres, weniger gehyptes“ Rollout akzeptieren.

4. Technische Überfokussierung auf „Minimales Vertrauen“ führte zu überflüssigem Design

Wir wollten ein „perfektes, universelles Slashing-System“ bauen – es sollte universell, flexibel und für alle Slashing-Szenarien geeignet sein, um „minimales Vertrauen“ zu erreichen.

In der Praxis verlangsamte das unsere Produktentwicklung und zwang uns, viel Zeit mit der Erklärung eines Mechanismus zu verbringen, den „die meisten noch nicht verstehen konnten“. Selbst heute müssen wir das vor fast einem Jahr eingeführte Slashing-System immer wieder erklären.

Im Nachhinein wäre es sinnvoller gewesen, mit einer einfachen Slashing-Lösung zu starten, verschiedene AVS fokussierte Modelle ausprobieren zu lassen und dann die Komplexität schrittweise zu erhöhen. Stattdessen haben wir das „komplexe Design“ vorangestellt und dafür bei „Tempo“ und „Klarheit“ bezahlt.

Was wirklich gelungen ist

Menschen neigen dazu, Dinge vorschnell als „gescheitert“ abzustempeln – das ist zu oberflächlich.

Im Kapitel „Restaking“ haben wir vieles sehr gut gemacht – und diese Erfolge sind für unsere zukünftige Richtung entscheidend.

1. Wir haben bewiesen: Wir können uns im harten Wettbewerb durchsetzen

Wir bevorzugen „Win-Win“, aber scheuen keinen Wettbewerb – wenn wir in einen Markt einsteigen, wollen wir auch führen.

Im Restaking-Bereich unterstützten Paradigm und Lido unseren direkten Konkurrenten. Damals lag der TVL (Total Value Locked) von EigenLayer bei unter 1.1 billions.

Die Konkurrenz hatte einen Narrativ-Vorteil, Zugang zu Kanälen, Kapital und „Default Trust“. Viele sagten mir: „Ihr werdet von deren Team überrollt.“ Doch es kam anders – heute halten wir 95 % Marktanteil im Restaking-Kapitalmarkt und haben 100 % der Top-Entwickler angezogen.

Im Bereich „Data Availability (DA)“ starteten wir später, mit kleinerem Team und weniger Kapital, während die Pioniere bereits Vorsprung und starke Marketingstrukturen hatten. Doch heute – egal nach welchem Key Metric – hält EigenDA (die Data Availability-Lösung von Eigen) einen großen Marktanteil; mit dem vollständigen Rollout der größten Partner wird dieser Anteil exponentiell wachsen.

Beide Märkte waren extrem kompetitiv – doch wir haben uns durchgesetzt.

2. EigenDA wurde zum „Gamechanger“-Produkt für das Ökosystem

EigenDA auf der EigenLayer-Infrastruktur zu launchen, war eine riesige Überraschung.

Es wurde zum Grundstein von EigenCloud und brachte Ethereum etwas dringend Benötigtes – einen hochskalierbaren DA-Kanal. Damit können Rollups weiterhin schnell laufen, ohne für „Speed“ das Ethereum-Ökosystem zu verlassen und auf neue Chains zu wechseln.

MegaETH wurde gestartet, weil das Team glaubte, dass Sreeram ihnen helfen kann, das DA-Bottleneck zu durchbrechen; auch Mantle schlug BitDAO ursprünglich vor, ein L2 zu bauen, aus demselben Vertrauen heraus.

EigenDA wurde auch zum „Schutzschild“ für Ethereum: Mit einer leistungsfähigen nativen DA-Lösung im Ökosystem wird es für externe Chains schwerer, „mit Ethereum-Narrativen Aufmerksamkeit zu erlangen und gleichzeitig Wert abzusaugen“.

3. Entwicklung des Pre-Confirmation-Marktes vorangetrieben

Eines der frühen Kernthemen von EigenLayer war, wie man mit EigenLayer Pre-Confirmation für Ethereum freischalten kann.

Seitdem hat Pre-Confirmation durch das Base-Netzwerk viel Aufmerksamkeit erhalten, doch die Umsetzung bleibt herausfordernd.

Um das Ökosystem zu fördern, haben wir das Commit-Boost-Programm mitinitiiert – es soll den „Lock-in-Effekt“ von Pre-Confirmation-Clients lösen und eine neutrale Plattform schaffen, auf der jeder durch Validatoren-Zusagen Innovationen umsetzen kann.

Inzwischen sind Milliarden von Dollar über Commit-Boost geflossen, über 35 % der Validatoren sind angeschlossen. Mit dem Launch der führenden Pre-Confirmation-Services in den kommenden Monaten wird dieser Anteil weiter steigen.

Das ist für die „Antifragilität“ des Ethereum-Ökosystems entscheidend und legt die Basis für kontinuierliche Innovation im Pre-Confirmation-Markt.

4. Stets die Sicherheit der Assets gewährleistet

Über Jahre haben wir die Sicherheit von Assets im Wert von mehreren Milliarden Dollar gewährleistet.

Das klingt unspektakulär, fast „langweilig“ – aber wenn man bedenkt, wie viele Krypto-Infrastrukturen auf verschiedenste Weise „kollabiert“ sind, weiß man, wie wertvoll diese „Langweiligkeit“ ist. Um Risiken zu vermeiden, haben wir ein solides Operations-Security-System aufgebaut, ein Weltklasse-Security-Team rekrutiert und eine „adversarial mindset“-Kultur etabliert.

Diese Kultur ist für jedes Geschäft mit Nutzerfonds, KI oder realen Systemen entscheidend – und sie lässt sich „im Nachhinein nicht nachrüsten“. Sie muss von Anfang an verankert sein.

5. Verhindert, dass Lido dauerhaft über 33 % Staking-Anteil hält

Eine unterschätzte Auswirkung der Restaking-Ära: Große Mengen ETH flossen zu LRT-Anbietern, wodurch verhindert wurde, dass Lido dauerhaft weit über 33 % Staking-Anteil hält.

Das ist für das „soziale Gleichgewicht“ von Ethereum enorm wichtig. Hätte Lido ohne Alternativen dauerhaft über 33 % gehalten, wären große Governance-Konflikte und interne Spannungen unvermeidlich gewesen.

Restaking und LRT haben keine „magische vollständige Dezentralisierung“ erreicht, aber sie haben die Zentralisierungstendenz beim Staking verändert – das ist keine Kleinigkeit.

6. Klarheit darüber, wo die „wahre Frontier“ liegt

Der größte „Ertrag“ war konzeptionell: Wir haben die Kernthese „Die Welt braucht mehr verifizierbare Systeme“ bestätigt, aber auch erkannt, dass unser bisheriger Weg falsch war.

Der richtige Weg ist nicht, „mit generischer Kryptoökonomie-Sicherheit zu starten, von Tag eins ein vollständig dezentrales Operator-System aufzubauen und zu warten, dass alle darauf aufsetzen“.

Wirklich Fortschritt bringt: Entwicklern direkte Tools zu geben, mit denen sie für ihre spezifischen Anwendungen Verifizierbarkeit erreichen – und diese Tools mit passenden Verifikations-Primitiven auszustatten. Wir müssen „aktiv auf Entwicklerbedürfnisse zugehen“, statt zu verlangen, dass sie von Anfang an „Protokolldesigner“ werden.

Dafür bauen wir bereits interne modulare Services – EigenCompute (verifizierbare Berechnungsdienste) und EigenAI (verifizierbare KI-Dienste). Manche Features, für die andere Teams hunderte Millionen Dollar und Jahre brauchen, können wir in Monaten launchen.

Die nächsten Schritte

Wie gehen wir also mit diesen Erfahrungen um – Timing, Erfolge, Fehler, „Narben“ der Marke?

Hier ein kurzer Überblick über unsere nächsten Pläne und die dahinterstehende Logik:

1. EIGEN-Token als Systemkern etablieren

Künftig werden EigenCloud und alle darauf aufbauenden Produkte rund um den EIGEN-Token zentriert sein.

Die Rolle des EIGEN-Tokens:

• Kern-Treiber der ökonomischen Sicherheit von EigenCloud;
• Asset, das für alle Risiken der Plattform bürgt;
• Kernwert-Erfassungsinstrument für alle Gebührenströme und ökonomischen Aktivitäten der Plattform.

Früher klaffte eine Lücke zwischen den Erwartungen vieler an den „Value Capture“ des EIGEN-Tokens und den „tatsächlichen Mechanismen“ – das sorgte für Verwirrung. Im nächsten Schritt werden wir diese Lücke durch konkrete Designs und Systeme schließen. Weitere Details folgen.

2. Entwicklern ermöglichen, „verifizierbare Anwendungen“ zu bauen – nicht nur AVS

Unsere Kernthese bleibt: Durch erhöhte Verifizierbarkeit von Off-Chain-Berechnungen können Menschen sicherere Anwendungen On-Chain bauen. Doch die Tools für „Verifizierbarkeit“ werden vielfältiger.

Manchmal ist es kryptoökonomische Sicherheit; manchmal ZK-Proofs, TEE (Trusted Execution Environment) oder hybride Ansätze. Entscheidend ist nicht die „Favorisierung einer Technologie“, sondern dass „Verifizierbarkeit“ zum Standard-Primitiv im Tech-Stack der Entwickler wird.

Unser Ziel: Die Lücke zwischen zwei Zuständen zu schließen:

Von „Ich habe eine Anwendung“ zu „Ich habe eine Anwendung, die von Nutzern, Partnern oder Regulatoren verifiziert werden kann“.

Aus heutiger Branchensicht ist „Kryptoökonomie + TEE“ zweifellos die beste Wahl – sie bietet das beste Gleichgewicht zwischen „Programmierbarkeit für Entwickler“ (was sie bauen können) und „Sicherheit“ (nicht nur theoretisch, sondern praktisch umsetzbar).

Wenn ZK-Proofs und andere Verifikationsmechanismen künftig ausgereift und für Entwickler nutzbar sind, werden wir sie ebenfalls in EigenCloud integrieren.

3. Tiefe Positionierung im KI-Bereich

Die größte globale Umwälzung im Computing ist derzeit KI – insbesondere KI-Agenten. Auch die Krypto-Branche bleibt davon nicht unberührt.

KI-Agenten sind im Kern „Sprachmodelle, die Tools einbinden und in spezifischen Umgebungen agieren“.

Heute sind nicht nur Sprachmodelle „Black Boxes“, auch die Operationslogik von KI-Agenten ist intransparent – deshalb gab es bereits Hacks, weil man „dem Entwickler vertrauen musste“.

Doch wenn KI-Agenten „verifizierbar“ sind, braucht man kein Vertrauen mehr in den Entwickler.

Um Verifizierbarkeit für KI-Agenten zu erreichen, braucht es drei Dinge: Verifizierbare Inferenzprozesse für LLMs (Large Language Models), verifizierbare Ausführungsumgebungen und eine verifizierbare Datenschicht für Speicherung, Abruf und Kontextverständnis.

Genau für solche Szenarien ist EigenCloud konzipiert:

• EigenAI: Bietet deterministische, verifizierbare LLM-Inferenzdienste;
• EigenCompute: Bietet verifizierbare Ausführungsumgebungen;
• EigenDA: Bietet verifizierbare Datenspeicherung und -abfrage.

Wir sind überzeugt: „Verifizierbare KI-Agenten“ sind eines der wettbewerbsfähigsten Anwendungsszenarien für unsere „verifizierbaren Cloud-Services“ – deshalb haben wir ein dediziertes Team für diesen Bereich aufgebaut.

4. Die Narrative von „Staking und Erträgen“ neu gestalten

Echte Erträge erfordern echte Risiken.

Wir erforschen breitere „Staking-Anwendungsfälle“, damit Staking-Kapital folgende Risiken abdecken kann:

• Smart-Contract-Risiken;
• Risiken verschiedener Berechnungstypen;
• Risiken, die klar beschreibbar und quantifizierbar sind.

Künftige Erträge werden die „übernommenen, transparenten und verständlichen Risiken“ widerspiegeln – und nicht bloß dem neuesten Liquidity-Mining-Trend folgen.

Diese Logik wird sich auch natürlich in die Nutzungsszenarien, das Backing und die Wertflüsse des EIGEN-Tokens einfügen.

Abschließende Worte

Restaking wurde nicht zu der „Allzweck-Schicht“, die ich (und andere) einst erwartet hatten, aber es ist auch nicht verschwunden. Im langen Entwicklungsprozess wurde es das, was die meisten „ersten Produkte“ werden:

Ein wichtiges Kapitel, viele mühsam gewonnene Lektionen und heute die Infrastruktur für breitere Geschäftsbereiche.

Wir pflegen das Restaking-Geschäft weiterhin und schätzen es – aber wir wollen uns nicht mehr von der ursprünglichen Narrative einschränken lassen.

Wenn du Community-Mitglied, AVS-Entwickler oder Investor bist, der Eigen immer noch mit „diesem Restaking-Projekt“ verbindet, hoffe ich, dass dieser Artikel dir klarer macht, „was passiert ist“ und „wohin wir jetzt steuern“.

Heute betreten wir ein Feld mit „größerem Total Addressable Market (TAM)“: Einerseits Cloud-Services, andererseits direkte Entwicklerbedürfnisse auf Anwendungsebene. Wir erforschen auch die „noch wenig erschlossene KI-Schiene“ und werden diese Richtungen mit gewohnter Execution-Power vorantreiben.

Das Team ist weiterhin voller Energie, und ich kann es kaum erwarten, allen Skeptikern zu beweisen – wir schaffen das.

Ich war noch nie so optimistisch für Eigen wie jetzt und stocke weiterhin meinen EIGEN-Token-Bestand auf – und werde das auch künftig tun.

Wir stehen immer noch ganz am Anfang.