Restaking in EigenLayer: AVS, Operatoren und ein zweiter Slashing-Kreis
Restaking ist eine freiwillige Erweiterung der Staking-Regeln: Bereits gestaktes ETH (oder LST) wird zusätzlich an EigenLayer delegiert, damit dieselbe Sicherheit mehrere Services absichert.
Der zentrale Fehler besteht darin, Restaking auf „mehr Rendite“ zu reduzieren. Im EigenLayer-Modell kommt nicht nur eine zusätzliche Zahlungsquelle hinzu, sondern auch ein eigener Strafkreis: Die Bedingungen für slashing werden nicht nur von Ethereum, sondern auch von externen Services festgelegt.
EigenLayer verbindet Ethereum-Stake über AVS mit externen Services: Der Service bezahlt Operatoren für die Ausführung der Regeln und erhält mit Slashing einen Strafmechanismus als kryptoökonomische Garantie.
In einem Satz: Restaking in EigenLayer bedeutet, bereits gestaktes ETH (oder LST) über Operatoren an externe Services (AVS) anzubinden, damit der Stake nach deren Regeln slashable wird.
Mini-Mechanik: Der restaker delegiert den Stake an einen Operator → der Operator bedient den gewählten AVS → der AVS zahlt die Vergütung → bei einem Regelverstoß initiiert der AVS Slashing nach einer vorab festgelegten Policy.
Im Folgenden werden die Rollen restaker / operator / AVS, die Architektur der Stake-Anbindung (native ETH und LST), die Zahlungsquellen (Zahlungen von AVS) und die Risikofaktoren (Slashing-Policy des AVS, Wahl des Operators, korrelierte Ausfälle) erläutert.
Restaking: macht ETH zu mehrfach nutzbarem Sicherheitenkapital: Ein Stake sichert Ethereum und ausgewählte AVS ab, während der Preis der Vergütungen in den Slashing-Regeln der AVS und der Abhängigkeit von Operatoren besteht.
Material aktualisiert → der Fokus auf die EigenLayer-Architektur (AVS/Operatoren) und den zweiten Slashing-Kreis wurde verstärkt.
- Überschneidungen getrennt → „was Restaking ist“ wurde in die Ecke „Verantwortungsmarkt / price of error“ verschoben.
- RSFi-Szenarien präzisiert → der LRT-Abschlag ist an das AVS-Risiko und korrelierte Ereignisse gebunden.
Wie das EigenLayer-Protokoll im Ethereum-Ökosystem funktioniert
EigenLayer ist ein Smart-Contract-Protokoll auf Ethereum, das bereits gestaktes ETH (oder LST) durch Delegation an Operatoren gemäß den Regeln externer Services (AVS) slashable macht.
Grundfluss: Der Stake wird in EigenLayer angebunden → an einen Operator delegiert → der Operator bedient ausgewählte AVS → der AVS bezahlt für korrekte Arbeit → bei einem Regelverstoß des AVS wird eine Strafe (slashing) auf den zugewiesenen Stake angewendet.
Rollen in EigenLayer: restaker / operator / AVS
| Rolle | Was bereitgestellt wird | Was ausgeführt wird | Wo das Risiko entsteht |
|---|---|---|---|
| Restaker | Sicherheit (ETH/LST), an einen Operator delegiert | Wahl des Operators und des zu unterstützenden AVS-Sets | Slashing nach AVS-Regeln + Abhängigkeit vom Verhalten des Operators |
| Operator | Infrastruktur und Betrieb des AVS-Stacks | Signaturen/Proofs/Verfügbarkeit gemäß den Anforderungen des AVS | Strafen bei Verstößen gegen AVS-Regeln; operative Fehler |
| AVS | Validierungsregeln und Slashing-/Belohnungspolitik | Prüfung der Korrektheit des Operatorverhaltens (nach eigener Logik) | Fehler im Regeldesign, Bugs in Verträgen/Verifikation |
Anbindung des Stakes: native ETH und LST
- Native ETH: Der Validator verknüpft die Withdrawal Credentials mit einer EigenPod-Adresse, damit der Stake in EigenLayer erfasst wird und unter AVS-Regeln fallen kann.
- LST: LST werden in EigenLayer-Strategien deponiert und anschließend an einen Operator delegiert, ohne eine eigene Node zu betreiben.
Slashing im Restaking: AVS-Regeln und zugewiesener Stake
- Die Bedingungen legt der AVS fest: Verstöße werden auf Service-Ebene definiert (z. B. falsche Signaturen, Nichterfüllung von Aufgaben, Verstoß gegen Verfügbarkeitsanforderungen).
- Die Strafe ist an den zugewiesenen Stake gebunden: Die Sanktion wird auf den Teil des delegierten Stakes angewendet, der am Betrieb des konkreten AVS gemäß dessen Regeln beteiligt ist.
Praktischer Risikofilter: Das Risikoprofil wird durch das AVS-Set des Operators, dessen Slashing-Policy und die Fähigkeit des Operators bestimmt, dieses Set ohne Einbruch von Uptime und Ausführungsqualität zu bedienen.
EigenLayer verbindet delegierten Stake und externe Services über Operatoren: Der AVS bezahlt für die Ausführung seiner Regeln, und ein Regelverstoß kann zum Slashing des zugewiesenen Stakes führen.
Praktische Beispiele für EigenLayer und Restaking
AVS (Actively Validated Services) nutzen Restaking als Verantwortungsmechanismus: Der Operator erhält Vergütung für die Erfüllung der Service-Regeln, und ein Regelverstoß kann zum Slashing des zugewiesenen Stakes in Ethereum führen.
AVS-Template: Der Service definiert eine Verpflichtung → definiert die Prüfung (wie ein Verstoß festgestellt wird) → definiert die Strafe (Umfang und Bedingungen) → der Operator haftet mit dem delegierten Stake.
Data Availability (EigenDA und Analoga)
DA-Services beantworten die zentrale Frage des Rollup-Ökosystems: Sind die Daten verfügbar, die für die Verifikation des Zustands und die Wiederherstellung der Historie nötig sind?
- Wozu sich der Operator verpflichtet: Datenfragmente (chunks — Teile eines Datensatzes) zu speichern und sie gemäß den Protokollregeln in den vorgegebenen Zeitfenstern bereitzustellen.
- Was als Verstoß gilt: Nichtverfügbarkeit der Daten, Verweigerung der Herausgabe, Bestätigung der Verfügbarkeit ohne tatsächliche Bereitstellung.
- Warum hier Restaking nötig ist: Datenverfügbarkeit wird zu einer strafbaren Verpflichtung und nicht zu einem bloßen Versprechen des Providers.
- Was der Markt erhält: Eine DA-Schicht, die getrennt von L1 skaliert und die Last auf Ethereum senkt, ohne auf „vertrauenswürdige“ Speicherung zu setzen.
Restaking verwandelt DA in eine
Oracles und Datendienste
Bei Oracles liegt der Wert von Restaking im „Preis des Fehlers“: Falsche Daten lösen Liquidationen aus und verändern Risikoparameter, daher ist eine ökonomische Strafe für die Verzerrung des Datenstroms nötig.
- Wozu sich der Operator verpflichtet: Korrekte Daten (z. B. einen Preis) im vereinbarten Format, mit der festgelegten Frequenz und aus den definierten Quellen zu veröffentlichen.
- Was als Verstoß gilt: Vorsätzliche Manipulation, koordinierte Verfälschung, systematische Verzögerung von Updates (stale data — „veraltete“ Daten).
- Warum hier Restaking nötig ist: Ein Angriff auf Daten muss teurer sein als der potenzielle Gewinn, sonst brechen die Anreize auseinander.
- Wie Verantwortung meist „eingebaut“ wird: Der AVS definiert die Teilnahme- und Strafregeln; Gewicht und Quoten können den delegierten Stake berücksichtigen, aber das Risiko wird durch die Slashing-Bedingungen des konkreten Services bestimmt.
Restaking erhöht den
Restaked Rollups und L2-Komponenten
Ein Teil der L2-Infrastruktur kann in einen AVS ausgelagert und an die strafbare Verantwortung von Operatoren gebunden werden, statt eine eigene „Validatorenökonomie“ (ein separates Teilnehmer- und Sicherheitsanreizsystem) aufzubauen.
- Wozu sich der Operator verpflichtet: Die Regeln der L2-Komponente (Ablaufreihenfolge, Publikationen, abgestimmte Prüfungen) unter den vorgegebenen Bedingungen auszuführen.
- Was als Verstoß gilt: Widersprüchliche Zustandsbehauptungen, Zensur, Verweigerung des Service, Verletzung der protokollarischen Garantien des Services.
- Warum hier Restaking nötig ist: Strafbare Verantwortung reduziert die Abhängigkeit von der „Gutwilligkeit“ eines begrenzten Operatorensets.
- Was der Markt erhält: einen schnellen Service-Start und weniger Anreiz, nur für die Sicherheit einen separaten Token zu schaffen.
Eine L2-Komponente kann
Berechnungen und verifizierbare Resultate
In Rechen-AVS wird die Aufgabe als Ergebnisvertrag formuliert: Vergütung gibt es für protokollkonforme Ausführung, und Sabotage wird zu einem strafbaren Risiko.
- Wozu sich der Operator verpflichtet: Eine Berechnung oder Prozedur auszuführen und einen Ergebnisnachweis gemäß den Service-Regeln zu liefern.
- Was als Verstoß gilt: Manipulation des Resultats, Nichterfüllung, Verstoß gegen das Verifikations- oder Beweisformat.
- Warum hier Restaking nötig ist: „Ausführungsehrlichkeit“ wird vom Vertrauen in einen Provider auf ökonomische Verantwortung verlagert.
- Was der Markt erhält: Recheninfrastruktur mit kontrollierbarem Preis des Fehlers und strafbaren Verpflichtungen der Teilnehmer.
Restaking macht Ausführungsqualität zu einer
AVS-Kategorien: Brücken und Cross-Chain-Messenger (bridged vs native Stablecoins), ZK-Module (Verifikation von Zero-Knowledge-Proofs), DePIN-Netzwerke (dezentrale physische Infrastruktur) und Koordinationsdienste, bei denen die ökonomische Verantwortung von Operatoren bei Regelverstößen fest verankert werden muss.
Restaking wird dort eingesetzt, wo ein hoher Preis des Fehlers nötig ist: Der AVS bezahlt für die Ausführung der Regeln; ein Regelverstoß macht den zugewiesenen Stake der Operatoren strafbar.
Restaking als Verantwortungsmarkt: security budget und Preis des Fehlers
In EigenLayer entstehen Zahlungen nicht „für den bloßen Staking-Fakt“, sondern für zusätzliche Verpflichtungen: Der AVS kauft strafbare Ausführungskorrektheit, und das Risiko wird durch die Slashing-Policy und die operative Komplexität bestimmt.
Kurzer Rahmen: security budget bedeutet „wie teuer ein Angriff oder Sabotage ist“. Restaking erhöht das Sicherheitsbudget nicht durch Versprechen, sondern durch die Verbindung „prüfbare Regel → formaler Verstoß-Trigger → Strafe auf den zugewiesenen Stake“.
-
Der AVS kauft Verantwortung, nicht „Liquidität“.
- Der Sinn des Deals: Der Service bezahlt für die Erfüllung seiner Anforderungen (Signaturen, Verfügbarkeit, korrekte Ergebnisse), und ein Verstoß wird durch Slashing zu einem messbaren Schaden.
- Was festgeschrieben wird: Der „Preis des Fehlers“ wird durch die Regeln des AVS bestimmt und nicht durch die Reputation eines Providers.
-
Restaking schließt die Startschwäche neuer Protokolle.
- Das Problem: Ein eigenes Validatorenset ist am Anfang klein, daher sind die Angriffskosten oft niedrig.
- Der praktische Effekt: Ein Service erhält Zugang zu einem größeren Pool delegierten Stakes, ohne einen separaten Token „für Sicherheit“ auszugeben.
-
Einnahmen sind Vergütung für Risiko und Ausführungskomplexität.
- Quelle der Zahlungen: Zahlungen von AVS an Operatoren (unter Berücksichtigung von Gebühren und Anforderungen).
- Preis der Zahlungen: Die Wahrscheinlichkeit von Slashing steigt mit der Zahl der AVS, der Komplexität des Stacks und Infrastrukturkorrelationen.
Marktregel: Restaking ist ein Markt für gemeinsame Sicherheit, bei dem „Wert“ durch Slashing-Policy, Schadens-Caps und die Qualität der operativen Ausführung bestimmt wird und nicht durch Schaufenster-Prozente.
EigenLayer monetarisiert Sicherheit als Dienstleistung: Der AVS bezahlt für Regeln und strafbare Garantien, und der Stake erhält einen zusätzlichen Zahlungsstrom zusammen mit einem zusätzlichen Slashing-Kreis.
Vorteile von EigenLayer-Restaking für Validatoren und ETH-Halter
Restaking fügt dem ETH-Staking einen zweiten Verantwortungskreis hinzu: Zahlungen kommen von AVS, und das Risiko wird durch deren Slashing-Regeln und die Qualität der Operatoren bestimmt.
Logik der Vorteile: Zusätzliche Zahlungen entstehen nur dort, wo der Stake zusätzliche Verantwortung übernimmt. Im Restaking wird diese Verantwortung durch die Slashing-Policy der konkreten AVS und die Ausführungsqualität der Operatoren definiert.
Vorteile von Restaking: Zahlungsquelle und Preis des Risikos
-
Zahlungen zusätzlich zum Basis-Staking
Quelle: Vergütung vom AVS für die Bedienung der Service-Regeln (über den Operator und dessen Gebühr).
Preis: Slashing nach AVS-Regeln und Abhängigkeit von der operativen Zuverlässigkeit des Operators.
-
Diversifikation der Zahlungsströme
Quelle: das AVS-Set des Operators (unterschiedliche Zahlungsmodelle und unterschiedliche Anforderungen).
Preis: Risikokreuzungen: Ein einzelner Operator-Ausfall kann mehrere AVS gleichzeitig treffen.
-
Teilnahme ohne eigene Node über LST/LRT
Quelle: liquide Konstruktionen (LST) und Aufbauten (LRT), die Basis-Belohnungen und AVS-Zahlungen in einem Asset bündeln.
Preis: zusätzliche Risikokreise: Smart Contracts, Depegs/Discounts, Exit-Liquidität, Bedingungen des LRT-Protokolls.
-
Flexibilität bei der Verteilung von Verantwortung
Quelle: Delegation an einen Operator und die Wahl des AVS bestimmen, welcher Teil des Stakes unter welche Regeln fällt.
Preis: Risikobegrenzung funktioniert nur über formale Limits und die Strategiearchitektur, nicht über Absichten.
-
Nachfrage nach ETH-Stake als „Sicherheitsdienst“
Quelle: AVS kaufen Sicherheit vom Ethereum-Staking-Markt, statt einen Token nur für Validatoren auszugeben.
Preis: Sicherheit wird zu einem Wettbewerbsmarkt: Zahlungsbedingungen, AVS-Sets und Operatoranforderungen ändern sich.
Beispiel (ohne Zahlen): Die Basis-Belohnung für Ethereum-Staking bleibt bestehen, und darüber kann eine Vergütung von einem oder mehreren AVS hinzukommen. Das Ergebnis wird durch zwei Parameter bestimmt: (1) die Summe der AVS-Zahlungen; (2) das Risikoprofil — die Slashing-Policy und die Wahrscheinlichkeit operativer Fehler beim gewählten Operator.
Restaking erhöht die Kapitaleffizienz (eine Sicherheit unterstützt mehrere Zahlungs- und Verantwortungskreise) durch AVS-Zahlungen, erweitert aber den Slashing-Kreis und macht Risikomanagement zu einem verpflichtenden Teil des Modells.
Risiken von Restaking: Slashing, korrelierte Fehler und Druck auf Ethereum
AVS-Zahlungen sind Vergütung für zusätzliche Verantwortung: Zu Ethereums Slashing kommen die Strafregeln externer Services hinzu, und korrelierte Ausfälle erhöhen die Wahrscheinlichkeit kaskadierender Szenarien.
Zwei Strafkreise: Ethereum definiert Slashing für den L1-Konsens, und Restaking ergänzt Slashing nach den Regeln der AVS. Das Risiko wird durch die Slashing-Policy des AVS und die operative Zuverlässigkeit des Operators bestimmt.
Slashing nach AVS-Regeln
Der Operator übernimmt gegenüber jedem AVS formale Verpflichtungen, und ein Regelverstoß führt zu einer Strafe auf den zugewiesenen Stake.
- Trigger: Downtime, falsche Signaturen, fehlerhafte Datenverarbeitung, widersprüchliche Handlungen, Inkompatibilität nach einem Client-Update.
- Schadensumfang: wird durch die AVS-Policy bestimmt (Bedingungen, Limits, Abstufungen von Verstößen) und durch die Menge an Stake, die tatsächlich für diesen AVS arbeitet.
- Begrenzer: Expositionslimits pro AVS, Verteilung auf mehrere Operatoren, Verzicht auf AVS mit unklarer Slashing-Policy oder hoher operativer Komplexität.
Beobachtung: Je mehr AVS ein Operator bedient, desto mehr unabhängige Ausfallpunkte entstehen und desto höher wird die Wahrscheinlichkeit einer Strafe bei gewöhnlichen Störungen.
Korrelierte Ereignisse und Massenstrafen
Eine gemeinsame Ursache kann viele Operatoren gleichzeitig treffen, einschließlich ehrlicher Teilnehmer.
- Trigger: Bug in der AVS-Logik, fragwürdige Konfiguration, mehrdeutige Regeln, synchrones fehlerhaftes Update bei vielen Operatoren.
- Schadensumfang: Massenabschreibungen verursachen gleichzeitige Verluste und verstärken den Abfluss von Stake aus dem Service oder Protokoll.
- Begrenzer: Caps auf die maximale Strafe, Limits für den Stake-Anteil in einem AVS, unabhängige Verifikation, Versicherungs- oder Kompensationsmechanismen (falls sie im Marktdesign vorgesehen sind).
Beobachtung: Ein gemeinsamer Bug oder eine umstrittene AVS-Konfiguration kann in einem Moment Massenabschreibungen auslösen.
Schwächung der Staking-Disziplin bei großem Schaden außerhalb von L1
Eine starke Strafe auf AVS-Ebene kann die ökonomische „Einsatzhöhe“ eines Validators abrupt senken und so die disziplinierende Rolle des Stakes schwächen.
- Trigger: tiefes Slashing in einem AVS oder eine Serie von Strafen in mehreren Services bei einem gemeinsamen operativen Problem.
- Schadensumfang: Ein reduzierter Stake senkt die „Kosten eines Fehlers“ für den Teilnehmer und erhöht die Neigung zu riskanten Entscheidungen.
- Begrenzer: Lokalisierung strittiger Fälle in der Restaking-Schicht, Begrenzung der Strafen, Konfliktlösungsverfahren auf Service-Ebene und nicht auf der Ebene des Ethereum-Konsenses.
Beobachtung: Umstrittene und subjektive Slashing-Fälle müssen unbedingt innerhalb der Restaking-Schicht gehalten werden.
Konzentration um einen großen AVS und systemischer Druck
Wächst der Anteil der Validatoren, die an einen AVS gebunden sind, steigt die Wahrscheinlichkeit, dass ein lokaler Konflikt systemisch wird.
- Trigger: umstrittene Strafe, kritischer Ausfall oder konfliktträchtiges Update in einem dominierenden AVS.
- Schadensumfang: Ein signifikanter Anteil der Operatoren und des delegierten Stakes wird getroffen, und eine „stille“ Konfliktlösung wird schwieriger.
- Begrenzer: Diversifikation über AVS, Konzentrationslimits, Konfliktlösungsverfahren auf Service- oder Restaking-Ebene und nicht auf Ethereum-Ebene.
Beobachtung: Eine hohe Konzentration um einen AVS erschwert die Isolierung von Konflikten ohne systemischen Effekt.
Restaking fügt Risiken hinzu, die es im Basis-ETH-Staking nicht gibt: AVS-Slashing, korrelierte Ausfälle und Konflikte rund um Regeln. Die Reduzierung der Exposition stützt sich meist auf Limits für den Stake-Anteil, Verteilung auf mehrere Operatoren und regelmäßige Revision des AVS-Sets und seiner Slashing-Policy. Eine Strafe kann die angesammelten Gewinne vollständig aufzehren.
Bedingung für Stabilität: Restaking verstärkt die Risiken des ETH-Stakings durch AVS-Slashing und korrelierte Infrastrukturereignisse. Ohne Expositionslimits und Verständnis der Slashing-Policy wird das Modell schneller zu einer Verlustquelle als zu einem stabilen Zahlungsstrom.
Restaking, LST, Delegation und LRT: Begriffsgrenzen und Risikopunkte
Restaking fügt dem Stake einen zweiten Regelkreis hinzu — Slashing nach AVS-Policy. LST löst das Liquiditätsproblem des Stakes. Delegation bestimmt den Ausführer. LRT bündelt Restaking-Strategien in einem Token und überträgt AVS-Risiko in den Preis.
Begriffsgrenze: LST = Token-Repräsentation des Stakes; Delegation = Wahl des Operators oder Validators; Restaking = Anbindung des Stakes an AVS mit separater Slashing-Policy; LRT = Aufbau, der Restaking-Strategien in einem Token aggregiert.
| Instrument | Was festgeschrieben wird | Woher die Zahlungen kommen | Was zum Risiko wird |
|---|---|---|---|
| Delegation | Wer die Netzwerkregeln ausführt | L1-Konsens-Belohnungen | Operative Ausfälle des Ausführenden innerhalb der L1-Regeln |
| LST | Anteil am Stake über einen liquiden Token | Staking-Belohnungen + Mechanik des LST-Protokolls | Smart-Contract-Risiken, Discount/Depeg, Exit-Liquidität |
| Restaking | Der Stake wird nach AVS-Regeln slashable | Zahlungen vom AVS (über Operatoren) | AVS-Slashing, korrelierte Ausfälle, Abhängigkeit vom AVS-Set des Operators |
| LRT | Strategiepaket (LST + Restaking) in einem Token | Staking-Belohnungen + AVS-Zahlungen | Vererbtes AVS-Slashing, Strategie-/Contract-Risiken, Discount als Preis des AVS-Risikos |
Praktische Zusammensetzung: Die Kette „Staking → LST → Restaking → LRT“ fügt Ebenen hinzu: zuerst Liquidität (LST), dann AVS-Verantwortung (Restaking), dann Aggregation von Strategien (LRT). Jede nächste Ebene bringt eigene Regeln und eigene Ausfallpunkte mit sich.
Delegation wählt den Ausführer, LST gibt Liquidität, Restaking fügt einen zweiten Slashing-Kreis nach den Regeln der AVS hinzu, und LRT überträgt das AVS-Risikoprofil in den Tokenpreis.
Restaking in DeFi: RSFi, LRT und die Übertragung von AVS-Risiko in den Sicherheitenpreis
Restaking bildet die Grundlage für RSFi (restaking finance): LRT-Produkte, Renditestrategien und Slashing-Versicherungsschemata, aber die zentrale Besonderheit ist die Übertragung von AVS-Risiko und Operatoren-Korrelationen in den LRT-Preis und die Qualität der Sicherheiten.
Wichtigster Risikotransmissionskanal: In RSFi zeigt sich der Zustand von Restaking über den LRT-Preis. Der LRT-Discount gegenüber ETH spiegelt nicht nur Exit-Liquidität wider, sondern auch eine Neubewertung der Wahrscheinlichkeit von AVS-Slashing und korrelierten Infrastrukturereignissen; im Lending zeigt sich dies meist über einen Anstieg des effektiven wie LTV wächst und Liquidationen ausgelöst werden.
-
Ein LRT tokenisiert ein „Verpflichtungsportfolio“.
- Mechanik: Basis-Staking-Belohnungen werden durch AVS-Zahlungen ergänzt, und die Strategie wird in einem LRT tokenisiert.
- Risikozusammensetzung: AVS-Slashing, Operatorenrisiko, korrelierte Ausfälle im AVS-Set, Contract- und Strategierisiko der Verpackung.
-
LRT als Sicherheit verstärkt die Verknüpfung systemischer Szenarien.
- Szenario: Ein LRT wird im Lending, in Pools oder in Derivaten verwendet und bleibt mit dem Restaking-Risiko verbunden.
- Folge: Derselbe ökonomische Stake nimmt gleichzeitig an den Kreisen von Ethereum, AVS und DeFi-Positionen teil.
-
Ein LRT-Discount beschleunigt Liquidationen über die Sicherheitenqualität.
- Trigger: erwartetes Slashing, steigende operative Unsicherheit bei Operatoren, Konzentration um einen großen AVS, umstrittene Updates oder Vorfälle in einem AVS.
- Übertragung nach DeFi: Der Discount verschlechtert die Sicherheit, erhöht den effektiven LTV und beschleunigt Liquidationen in verbundenen Protokollen.
-
Slashing-Versicherung wird zu einer separaten Design-Ebene.
- Mechanik: Ein Teil der AVS-Zahlungen fließt in einen Versicherungspool oder eine Kompensationsreserve.
- Struktur: Konservative Schichten erhalten geringere Zahlungen, haben aber Priorität bei Kompensationen; aggressive Schichten übernehmen höheres Risiko.
Warum das zu systemischem Risiko werden kann: Der LRT-Preis beeinflusst Sicherheiten in vielen Protokollen gleichzeitig. Bei einer Neubewertung des AVS-Risikos verschlechtert der LRT-Discount die Sicherheitenqualität und beschleunigt Liquidationen, was kaskadierende Verkäufe verstärkt.
Beispielszenario: ETH → LST → Restaking → LRT → Nutzung des LRT als Sicherheit für einen Stablecoin-Kredit. In dieser Kette sichert derselbe Stake gleichzeitig Ethereum ab, bedient AVS und stützt eine Kreditposition, daher beschleunigt ein LRT-Discount das Liquidationsrisiko.
Quelle von Kaskaden: RSFi baut rund um LRT und AVS-Zahlungen auf, und der wichtigste Kanal systemischer Effekte ist die Übertragung der Erwartung von AVS-Slashing und korrelierten Ausfällen in den Preis der Sicherheiten und die Exit-Liquidität.
Die Zukunft von Restaking und Modellen gemeinsamer Sicherheit
Restaking bewegt sich in Richtung „gemeinsamer Sicherheit“: Projekte schließen sich an eine Marktschicht der Verantwortung (Zahlung für Regeln und Strafen) an, statt eine eigene Validatorenökonomie aufzubauen.
Die wichtigste Wachstumsgabelung: Das Ausmaß von Restaking wird durch Integrationsstandards, Slashing-Design und Verfahren zur Lokalisierung von Vorfällen bestimmt und nicht nur durch die Zahl neuer AVS.
| Was sich ändert | Wozu das nötig ist | Was dadurch sinkt |
|---|---|---|
| Standardisierung von AVS-Schnittstellen und Risikoprofilen | Vergleichbarkeit der Bedingungen und geringere „Integrationskosten“ für Sicherheit | Fragmentierung von Integrationen und Fehler durch einzigartige Implementierungen |
| Formale Strenge (Audits, Verifikation, Post-Mortems) | Zulassung zu großem Stake nur für reife Module | Risiko kritischer Bugs und „Black Boxes“ ohne Erklärung |
| Engineering von Slashing (Caps, Abstufungen, klare Trigger) | Kontrollierbarer Preis des Fehlers und Vorhersehbarkeit des Schadens | Massenabschreibungen durch seltene oder umstrittene Ereignisse |
| Incident-Verfahren (Resolver, Schiedsverfahren, Kompensationen) | Lokalisierung von Konflikten innerhalb der Restaking-Schicht | Übertragung von Streit und Druck auf die Basisschicht Ethereum |
Was für Sicherheitsoperatoren zur „Marktnorm“ wird:
- AVS-Portfolio und Expositionslimits. Ein Service-Set und formale Begrenzungen des Stake-Anteils unter jeder Slashing-Policy.
- Prozesse statt Versprechen. Update-Regeln, Monitoring, Reaktion, Tests und Incident-Logging.
- Transparenz und Reputation. Historie von Ausfällen und Slashing, öffentliche Berichte, verständliche Regeln zum Umgang mit Konflikten und Kompensationen (falls vorgesehen).
- Kontrolle von Korrelationen. Berücksichtigung gemeinsamer Stack-Komponenten und des Risikos „ein Bug für alle“ bei Massen-Updates.
Die ersten großen Stressszenarien sind fast unvermeidlich (Bugs, umstrittene Strafen, korrelierte Ausfälle). Die Stabilität des Modells wird durch Caps auf Schäden, transparente Analyseverfahren und Mechanismen zur Lokalisierung von Konflikten auf Restaking-Ebene bestimmt und nicht auf der Ebene des Ethereum-Konsenses.
Vektor: Bei erfolgreicher Standardisierung kann Sicherheit zu einer Infrastruktur-Dienstleistung mit kryptoökonomischen Garantien werden, bei der „Verantwortungsbedingungen“ genauso transparent lesbar sind wie Tarife und SLA in klassischen Infrastrukturservices.
Die Zukunft von Restaking wird durch Engineering von Verantwortung bestimmt: Standardisierung von AVS, vorhersehbares Slashing und Verfahren zur Lokalisierung von Vorfällen ohne systemische Kaskaden.
FAQ zu Restaking und dem EigenLayer-Protokoll
Kurze Antworten auf häufige Fragen: Was Restaking und AVS sind, ob 32 ETH nötig sind, woher Zahlungen kommen und wo genau das Slashing-Risiko entsteht.
Was ist Restaking in einfachen Worten?
Was ist ein AVS im Kontext von EigenLayer?
Müssen 32 ETH vorhanden sein, um an Restaking teilzunehmen?
Welche Rendite kann Restaking bringen?
Worin unterscheidet sich Restaking vom Liquid Staking (LST)?
Ist ein Kapitalverlust durch Restaking möglich?
Schwächt Restaking nicht die Sicherheit von Ethereum selbst?
Abschließende Zusammenfassung: Restaking, LST, Delegation und LRT
Restaking fügt dem ETH-Staking einen zweiten Verantwortungskreis hinzu: Der Stake wird nach AVS-Regeln slashable. Das schafft einen Markt gemeinsamer Sicherheit und Zahlungen für Infrastrukturaufgaben, erweitert aber den Risikokreis für den Stake und für DeFi-Ketten rund um LRT.
Zusammenfassung in einer Zeile: EigenLayer verbindet ETH-Stake mit externen Services und macht die Verpflichtungen von Operatoren gegenüber AVS zu strafbarer Verantwortung über Slashing des zugewiesenen Stakes.
Wo der Nutzen entsteht (was der Markt kauft):
- Sicherheit als Dienstleistung. AVS erhalten Schutz auf Basis des Ethereum-Stakes, ohne eine eigene Validatorenökonomie zu starten.
- Schneller Start von Infrastruktur. Protokolle binden eine fertige Verantwortungsschicht an, statt einen „Token für Validatoren“ aufzubauen.
- Neue Primitive für DeFi. LRT- und RSFi-Produkte tokenisieren Zahlungen und Verantwortung, aber mit ihnen werden auch Risiken tokenisiert.
Wo das Risiko entsteht (was zum Preis der Zahlungen wird):
- AVS-Slashing. Zu den Ethereum-Regeln kommen separate Slashing-Policies für jeden Service hinzu.
- Korrelierte Ausfälle. Gemeinsame Stack-Komponenten und Massen-Updates können zu synchronen Verstößen vieler Operatoren führen.
- Kaskaden über den LRT-Preis. Ein LRT-Discount verschlechtert die Sicherheitenqualität und beschleunigt Liquidationen in Kreditprotokollen.
Wesen des Modells: Restaking auf EigenLayer ist keine „Zugabe zum Prozentsatz“, sondern ein Modell erweiterter Verantwortung. Die Stabilität stützt sich auf Expositionslimits, Diversifikation über Operatoren und AVS sowie auf die Bereitschaft für Slashing und korrelierte Ausfälle.
Bedingung für den Standard: Restaking wird sich als Infrastrukturstandard etablieren, wenn Vorfälle innerhalb der Restaking-Schicht lokalisiert werden (Caps auf Schäden, Analyseverfahren, Reserven/Kompensationen) und das Risiko genauso streng bewertet wird wie Smart Contracts und Sicherheiten in DeFi.