Warum EOA veraltet sind: Was ein Smart Account tatsächlich leistet

Seit April 2026 verzeichnet BundleBear über 1,07 Milliarden ERC-4337-UserOperations und 56,7 Millionen Smart Accounts, mit denen mindestens einmal auf Ethereum und den großen L2s Transaktionen ausgeführt wurden. Das ist längst kein Nischenthema mehr. Der Account mit einem einzigen Schlüssel, der ausschließlich secp256k1 unterstützt und mit dem Ethereum 2015 gestartet ist, wird zunehmend umgangen. Die On-Chain-Zahlen holen eine weniger beachtete Tatsache auf Protokollebene ein: Der Account selbst ist inzwischen programmierbar.

Dies ist Teil 1 einer fünfteiligen Serie über Smart Accounts. Der Fokus liegt hier eng auf den Grundlagen: Wir erklären, was ein EOA tatsächlich ist, was ein Smart Account tatsächlich ist und warum „Smart Account vs. EOA“ keine Frage der UX-Präferenz mehr ist, sondern eine grundlegende Entscheidung darüber, wie Ihre Selbstverwahrung durchgesetzt wird.

Was ein EOA auf Protokollebene tatsächlich ist

Das Yellow Paper von Ethereum definiert zwei Account-Typen: Externally Owned Accounts und Contract Accounts. Auf Zustandsebene unterscheiden sie sich nur durch das Feld codeHash. Bei einem EOA ist codeHash der Hash der leeren Zeichenfolge. Bei einem Contract Account verweist es auf ausführbaren EVM-Bytecode. Das ist der gesamte Unterschied auf Protokollebene.

Ein EOA ist daher in keiner sinnvollen Bedeutung eine „Wallet“. Es ist eine Adresse, die aus den letzten 20 Bytes von keccak256(public key) abgeleitet wird; das Schlüsselpaar ist fest an die Kurve secp256k1 gebunden. MetaMask, Ledger und Zelcore sind Benutzeroberflächen, die den Schlüssel verwahren. Sie sind nicht der Account. Falls Ihnen der zugrunde liegende Mechanismus noch nicht vertraut ist, erklärt unser Einführungsartikel öffentliche und private Schlüssel und die Ableitung einer Adresse den gesamten Ablauf.

Bis zur Einführung von ERC-4337 im Jahr 2023 musste jede Transaktion auf Ethereum von einem EOA ausgehen. Das Protokoll setzte dabei genau eine Validierungsregel durch: eine gültige secp256k1-Signatur über den Transaktions-Hash. Guthaben halten, für jede Transaktion eine ECDSA-Signatur leisten und Gas in ETH vom selben Account bezahlen. Mehr kann ein EOA nicht. Es gibt nichts Weiteres, was es tun kann.

Die strukturellen Grenzen, die für Nutzer zählen

Das sind keine bloßen Schönheitsfehler der UX. Sie sind der strukturelle Grund für einen Großteil der Verluste bei der Selbstverwahrung, die wir auch 2026 noch beobachten.

• Ein einzelner Ausfallpunkt. Ein privater Schlüssel kontrolliert alles. Geht er verloren, ist auch der Zugriff auf den Account verloren. Wird er offengelegt, sind die Mittel unwiederbringlich verloren. Das Protokoll bietet keine Wiederherstellungsmöglichkeit. Genau deshalb ist eine einzelne Seed-Phrase der häufigste Ausfallpunkt bei der Selbstverwahrung.
• Eine einzige Kurve. secp256k1 ist fest vorgegeben. Sie können weder einen Passkey (P-256) noch einen Ed25519-Schlüssel, BLS oder ein Post-Quantum-Verfahren verwenden.
• Keine native Mehrfachsignatur. Jedes „Multisig“ auf Ethereum, vom ursprünglichen Gnosis Multisig bis Safe, ist ein Contract, den ein EOA aufruft. Das EOA selbst kann niemals zwei Signaturen voraussetzen.
• Keine Bündelung. Ein EOA erledigt pro Transaktion genau eine Sache. Einen Token freizugeben und anschließend zu tauschen, erfordert zwei signierte Transaktionen, zwei Bestätigungen und zwei Gaszahlungen.
• Keine Ausgabenregeln. Das Protokoll kennt keine Vorgaben wie „Dieser Schlüssel darf bis zu 500 $ pro Tag ausgeben“ oder „Dieser Schlüssel darf nur Uniswap aufrufen“.
• Das Gas muss in ETH von demselben Account bezahlt werden, der die Aktion ausführt. Es gibt weder natives Sponsoring noch eine native Möglichkeit, in USDC zu zahlen.

In diesem Rahmen mussten sich ein Jahrzehnt lang alle Ethereum-Nutzer bewegen.

Was ein Smart Account tatsächlich ist

Im wörtlichen Sinn des Protokolls ist ein Smart Account ein Contract Account: eine Adresse, deren codeHash auf Bytecode verweist. Dieser Bytecode legt fest, unter welchen Bedingungen der Account eine Aktion akzeptiert.

Während die Validierungsregel eines EOA auf die eine fest vorgegebene secp256k1-Prüfung beschränkt ist, richtet sich die eines Smart Accounts nach den Vorgaben des Contracts. Möglich sind etwa eine Mehrfachsignatur mit zwei von drei Unterzeichnern, eine Passkey-Signatur, die auf der Kurve secp256r1 überprüft wird, ein durch Hardware attestierter Schlüssel, eine Zeitsperre, ein Tageslimit, ein freigegebenes Aufrufziel oder jede Kombination daraus. Smart Contract Accounts validieren Signaturen nach dem EIP-1271-Standard statt mit einer fest vorgegebenen secp256k1-Prüfung auf Protokollebene. Erst dadurch werden alternative Signaturverfahren möglich.

Da die Regeln im Code festgelegt sind, lassen sie sich aktualisieren, kombinieren und widerrufen. Smart Accounts gibt es auf Ethereum seit 2018; Safe ist das bekannteste Beispiel. Es fehlte eine Möglichkeit, sie zum Standard zu machen und Transaktionen zu senden, ohne dass zuvor ein EOA das Gas bezahlt. ERC-4337 und EIP-7702 haben diese Lücke geschlossen.

Wie es dazu kam: ein kurzer Überblick über die Account-Abstraktion

Die Idee, EOAs und Contracts zusammenzuführen, ist so alt wie Ethereum selbst. Vitaliks EIP-86 aus dem Jahr 2016 war der erste detaillierte Vorschlag. Von dort bis zu den heute eingesetzten Standards waren fünf Anläufe nötig.

• EIP-2938 (September 2020) schlug eine Account-Abstraktion auf Protokollebene vor. Der Vorschlag wurde aufgegeben: Er griff zu stark in das Protokoll ein, und Ethereum steckte mitten im Übergang zu Proof of Stake.
• EIP-3074 (Oktober 2020) führte die Opcodes AUTH und AUTHCALL ein. Damit konnte ein EOA seine Befugnisse an einen Invoker-Contract delegieren. Der Vorschlag wurde wegen Sicherheitsbedenken zurückgezogen und ersetzt.
• ERC-4337 wurde am 1. März 2023 im Ethereum-Mainnet eingeführt. Der Standard funktioniert ausschließlich auf Anwendungsebene und erfordert keine Hard Fork. Pseudo-Transaktionen namens UserOperations werden über einen separaten Mempool, einen Bundler und einen Singleton-EntryPoint-Contract weitergeleitet.
• EIP-7702 wurde mit dem Upgrade Pectra am 7. Mai 2025 eingeführt. Der Standard führt den Transaktionstyp 0x04 ein. Dabei signiert ein EOA ein Autorisierungstupel (chain_id, address, nonce, y_parity, r, s), das den Account über den Indikator 0xef0100 || address auf delegierten Contract-Code verweist. Das EOA verhält sich vorübergehend wie ein Smart Account, ohne dass Mittel migriert werden müssen.
• ERC-6900 standardisiert die modulare Plug-in-Architektur, mit der Smart Accounts Validierungs-, Ausführungs- und Hook-Module kombinieren.

Die zentrale Erkenntnis: Account-Abstraktion ist kein Experiment mehr. Sie ist ein eingesetzter, mehrschichtiger Standard: ERC-4337 bietet einen direkten Weg für neue Smart Accounts, und mit EIP-7702 kann jeder bestehende EOA die Funktion nutzen.

Die fünf Funktionen, die ein Smart Account bietet

Wenn ein EOA für „ein Schlüssel, eine Signatur, eine Transaktion“ steht, bietet ein Smart Account all das und mehr.

• Programmierbare Validierung. Jedes Signaturverfahren (Passkey, P-256, Hardware-HSM), jede erforderliche Anzahl von Unterzeichnern (zwei von drei, drei von fünf) und jede Bedingung (Blockhöhe, Oracle-Preis) ist möglich. Der Account legt fest, was als „autorisiert“ gilt.
• Atomare Bündelung. Freigabe, Swap und Einzahlung lassen sich in einer einzigen signierten Aktion ausführen. Entweder wird alles ausgeführt oder nichts davon. Damit entfällt unmittelbar der Freigabeaufwand und das Multisig-Muster in Zelcore, mit denen sich Nutzer bisher manuell behelfen mussten.
• Gas-Abstraktion durch Paymaster. Ein Drittanbieter-Contract bezahlt das Gas im Namen des Nutzers. Alternativ kann der Nutzer in USDC, USDT oder einem beliebigen ERC-20 zahlen, den der Paymaster akzeptiert. Eine vertiefte Erklärung dazu, wie Gas, Freigaben und DeFi-Mechanismen zusammenspielen, finden Sie im Beitrag zu den DeFi-Grundlagen, der dafür vorausgesetzt wird.
• Sitzungsschlüssel. Signaturschlüssel mit eingeschränkten Befugnissen, begrenzter Laufzeit und Bindung an eine bestimmte App. „Dieser Schlüssel darf in den nächsten 24 Stunden bis zu 100 USDC auf Uniswap ausgeben.“ Wird ein Sitzungsschlüssel kompromittiert, begrenzen die festgelegten Regeln den Schaden, nicht der Umfang des Accounts.
• Wiederherstellung. Soziale Wiederherstellung, Wiederherstellung über Hardware oder mit Zeitsperre. Der Account lässt sich ohne den ursprünglichen Signaturschlüssel wiederherstellen. Damit wird die Seed-Phrase endgültig als einzelner Ausfallpunkt überflüssig.

Warum Selbstverwahrung heute davon abhängt

Die Frage, ob sich dieser Ansatz durchsetzt, stellt sich nicht mehr. EIP-7702 verzeichnete in der ersten Woche nach Pectra mehr als 11.000 Autorisierungen und überschritt kurz darauf die Marke von 25.000 Wallets. OKX und MetaMask lagen dabei vorn. Die laufenden Zahlen von BundleBear (1,07B UserOps, 56,7M Smart Accounts) zeigen das übrige Ausmaß.

Was sich tatsächlich ändert, ist das Bedrohungsmodell. Bei einer EOA lautet die Aufgabe der Nutzer: „Die Seed-Phrase für immer schützen, niemals eine schädliche Transaktion signieren, niemals auf Phishing hereinfallen und niemals das falsche Gerät wiederverwenden.“ Nachweislich scheitern Menschen an dieser Aufgabe. Bei einem Smart Account lautet die Aufgabe: „Ein Wiederherstellungsquorum und eine Ausgabenregel einmalig konfigurieren.“ Diese Aufgabe kann Code zuverlässig durchsetzen.

Ein Smart Account ersetzt keine Hardware-Wallet. Er ermöglicht es einer Hardware-Wallet, mehr zu leisten. Tatsächlich beschränkt er die Rolle, die eine Hardware-Wallet bei einem Smart Account weiterhin übernimmt, auf ihren wirkungsvollsten Einsatz: das Signieren wichtiger, seltener Master-Operationen, während Sitzungsschlüssel den Alltag abdecken.

Wie es in dieser Reihe weitergeht

Dieser Teil hat den Rahmen abgesteckt. Die weiteren Teile behandeln die praktische Umsetzung.

• Teil 2 erläutert den ERC-4337-Stack: UserOperations, Bundler, EntryPoint, Paymasters und mögliche Fehlerquellen der einzelnen Komponenten.
• Teil 3 behandelt die Delegation durch EIP-7702 im Detail: das Autorisierungstupel, den 0xef0100-Indikator und die Sicherheitsaspekte, wenn Sie Ihre EOA auf den Code einer anderen Person verweisen.
• Teil 4 vergleicht die wichtigsten Implementierungen von Smart Accounts (Coinbase Smart Wallet, Safe, Argent, Ambire) und zeigt, welche Standardeinstellungen sie jeweils tatsächlich verwenden.
• Teil 5 bildet den praktischen Abschluss: Sie erfahren, wie Sie Wiederherstellung, Sitzungsschlüssel und Ausgabenregeln für ein echtes Konto konfigurieren, ohne die Selbstverwahrung aufzugeben.

Der eine Satz, den Sie in Teil 2 mitnehmen sollten: Eine EOA ist ein Schlüssel mit einer Adresse; ein Smart Account ist ein Vertrag, der festlegt, was sein Schlüssel tun darf.