4 Beiträge getaggt mit „Restaking“

In nur 18 Tagen im April dieses Jahres entwendeten Angreifer 606 Millionen Dollar aus dem DeFi-Sektor. Dieser einzige Zeitraum übertraf die Verluste des ersten Quartals 2026 um das 3,7-fache und machte den Monat zum schlimmsten seit dem Bybit-Raub im Februar 2025. Zwei Protokolle — Drift auf Solana und Kelp DAO auf Ethereum — machten 95 Prozent des Schadens aus. Beide waren auditiert worden. Beide bestanden die statische Analyse. Beide führten Routine-Upgrades durch, die im Stillen die Annahmen entkräfteten, die ihre Auditoren zuvor verifiziert hatten.

Dies ist das neue Gesicht des DeFi-Risikos. Die katastrophalen Exploits von 2026 sind keine Reentrancy-Fehler oder Integer-Overflows mehr, die Fuzzer in der CI aufspüren können. Es geht um durch Upgrades eingeführte Schwachstellen: subtile Änderungen an Bridge-Konfigurationen, Oracle-Quellen, Admin-Rollen oder Messaging-Standardeinstellungen, die zuvor sicheren Code in eine offene Tür verwandeln — ohne dass eine einzige Zeile Solidity offensichtlich falsch aussieht.

Wenn Sie DeFi-Anwendungen entwickeln, verwalten oder einfach nur Assets darin halten, ist die Lehre aus dem April 2026 unbequem: Ein sauberer Audit-Bericht von vor drei Monaten ist kein Beweis mehr dafür, dass ein Protokoll heute sicher ist.

Das April-Muster: Konfiguration, nicht Code​

Um zu verstehen, warum „durch Upgrades eingeführte Fehler“ eine eigene Kategorie verdienen, muss man sich ansehen, wie sich die beiden größten Exploits tatsächlich abgespielt haben.

Drift Protocol — 285 Millionen Dollar, 1. April 2026. Solanas größte Perp-DEX verlor mehr als die Hälfte ihres TVL, nachdem Angreifer sechs Monate lang eine Social-Engineering-Kampagne gegen das Team durchgeführt hatten. Sobald Vertrauen aufgebaut war, nutzten sie das Solana-Feature „durable nonces“ — eine UX-Erleichterung, die es Nutzern ermöglicht, Transaktionen für eine spätere Einreichung vorab zu signieren —, um Mitglieder des Drift Security Council dazu zu verleiten, Signaturen zu autorisieren, die sie für routinemäßige operative Vorgänge hielten. Diese Signaturen übertrugen schließlich die Admin-Kontrolle an die Angreifer, die einen gefälschten Collateral-Token (CVT) auf die Whitelist setzten, 500 Millionen Einheiten davon hinterlegten und 285 Millionen Dollar in echten USDC, SOL und ETH abhoben. Das Solana-Feature funktionierte wie vorgesehen. Die Contracts von Drift taten das, was ihre Admins befahlen. Der Angriff fand vollständig in der Lücke zwischen dem statt, was die Multisig-Unterzeichner zu genehmigen glaubten, und dem, was sie tatsächlich taten.

Kelp DAO — 292 Millionen Dollar, 18. April 2026. Angreifer, die von LayerZero der nordkoreanischen Lazarus-Gruppe zugerechnet wurden, kompromittierten zwei RPC-Nodes, die die Cross-Chain rsETH-Bridge von Kelp stützten, tauschten die darauf laufenden Binärdateien aus und nutzten einen DDoS-Angriff, um ein Verifizierer-Failover zu erzwingen. Die bösartigen Nodes meldeten dem Verifizierer von LayerZero daraufhin, dass eine betrügerische Transaktion stattgefunden habe. Der Exploit funktionierte nur, weil Kelp eine 1-von-1-Verifizierer-Konfiguration verwendete — was bedeutet, dass ein einzelner von LayerZero betriebener DVN die unilaterale Autorität hatte, Cross-Chain-Nachrichten zu bestätigen. Laut LayerZero ist dieses 1-von-1-Setup der Standard in ihrem Quickstart-Guide und wird derzeit von etwa 40 Prozent der Protokolle im Netzwerk verwendet. In 46 Minuten zog ein Angreifer 116.500 rsETH ab — etwa 18 Prozent des gesamten umlaufenden Angebots — und ließ gemappte Sicherheiten auf 20 Chains festsitzen. Aave, das rsETH listet, wurde in eine Liquiditätskrise gezwungen, als die Einleger um den Ausstieg kämpften.

Weder für den einen noch für den anderen Angriff war ein Smart-Contract-Bug erforderlich. Beide setzten das Verständnis voraus, wie eine Konfiguration — Multisig-Signaturabläufe, Standard-DVN-Anzahlen, RPC-Redundanz — stillschweigend von einem „operativen Detail“ zu einer „tragenden Sicherheitsannahme“ erhoben worden war.

Warum statische Audits diese Fehlerklasse übersehen​

Das traditionelle DeFi-Audit ist für das falsche Bedrohungsmodell optimiert. Firmen wie Certik, OpenZeppelin, Trail of Bits und Halborn sind exzellent in der Zeile-für-Zeile-Codeüberprüfung und im Ausführen von Invarianten-Tests gegen eine eingefrorene Contract-Version. Das fängt Reentrancy, Fehler bei der Zugriffskontrolle, Integer-Overflows und Versäumnisse im OWASP-Stil ab.

Doch die Klasse der durch Upgrades eingeführten Fehler weist drei Eigenschaften auf, die diesen Workflow unterlaufen:

1. Sie existiert im zusammengesetzten Laufzeitverhalten, nicht im Quellcode. Die Sicherheit einer Bridge hängt von der Verifizierer-Konfiguration ihrer Messaging-Schicht, dem DVN-Set, der RPC-Redundanz dieser DVNs und dem Slashing-Risiko dieser Betreiber ab. Nichts davon steht in dem Solidity-Code, den ein Auditor liest.

2. Sie wird durch Änderungen eingeführt, nicht durch die Erstbereitstellung. Kelps Bridge sah vermutlich gut aus, als LayerZero v2 zum ersten Mal integriert wurde. Die DVN-Anzahl wurde erst dann gefährlich, als der TVL groß genug war, um einen Angriff lohnenswert zu machen, und als Lazarus in die Kompromittierung der RPC-Infrastruktur investierte.

3. Sie erfordert verhaltensbasiertes Differenzial-Testing — die Beantwortung der Frage: „Wurde Invariante X unter dem neuen Codepfad beibehalten?“ — was keine der großen Audit-Firmen als geplanten Post-Upgrade-Service anbietet. Man erhält ein einmaliges Audit für Version 1.0 und ein separates einmaliges Audit für Version 1.1, aber keine kontinuierliche Bestätigung, dass das Upgrade von 1.0 auf 1.1 keine Eigenschaften bricht, auf die sich 1.0 verlassen hat.

Die Statistiken für das erste Quartal 2026 verdeutlichen diese Lücke. DeFi verzeichnete im gesamten Quartal Verluste in Höhe von 165,5 Millionen Dollar bei 34 Vorfällen. Allein der April verursachte 606 Millionen Dollar in 12 Vorfällen. Die Bereitstellungsseite skalierte — im ersten Quartal kamen über 40 Milliarden Dollar an neuem TVL hinzu —, während die Audit-Kapazitäten, die Reaktion auf Vorfälle und die Validierung nach der Bereitstellung weitgehend stagnierten. Irgendetwas musste nachgeben.

Drei Kräfte , die 2026 zum Jahr machen , in dem dies massenhaft zuschlägt​

1 . Die Upgrade-Kadenz hat sich auf jeder Ebene beschleunigt​

Jedes L1 und L2 iteriert schneller . Das Pectra-Upgrade von Ethereum befindet sich im aktiven Rollout , Fusaka und Glamsterdam sind im Design , und Solana , Sui und Aptos liefern alle Änderungen an der Execution-Layer in mehrwöchigen Zyklen aus . Jedes Upgrade auf Chain-Ebene kann die Gas-Semantik , Signaturschemata oder die Transaktionsreihenfolge auf eine Weise subtil verschieben , die sich auf die Annahmen der Applikationsschicht auswirkt . Der Exploit von Drift ist ein klares Beispiel — ein Solana-Feature ( Durable Nonces ) , das für den UX-Komfort gedacht war , wurde zum Träger für eine Admin-Übernahme .

2 . Restaking vergrößert die Upgrade-Angriffsfläche​

Der Restaking-Stack — EigenLayer ( immer noch über 80 Prozent des Marktes ) , Symbiotic , Karak , Babylon , Solayer — fügt dem Problem eine dritte Dimension hinzu . Ein einzelnes LRT wie rsETH sitzt auf EigenLayer , das wiederum auf nativem ETH-Staking sitzt . Jede Ebene liefert ihre eigenen Upgrades nach ihrem eigenen Zeitplan aus . Eine Änderung der Slashing-Semantik von EigenLayer hat implizite Folgen für jeden Operator und jedes LRT , das die Validierung dieses Operators nutzt . Als die Bridge von Kelp geleert wurde , bedrohte die Ansteckung sofort den TVL von EigenLayer , da dieselben Einleger ein dreistufiges Rehypothekarisierungs-Risiko hatten , zu dessen Modellierung sie nie gezwungen worden waren . Die Roadmap von EigenCloud mit den bevorstehenden Erweiterungen EigenDA , EigenCompute und EigenVerify wird diese Angriffsfläche nur noch weiter vergrößern .

3 . KI-gesteuerte DeFi-Aktivitäten bewegen sich schneller als menschliche Überprüfungen​

Agent-Stacks wie XION , Brahma Console und Giza interagieren jetzt mit Maschinengeschwindigkeit mit aktualisierten Verträgen . Wo ein menschlicher Schatzmeister nach einem Vertrags-Upgrade vielleicht Tage warten würde , bevor er sich erneut engagiert , testet ein Agent es back , integriert es und leitet Kapital innerhalb von Stunden hindurch . Jedes Upgrade , das stillschweigend eine Invariante bricht , wird durch gegnerische Flows einem Stresstest unterzogen , bevor ein menschlicher Auditor es erneut prüfen kann .

Die entstehende Verteidigungsarchitektur​

Die ermutigende Nachricht ist , dass die Sicherheitsforschungsgemeinschaft nicht untätig war . Die Verluste vom April 2026 haben konkrete Vorschläge an vier Fronten katalysiert .

Kontinuierliche formale Verifizierung . Die langjährige Zusammenarbeit von Certora mit Aave — finanziert als Zuschuss für kontinuierliche Verifizierung statt als einmaliges Engagement — ist nun eine Vorlage . Der Certora Prover führt automatisch Invarianten-Beweise aus , jedes Mal , wenn sich ein Vertrag ändert , und lässt Brüche vor dem Merge auftauchen . Halmos und HEVM bieten alternative Open-Source-Wege zum gleichen Ziel . Als die formale Verifizierung kürzlich eine Schwachstelle in einer Integration mit dem Electra-Upgrade von Ethereum entdeckte , die herkömmliche Audits übersehen hatten , war dies kein Einzelfall ; es war eine Vorschau .

Upgrade-Diff-Audit-Dienste . Spearbit , Zellic und Cantina haben damit begonnen , kostenpflichtige Dienste zu pilotieren , die den Diff zwischen zwei Vertragsversionen prüfen , nicht die neue Version isoliert . Das Modell behandelt jedes Upgrade als neue Attestierung und prüft explizit , ob frühere Invarianten erhalten bleiben . Das 1-Million-Dollar-Audit-Subventionsprogramm der Ethereum Foundation , das am 14 . April 2026 mit einer Partnerliste gestartet wurde , zu der Certora , Cyfrin , Dedaub , Hacken , Immunefi , Quantstamp , Sherlock , Spearbit , Zellic und Zokyo gehören , zielt teilweise darauf ab , die Kapazitäten für genau diese Art von Arbeit zu erweitern .

Chaos Engineering und Runtime-Monitoring . OpenZeppelin Defender und neue Tools integrieren Simulationen auf geforkten Mainnets in CI-Pipelines , sodass Protokolle gegnerische Szenarien gegen jedes vorgeschlagene Upgrade durchspielen können . Die Disziplin ist direkt aus der Web2 SRE-Praxis entlehnt — und im DeFi-Bereich längst überfällig .

Time-locked Upgrade Escrows . Das Compound Timelock v3-Muster , bei dem jedes von der Governance genehmigte Upgrade für eine festgelegte Verzögerung in einer öffentlichen Warteschlange verbleibt , bevor es ausgeführt wird , gibt der Community Zeit , Probleme zu erkennen , die bei der internen Prüfung übersehen wurden . Es verhindert keine durch Upgrades eingeführten Bugs , erkauft aber Zeit , damit diese vor einer Ausnutzung entdeckt werden können .

Der TradFi-Vergleich : Kontinuierliche Audits sind außerhalb von DeFi die Norm​

Das traditionelle Finanzwesen hat das analoge Problem vor Jahrzehnten gelöst . SOC 2 Type II , der Standard , an den die meisten institutionellen Dienstleister gebunden sind , ist keine einmalige Bescheinigung ; es ist ein sechs- bis zwölfmonatiges kontinuierliches Audit-Fenster . Das Kontrahentenrisiko-Framework von Basel III verlangt von Banken , ihre Kapitalmodelle zu aktualisieren , sobald sich die Risiken ändern , nicht jährlich . Einer Depotbank , die ein Abwicklungssystem aktualisiert , wäre es nicht gestattet , auf der Basis von „ wir haben v1 geprüft ; v2 war nur eine kleine Änderung “ zu arbeiten .

Die vorherrschende Kultur im DeFi-Bereich — „ einmal prüfen , für immer bereitstellen , erneute Prüfung nur bei größeren Neuschreibungen “ — ist genau die Praxis , die TradFi nach der Krise von 2008 ausdrücklich abgelehnt hat . Bei der aktuellen Verlustrate ist die Branche auf dem Weg zu 2 Milliarden Dollar oder mehr an jährlichen Verlusten durch Upgrade-Exploits . Das ist groß genug , um Regulierungsbehörden anzuziehen , die DeFi-Audit-Standards ohnehin als unzureichend betrachten , und es ist groß genug , um eine kontinuierliche Validierung zur Voraussetzung für institutionelles Kapital zu machen .

Was das für Builder , Einleger und die Infrastruktur bedeutet​

Für Protokoll-Teams ist das operative Mandat einfach , auch wenn es nicht billig ist : Jedes Upgrade muss als neues Release behandelt werden , das seine Sicherheitsgarantien neu ableitet und nicht nur erbt . Das bedeutet geplante Re-Audits auf Diff-Basis , Spezifikationen zur formalen Verifizierung , die jedem Governance-Vorschlag beiliegen , und aussagekräftige Timelocks vor der Ausführung . Es bedeutet , — im Stil von Aave — ein quantifiziertes Kaskadenrisiko-Framework zu veröffentlichen , das benennt , von welchen Protokollen man abhängt und wie das Risiko aussieht , wenn eines davon ausfällt .

Für Einleger ist die Lektion , dass „ dieses Protokoll wurde geprüft “ für sich genommen kein nützliches Signal mehr ist . Die richtige Frage lautet : „ Wann fand der letzte kontinuierliche Verifizierungslauf gegen welche Invarianten und auf welcher Version des bereitgestellten Codes statt ? “ Protokolle , die das nicht beantworten können , sollten entsprechend bepreist werden .

Für Infrastrukturanbieter — RPC-Betreiber , Indexer , Custodians — ist der Kelp-Vorfall eine direkte Warnung . Die Kompromittierung fand in zwei RPC-Nodes statt , deren Binärdateien stillschweigend ausgetauscht wurden . Jeder , der Infrastruktur betreibt , die an der Cross-Chain-Verifizierung teilnimmt ( DVNs , Oracle-Nodes , Sequencer ) , ist nun Teil des Sicherheitsmodells , ob er sich dafür angemeldet hat oder nicht . Reproduzierbare Builds , attestierte Binärdateien , Multi-Operator-Quoren anstelle von 1-von-1-Standardeinstellungen und die Verifizierung signierter Binärdateien beim Start sind nicht länger optional .

Upgrades auf Chain-Ebene — Pectra und Fusaka auf Ethereum , Rollouts für parallele Ausführung auf Solana und Aptos , die Durchsatzziele von Glamsterdam — werden die Angriffsfläche weiter vergrößern . Die Protokolle und Infrastrukturbetreiber , die 2026 überleben , werden diejenigen sein , die die kontinuierliche Validierung früh genug eingeführt haben , sodass ihr nächstes Routine-Upgrade auch ihr nächster beweisbarer Sicherheits-Checkpoint ist .

BlockEden . xyz betreibt RPC- , Indexer- und Node-Infrastrukturen in Produktionsumgebungen für Sui , Aptos , Ethereum , Solana und ein Dutzend weiterer Chains . Wir behandeln jedes Protokoll-Upgrade — auf der Chain-Ebene oder der Applikationsebene — als neues Sicherheitsereignis , nicht als Wartungsaufgabe . Erkunden Sie unsere Enterprise-Infrastruktur , um auf einem Fundament aufzubauen , das darauf ausgelegt ist , die kommende Upgrade-Kadenz zu überstehen .

Quellen​

• Cryptos 606 Mio. $ April-Albtraum: 12 Hacks, 18 Tage, schlimmster Monat seit dem Bybit-Raub — CryptoTimes
• 606 Millionen $ verloren: April 2026 wird zum schlimmsten Monat für Krypto-Exploits — Blockonomi
• Kelp DAO für 292 Millionen $ ausgenutzt, wobei Wrapped Ether über 20 Chains gestrandet ist — CoinDesk
• LayerZero macht Kelps Setup für 290-Millionen-$-Exploit verantwortlich und schreibt ihn Nordkoreas Lazarus-Gruppe zu — CoinDesk
• Drift Protocol Hack: Wie privilegierter Zugriff zu einem Verlust von 285 Mio. $ führte — Chainalysis
• Wie Drift-Angreifer mehr als 270 Millionen $ mit einer auf Komfort ausgelegten Solana-Funktion entwendeten — CoinDesk
• Nordkoreanische Hacker greifen Drift Protocol in einem 285-Millionen-USD-Raub an — TRM Labs
• Q1 2026 DeFi Exploit-Musteranalyse: 137 Mio. $ verloren, 5 Angriffsmuster, die jeder Auditor kennen muss — DEV Community
• Die OWASP Smart Contract Top 10: 2026 — DEV Community
• Aave-Certora-Secureum: Eine DeFi-Sicherheitskooperation — Secureum
• Ethereum Foundation finanziert 1 Mio. $ Audit-Programm für Smart-Contract-Entwickler
• Upgradefähige Smart Contracts: Proxies, Patterns, Pitfalls und CI/CD-Schutzmaßnahmen — Octane Security
• 292 Mio. $ Kelp DAO rsETH-Hack löst Aave-Liquiditätskrise aus — CCN
• Über 400 Mio. $ durch DeFi-Exploits im Jahr 2026 verloren — CCN

Seit zwei Jahren ist das Versprechen von EigenLayer an Restaker simpel: ETH staken, das Protokoll eines anderen sichern, zusätzliche Rendite kassieren. Die Slashing-Parameter existierten nur auf dem Papier. Betreiber konnten kein tatsächliches Kapital durch Fehlverhalten bei einem AVS verlieren, da der Code, der ihren Einsatz einziehen würde, noch nicht veröffentlicht war. Diese Ära endete am 17. April 2026, als EigenLayer das Production-Slashing im Mainnet aktivierte.

Etwa 15 – 18 Milliarden $ an restaktem ETH sind nun zum ersten Mal seit dem Start des Protokolls einem realen kryptookönomischen Verlustrisiko ausgesetzt. Die Frage, der Restaker, Betreiber, AVS-Entwickler und die DeFi-Lending-Märkte – die Hunderte von Milliarden an LST-besicherten Schulden halten – seit vierundzwanzig Monaten höflich aus dem Weg gegangen sind, wird nun endlich beantwortet: Ist die Restaking-Rendite eine Vergütung für echte Sicherheitsarbeit oder ist es eine Vergütung für ein Risiko, das bisher niemand wirklich eingegangen ist?

Zwei Jahre Slashing-Theater​

EigenLayer startete 2023 im Mainnet mit einem klaren Versprechen. Betreiber würden ETH restaken, um Actively Validated Services — Oracle-Netzwerke, Bridges, Datenverfügbarkeitsschichten, Co-Prozessoren — zu sichern, und wenn sie sich falsch verhielten, konnte der AVS ihren Einsatz (Stake) slashen. Das Modell sollte einen einheitlichen Markt für kryptookönomische Sicherheit schaffen, auf dem jedes neue Protokoll das Validatoren-Set von Ethereum ausleihen konnte, anstatt ein eigenes Validatoren-Set aufzubauen.

Was tatsächlich geliefert wurde, war die erste Hälfte dieses Versprechens. Betreiber konnten sich registrieren, delegieren und Belohnungen verdienen. Die Slashing-Logik selbst war mit Platzhalter-Parametern versehen. In den Jahren 2024 und dem Großteil von 2025 hatte ein AVS, der Double-Signing, Datenzensur oder das Erstellen eines fehlerhaften Proofs durch einen Betreiber feststellte, keine Möglichkeit auf Protokollebene, das ETH dieses Betreibers einzuziehen. Die Zahl für „slashbare Sicherheit“ auf den Dashboards war lediglich ein angestrebtes Ziel.

Dies war kein Geheimnis. Die Dokumentation von EigenLayer wies explizit auf den phasenweisen Rollout hin. Doch die Auswirkungen auf das Verhalten der Betreiber und die Erwartungen der Restaker waren erheblich. Ein AVS-Betreiber, der gleichzeitig EigenDA, Hyperlane und Lagrange betrieb, wusste, dass ein Softwarefehler, eine Oracle-Abweichung oder sogar vorsätzliches Fehlverhalten zwar Rendite, aber nicht das Kapital kosten konnte. Restaker wiederum behandelten Restaking eher als eine höher verzinste Variante des einfachen ETH-Stakings und nicht als ein grundlegend anderes Risikoprodukt.

ELIP-002 — „Slashing via Unique Stake & Operator Sets“ — ist das, was die Kalkulation schließlich änderte. Das Mainnet-Upgrade vom 17. April aktiviert die Verträge, die es einem AVS ermöglichen, eine Slashing-Transaktion gegen die spezifische Zuweisung eines bestimmten Betreibers auszuführen, wobei echtes ETH aus echten Wallets abfließt. Die Ära der Platzhalter ist vorbei.

Was tatsächlich live gegangen ist​

Das Upgrade ist kein einzelner Schalter, der jeden Betreiber sofort slasht, sobald eine Spezifikationsverletzung auftritt. Es ist ein Framework, für das sich AVSs, Betreiber und Restaker nun bewusst entscheiden.

Betreiber-Sets (Operator Sets) sind das neue Kern-Primitiv. Ein AVS verfügt nicht mehr über einen globalen Pool von Betreibern, die ihn sichern. Stattdessen definiert er ein oder mehrere Betreiber-Sets, jedes mit eigenen Registrierungsregeln, Aufgabenzuweisungen, Slashing-Bedingungen und Belohnungsstrukturen. Ein Betreiber, der einen AVS sichern möchte, registriert sich in einem spezifischen Betreiber-Set und akzeptiert ausdrücklich die damit verbundenen Slashing-Bedingungen.

Einzigartige Stake-Zuweisung (Unique Stake Allocation) ist das dahinterliegende Abrechnungsmodell. Jeder Betreiber beginnt mit einer protokollseitig definierten Gesamtmagnitude (Total Magnitude, 1 × 10^18 Einheiten), die seinen gesamten delegierten Stake repräsentiert. Der Betreiber weist Teile dieser Magnitude verschiedenen Betreiber-Sets zu. Nur der AVS, dem ein bestimmtes Betreiber-Set gehört, kann den ihm zugewiesenen Anteil slashen. Wenn das Betreiber-Set von EigenDA 40 % der Magnitude eines Betreibers hält und das von Hyperlane 30 %, kann ein Slashing-Ereignis bei EigenDA im schlimmsten Fall diese 40 % verbrauchen — der Stake von Hyperlane ist für den Slasher von EigenDA unantastbar und umgekehrt.

Opt-in als Standard ist der Mechanismus für den schrittweisen Rollout. Betreiber, die bereits AVSs unter dem Pre-Slashing-Regime betreiben, werden nicht automatisch in die neuen Betreiber-Sets aufgenommen. Sie müssen die Slashing-Bedingungen jedes AVS prüfen, entscheiden, welche akzeptabel sind, und sich aktiv anmelden (Opt-in). Ebenso müssen AVSs ihre Slashing-Bedingungen formulieren und veröffentlichen, damit die Betreiber sie bewerten können. In der Praxis bedeutet dies, dass das Slashing-Risiko über Wochen und Monate hinweg ansteigen wird, während Betreiber und AVSs vom Legacy-Modell zu den Betreiber-Sets migrieren, anstatt über Nacht als einzelner Schadensradius zu erscheinen.

Der EIGEN-Token fügt einen separaten Mechanismus für „intersubjektive“ Fehler hinzu — Fehlverhalten, das on-chain nicht beweisbar ist, bei dem aber jeder vernünftige Beobachter einer Strafe zustimmen würde. Wenn eine Super-Mehrheit der EIGEN-Staker konspiriert, um einen AVS auf eine Weise anzugreifen, die durch einen Fork gelöst werden kann, können Herausforderer einen Slashing-Fork des Tokens erstellen. Dies erfolgt orthogonal zum ETH-Slashing in ELIP-002 und zielt auf eine andere Art von Versagen ab.

Insgesamt ist das Design auf eine Weise konservativ, die entscheidend ist. Die einzigartige Stake-Zuweisung isoliert den Schadensradius pro AVS, was direkt das am häufigsten genannte Restaking-Risiko adressiert: dass ein einzelner fehlerhafter AVS mit einem defekten Slashing-Schaltkreis über den gemeinsamen Betreiber-Stake unbeteiligte AVSs mit in den Abgrund reißen könnte. Dieser Fehlermodus ist nun strukturell schwerer auszulösen.

Die empirische Frage , die das Restaking bisher gemieden hat​

EigenLayer hält derzeit je nach Zählweise zwischen 15,2 Milliarden $und 19,7 Milliarden$ an restaked Assets und kontrolliert damit etwa 94 % des Restaking - Marktes . Mehr als 4,3 Millionen ETH sind delegiert . Das Protokoll sichert über 20 AVSs , wobei EigenDA , Hyperlane und Lagrange den Großteil der Gebühreneinnahmen generieren .

Diese Zahlen wurden in einer Zeit aufgebaut , in der Slashing noch theoretisch war . Die empirische Frage , welche die Aktivierung am 17. April nun erzwingt , ist einfach : Wie viel der Sicherheit , die diese AVSs " bereitgestellt " haben , war tatsächlich real ?

Betrachten wir die zwei Möglichkeiten .

Im ersten Szenario haben die führenden AVSs von Anfang an nach hohen Standards gearbeitet . Ihre Betreiber nutzen Infrastruktur auf Produktionsniveau , ihre Slashing - Spezifikationen erfassen echtes Fehlverhalten , und die Basis - Slashing - Rate nach der Aktivierung pendelt sich bei etwas ein , das deutlich über der nahezu bei Null liegenden Rate von Lido liegt — vielleicht 10 bis 100 Basispunkte jährlich . Dies spiegelt die Tatsache wider , dass die Sicherung eines DA - Layers oder einer Bridge eine schwierigere Aufgabe ist als die Validierung von Blöcken . Die Restaking - Renditen passen sich nach oben an , um dieses Risiko zu kompensieren , und die These , dass restaked ETH zusätzliche wirtschaftliche Sicherheit bietet , hat Bestand .

Im zweiten Szenario war vieles von dem , was zwei Jahre lang wie Sicherheit aussah , in Wirklichkeit nur ein Zufall aufgrund fehlender Durchsetzung . Die Betreiber haben Belohnungen für Dienste kassiert , deren Slashing - Spezifikationen nie an echtem Fehlverhalten getestet wurden . Sobald das Slashing aktiviert wird , passiert eines von drei Dingen : AVSs stellen fest , dass ihre eigenen Spezifikationen zu locker sind und echtes Fehlverhalten durchlassen ; sie stellen fest , dass ihre Spezifikationen zu streng sind und ehrliche Betreiber aufgrund von Grenzfällen ( Edge Cases ) bestrafen , die in der Testumgebung nie auftraten ; oder die Betreiber kommen angesichts der ersten echten Slashing - Ereignisse zu dem Schluss , dass die risikobereinigte Rendite schlechter ist als beim einfachen ETH - Staking , und ziehen ihr Kapital ab .

Der Grund , warum das zweite Szenario plausibel ist , liegt darin , dass bisher niemand durch Verluste diszipliniert wurde . AVSs , die als hochsicher erscheinen wollen , hatten keine Möglichkeit , dies zu beweisen , und AVSs , die nachlässig waren , hatten keine Möglichkeit , entlarvt zu werden . Auf einem Dashboard sehen beide identisch aus . Die Aktivierung des Slashings ist der erste Mechanismus , der die beiden Gruppen voneinander trennt .

Der entscheidende Vergleich ist hier Lido . Lido hat seit 2020 weniger als 0,01 % des gestakten ETH durch Slashing auf der Konsensschicht verloren . Das ist der Referenzwert für " passives Staking " , bei dem die einzige Aufgabe darin besteht , Attestierungsregeln zu befolgen , die über fünf Jahre hinweg durch echte Strafen in Höhe von Hunderten Millionen Dollar getestet wurden . Wenn die AVSs von EigenLayer tatsächlich schwierigere Arbeit leisten — den Betrieb von Oracles , Bridges , DA - Layern , Co - Prozessoren — sollten ihre Slashing - Raten höher sein als die von Lido , da schwierigere Arbeit mehr Fehlermöglichkeiten schafft . Wenn sich die Slashing - Raten nach der Aktivierung denen von Lido annähern , ist dies ein starker Beweis dafür , dass AVSs nicht die zusätzliche Sicherheit produziert haben , die ihre Gebühren implizieren .

Das LST - Übertragungsrisiko​

EigenLayer existiert nicht isoliert . Das größte LST im DeFi - Bereich ist stETH von Lido , und stETH ist eine der am weitesten verbreiteten Formen von Sicherheiten im Restaking - System . Betrachtet man dies im Zusammenhang mit den großen Kreditmärkten : Aave , Morpho und Spark halten zusammen Einlagen von über 30 Milliarden $ , wovon ein erheblicher Teil aus stETH oder wstETH besteht , die als Sicherheit für Stablecoin - Kredite dienen .

Die Kette der Risikoexposition sieht wie folgt aus : Ein stETH - Inhaber betreibt Restaking bei EigenLayer . Der EigenLayer - Betreiber , an den er delegiert , betreibt ein AVS , bei dem ein Slashing - Ereignis eintritt . Ein Teil der stETH - Deckung ist nun weniger wert , als sein ETH - Rückzahlungswert implizieren würde . Wenn das Slashing groß genug ist , um die Bindung ( Peg ) von stETH an ETH spürbar zu beeinflussen , erleiden gehebelte stETH - Positionen auf Aave und Morpho Liquidationsschäden . Liquidationen zwingen mehr stETH auf den Markt , was den Depeg vertieht und weitere Liquidationen auslöst . Die Rückkopplungsschleife , die das System im Mai 2022 — als stETH während des UST - Zusammenbruchs an Wert verlor — kurzzeitig bedrohte , hat nun einen neuen potenziellen Auslöser .

Mehrere strukturelle Faktoren machen dies weniger beängstigend , als es klingt . Die " Unique Stake Allocation " begrenzt den Schadensradius auf ein bestimmtes AVS , anstatt zuzulassen , dass sich ein Fehler ausbreitet . Die meisten AVSs haben Slashing - Schwellenwerte , die weit unter 100 % liegen , sodass selbst ein Ereignis maximaler Schwere nur einen Bruchteil des gefährdeten Einsatzes verbraucht . Abhebungen von der Beacon Chain haben die Rückzahlung von stETH wesentlich reibungsloser gemacht als im Jahr 2022 , was die Anfälligkeit für einen Depeg verringert . Zudem bedeutet die schrittweise Einführung ( Opt - in Ramp ) , dass die ersten Slashing - Ereignisse nur einen kleinen Bruchteil der gesamten restaked Basis treffen werden .

Doch das Risiko ist nicht null , und es ist höher , als die meisten Nutzer , die stETH als Sicherheit für " sichere Rendite " halten , verstehen . Jeder , der gehebeltes stETH auf Aave oder Morpho nutzt , hat nun eine neue exogene Variable in seiner Liquidationsrechnung . Kreditnehmer , die zuvor die Slashing - Bedingungen von AVSs nicht verfolgt haben , sind diesen nun indirekt ausgesetzt .

Wie die nächsten sechs Monate wahrscheinlich aussehen werden​

Die ehrliche Antwort ist , dass es niemand weiß . Aber die Konturen dessen , worauf man achten sollte , sind klar .

Das erste echte Slashing - Ereignis wird das Narrativ definieren . Wenn es ein großes AVS trifft und die Fehleranalyse einen Fehler in der Spezifikation anstelle von echtem Fehlverhalten des Betreibers offenbart , wird das Vertrauen in das Modell erschüttert , und Restaker werden beginnen , kritischere Fragen zur Qualität der Spezifikationen jedes AVS zu stellen . Wenn es echtes Fehlverhalten trifft und das System den schlechten Betreiber sauber bestraft , während ehrliche Betreiber unversehrt bleiben , erhält die Restaking - These einen massiven Glaubwürdigkeitsschub . Beide Ergebnisse sind möglich , und der Unterschied ist von enormer Bedeutung .

Die AVS - Gebühreneinnahmen werden sich stratifizieren . AVSs , die robuste Slashing - Spezifikationen und einwandfreies Betreiberverhalten nachweisen können , werden höhere Renditen erzielen , da Restaker sie korrekterweise als Anbieter echter Sicherheit einpreisen werden . AVSs , deren Spezifikationen nachlässig erscheinen , werden entweder nachbessern oder Betreiber an besser geführte Alternativen verlieren . Es ist zu erwarten , dass sich in den nächsten zwei Quartalen eine sichtbare Lücke zwischen den Top 3 und dem " Long Tail " auftun wird .

Die Betreiber werden konsolidieren . Der Betrieb von AVSs mit echtem Slashing - Risiko erfordert eine Infrastruktur und eine operative Disziplin , über die viele derzeitige Betreiber nicht verfügen . Es ist zu erwarten , dass ein erheblicher Teil der kleineren Betreiber aussteigt , anstatt das Risiko zu übernehmen . Der Betreibermarkt wird sich auf Unternehmen konzentrieren , die ihre Slashing - Anfälligkeit tatsächlich verteidigen können .

LRT - Emittenten werden explizit werden müssen . Liquid Restaking Tokens — die Wrapper - Produkte auf Basis von EigenLayer — waren in der Vergangenheit vage in Bezug darauf , welche AVSs durch den zugrunde liegenden Stake gesichert werden . Nach der Aktivierung wird diese Unklarheit zu einer Belastung . Es ist zu erwarten , dass LRT - Emittenten entweder Transparenz über die AVS - Allokation schaffen oder Marktanteile an diejenigen verlieren , die dies tun .

Die Aktivierung ist keine Krise . Es ist der Moment , in dem Restaking aufhört , ein Narrativ zu sein , und beginnt , ein Produkt mit einem echten Risikomodell zu sein . Zum ersten Mal seit 2023 wird die Zinskurve für restaked ETH gezwungen sein , das widerzuspiegeln , was tatsächlich innerhalb der AVSs passiert , und nicht das , was Restaker sich vorstellen . Das ist ein gesunder Übergang , und die Protokolle , die die nötige Arbeit geleistet haben , werden davon profitieren . Diejenigen , die sich ausgeruht haben , werden es nicht .

BlockEden.xyz bietet RPC - und Indexierungs - Infrastruktur auf Enterprise - Niveau für Ethereum und sein Restaking - Ökosystem . Wenn Sie AVSs oder LRTs entwickeln oder betreiben oder Monitoring - Tools entwickeln , die einen Zugriff mit geringer Latenz auf den EigenLayer - Status benötigen , erkunden Sie unseren API - Marktplatz , um auf einer Infrastruktur aufzubauen , die für die Ära des produktiven Slashings konzipiert ist .

Quellen​

• EigenLayer Mainnet Slashing: Leitfaden für institutionelle Staker
• Einführung in Slashing auf EigenLayer: AVS-Edition
• EigenLayer Slashing geht live — Wie sollten sich AVSs, Betreiber und Restaker vorbereiten?
• ELIP-002: Slashing über Unique Stake & Operator Sets (EigenLayer Forum)
• Strategien und Größenordnungen — EigenCloud-Dokumentation
• EigenLayer überschreitet 18 Mrd. $ an restaked ETH (BlockEden.xyz)
• EigenLayers Restaking-Wirtschaft erreicht 25 Mrd. $ TVL — Too Big to Fail?
• Aufklärung eines kuriosen Sonderfalls in der Slashing-Buchhaltung von EigenLayer (Sigma Prime)
• Restaking 2026: Ertragsmaximierung mit EigenLayer & Jito
• EigenLayers TVL überschreitet 15 Milliarden $ (The Block)

Seit mehr als einem Jahrzehnt bepreist Ethereum seine wichtigste Ressource auf die gleiche Weise, wie ein Fischmarkt den Thunfisch um 4 Uhr morgens bepreist: Wer in der allerletzten Sekunde am lautesten schreit, gewinnt. Alle zwölf Sekunden öffnet und schließt sich eine neue Auktion, ohne die Möglichkeit, einen Preis am Vortag zu sichern, sich gegen eine Spitze abzusichern oder für einen Validator zu wissen, wie die Einnahmen am nächsten Dienstag aussehen könnten.

Das änderte sich am 15. April 2026. ETHGas und ether.fi schlossen eine dreijährige Handelsvereinbarung über 3 Milliarden US-Dollar ab, die den ersten ernsthaften Terminmarkt für Ethereum-Blockspace einführt. Ether.fi, das größte Liquid Staking-Protokoll neben Lido mit 2,8 Millionen verwalteten ETH, stellt rund 40 % seiner Bestände für den High Performance Staking-Service von ETHGas zur Verfügung. Im Gegenzug erhält ETHGas die Validator-Tiefe, die es benötigt, um etwas zu verkaufen, das Ethereum noch nie hatte: einen garantierten, vorab bepreisten Platz in einem Block, der noch nicht gebaut wurde.

Es klingt nach Infrastruktur. Es ist Infrastruktur. Aber das waren auch die ersten Erdgasterminkontrakte im Jahr 1990, und diese veränderten in der Folge die Art und Weise, wie jede Fluggesellschaft, jeder Versorger und jeder industrielle Käufer auf der Welt Geschäfte macht.

Restaking erklärt: Im Proof-of-Stake-Modell von Ethereum staken Validatoren normalerweise ETH, um das Netzwerk zu sichern und Belohnungen zu verdienen, wobei das Risiko des Slashing besteht, wenn sie sich falsch verhalten. Restaking ermöglicht es, dieselbe gestakte ETH (oder ihre Liquid Staking Derivate) wiederzuverwenden, um zusätzliche Protokolle oder Dienste zu sichern. EigenLayer führte Restaking über Smart Contracts ein, die es ETH-Stakern ermöglichen, sich anzumelden, um ihre Sicherheit auf neue Systeme auszudehnen und dafür zusätzliche Rendite zu erhalten. In der Praxis kann sich ein Ethereum-Validator bei EigenLayer registrieren und dessen Verträgen die Erlaubnis erteilen, zusätzliche Slashing-Bedingungen zu verhängen, die von externen Protokollen festgelegt werden. Wenn der Validator bei einem der abonnierten Dienste böswillig handelt, können die EigenLayer-Verträge seine gestakte ETH slashen, genau wie Ethereum es bei Konsensverletzungen tun würde. Dieser Mechanismus verwandelt die robuste Staking-Sicherheit von Ethereum effektiv in ein komponierbares „Security-as-a-Service“: Entwickler können die wirtschaftliche Sicherheit von Ethereum ausleihen, um neue Projekte zu starten, anstatt ihr eigenes Validatoren-Netzwerk von Grund auf neu aufzubauen. Durch die Nutzung der bereits über 31 Millionen ETH, die Ethereum sichern, schafft EigenLayers Restaking einen „gepoolten Sicherheits“-Marktplatz, auf dem mehrere Dienste dieselbe vertrauenswürdige Kapitalbasis teilen.

EigenLayers Ansatz: EigenLayer ist als eine Reihe von Ethereum-Smart-Contracts implementiert, die diesen Restaking-Prozess koordinieren. Validatoren (oder ETH-Halter), die Restaking betreiben möchten, zahlen entweder ihre Liquid Staking Tokens ein oder leiten im Falle von nativen Stakern ihre Auszahlungsnachweise an einen von EigenLayer verwalteten Vertrag (oft als EigenPod bezeichnet) um. Dies stellt sicher, dass EigenLayer das Slashing durch Sperren oder Verbrennen der zugrunde liegenden ETH durchsetzen kann, falls erforderlich. Restaker behalten stets das Eigentum an ihrer ETH (auszahlbar nach einer Ausstiegs-/Treuhandperiode), aber sie stimmen neuen Slashing-Regeln zusätzlich zu denen von Ethereum zu. Im Gegenzug qualifizieren sie sich für zusätzliche Restaking-Belohnungen, die von den Diensten gezahlt werden, die sie sichern. Das Endergebnis ist eine modulare Sicherheitsschicht: Ethereums Validatoren-Set und Stake werden an externe Protokolle „vermietet“. Wie Sreeram Kannan, der Gründer von EigenLayer, es ausdrückt, entsteht dadurch eine „Verifizierbare Cloud“ für Web3 – analog dazu, wie AWS Computing-Dienste anbietet, bietet EigenLayer Entwicklern Sicherheit als Dienstleistung an. Die frühe Akzeptanz war stark: Bis Mitte 2024 wurden über 4,9 Millionen ETH (ca. 15 Mrd. US-Dollar) in EigenLayer gerestaked, was die Nachfrage von Stakern nach maximaler Rendite und von neuen Protokollen nach einem Bootstrapping mit minimalem Overhead zeigt. Zusammenfassend lässt sich sagen, dass Restaking auf Ethereum bestehendes Vertrauen (gestakte ETH) umfunktioniert, um neue Anwendungen zu sichern, und EigenLayer die Infrastruktur bereitstellt, um diesen Prozess komponierbar und permissionless zu gestalten.

Designmuster von aktiv validierten Diensten (AVSs)​

Was sind AVSs? Actively Validated Services (AVSs) beziehen sich auf jeden dezentralen Dienst oder jedes Netzwerk, das eigene Validatoren und Konsensregeln benötigt, aber die Sicherheit an eine Restaking-Plattform wie EigenLayer auslagern kann. Mit anderen Worten, ein AVS ist ein externes Protokoll (außerhalb der Ethereum L1), das Ethereums Validatoren anheuert, um Verifizierungsarbeiten durchzuführen. Beispiele sind Sidechains oder Rollups, Datenverfügbarkeitsschichten, Orakelnetzwerke, Brücken, Shared Sequencer, dezentrale Compute-Module und mehr. Jedes AVS definiert eine einzigartige verteilte Validierungsaufgabe – zum Beispiel könnte ein Orakel das Signieren von Preis-Feeds erfordern, während eine Datenverfügbarkeitskette (wie EigenDA) das Speichern und Bestätigen von Daten-Blobs erfordert. Diese Dienste betreiben ihre eigene Software und möglicherweise ihren eigenen Konsens unter den teilnehmenden Betreibern, aber sie verlassen sich auf gemeinsame Sicherheit: Der wirtschaftliche Einsatz, der sie absichert, wird durch gerestakte ETH (oder andere Assets) von Ethereum-Validatoren bereitgestellt, anstatt durch einen nativen Token für jedes neue Netzwerk.

Architektur und Rollen: EigenLayers Architektur trennt die Rollen in diesem Shared-Security-Modell sauber:

• Restaker – ETH-Staker (oder LST-Halter), die sich anmelden, um AVSs zu sichern. Sie zahlen in EigenLayer-Verträge ein und erweitern ihr gestaktes Kapital als Sicherheit für mehrere Dienste. Restaker können wählen, welche AVSs sie direkt oder über Delegation unterstützen möchten, und Belohnungen von diesen Diensten verdienen. Entscheidend ist, dass sie das Slashing-Risiko tragen, wenn ein unterstütztes AVS Fehlverhalten meldet.

• Operatoren – Node-Operatoren, die tatsächlich die Off-Chain-Client-Software für jedes AVS betreiben. Sie sind analog zu Minern/Validatoren für das Netzwerk des AVS. In EigenLayer muss sich ein Operator registrieren und genehmigt werden (anfänglich auf einer Whitelist stehen), um beizutreten, und kann sich dann anmelden, um bestimmte AVSs zu bedienen. Restaker delegieren ihren Stake an Operatoren (wenn sie nicht selbst Nodes betreiben), sodass Operatoren den Stake von potenziell vielen Restakern aggregieren. Jeder Operator unterliegt den Slashing-Bedingungen jedes AVS, das er unterstützt, und er verdient Gebühren oder Belohnungen für seinen Dienst. Dies schafft einen Marktplatz von Operatoren, die um Leistung und Vertrauenswürdigkeit konkurrieren, da AVSs kompetente Operatoren bevorzugen und Restaker diejenigen bevorzugen, die Belohnungen maximieren, ohne Slashing zu riskieren.

• AVS (Actively Validated Service) – Das externe Protokoll oder der Dienst selbst, der typischerweise aus zwei Komponenten besteht: (1) einem Off-Chain-Binary oder Client, den Operatoren ausführen, um den Dienst zu erbringen (z. B. eine Sidechain-Node-Software), und (2) einem On-Chain-AVS-Vertrag, der auf Ethereum bereitgestellt wird und mit EigenLayer interagiert. Der Ethereum-Vertrag des AVS kodiert die Regeln für das Slashing und die Belohnungsverteilung dieses Dienstes. Zum Beispiel könnte er definieren, dass, wenn zwei widersprüchliche Signaturen eingereicht werden (Beweis der Äquivokation durch einen Operator), ein Slashing von X ETH auf den Stake dieses Operators ausgeführt wird. Der AVS-Vertrag greift auf EigenLayers Slashing-Manager zu, um gerestakte ETH bei Verstößen tatsächlich zu bestrafen. Somit kann jedes AVS benutzerdefinierte Validierungslogik und Fehlerbedingungen haben, während es sich auf EigenLayer verlässt, um wirtschaftliche Strafen unter Verwendung des gemeinsamen Stakes durchzusetzen. Dieses Design ermöglicht es AVS-Entwicklern, neue Vertrauensmodelle (sogar neue Konsensmechanismen oder kryptografische Dienste) zu innovieren, ohne einen Bonding-/Slashing-Token für die Sicherheit neu erfinden zu müssen.

• AVS-Konsumenten/Nutzer – Schließlich die Endnutzer oder andere Protokolle, die die Ausgabe des AVS konsumieren. Zum Beispiel könnte eine dApp ein Orakel-AVS für Preisdaten verwenden oder ein Rollup Daten an ein Datenverfügbarkeits-AVS senden. Konsumenten zahlen Gebühren an das AVS (die oft die Belohnungen finanzieren, die Restaker/Operatoren verdienen) und verlassen sich auf dessen Korrektheit, die durch die wirtschaftliche Sicherheit gewährleistet wird, die das AVS von Ethereum geleast hat.

Nutzung gemeinsamer Sicherheit: Das Schöne an diesem Modell ist, dass selbst ein brandneuer Dienst mit Sicherheitsgarantien auf Ethereum-Niveau starten kann. Anstatt eine neue Gruppe von Validatoren zu rekrutieren und zu incentivieren, greift ein AVS vom ersten Tag an auf ein erfahrenes, wirtschaftlich gebundenes Validatoren-Set zurück. Kleinere Ketten oder Module, die allein unsicher wären, werden sicher, indem sie auf Ethereum aufbauen. Diese gepoolte Sicherheit erhöht die Kosten für einen Angriff auf ein einzelnes AVS erheblich – ein Angreifer müsste große Mengen ETH (oder andere auf der Whitelist stehende Sicherheiten) erwerben und staken und dann riskieren, diese durch Slashing zu verlieren. Da viele Dienste denselben Pool an gerestakter ETH teilen, bilden sie effektiv einen gemeinsamen Sicherheits-Schirm: Das kombinierte wirtschaftliche Gewicht des Stakes schreckt Angriffe auf jeden einzelnen von ihnen ab. Aus Entwicklersicht modularisiert dies die Konsensschicht – Sie konzentrieren sich auf die Funktionalität Ihres Dienstes, während EigenLayer die Sicherung mit einem bestehenden Validatoren-Set übernimmt. AVSs können daher sehr vielfältig sein. Einige sind allgemeine „horizontale“ Dienste, die viele dApps nutzen könnten (z. B. ein generischer dezentraler Sequencer oder ein Off-Chain-Compute-Netzwerk), während andere „vertikal“ oder anwendungsspezifisch sind (zugeschnitten auf eine Nische wie eine bestimmte Brücke oder ein DeFi-Orakel). Frühe Beispiele für AVSs auf EigenLayer umfassen Datenverfügbarkeit (z. B. EigenDA), Shared Sequencing für Rollups (z. B. Espresso, Radius), Orakelnetzwerke (z. B. eOracle), Cross-Chain-Brücken (z. B. Polymer, Hyperlane), Off-Chain-Berechnungen (z. B. Lagrange für ZK-Proofs) und mehr. Alle diese nutzen dieselbe Ethereum-Vertrauensbasis. Zusammenfassend ist ein AVS im Wesentlichen ein steckbares Modul, das Vertrauen an Ethereum auslagert: Es definiert, was Validatoren tun müssen und was einen slashbaren Fehler darstellt, und EigenLayer setzt diese Regeln auf einem Pool von ETH durch, der global zur Sicherung vieler solcher Module verwendet wird.

Anreizmechanismen für Restaker, Operatoren und Entwickler​

Ein robustes Anreizdesign ist entscheidend, um alle Parteien in einem Restaking-Ökosystem aufeinander abzustimmen. EigenLayer und ähnliche Plattformen schaffen eine „Win-Win-Win“-Situation, indem sie Stakern und Operatoren neue Einnahmen bieten und gleichzeitig die Kosten für aufstrebende Protokolle senken. Lassen Sie uns die Anreize nach Rollen aufschlüsseln:

• Anreize für Restaker: Restaker werden hauptsächlich durch Rendite motiviert. Durch die Anmeldung bei EigenLayer kann ein ETH-Staker zusätzliche Belohnungen zusätzlich zu seiner Standard-Ethereum-Staking-Rendite verdienen. Zum Beispiel verdient ein Validator mit 32 ETH, die in Ethereums Beacon Chain gestakt sind, weiterhin die Basis-APR von ~4-5%, aber wenn er über EigenLayer restaked, kann er gleichzeitig Gebühren oder Token-Belohnungen von mehreren AVSs verdienen, die er mitsichert. Dieses „Double Dipping“ erhöht die potenziellen Renditen für Validatoren dramatisch. Beim frühen Rollout von EigenLayer erhielten Restaker Anreizpunkte, die in EIGEN-Token-Airdrops umgewandelt wurden (zum Bootstrapping); später wurde ein kontinuierlicher Belohnungsmechanismus (Programmatic Incentives) eingeführt, der Millionen von EIGEN-Tokens als Liquiditäts-Mining an Restaker verteilte. Über Token-Anreize hinaus profitieren Restaker von der Diversifizierung der Einnahmen – anstatt sich ausschließlich auf Ethereum-Block-Belohnungen zu verlassen, können sie in verschiedenen AVS-Tokens oder Gebühren verdienen. Natürlich gehen diese höheren Belohnungen mit einem höheren Risiko (größere Slashing-Exposition) einher, sodass rationale Restaker nur AVSs wählen werden, von denen sie glauben, dass sie gut verwaltet werden. Dies schafft eine marktwirtschaftliche Kontrolle: AVSs müssen attraktive genug Belohnungen bieten, um das Risiko zu kompensieren, sonst werden Restaker sie meiden. In der Praxis delegieren viele Restaker an professionelle Operatoren, sodass sie dem Operator möglicherweise auch eine Provision aus ihren Belohnungen zahlen. Dennoch können Restaker erheblich profitieren, indem sie die ansonsten ungenutzte Sicherheitskapazität ihrer gestakten ETH monetarisieren. (Bemerkenswert ist, dass EigenLayer berichtet, dass über 88% aller verteilten EIGEN direkt wieder gestakt/delegiert wurden – was darauf hindeutet, dass Restaker ihre Positionen eifrig aufstocken.)

• Anreize für Operatoren: Operatoren in EigenLayer sind die Dienstleister, die die Hauptarbeit des Betriebs von Nodes für jedes AVS leisten. Ihr Anreiz ist der Gebührenerlös oder der Belohnungsanteil, der von diesen AVSs gezahlt wird. Typischerweise zahlt ein AVS Belohnungen (in ETH, Stablecoins oder seinem eigenen Token) an alle Validatoren aus, die es sichern; Operatoren erhalten diese Belohnungen im Namen des Stakes, den sie hosten, und nehmen oft einen Anteil (wie eine Provision) für die Bereitstellung der Infrastruktur. EigenLayer ermöglicht es Restakern, an Operatoren zu delegieren, sodass Operatoren darum konkurrieren, so viel gerestakte ETH wie möglich anzuziehen – mehr delegierter Stake bedeutet mehr Aufgaben, die sie erledigen können, und mehr verdiente Gebühren. Diese Dynamik ermutigt Operatoren, hochzuverlässig zu sein und sich auf AVSs zu spezialisieren, die sie effizient betreiben können (um Slashing zu vermeiden und die Betriebszeit zu maximieren). Ein Operator mit gutem Ruf kann eine größere Delegation und somit höhere Gesamtbelohnungen sichern. Wichtig ist, dass Operatoren Slashing-Strafen für Fehlverhalten erleiden, genau wie Restaker (da der von ihnen getragene Stake geslasht werden kann), was ihr Verhalten mit ehrlicher Ausführung in Einklang bringt. EigenLayers Design schafft effektiv einen offenen Marktplatz für Validatorendienste: AVS-Teams können Operatoren „anheuern“, indem sie Belohnungen anbieten, und Operatoren werden AVSs wählen, die im Verhältnis zum Risiko profitabel sind. Zum Beispiel könnte sich ein Operator auf den Betrieb eines Orakel-AVS konzentrieren, wenn es hohe Gebühren hat, während ein anderer ein Datenlayer-AVS betreiben könnte, das viel Bandbreite erfordert, aber gut bezahlt wird. Im Laufe der Zeit erwarten wir ein Freimarktgleichgewicht, in dem Operatoren die beste Mischung von AVSs wählen und eine angemessene Gebührenaufteilung mit ihren Delegatoren festlegen. Dies steht im Gegensatz zum traditionellen Single-Chain-Staking, bei dem Validatoren feste Aufgaben haben – hier können sie über Dienste hinweg Multitasking betreiben, um Einnahmen zu stapeln. Der Anreiz für Operatoren besteht also darin, ihre Einnahmen pro Einheit gestakter Sicherheit zu maximieren, ohne bis zum Slashing zu überlasten. Es ist ein heikles Gleichgewicht, das die Professionalisierung und vielleicht sogar Versicherungs- oder Absicherungslösungen vorantreiben sollte (Operatoren könnten sich gegen Slashing versichern, um ihre Delegatoren zu schützen usw.).

• Anreize für AVS-Entwickler: Protokollentwickler (die Teams, die neue AVSs oder Chains aufbauen) haben wohl am meisten von Restakings „Sicherheits-Outsourcing“-Modell zu gewinnen. Ihr Hauptanreiz sind Kosten- und Zeiteinsparungen: Sie müssen keinen neuen Token mit hoher Inflation einführen oder Tausende unabhängiger Validatoren überzeugen, ihr Netzwerk von Grund auf zu sichern. Das Bootstrapping eines PoS-Netzwerks erfordert normalerweise, dass frühen Validatoren große Token-Belohnungen gegeben werden (was das Angebot verwässert) und kann immer noch zu schwacher Sicherheit führen, wenn die Marktkapitalisierung des Tokens niedrig ist. Mit Shared Security kann ein neues AVS mit der wirtschaftlichen Sicherheit von über 200 Mrd. US-Dollar von Ethereum online gehen, was Angriffe sofort wirtschaftlich unrentabel macht. Dies ist ein großer Anziehungspunkt für Infrastrukturprojekte wie Brücken oder Orakel, die starke Sicherheitsgarantien benötigen. Darüber hinaus können sich Entwickler auf ihre Anwendungslogik konzentrieren und sich für das Validatoren-Set-Management auf EigenLayer (oder Karak usw.) verlassen, was die Komplexität erheblich reduziert. Wirtschaftlich gesehen muss das AVS zwar für Sicherheit bezahlen, kann dies aber oft auf eine nachhaltigere Weise tun. Anstatt einer riesigen Inflation könnte es Protokollgebühren umleiten oder ein bescheidenes natives Token-Stipendium anbieten. Zum Beispiel könnte ein Brücken-AVS Benutzern Gebühren in ETH berechnen und diese verwenden, um Restaker zu bezahlen, wodurch Sicherheit erreicht wird, ohne ungedeckte Token zu drucken. Eine aktuelle Analyse stellt fest, dass die Eliminierung der Notwendigkeit von „stark verwässernden Belohnungsmechanismen“ eine Schlüsselmotivation hinter Karaks universellem Restaking-Design war. Im Wesentlichen ermöglicht Shared Security „Bootstrapping mit kleinem Budget“. Zusätzlich kann, wenn das AVS einen Token besitzt, dieser eher für Governance oder Utility verwendet werden, anstatt rein für Sicherheitsausgaben. Entwickler werden auch durch Netzwerkeffekte incentiviert: Durch das Anschließen an einen Restaking-Hub kann ihr Dienst leichter mit anderen AVSs (gemeinsame Nutzer und Operatoren) interoperieren und Zugang zur großen Gemeinschaft der Ethereum-Staker erhalten. Die Kehrseite ist, dass AVS-Teams überzeugende Belohnungssysteme entwerfen müssen, um Restaker und Operatoren auf dem offenen Markt anzuziehen. Dies bedeutet oft, anfänglich großzügige Renditen oder Token-Anreize anzubieten, um die Teilnahme anzukurbeln – ähnlich wie beim Liquiditäts-Mining in DeFi. Zum Beispiel verteilte EigenLayer selbst den EIGEN-Token breit an frühe Staker/Operatoren, um die Teilnahme zu fördern. Ähnliche Muster sehen wir bei neuen Restaking-Plattformen (z. B. Karaks XP-Kampagne für zukünftige $KAR-Tokens). Zusammenfassend tauschen AVS-Entwickler einen Teil der Belohnungen an Ethereum-Staker ein, um das Dead-Start-Problem der Sicherung eines neuen Netzwerks zu vermeiden. Der strategische Gewinn ist eine schnellere Markteinführung und höhere Sicherheit vom ersten Tag an, was insbesondere für kritische Infrastrukturen wie Cross-Chain-Brücken oder Finanzdienstleistungen, die Vertrauen erfordern, ein entscheidender Vorteil sein kann.

Regulatorische Risiken und Governance-Bedenken​

Regulatorische Unsicherheit: Das neuartige Restaking-Modell bewegt sich in einem rechtlichen Graubereich und wirft mehrere regulatorische Fragen auf. Eine Sorge ist, ob das Angebot von „Security-as-a-Service“ von Regulierungsbehörden als nicht registriertes Wertpapierangebot oder als eine Form von Hochrisiko-Anlageprodukt angesehen werden könnte. Zum Beispiel hat die Verteilung des EIGEN-Tokens über einen Staker-Airdrop und laufende Belohnungen die Einhaltung von Wertpapiergesetzen in den Fokus gerückt. Projekte müssen darauf achten, dass ihre Tokens oder Belohnungssysteme keine Wertpapierdefinitionen auslösen (z. B. den Howey-Test in den USA). Zusätzlich aggregieren und reallokieren Restaking-Protokolle Stakes über Netzwerke hinweg, was als eine Form von gepoolter Investition oder sogar als bankähnliche Aktivität angesehen werden könnte, wenn es nicht ordnungsgemäß dezentralisiert ist. Das Team von EigenLayer erkennt das regulatorische Risiko an und weist darauf hin, dass sich ändernde Gesetze die Machbarkeit von Restaking beeinträchtigen könnten und dass EigenLayer „in einigen Regionen als illegale Finanzaktivität eingestuft werden könnte“. Dies bedeutet, dass Regulierungsbehörden feststellen könnten, dass die Übergabe der Slashing-Kontrolle an Drittanbieter (AVSs) Finanz- oder Verbraucherschutzvorschriften verletzt, insbesondere wenn Kleinanleger beteiligt sind. Ein weiterer Aspekt sind Sanktionen/AML: Restaking verschiebt Stake in Verträge, die dann andere Ketten validieren – wenn eine dieser Ketten illegale Transaktionen verarbeitet oder sanktioniert ist, könnten Ethereum-Validatoren unbeabsichtigt gegen Compliance-Vorschriften verstoßen? Dies ist noch unerprobt. Bisher gibt es keine klaren Vorschriften, die speziell auf Restaking abzielen, aber die sich entwickelnde Haltung zum Krypto-Staking (z. B. die Maßnahmen der SEC gegen zentralisierte Staking-Dienste) deutet darauf hin, dass Restaking bei seinem Wachstum genauer unter die Lupe genommen werden könnte. Projekte wie EigenLayer haben einen vorsichtigen Ansatz gewählt – zum Beispiel war der EIGEN-Token bei der Einführung zunächst nicht übertragbar, um spekulativen Handel und potenzielle regulatorische Probleme zu vermeiden. Dennoch arbeiten Restaking-Plattformen, bis Rahmenbedingungen definiert sind, mit dem Risiko, dass neue Gesetze oder Durchsetzungsmaßnahmen Einschränkungen auferlegen könnten (wie die Anforderung einer Teilnehmerakkreditierung, Offenlegungen oder sogar das Verbot bestimmter Arten von Cross-Chain-Staking).

Governance- und Konsensbedenken: Restaking führt komplexe Governance-Herausforderungen sowohl auf Protokollebene als auch für das breitere Ethereum-Ökosystem ein:

• Überlastung des sozialen Konsenses von Ethereum: Eine von Vitalik Buterin geäußerte große Sorge ist, dass eine erweiterte Nutzung des Ethereum-Validatoren-Sets Ethereum selbst unbeabsichtigt in externe Streitigkeiten verwickeln könnte. Vitaliks Mahnung: „Die doppelte Nutzung von durch Validatoren gestakter ETH ist, obwohl sie einige Risiken birgt, grundsätzlich in Ordnung, aber der Versuch, Ethereums sozialen Konsens für die eigenen Zwecke Ihrer Anwendung zu ‚rekrutieren‘, ist es nicht.“. Einfach ausgedrückt ist es akzeptabel, wenn Ethereum-Validatoren auch, sagen wir, ein Orakelnetzwerk validieren und dort individuell für Fehlverhalten geslasht werden (ohne Auswirkung auf Ethereums Konsens). Gefährlich wird es, wenn ein externes Protokoll erwartet, dass die Ethereum-Community oder das Kernprotokoll eingreift, um ein Problem zu lösen (zum Beispiel, um Validatoren, die sich auf dem externen Dienst schlecht verhalten haben, herauszuforken). EigenLayers Design versucht bewusst, dieses Szenario zu vermeiden, indem es slashbare Fehler objektiv und isoliert hält. Slashing-Bedingungen sind kryptografisch (z. B. Double-Signing-Proof) und erfordern keine Intervention der Ethereum-Governance – somit ist jede Bestrafung auf den EigenLayer-Vertrag beschränkt und beinhaltet keine Änderung des Zustands oder der Regeln von Ethereum. In Fällen subjektiver Fehler (wo menschliches Urteilsvermögen erforderlich ist, z. B. bei einem Orakel-Preisstreit) plant EigenLayer, seine eigene Governance zu nutzen (z. B. eine EIGEN-Token-Abstimmung oder einen Rat), anstatt die soziale Schicht von Ethereum zu belasten. Diese Trennung ist entscheidend, um Ethereums Neutralität zu wahren. Wenn das Restaking jedoch wächst, besteht ein systemisches Risiko, dass bei einem größeren Vorfall (wie einem Fehler, der ein massives Slashing eines großen Teils der Validatoren verursacht) die Ethereum-Community unter Druck geraten könnte, zu reagieren (zum Beispiel durch die Rückgängigmachung von Slashes). Das würde Ethereum in das Schicksal externer AVSs verwickeln – genau das, wovor Vitalik warnt. Das Risiko des sozialen Konsenses betrifft somit hauptsächlich extreme „Black Swan“-Fälle, aber es unterstreicht die Bedeutung, Ethereums Kern minimal und unbeteiligt an der Restaking-Governance zu halten.

• Slashing-Kaskaden und Ethereum-Sicherheit: In diesem Zusammenhang besteht die Sorge, dass Slashing-Ereignisse im Restaking kaskadieren und Ethereum kompromittieren könnten. Wenn ein sehr beliebtes AVS (mit vielen Validatoren) einen katastrophalen Fehler erleiden würde, der zu einem massiven Slashing führt, könnten Tausende von ETH-Validatoren ihren Stake verlieren oder gezwungen werden, auszutreten. Im schlimmsten Fall könnte, wenn genügend Stake geslasht wird, Ethereums eigenes Validatoren-Set schrumpfen oder sich schnell zentralisieren. Stellen Sie sich zum Beispiel vor, ein Top-EigenLayer-Operator, der 10% aller Validatoren betreibt, wird auf einem AVS geslasht – diese Validatoren könnten nach dem Verlust von Geldern offline gehen, was Ethereums Sicherheit reduziert. Chorus One (ein Staking-Dienst) analysierte EigenLayer und stellte fest, dass dieses Kaskadenrisiko verschärft wird, wenn der Restaking-Markt dazu führt, dass nur wenige große Operatoren dominieren. Die gute Nachricht ist, dass Slashing auf Ethereum historisch selten und meist kleinräumig ist. EigenLayer begrenzte anfangs auch die Höhe des Stakes und deaktivierte das Slashing, solange das System neu war. Bis April 2025 aktivierte EigenLayer das Slashing im Mainnet mit sorgfältiger Überwachung. Um unbeabsichtigte Slashes (z. B. aufgrund von Bugs) weiter zu mindern, führte EigenLayer „Slashing-Veto-Komitees“ ein – im Wesentlichen eine Multi-Sig von Experten, die ein Slashing aufheben können, wenn es sich um einen Fehler oder einen Angriff auf das Protokoll handelt. Dies ist eine vorübergehende zentralisierende Maßnahme, aber sie begegnet dem Risiko, dass ein fehlerhafter AVS-Smart-Contract Chaos anrichtet. Mit der Zeit könnten solche Komitees durch eine dezentralere Governance oder Sicherheitsvorkehrungen ersetzt werden.

• Zentralisierung von Restaking und Governance: Ein zentrales Governance-Anliegen ist, wer das Restaking-Protokoll und seine Parameter kontrolliert. In den frühen Phasen von EigenLayer wurden Upgrades und kritische Entscheidungen durch eine Multisig des Teams und der engen Community kontrolliert (z. B. eine 9-von-13-Multisig). Dies ist praktisch für die Sicherheit der schnellen Entwicklung, birgt aber ein Zentralisierungsrisiko – diese Schlüsselhalter könnten kolludieren oder kompromittiert werden, um Regeln böswillig zu ändern (zum Beispiel, um gestakte Gelder zu stehlen). In Anerkennung dessen etablierte EigenLayer Ende 2024 einen formelleren EigenGov-Rahmen, der einen Protokollrat von Experten und einen Community-Governance-Prozess für Änderungen einführte. Der Rat kontrolliert nun Upgrades über eine 3-von-5-Multisig, mit Community-Aufsicht. Im Laufe der Zeit ist beabsichtigt, sich zu einer Token-Halter-Governance oder einem vollständig dezentralisierten Modell zu entwickeln. Dennoch sind in jedem Restaking-System Governance-Entscheidungen (wie welche neue Sicherheit unterstützt werden soll, welches AVS mit offiziellem Status „gesegnet“ werden soll, wie Slashing-Streitigkeiten gelöst werden) mit hohen Einsätzen verbunden. Es besteht ein potenzieller Interessenkonflikt: Große Staking-Anbieter (wie Lido oder Börsen) könnten die Governance beeinflussen, um ihre Operatoren oder Assets zu bevorzugen. Tatsächlich entsteht Wettbewerb – z. B. unterstützen Lidos Gründer Symbiotic, eine Multi-Asset-Restaking-Plattform – und man kann sich Governance-Kriege vorstellen, wenn zum Beispiel ein Vorschlag entsteht, ein bestimmtes AVS, das als riskant angesehen wird, zu verbieten. Die Restaking-Schicht selbst benötigt eine robuste Governance, um solche Probleme transparent zu verwalten.

• Validatoren-Zentralisierung: Auf der operativen Seite besteht die Sorge, dass AVSs bevorzugt große Operatoren wählen werden, was zu einer Zentralisierung bei der Validierung der meisten gerestakten Dienste führt. Wenn aus Effizienzgründen viele AVS-Teams alle eine Handvoll professioneller Validatoren (z. B. große Staking-Unternehmen) auswählen, um sie zu bedienen, erhalten diese Entitäten übermäßige Macht und einen größeren Anteil an Belohnungen. Sie könnten dann andere unterbieten, indem sie bessere Konditionen anbieten (dank Skaleneffekten), was potenziell zu einem Oligopol führen könnte. Dies spiegelt Bedenken im Vanilla-Ethereum-Staking wider (z. B. Lidos Dominanz). Restaking könnte dies verstärken, da Operatoren, die mehrere AVSs betreiben, mehr Einnahmequellen haben. Dies ist sowohl ein wirtschaftliches als auch ein Governance-Anliegen – es könnte von der Community auferlegte Grenzen oder Anreize erfordern, um die Dezentralisierung zu fördern (zum Beispiel könnte EigenLayer begrenzen, wie viel Stake ein Operator kontrollieren kann, oder AVSs könnten verpflichtet werden, ihre Zuweisungen zu verteilen). Ohne Kontrollen könnte die „Reichen werden reicher“-Dynamik dazu führen, dass einige wenige Node-Operatoren effektiv große Teile des Ethereum-Validatoren-Sets über viele Dienste hinweg kontrollieren, was für die Dezentralisierung ungesund ist. Die Community diskutiert solche Probleme aktiv, und einige haben vorgeschlagen, dass Restaking-Protokolle Mechanismen enthalten sollten, um kleinere Operatoren zu bevorzugen oder Vielfalt zu erzwingen (vielleicht über die Delegationsstrategie oder durch soziale Koordination durch Staker-Communities).

Zusammenfassend lässt sich sagen, dass Restaking zwar enorme Innovationen freisetzt, aber auch neue Risikovektoren einführt. Regulierungsbehörden prüfen, ob dies unregulierte Renditeprodukte darstellt oder systemische Gefahren birgt. Ethereums Führung betont die Wichtigkeit, die Governance der Basisschicht nicht in diese neuen Nutzungen zu verwickeln. Die EigenLayer-Community und andere haben mit sorgfältigem Design (nur objektives Slashing, zweistufige Token für verschiedene Fehlertypen, Überprüfung von AVSs usw.) und vorübergehender zentraler Kontrolle reagiert, um Unfälle zu verhindern. Laufende Governance-Herausforderungen umfassen die Dezentralisierung der Kontrolle ohne Einbußen bei der Sicherheit, die Gewährleistung offener Teilnahme statt Konzentration und die Schaffung klarer rechtlicher Rahmenbedingungen. Wenn diese Restaking-Netzwerke reifen, sind verbesserte Governance-Strukturen und möglicherweise Industriestandards oder -vorschriften zu erwarten, die diese Bedenken adressieren.

EigenLayer vs. Karak vs. Babylon: Eine vergleichende Analyse​

Die Restaking-/Shared-Security-Landschaft umfasst nun mehrere Frameworks mit unterschiedlichen Designs. Hier vergleichen wir EigenLayer, Karak Network und Babylon – und beleuchten ihre technischen Architekturen, Wirtschaftsmodelle und strategischen Schwerpunkte:

Technische Architektur & Sicherheitsbasis: EigenLayer ist ein Ethereum-natives Protokoll (Smart Contracts auf Ethereum L1), das gestakte ETH (und äquivalente Liquid Staking Tokens) als Sicherheits-Collateral nutzt. Es „reitet auf“ Ethereums Beacon Chain – Validatoren melden sich über Ethereum-Verträge an, und Slashing wird auf ihren ETH-Stake durchgesetzt. Dies bedeutet, dass EigenLayers Sicherheit fundamental an Ethereums PoS und den Wert von ETH gebunden ist. Im Gegensatz dazu positioniert sich Karak als „universelle Restaking-Schicht“, die nicht an eine einzelne Basiskette gebunden ist. Karak startete seine eigene L1-Blockchain (mit EVM-Kompatibilität), optimiert für Shared-Security-Dienste. Karaks Modell ist kettenunabhängig und asset-unabhängig: Es ermöglicht das Restaking von vielen Arten von Assets über mehrere Ketten hinweg, nicht nur ETH. Zu den unterstützten Sicherheiten gehören Berichten zufolge ETH und LSTs sowie andere ERC-20s (Stablecoins wie USDC/sDAI, LP-Tokens, sogar andere L1-Tokens). Dies bedeutet, dass Karaks Sicherheitsbasis ein diversifizierter Korb ist; die Validierung in Karak könnte beispielsweise durch eine Kombination aus gestakter ETH, gestakter SOL (falls überbrückt), Stablecoins usw. abgesichert sein, je nachdem, was das AVS (oder „VaaS“ in Karaks Terminologie) akzeptiert. Babylon geht einen anderen Weg: Es nutzt die Sicherheit von Bitcoin (BTC) – dem größten Krypto-Asset – um andere Ketten zu sichern. Babylon ist als Cosmos-basierte Kette (Babylon Chain) aufgebaut, die über das IBC-Protokoll mit Bitcoin und PoS-Ketten verbunden ist. BTC-Halter sperren native BTC im Bitcoin-Mainnet (in einem cleveren zeitgesperrten Tresor) und „staken“ dadurch BTC an Babylon, das dies dann als Sicherheit zur Absicherung von Consumer-PoS-Ketten verwendet. Somit ist Babylons Sicherheitsbasis der Wert von Bitcoin (über 500 Mrd. US-Dollar Marktkapitalisierung), der auf vertrauenslose Weise genutzt wird (keine Wrapped BTC oder Verwahrer – es verwendet Bitcoin-Skripte, um Slashing durchzusetzen). Zusammenfassend lässt sich sagen, dass EigenLayer auf Ethereums wirtschaftliche Sicherheit setzt, Karak Multi-Asset und Multi-Chain ist (eine generische Schicht für jede Sicherheit) und Babylon Bitcoins Proof-of-Work-Sicherheit in PoS-Ökosysteme erweitert.

Restaking-Mechanismus: In EigenLayer ist Restaking über Ethereum-Verträge opt-in; Slashing ist programmatisch und wird durch den Ethereum-Konsens durchgesetzt (unter Einhaltung der EigenLayer-Verträge). Karak, als unabhängige L1, pflegt seine eigene Restaking-Logik auf seiner Kette. Karak führte das Konzept von Validation-as-a-Service (VaaS) ein – analog zu EigenLayers AVS – jedoch mit einem universellen Validatoren-Marktplatz über Ketten hinweg. Karaks Validatoren (Operatoren) betreiben seine Kette und eine beliebige Anzahl von Distributed Secure Services (DSS), die Karaks Äquivalent zu AVSs sind. Ein DSS könnte eine neue anwendungsspezifische Blockchain oder ein Dienst sein, der Sicherheit aus Karaks gestaktem Asset-Pool mietet. Karaks Innovation besteht darin, Anforderungen zu standardisieren, sodass jede Kette oder App (Ethereum, Solana, eine L2 usw.) sich anschließen und sein Validatoren-Netzwerk und vielfältige Sicherheiten nutzen könnte. Slashing in Karak würde durch seine Protokollregeln gehandhabt – da es z. B. USDC staken kann, slasht es vermutlich das USDC eines Validators, wenn dieser sich bei einem Dienst falsch verhält (die genauen Multi-Asset-Slashing-Mechanismen sind komplex und nicht öffentlich, aber die Idee ist ähnlich: jede Sicherheit kann entzogen werden, wenn Verstöße nachgewiesen werden). Babylons Mechanismus ist aufgrund der Einschränkungen von Bitcoin einzigartig: Bitcoin unterstützt keine Smart Contracts zum automatischen Slashing, daher verwendet Babylon kryptografische Tricks. BTC wird in einem speziellen Output gesperrt, der einen Schlüssel erfordert. Wenn ein BTC-Staking-Teilnehmer betrügt (z. B. zwei widersprüchliche Blöcke auf einer Client-Kette signiert), nutzt das Protokoll ein Extractable One-Time Signature (EOTS)-Schema, um den privaten Schlüssel des Teilnehmers offenzulegen, wodurch seine gesperrte BTC an eine Burn-Adresse gesendet werden kann. Einfacher ausgedrückt führt Fehlverhalten dazu, dass der BTC-Staker sich effektiv selbst slasht, da der Akt des Betrugs die Kontrolle über seine Einlage preisgibt (die dann zerstört wird). Babylons Cosmos-basierte Kette koordiniert diesen Prozess und kommuniziert mit Partnerketten (über IBC), um Dienste wie Checkpointing und Finalität unter Verwendung von BTCs Zeitstempeln bereitzustellen. In Babylon sind die Validatoren der Babylon-Kette (genannt Finalitätsanbieter) getrennt – sie betreiben den Babylon-Konsens und helfen bei der Weiterleitung von Informationen an Bitcoin – aber sie bieten keine wirtschaftliche Sicherheit; die wirtschaftliche Sicherheit kommt rein von gesperrten BTC.

Wirtschaftsmodell & Belohnungen: EigenLayers Wirtschaftsmodell konzentriert sich auf die Staking-Ökonomie von Ethereum. Restaker verdienen AVS-spezifische Belohnungen – diese könnten in ETH-Gebühren, dem eigenen Token des AVS oder anderen Tokens gezahlt werden, abhängig vom Design jedes AVS. EigenLayer selbst führte den $EIGEN-Token hauptsächlich für Governance und zur Belohnung früher Teilnehmer ein, aber AVSs sind nicht verpflichtet, EIGEN zu verwenden oder damit zu bezahlen (es ist kein Gas-Token für sie). Die Plattform strebt ein Freimarktgleichgewicht an, bei dem jedes AVS eine Belohnungsrate festlegt, um ausreichende Sicherheit anzuziehen. Karak scheint seinen nativen Token $KAR (Anfang 2025 noch nicht live) als primäres Asset in seinem Ökosystem einzuführen. Karak hat 48 Mio. US-Dollar eingesammelt und wurde von großen Investoren unterstützt, was darauf hindeutet, dass $KAR Wert haben und wahrscheinlich für Governance und möglicherweise Gebührenzahlungen im Karak-Netzwerk verwendet wird. Karaks Hauptversprechen ist jedoch „keine Inflation“ für neue Netzwerke, die es nutzen – anstatt eigene Tokens für Sicherheit auszugeben, greifen sie über Karak auf bestehende Assets zurück. Eine neue Kette, die Karak verwendet, könnte Validatoren beispielsweise in ihren Transaktionsgebühren bezahlen (die in einem Stablecoin oder im nativen Token der Kette sein könnten, falls vorhanden), müsste aber nicht kontinuierlich neue Tokens für Staking-Belohnungen prägen. Karak hat einen Validatoren-Marktplatz eingerichtet, auf dem Entwickler Kopfgelder/Belohnungen für Validatoren ausschreiben können, um Assets zu restaken und ihren Dienst zu sichern. Dieser Marktplatzansatz zielt darauf ab, Belohnungen wettbewerbsfähiger und konsistenter zu gestalten, anstatt extrem hoher Inflation gefolgt von einem Crash – theoretisch reduziert dies die Kosten für Entwickler und verschafft Validatoren ein stabiles Multi-Chain-Einkommen. Babylons Ökonomie unterscheidet sich ebenfalls: BTC-Staker, die ihre Bitcoin sperren, verdienen Rendite in den Tokens der Netzwerke, die sie sichern. Wenn Sie zum Beispiel BTC staken, um eine Cosmos-Zone (eine der Client-Ketten von Babylon) zu sichern, erhalten Sie die Staking-Belohnungen dieser Zone (ihren nativen Staking-Token), als wären Sie ein Delegator dort. Diese Partnerketten profitieren von einer zusätzlichen Sicherheitsebene (Checkpoints auf Bitcoin usw.), und im Gegenzug weisen sie einen Teil ihrer Inflation oder Gebühren den BTC-Stakern über Babylon zu. Im Grunde fungiert Babylon als Hub, wo BTC-Halter Sicherheit an viele Ketten delegieren und in vielen Tokens bezahlt werden können. Die Babylon-Kette selbst hat einen Token namens $BABY, der zum Staken im eigenen Konsens von Babylon verwendet wird (Babylon benötigt immer noch eigene PoS-Validatoren, um die Infrastruktur der Kette zu betreiben). $BABY wird wahrscheinlich auch in der Governance verwendet und möglicherweise, um Anreize auszurichten (zum Beispiel staken Finalitätsanbieter BABY). Wichtig ist jedoch, dass $BABY BTC nicht als Sicherheitsquelle ersetzt – es dient eher dem Betrieb der Kette – während BTC die Sicherheit ist, die den Shared-Security-Dienst absichert. Stand Mai 2025 hatte Babylon erfolgreich über 50.000 BTC (ca. 5,5 Milliarden US-Dollar) von BTC-Haltern gestakt, was es zu einer der sichersten Cosmos-Ketten nach Kapital macht. Diese BTC-Staker verdienen dann Staking-Belohnungen von mehreren verbundenen Ketten (z. B. Cosmos Hubs ATOM, Osmosis' OSMO usw.), wodurch sie eine diversifizierte Rendite erzielen, während sie BTC halten.

Strategischer Fokus und Anwendungsfälle: EigenLayers Strategie war Ethereum-zentriert und zielte darauf ab, Innovationen innerhalb des Ethereum-Ökosystems zu beschleunigen. Seine frühen Zielanwendungsfälle (Datenverfügbarkeit, Middleware wie Orakel, Rollup-Sequenzierung) verbessern alle Ethereum oder seine Rollups. Es lädt Ethereum im Wesentlichen als Meta-Schicht von Diensten auf, und mit seiner geplanten „Multi-Chain“-Unterstützung (hinzugefügt im Jahr 2025) wird EigenLayer es AVSs ermöglichen, auf anderen EVM-Ketten oder L2s zu laufen, während sie weiterhin Ethereums Validatoren-Set nutzen. Diese Cross-Chain-Verifizierung bedeutet, dass EigenLayer sich zu einem Cross-Chain-Sicherheitsanbieter entwickelt, der jedoch in Ethereum verankert ist (Validatoren und Staking leben weiterhin auf Ethereum für das Slashing). Karak positioniert sich als global erweiterbare Basisschicht für alle Arten von Anwendungen – nicht nur Krypto-Infrastruktur, sondern auch Real-World-Assets, Finanzmärkte, sogar Regierungsdienste, laut seinem Marketing. Der Name „Global Base Layer for Programmable GDP“ deutet auf die Ambition hin, mit Institutionen und Nationalstaaten zusammenzuarbeiten. Karak betont die Integration von traditionellen Finanzen und KI, was darauf hindeutet, dass es Partnerschaften über den krypto-nativen Bereich hinaus anstreben wird. Technisch gesehen könnte Karak durch die Unterstützung von Assets wie Stablecoins und potenziell staatlichen Währungen beispielsweise einer Regierung ermöglichen, eine Blockchain zu starten, die durch ihren eigenen Fiat-Token gesichert ist, der über Karaks Validatoren gestakt wird. Seine Unterstützung für Unternehmen und mehrere Jurisdiktionen ist ein Alleinstellungsmerkmal. Im Wesentlichen versucht Karak, „Restaking für jedermann, auf jeder Kette, mit jedem Asset“ zu sein – ein breiteres Netz als EigenLayers Ethereum-First-Ansatz. Babylons Fokus liegt auf der Überbrückung der Bitcoin- und Cosmos- (und breiteren PoS-) Ökosysteme. Es verbessert spezifisch die Inter-Chain-Sicherheit, indem es Bitcoins Unveränderlichkeit und wirtschaftliches Gewicht an ansonsten kleinere Proof-of-Stake-Ketten liefert. Eine der Killer-Apps von Babylon ist das Hinzufügen von Bitcoin-Finalitäts-Checkpoints zu PoS-Ketten, wodurch es extrem schwierig wird, diese Ketten anzugreifen oder zu reorganisieren, ohne auch Bitcoin anzugreifen. Babylon vermarktet sich somit als das Projekt, das „Bitcoins Sicherheit in die gesamte Krypto-Welt bringt“. Sein kurzfristiger Fokus lag auf Cosmos SDK-Ketten (die es in Phase 3 als Bitcoin Supercharged Networks bezeichnet), aber das Design ist auch für die Interoperabilität mit Ethereum und Rollups gedacht. Strategisch greift Babylon auf die riesige BTC-Halterbasis zurück, bietet ihnen eine Renditeoption (BTC ist ansonsten ein nicht-renditetragendes Asset) und gleichzeitig Ketten Zugang zum „Goldstandard“ der Krypto-Sicherheit (BTC + PoW). Dies unterscheidet sich deutlich von EigenLayer und Karak, die sich mehr auf die Nutzung von PoS-Assets konzentrieren.

Tabelle: EigenLayer vs. Karak vs. Babylon

Merkmal	EigenLayer (Ethereum)	Karak Network (Universelle L1)	Babylon (Bitcoin–Cosmos)
Basissicherheits-Asset	ETH (Ethereum-Stake) und auf der Whitelist stehende LSTs.	Multi-Asset: ETH, LSTs, Stablecoins, ERC-20s usw. Auch Cross-Chain-Assets (Arbitrum, Mantle usw.).	BTC (natives Bitcoin) im Bitcoin-Mainnet gesperrt. Nutzt Bitcoins hohe Marktkapitalisierung als Sicherheit.
Plattformarchitektur	Smart Contracts auf Ethereum L1. Nutzt Ethereum-Validatoren/Clients; Slashing wird durch den Ethereum-Konsens durchgesetzt. Erweitert nun die Unterstützung für AVSs auf anderen Ketten über Ethereum-Proofs.	Unabhängige Layer-1-Kette („Karak L1“) mit EVM. Bietet ein Restaking-Framework (KNS) zum Starten neuer Blockchains oder Dienste mit sofortigen Validatoren-Sets. Kein Rollup oder L2 – ein separates Netzwerk, das mehrere Ökosysteme verbindet.	Cosmos-basierte Kette (Babylon Chain), die über kryptografische Protokolle mit Bitcoin verbunden ist. Nutzt IBC zur Verknüpfung mit PoS-Ketten. Babylon-Validatoren betreiben einen Tendermint-Konsens, und das Bitcoin-Netzwerk wird für Zeitstempel und Slashing-Logik genutzt.
Sicherheitsmodell	Opt-in-Restaking: Ethereum-Staker delegieren Stake an EigenLayer und stimmen AVS-spezifischen Slashing-Bedingungen zu. Slashing-Bedingungen sind objektiv (kryptografische Beweise), um Probleme des Ethereum-Sozialkonsenses zu vermeiden.	Universelle Validierung: Karak-Validatoren können verschiedene Assets staken und werden zugewiesen, um Distributed Secure Services (DSS) (ähnlich wie AVSs) über viele Ketten hinweg zu sichern. Slashing und Belohnungen werden durch Karaks Kettenlogik gehandhabt; standardisiert Sicherheit als Dienstleistung für jede Kette.	„Remote Staking“ BTC: Bitcoin-Halter sperren BTC in selbstverwahrten Tresoren (zeitgesperrte UTXOs), und wenn sie sich auf einer Client-Kette falsch verhalten, kann ihr privater Schlüssel offengelegt werden, um ihre BTC zu slashen (verbrennen). Nutzt Bitcoins eigene Mechanismen (kein Token-Wrapping). Die Babylon-Kette koordiniert dies und bietet Checkpointing (BTC-Finalität) für Client-Ketten.
Token & Belohnungen	EIGEN-Token: Wird für Governance und zur Belohnung früher Teilnehmer (über Airdrop, Anreize) verwendet. Restaker verdienen hauptsächlich in AVS-Gebühren oder Tokens (könnten ETH, Stablecoins oder AVS-native Tokens sein). EigenLayer selbst schreibt keinen Anteil für EIGEN-Token-Halter an AVS-Einnahmen vor (obwohl EIGEN zukünftigen Nutzen bei subjektiven Validierungsaufgaben haben könnte).	KAR-Token: Noch nicht gestartet (erwartet 2025). Wird der Haupt-Utility-/Governance-Token im Karak-Ökosystem sein. Karak bewirbt keine native Inflation für neue Ketten – Validatoren verdienen konsistente Belohnungen, indem sie viele Dienste sichern. Neue Protokolle können Validatoren über den Karak-Marktplatz anreizen, anstatt hochinflationäre Tokens zu verwenden. KAR wird wahrscheinlich für die Karak-Kettensicherheit und Governance-Entscheidungen verwendet.	BABY-Token: Nativ zur Babylon Chain (für das Staking ihrer Validatoren, Governance). BTC-Staker erhalten kein BABY für ihren Dienst, stattdessen verdienen sie Rendite in den Tokens der verbundenen PoS-Ketten, die sie sichern. (Z. B. BTC staken, um Kette X zu sichern, Staking-Belohnungen von Kette X verdienen). Dies hält die Exposition von BTC-Stakern hauptsächlich auf bestehende Tokens beschränkt. BABYs Rolle ist es, den Babylon-Hub zu sichern und möglicherweise als Gas oder Governance im Babylon-Ökosystem zu dienen.
Bemerkenswerte Anwendungsfälle	Ethereum-ausgerichtete Infrastruktur: z. B. EigenDA (Datenverfügbarkeit für Rollups), Orakelnetzwerke (z. B. Tellor/eOracle), Cross-Chain-Brücken (LayerZero-Integration), Shared Sequencer für Rollups (Espresso, Radius), Off-Chain-Berechnungen (Risc Zero usw.). Erforscht auch dezentrale MEV-Relay-Dienste und Liquid Restaking Derivate. Im Wesentlichen erweitert es Ethereums Fähigkeiten (Skalierung, Interoperabilität, DeFi-Middleware), indem es eine dezentrale Vertrauensschicht bereitstellt.	Breiter Fokus einschließlich traditioneller Finanzintegration: tokenisierte Real-World-Assets, 24/7-Handelsmärkte, sogar Regierungs- und KI-Anwendungen auf maßgeschneiderten Ketten. Zum Beispiel werden KUDA (Datenverfügbarkeits-Marktplatz) und andere im Karak-Ökosystem aufgebaut. Könnte Unternehmenskonsortialketten hosten, die USD-Stablecoins als Staking-Sicherheit verwenden usw. Karak richtet sich an Multi-Chain-Entwickler, die Sicherheit wünschen, ohne auf Ethereum-Validatoren oder nur ETH beschränkt zu sein. Betont auch Interoperabilität und Kapitaleffizienz – z. B. die Verwendung von Assets mit geringeren Opportunitätskosten (wie kleinere L1-Tokens) für Restaking, damit die Renditen höher sein können, ohne mit der ETH-Rendite zu konkurrieren.	Sicherheit für Cosmos-Ketten und darüber hinaus: z. B. die Verwendung von BTC zur Sicherung von Cosmos Hub, Osmosis und anderen Zonen (verbessert deren Sicherheit, ohne dass diese Zonen die Inflation erhöhen). Bietet Bitcoin-Zeitstempel-Finalität – jede Kette, die sich anmeldet, kann wichtige Transaktionen auf Bitcoin hashen lassen, um Zensurresistenz und Finalität zu gewährleisten. Besonders nützlich für neue PoS-Ketten, die Long-Range-Angriffe verhindern oder eine Bitcoin-„Vertrauenswurzel“ hinzufügen möchten. Babylon schafft effektiv eine Brücke zwischen Bitcoin- und PoS-Netzwerken: Bitcoin-Halter erhalten Rendite von PoS, und PoS-Ketten erhalten Bitcoins Sicherheit und Community. Es ergänzt das Restaking mit ETH; zum Beispiel könnte eine Kette EigenLayer für die wirtschaftliche Sicherheit von ETH und Babylon für die BTC-Robustheit nutzen.

Strategische Unterschiede: EigenLayer profitiert von Ethereums massivem dezentralisiertem Validatoren-Set und seiner Glaubwürdigkeit, ist aber auf ETH-basierte Sicherheit beschränkt. Es ist hervorragend darin, Ethereum-orientierte Projekte zu bedienen (viele AVSs sind Ethereum-Rollup- oder Middleware-Projekte). Karaks Strategie ist es, einen größeren Markt zu erobern, indem es flexibel in der Asset- und Kettenunterstützung ist – es ist nicht an Ethereum gebunden und wirbt sogar damit, dass Entwickler vermeiden können, „ausschließlich auf Ethereum für Sicherheit beschränkt zu sein“. Dies könnte Projekte in Ökosystemen wie Arbitrum, Polygon oder sogar Nicht-EVM-Ketten anziehen, die einen neutralen Sicherheitsanbieter wünschen. Karaks Multi-Asset-Ansatz bedeutet auch, dass es Assets nutzen kann, die anderswo geringere Renditen aufweisen; wie Mitbegründer Raouf Ben-Har bemerkte: „Viele Assets haben geringere Opportunitätskosten im Vergleich zu ETH… was bedeutet, dass [unsere Dienste] einen einfacheren Weg zu nachhaltigen Renditen haben.“. Zum Beispiel hat gestakter ARB (Arbitrums Token) derzeit wenige Verwendungszwecke; Karak könnte ARB-Haltern ermöglichen, in die Sicherung neuer dApps zu restaken, wodurch eine Win-Win-Situation entsteht (Rendite für ARB-Halter, Sicherheit für die dApp). Diese Strategie bringt jedoch technische Komplexität (Verwaltung verschiedener Asset-Risiken) und Vertrauensannahmen (sicheres Überbrücken von Assets auf Karaks Plattform) mit sich. Babylons Strategie unterscheidet sich durch den Fokus auf Bitcoin – es nutzt das größte Krypto-Asset nach Marktkapitalisierung, das auch eine sehr unterschiedliche Community und ein anderes Nutzungsprofil (Langzeit-Halter) aufweist. Babylon hat im Grunde eine neue Staking-Quelle erschlossen, die zuvor ungenutzt war: 1,2 Billionen US-Dollar an BTC, die nicht nativ gestakt werden konnten. Dadurch adressiert es einen riesigen Sicherheitspool und zielt auf Ketten ab, die Bitcoins Zusicherungen schätzen. Es spricht auch Bitcoin-Halter an, indem es ihnen eine Möglichkeit bietet, Rendite zu erzielen, ohne die Verwahrung von BTC aufzugeben. Man könnte sagen, Babylon ist fast das Gegenteil von EigenLayer: Anstatt Ethereums Sicherheit nach außen zu erweitern, importiert es Bitcoins Sicherheit in PoS-Netzwerke. Strategisch könnte es die historisch getrennten Welten von Bitcoin und DeFi vereinen.

Jedes dieser Frameworks hat Kompromisse. EigenLayer genießt derzeit einen First-Mover-Vorteil im Ethereum-Restaking und einen großen TVL (ca. 20 Mrd. US-Dollar bis Ende 2024 gerestaked), plus tief integrierte Unterstützung der Ethereum-Community. Karak ist neuer (Mainnet im April 2024 gestartet) und zielt darauf ab, durch die Abdeckung von Nischen zu wachsen, die EigenLayer nicht bedient (Nicht-ETH-Sicherheiten, Nicht-Ethereum-Ketten). Babylon agiert im Cosmos-Bereich und nutzt Bitcoin – es konkurriert nicht mit EigenLayer um ETH-Staker, sondern bietet einen orthogonalen Dienst an (einige Projekte könnten beide nutzen). Wir sehen eine Konvergenz, bei der mehrere Restaking-Schichten sogar interoperieren könnten: z. B. könnte eine Ethereum L2 EigenLayer für ETH-basierte Sicherheit nutzen und auch BTC-Sicherheit über Babylon akzeptieren – was zeigt, dass diese Modelle sich nicht gegenseitig ausschließen, sondern Teil eines breiteren „Shared-Security-Marktes“ sind.

Aktuelle Entwicklungen und Ökosystem-Updates (2024–2025)​

EigenLayers Fortschritt: Seit seiner Gründung im Jahr 2021 hat sich EigenLayer schnell vom Konzept zu einem Live-Netzwerk entwickelt. Es wurde schrittweise im Ethereum-Mainnet gestartet – Stufe 1 Mitte 2023 ermöglichte grundlegendes Restaking, und bis April 2024 wurde das vollständige EigenLayer-Protokoll (mit Unterstützung für Operatoren und anfängliche AVSs) bereitgestellt. Das Ökosystemwachstum war beträchtlich: Anfang 2025 meldet EigenLayer 29 AVSs live im Mainnet (und über 130 in Entwicklung), die von Datenschichten bis zu Orakeln reichen. Über 200 Operatoren und Zehntausende von Restakern nehmen teil und tragen zu einem gerestakten TVL bei, der Ende 2024 rund 20 Milliarden US-Dollar erreichte. Ein wichtiger Meilenstein war die Einführung von Slashing und Belohnungsdurchsetzung im Mainnet im April 2025, was den letzten Schritt der Inkraftsetzung von EigenLayers Sicherheitsmodell darstellt. Dies bedeutet, dass AVSs nun Fehlverhalten wirklich bestrafen und Belohnungen vertrauenslos auszahlen können, wodurch die „Testphase“, in der diese Funktionen deaktiviert waren, überwunden wird. Parallel dazu implementierte EigenLayer eine Reihe von Upgrades: zum Beispiel verbesserte das MOOCOW-Upgrade (Juli 2025) die Validatoreneffizienz, indem es einfachere Restake-Auszahlungen und Konsolidierungen ermöglichte (unter Nutzung von Ethereums Pectra-Fork). Die vielleicht bedeutendste neue Funktion ist die im Juli 2025 eingeführte Multi-Chain-Verifizierung, die es AVSs ermöglicht, über mehrere Ketten (einschließlich L2s) hinweg zu operieren, während sie weiterhin Ethereum-basierte Sicherheit nutzen. Dies wurde auf dem Base Sepolia Testnet demonstriert und wird im Mainnet ausgerollt, wodurch EigenLayer effektiv zu einem Cross-Chain-Sicherheitsanbieter wird (nicht nur für Ethereum L1-Anwendungen). Es behebt eine frühere Einschränkung, dass EigenLayer AVSs alle Daten auf Ethereum posten mussten; jetzt kann ein AVS beispielsweise auf einem Optimistic Rollup oder einer anderen L1 laufen, und EigenLayer wird Beweise (unter Verwendung von Merkle-Roots) auf Ethereum zurückverifizieren, um bei Bedarf zu slashen oder zu belohnen. Dies erweitert EigenLayers Reichweite und Leistung erheblich (AVSs können dort laufen, wo es billiger ist, während die Ethereum-Sicherheit erhalten bleibt). In Bezug auf Community und Governance führte EigenLayer Ende 2024 EigenGov ein – einen Rat und ein ELIP (EigenLayer Improvement Proposal)-Framework zur Dezentralisierung der Entscheidungsfindung. Der Protokollrat (5 Mitglieder) überwacht nun kritische Änderungen mit Community-Input. Zusätzlich hat EigenLayer Bedenken der Ethereum-Kerncommunity berücksichtigt. Als Reaktion auf Vitaliks Warnungen hat das Team Materialien veröffentlicht, die erklären, wie sie eine Überlastung des Ethereum-Konsenses vermeiden, zum Beispiel durch die Verwendung des EIGEN-Tokens für alle „subjektiven“ Dienste und die Belassung von ETH-Restaking für rein objektive Slashing-Fälle. Dieser zweistufige Ansatz (ETH für eindeutige Fehler, EIGEN für subjektivere oder governance-geführte Entscheidungen) wird noch verfeinert, zeigt aber EigenLayers Engagement, sich an Ethereums Ethos anzupassen.

Auf der Ökosystemseite hat das Aufkommen von EigenLayer eine Welle der Innovation und Diskussion ausgelöst. Mitte 2024 stellten Analysten fest, dass Restaking „eine führende Erzählung innerhalb der Ethereum-Community“ geworden war. Viele DeFi- und Infrastrukturprojekte begannen zu planen, wie sie EigenLayer für Sicherheit oder zusätzliche Rendite nutzen könnten. Gleichzeitig diskutieren Community-Mitglieder über Risikomanagement: Zum Beispiel lenkte der detaillierte Risikobericht von Chorus One (April 2024) die Aufmerksamkeit auf die Zentralisierung von Operatoren und Kaskaden-Slashing-Risiken, was weitere Forschung und möglicherweise Funktionen wie die Überwachung der Stake-Verteilung auslöste. Die EIGEN-Token-Verteilung war ebenfalls ein heißes Thema – im 4. Quartal 2024 führte EigenLayer einen „Stake Drop“ durch, bei dem aktive Ethereum-Nutzer und frühe EigenLayer-Teilnehmer EIGEN erhielten, der jedoch anfänglich nicht übertragbar war. Einige Community-Mitglieder waren mit Aspekten des Drops unzufrieden (z. B. große Anteile, die an VCs gingen, und einige DeFi-Protokolle, die EigenLayer integriert hatten, wurden nicht direkt belohnt). Dieses Feedback hat das Team dazu veranlasst, zukünftig stärker auf gemeinschaftszentrierte Anreize zu setzen, und die eingeführten Programmatic Incentives zielen darauf ab, diejenigen kontinuierlich zu belohnen, die tatsächlich Restaking betreiben und operieren. Bis 2025 ist EigenLayer eines der am schnellsten wachsenden Entwickler-Ökosysteme – sogar in einem Electric Capital-Bericht anerkannt – und hat wichtige Partnerschaften (z. B. mit LayerZero, ConsenSys, Risc0) geschlossen, um die Akzeptanz von AVSs voranzutreiben. Insgesamt zeigt EigenLayers Entwicklung in den Jahren 2024–2025 eine reifende Plattform, die frühe Bedenken adressiert und die Funktionalität erweitert, wodurch ihre Position als Pionier des Ethereum-Restakings gefestigt wird.

Karak und andere Wettbewerber: Karak Network trat mit seinem Mainnet-Start im April 2024 ins Rampenlicht und positionierte sich schnell als bemerkenswerter EigenLayer-Rivale auf Ethereum und darüber hinaus. Unterstützt von großen Investoren und sogar bestimmten Ethereum-Stakeholdern (u. a. Coinbase Ventures) erregte Karaks Versprechen von „Restaking für jedermann, auf jeder Kette, mit jedem Asset“ Aufmerksamkeit. Ende 2024 wurde Karak auf ein V2-Mainnet mit erweiterten Funktionen für universelle Sicherheit aktualisiert und schloss die Migrationen über Arbitrum und Ethereum bis November 2024 ab. Dies deutet darauf hin, dass Karak die Unterstützung für weitere Assets erweitert und möglicherweise seine Smart Contracts oder seinen Konsens verbessert hat. Anfang 2025 hatte Karak seine Nutzerbasis über ein XP-Anreizprogramm erweitert (das zur Testnet-Teilnahme, zum Staking usw. ermutigte, in der Hoffnung auf einen zukünftigen $KAR-Airdrop). Community-Diskussionen um Karak vergleichen es oft mit EigenLayer: Bankless bemerkte im Mai 2024, dass Karaks gesamter gestakter Wert zwar immer noch „nicht annähernd die Größe von EigenLayer“ erreichte, es aber ein schnelles Wachstum (4x in einem Monat) verzeichnete, möglicherweise weil Nutzer höhere Belohnungen suchten oder sich von EigenLayer diversifizierten. Karaks Attraktivität liegt in der Unterstützung von Assets wie Pendle Yield Tokens, Arbitrums ARB, Mantles Token usw., was den Restaking-Markt erweitert. Stand 2025 konzentriert sich Karak wahrscheinlich darauf, weitere „Validation-as-a-Service“-Clients an Bord zu holen und möglicherweise den Start seines KAR-Tokens vorzubereiten (seine Dokumentation empfiehlt, offizielle Kanäle für Token-Updates zu verfolgen). Der Wettbewerb zwischen EigenLayer und Karak bleibt freundlich, aber bedeutsam – beide zielen darauf ab, Staker und Projekte anzuziehen. Wenn EigenLayer das ETH-Maximalisten-Segment hält, spricht Karak Multi-Chain-Nutzer und diejenigen mit Nicht-ETH-Assets an, die nach Rendite suchen. Wir können erwarten, dass Karak im kommenden Jahr Partnerschaften ankündigen wird, vielleicht mit Layer2-Netzwerken oder sogar institutionellen Akteuren, angesichts seines „Institutional-Grade“-Brandings. Der Restaking-Markt ist somit kein Monopol; vielmehr finden mehrere Plattformen Nischen, was zu einem fragmentierten, aber reichen Ökosystem von Shared-Security-Anbietern führen könnte.

Babylons Start und die BTC-Staking-Grenze: Babylon erreichte 2025 einen wichtigen Meilenstein, indem es seine Kernfunktionalität aktivierte – Bitcoin-Staking für Shared Security. Nach einem Phase-1-Testnet und schrittweiser Einführung ging Babylons Phase-2-Mainnet im April 2025 live, und bis Mai 2025 meldete es über 50.000 BTC, die im Protokoll gestakt wurden. Dies ist eine bemerkenswerte Leistung, die effektiv ~5 Mrd. US-Dollar Bitcoin in den Interchain-Sicherheitsmarkt einspeist. Zu Babylons frühen Adopter-Ketten (den ersten „Bitcoin Supercharged Networks“) gehören mehrere Cosmos-basierte Ketten, die Babylons Light Client integrierten und begannen, sich auf die BTC-Checkpoint-Finalität zu verlassen. Die Babylon Genesis Chain selbst startete am 10. April 2025, gesichert durch das neue $BABY-Token-Staking, und einen Tag später (11. April) wurde das vertrauenslose BTC-Staking mit einer anfänglichen Obergrenze von 1000 BTC pilotiert. Bis zum 24. April 2025 wurde das BTC-Staking für alle permissionless geöffnet, und die Obergrenze wurde aufgehoben. Der reibungslose Betrieb in den ersten Wochen führte das Team dazu, das Bitcoin-Staking als „erfolgreich gebootstrappt“ zu erklären und Babylon Genesis nun als „eine der sichersten L1s der Welt in Bezug auf die Staking-Marktkapitalisierung“ zu bezeichnen. Mit Abschluss von Phase 2 zielt Phase 3 darauf ab, viele externe Netzwerke als Clients an Bord zu holen und sie in BSNs (Bitcoin Supercharged Networks) zu verwandeln. Dies wird Interoperabilitätsmodule umfassen, sodass Ethereum, seine Rollups und jede Cosmos-Kette Babylon nutzen können, um Sicherheit von BTC zu beziehen. Die Babylon-Community – bestehend aus Bitcoin-Haltern, Cosmos-Entwicklern und anderen – hat aktiv über die Governance des $BABY-Tokens (um sicherzustellen, dass die Babylon-Kette für alle verbundenen Ketten neutral und zuverlässig bleibt) und die Ökonomie (zum Beispiel das Ausbalancieren der BTC-Staking-Belohnungen unter vielen Consumer-Ketten, damit es für BTC-Halter attraktiv ist, ohne übermäßig subventioniert zu werden) diskutiert. Eine interessante Entwicklung ist Babylons Unterstützung für Dinge wie Nexus Mutual Cover (gemäß einem Beitrag vom Mai 2025), um eine Versicherung gegen BTC-Staking-Slashing anzubieten, was weitere Teilnehmer anlocken könnte. Dies zeigt, wie das Ökosystem um das Risikomanagement für dieses neue Paradigma reift.

Community- und Cross-Project-Diskussionen: Ab 2025 findet eine breitere Diskussion über die Zukunft der Shared Security in Krypto statt. Ethereums Community begrüßt EigenLayer weitgehend, bleibt aber vorsichtig; Vitaliks Blogbeitrag (Mai 2023) gab den Ton für eine sorgfältige Abgrenzung dessen vor, was akzeptabel ist. EigenLayer engagiert sich regelmäßig mit der Community über sein Forum und beantwortet Fragen wie „Überlastet EigenLayer Ethereums Konsens?“ (kurze Antwort: Sie argumentieren, dass dies aufgrund von Design-Sicherheitsvorkehrungen nicht der Fall ist). In der Cosmos-Community löste Babylon Begeisterung aus, da es potenziell langjährige Sicherheitsprobleme (z. B. kleine Zonen, die 51%-Angriffe erleiden) löst, ohne dass sie einem Shared-Security-Hub wie Polkadot oder Cosmos Hubs ICS beitreten müssen. Es gibt auch eine interessante Konvergenz: Einige Cosmos-Leute fragen, ob Ethereum-Staking jemals Cosmos-Ketten antreiben könnte (was eher EigenLayers Domäne ist), während Ethereum-Leute sich fragen, ob Bitcoin-Staking Ethereum-Rollups sichern könnte (Babylons Konzept). Wir sehen frühe Anzeichen von Cross-Pollination: zum Beispiel Ideen, EigenLayer zu nutzen, um ETH auf Nicht-Ethereum-Ketten zu restaken (Symbiotic und Karak sind Schritte in diese Richtung) und Babylons BTC-Staking als Option für Ethereum L2s zu verwenden. Sogar Solana hat ein Restaking-Projekt (Solayer) gestartet, das einen Soft-Test durchführte und schnell an die Grenzen stieß, was zeigt, dass das Interesse mehrere Ökosysteme umfasst.

Governance-Entwicklungen in diesen Projekten umfassen eine zunehmende Community-Vertretung. EigenLayers Rat umfasst nun externe Community-Mitglieder, und es hat Zuschüsse (über die Eigen Foundation) an Ethereum-Core-Entwickler finanziert, was guten Willen gegenüber Ethereums Kern signalisiert. Karaks Governance wird sich wahrscheinlich um den KAR-Token drehen – derzeit betreiben sie ein Off-Chain-XP-System, aber man kann eine formellere DAO erwarten, sobald KAR liquide ist. Babylons Governance wird entscheidend sein, da sie zwischen Bitcoin (das keine formale Governance hat) und Cosmos-Ketten (die On-Chain-Governance haben) koordiniert. Es wurde eine Babylon Foundation und ein Community-Forum eingerichtet, um Parameter wie Unbonding-Perioden für BTC zu diskutieren, die eine sorgfältige Abstimmung mit Bitcoins Einschränkungen erfordern.

Zusammenfassend lässt sich sagen, dass Mitte 2025 der Restaking- und Shared-Security-Markt von der Theorie zur Praxis übergegangen ist. EigenLayer ist voll funktionsfähig mit echten Diensten und Slashing und beweist das Modell auf Ethereum. Karak hat eine überzeugende Multi-Chain-Variante eingeführt, die den Designraum erweitert und neue Assets anspricht. Babylon hat gezeigt, dass selbst Bitcoin über clevere Kryptografie an der Shared-Security-Party teilnehmen kann, wodurch ein völlig anderes Marktsegment angesprochen wird. Das Ökosystem ist lebendig: Neue Wettbewerber (z. B. Symbiotic auf Ethereum, Solayer auf Solana, BounceBit mit custodial BTC) entstehen, die jeweils mit unterschiedlichen Kompromissen experimentieren (Symbiotic richtet sich an Lido aus, um stETH und beliebige ERC-20 zu verwenden, BounceBit verfolgt einen regulierten Ansatz mit Wrapped BTC usw.). Diese Wettbewerbslandschaft treibt schnelle Innovationen voran – und, was wichtig ist, Diskussionen über Standards und Sicherheit. Community-Foren und Forschungsgruppen diskutieren aktiv Fragen wie: Sollte es Grenzen für den gerestakten Stake pro Operator geben? Wie lassen sich Cross-Chain-Slashing-Proofs am besten implementieren? Könnte Restaking unbeabsichtigt die systemische Korrelation zwischen Ketten erhöhen? All dies wird untersucht. Die Governance-Modelle entwickeln sich ebenfalls weiter – EigenLayers Übergang zu einem semi-dezentralisierten Rat ist ein Beispiel für das Gleichgewicht zwischen Agilität und Sicherheit in der Governance.

Mit Blick in die Zukunft ist das Restaking-Paradigma dazu bestimmt, eine Grundlage der Web3-Infrastruktur zu werden, ähnlich wie Cloud-Dienste in Web2 unerlässlich wurden. Durch die Kommodifizierung von Sicherheit ermöglicht es kleineren Projekten, mit Vertrauen zu starten, und größeren Projekten, ihre Kapitalnutzung zu optimieren. Die Entwicklungen bis 2025 zeigen eine vielversprechende, aber vorsichtige Entwicklung: Die Technologie funktioniert und skaliert, aber alle Akteure sind sich der Risiken bewusst. Da Ethereums Core-Entwickler, Cosmos-Builder und sogar Bitcoiner nun an Shared-Security-Initiativen beteiligt sind, ist klar, dass dieser Markt nur wachsen wird. Wir können eine engere Zusammenarbeit über Ökosysteme hinweg erwarten (vielleicht gemeinsame Sicherheitspools oder standardisierte Slashing-Proofs) und, unvermeidlich, regulatorische Klarheit, wenn die Regulierungsbehörden diese Multi-Chain-, Multi-Asset-Konstrukte verstehen. In der Zwischenzeit haben Forscher und Entwickler eine Fülle neuer Daten von EigenLayer, Karak, Babylon und anderen, die sie analysieren und verbessern können, um sicherzustellen, dass die „Restaking-Revolution“ sicher und nachhaltig fortgesetzt wird.

Quellen:

1. EigenLayer Dokumentation und Whitepaper – Definition von Restaking und AVS
2. Coinbase Cloud Blog (Mai 2024) – EigenLayer Überblick, Rollen von Restakern/Operatoren/AVSs
3. Blockworks News (April 2024) – Karak-Gründer über „universelles Restaking“ vs. EigenLayer
4. Ditto Research (2023) – Vergleich der Asset-Unterstützung von EigenLayer, Symbiotic, Karak
5. Messari Research (April 2024) – „Babylon: Bitcoin Shared Security“, BTC-Staking-Mechanismus
6. HashKey Research (Juli 2024) – Babylon vs. EigenLayer Restaking-Renditen
7. EigenLayer Forum (Dez. 2024) – Diskussion über Vitaliks „Überlasten Sie Ethereums Konsens nicht“ und EigenLayers Ansatz
8. Blockworks News (April 2024) – Chorus One Bericht über EigenLayer-Risiken (Slashing-Kaskade, Zentralisierung)
9. Kairos Research (Okt. 2023) – EigenLayer AVS Überblick und Hinweis auf regulatorisches Risiko
10. EigenCloud Blog (Jan. 2025) – „Jahresrückblick 2024“ (EigenLayer Statistiken, Governance-Updates)
11. Blockworks News (April 2024) – Karak Launch-Berichterstattung und Asset-Unterstützung
12. Babylon Labs Blog (Mai 2025) – „Phase-2 Launch-Zusammenfassung“ (Bitcoin-Staking live, 50.000 BTC gestakt)
13. Bankless (Mai 2024) – „Der Restaking-Wettbewerb“ (EigenLayer vs. Karak vs. andere)
14. Vitalik Buterin, „Überlasten Sie Ethereums Konsens nicht“, Mai 2023 – Leitfaden zur Validatoren-Wiederverwendung vs. sozialer Konsens
15. Coinbase Developer Guide (April 2024) – Technische Details zum EigenLayer-Betrieb (EigenPods, Delegation, AVS-Struktur).