Tiefgehende Aufarbeitung von EigenLayers Restaking-Weg: Die Stolpersteine, die Verdienste von EigenDA – all das ebnet den Weg für die neue Richtung EigenCloud. Dieser Artikel stammt ursprünglich von Kydo, Head of Narrative bei EigenCloud, und wurde von Saoirse für Foresight News zusammengefasst, übersetzt und verfasst.
(Vorgeschichte: Zehntausend-Wörter-Report – Umfassendes Verständnis des Restaking-Pioniers EigenLayer)
(Hintergrund: Was ist das Flaggschiffprodukt EigenDA des Restaking-Protokolls EigenLayer?)
Immer wieder schicken mir Freunde spöttische Tweets über das Restaking, aber diese Kritik trifft selten ins Schwarze. Deshalb habe ich beschlossen, selbst einen selbstreflektierenden “Rant” zu schreiben.
Du könntest denken, ich sei zu nah dran am Thema, um objektiv zu bleiben; oder zu stolz, um zuzugeben, dass „wir uns verkalkuliert haben“. Vielleicht glaubst du, dass ich selbst dann noch einen langen Rechtfertigungstext schreiben würde, wenn alle das Restaking bereits für gescheitert erklären – und niemals das Wort „Scheitern“ in den Mund nehmen würde.
Diese Sichtweisen sind nachvollziehbar, und viele davon haben ihre Berechtigung.
Doch dieser Artikel soll schlicht die Fakten 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 bieten anderen Ökosystem-Entwicklern Orientierung.
Nach über zwei Jahren Integration aller wichtigen AVS (Actively Validated Services) auf EigenLayer und der Entwicklung von EigenCloud, möchte ich ehrlich Bilanz ziehen: Was haben wir falsch gemacht, was richtig – und wohin geht unser Weg?
Was ist eigentlich Restaking?
Dass ich das heute noch ausführlich erklären muss, zeigt bereits, dass wir es während des Hypes nicht klar genug kommuniziert haben. Das ist Lektion Null: Konzentriere dich auf ein zentrales Narrativ und wiederhole es stetig.
Das Ziel des Eigen-Teams war stets „einfach gesagt, schwer gemacht“: Durch die Verbesserung der Verifizierbarkeit von Offchain-Computing sollen Anwendungen on-chain sicherer gebaut werden können.
AVS ist unser erster, klar positionierter Versuch in diese Richtung.
AVS (Actively Validated Service) ist ein Proof-of-Stake (PoS)-Netzwerk, das aus einer Gruppe dezentraler Operatoren besteht, die Offchain-Aufgaben ausführen. Das Verhalten dieser Operatoren wird überwacht; bei Verstößen werden ihre gestakten Vermögenswerte mit Strafen belegt. Um dieses „Strafmechanismus“-System umsetzen zu können, braucht es „Staking-Kapital“ als Grundlage.
Genau darin liegt der Wert von Restaking: Es ermöglicht, bereits gestaktes ETH mehrfach für verschiedene AVS zu verwenden, statt dass jede AVS ihr eigenes Sicherheitskonstrukt von Null aufbaut. Das senkt die Kapitalkosten und beschleunigt den Start neuer Ökosysteme.
Der konzeptionelle Rahmen von Restaking lässt sich also so zusammenfassen:
Ich halte diese Idee bis heute für brillant – aber die Realität war weniger ideal als das Schaubild, denn vieles hat nicht wie erhofft funktioniert.
Was hat nicht funktioniert?
Wir wollten nicht „irgendeine verifizierbare Berechnung“, sondern waren fixiert auf Systeme, die von Anfang an dezentralisiert, mit Strafmechanismus und rein kryptoökonomisch gesichert sind.
Unser Ziel war, dass AVS eine „Infrastruktur-Service“-Rolle einnehmen – ähnlich wie Entwickler SaaS (Software as a Service) bauen, sollte jeder AVS erstellen können.
Diese Ausrichtung war prinzipientreu, aber schränkte die potenzielle Entwicklerbasis massiv ein.
Das Ergebnis: Der Markt war „klein, langsam, hohe Einstiegshürden“ – wenige Nutzer, hohe Umsetzungskosten, lange Vorlaufzeiten auf beiden Seiten (Team und Entwickler). Egal ob die Infrastruktur von EigenLayer, die Entwicklungstools oder jede einzelne AVS – alles brauchte Monate bis Jahre für die Umsetzung.
Fast drei Jahre sind vergangen: Aktuell laufen nur zwei große AVS im Produktionsbetrieb – Infuras DIN (Dezentralisiertes Infrastruktur-Netzwerk) und LayerZeros EigenZero. Von „breiter Adoption“ kann keine Rede sein.
Ehrlich gesagt: Wir gingen davon aus, dass Teams von Anfang an kryptoökonomische Sicherheit und dezentrale Operatoren wollten. Tatsächlich sucht der Markt aber eher „schrittweise, anwendungsorientierte“ Lösungen.
Als wir das Projekt starteten, befanden wir uns auf dem Höhepunkt der „Gary Gensler-Ära“ (Anmerkung: Gary Gensler ist Vorsitzender der US-SEC und hat einen harten Kurs gegenüber der Kryptoindustrie gefahren). Damals wurden viele Staking-Firmen untersucht und verklagt.
Als „Restaking-Projekt“ war praktisch jedes öffentliche Statement von uns potenziell als „Investitionsversprechen“ oder „Renditewerbung“ auslegbar – das konnte zu einer Vorladung führen.
Dieses regulatorische Graufeld bestimmte unsere Kommunikation: Wir konnten uns nicht frei äußern, negative Berichterstattung, Schuldzuweisungen von Partnern oder öffentliche Angriffe nicht zeitnah aufklären.
Wir konnten nicht einmal sagen: „So ist es nicht“ – ohne vorher die rechtlichen Risiken abzuwägen.
Die Folge: Wir haben inmitten unzureichender Kommunikation Locked-Token gelauncht. Rückblickend war das ein riskantes Vorgehen.
Falls du das Gefühl hattest, dass das Eigen-Team bei bestimmten Themen ausweichend oder ungewöhnlich still war – das lag oft an diesem regulatorischen Umfeld. Ein einziger falscher Tweet hätte schwerwiegende Folgen haben können.
Die frühe Markenwirkung von Eigen beruhte stark auf Sreeram (Kernteam), dessen Energie, Optimismus und Glaube an die Verbesserung von System und Menschen viel Sympathie schufen.
Milliarden an gestaktem Kapital verstärkten dieses Vertrauen zusätzlich.
Doch unsere Co-Marketing-Aktionen mit den ersten AVS spiegelten diesen „Markenanspruch“ nicht wider. Viele der ersten AVS machten viel Lärm, jagten aber nur kurzfristigen Hypes hinterher – sie waren weder technisch führend noch Vorbilder in Sachen Integrität.
Mit der Zeit wurde „EigenLayer“ mit „neuestem Liquidity Mining, Airdrops“ gleichgesetzt. Heute stammen viele Zweifel, Erschöpfung und sogar Ablehnung aus genau dieser Phase.
Könnte ich es wieder machen, würde ich mit „weniger, aber qualitativ hochwertigeren AVS“ beginnen, Partner für Brand-Partnerschaften strenger auswählen und ein langsameres, weniger auf Hype ausgerichtetes Go-to-Market akzeptieren.
Wir wollten ein „perfektes, generisches Strafsystem“ bauen – universell, flexibel, abdeckend für alle Strafszenarien, um „Trust Minimization“ zu erreichen.
In der Praxis führte das aber zu langsamen Produktiterationen und zwang uns, eine Mechanik zu erklären, für die die meisten noch nicht bereit waren. Noch immer müssen wir das fast ein Jahr alte Slashing-System regelmäßig erklären.
Im Nachhinein wäre es klüger gewesen, erst einfache Strafmechanismen zu launchen, verschiedene AVS auf fokussierte Modelle zu setzen und die Komplexität schrittweise zu erhöhen. Stattdessen haben wir „Komplexität“ vorgezogen und am Ende bei „Geschwindigkeit“ und „Klarheit“ einen Preis bezahlt…