Wallet-Architektur · Stand 2026-08-30

Account Abstraction erklärt: Smart Accounts und ERC-4337

Account Abstraction macht Autorisierung programmierbarer. Das kann Batching, Sponsoring oder Recovery ermöglichen, garantiert aber keine bestimmte Funktion, Sicherheit oder Gebühr.

Wallet-Grundlagen Gebühren prüfen

Kurzfassung

Account Abstraction ist ein Architekturprinzip, keine einzelne Wallet-Funktion.
ERC-4337 führt UserOperations, Bundler und einen EntryPoint-Vertrag ein.
Der Account prüft die Autorisierung; der Bundler übermittelt die gebündelte Transaktion.
Paymaster-Sponsoring ist optional und kann Bedingungen oder andere Kosten haben.
Passkeys, Recovery, Batching und Session-Rechte hängen von der Implementierung ab.
EIP-7702 delegiert EOA-Code und hat eigene Sicherheits- und Widerrufsfragen.

1. EOA, Smart Contract Account und delegierter EOA

Ethereum unterscheidet unter anderem Externally Owned Accounts (EOA) und Contract Accounts. Beim EOA erzwingt das Protokoll eine feste Signaturregel. Ein Contract Account wird von Code gesteuert und reagiert auf Aufrufe.

Account Abstraction ermöglicht flexiblere Account-Logik. ERC-4337 baut dafür ein zusätzliches UserOperation-System oberhalb des Konsensprotokolls. EIP-7702 ist ein anderer Weg: Ein EOA kann Codeausführung an eine Implementierung delegieren. Diese Fälle dürfen nicht als identische Wallet-Architektur behandelt werden.

2. ERC-4337 in fünf Stationen

Eine Wallet erstellt eine UserOperation mit Account, Calls, Gasgrenzen und Autorisierungsdaten.
Ein Bundler simuliert und prüft, ob die UserOperation die geltenden Regeln erfüllt.
Der Bundler kann mehrere gültige UserOperations in eine normale Transaktion bündeln.
Diese Transaktion ruft handleOps am EntryPoint-Vertrag auf.
Der Account validiert die Autorisierung; danach führt der EntryPoint die zulässigen Calls aus und verrechnet die Kosten.

Eine UserOperation ähnelt einer Transaktion, ist laut Spezifikation aber bewusst anders benannt. Sie enthält zusätzliche Felder für Account-Erstellung, Validierung, Gas und optional einen Paymaster. Ihre Signaturbedeutung wird vom Account festgelegt.

3. Bundler signieren nicht automatisch für Nutzer

Ein Bundler nimmt UserOperations entgegen, simuliert ihre Validierung, baut ein Bundle und übermittelt die daraus entstehende Ethereum-Transaktion. Er ersetzt nicht automatisch den Signer des Nutzers. Der Smart Account beziehungsweise die delegierte Account-Logik entscheidet, welche Autorisierung akzeptiert wird.

Bundler-Verfügbarkeit, unterstützte EntryPoint-Version, Gebührenregeln und Mempool können sich unterscheiden. Ein einzelner Bundler ist deshalb kein Beleg für globale Netzwerkverfügbarkeit oder dauerhaft niedrige Gebühren.

4. Paymaster bedeutet nicht automatisch kostenlos

Ein Paymaster ist ein Vertrag, der sich bereit erklären kann, die Netzwerkgebühr einer UserOperation zu übernehmen. Der EntryPoint prüft, ob der Paymaster genug hinterlegt hat und die konkrete UserOperation akzeptiert.

Der Paymaster kann Regeln, Limits oder einen anderen Abrechnungsweg verwenden. Sponsoring kann abgelehnt werden oder ausfallen. Prüfe Netzwerkgebühr, Drittanbieter- und Protokollkosten, Tokenzahlung und Gegenleistung zusammen.

5. Mögliche Funktionen sind keine ERC-4337-Garantie

Programmierbare Account-Logik kann mehrere Owner, austauschbare Schlüssel, Passkeys, Recovery-Module, Limits, gebündelte Calls oder zeitlich und sachlich begrenzte Session-Berechtigungen unterstützen. ERC-4337 schreibt diese konkrete Produktauswahl jedoch nicht vor.

Jede zusätzliche Regel bringt eigene Fehler- und Machtpfade mit: fehlerhafter Code, gefährliche Module, falsche Limits, unklare Upgrades, kompromittierte Guardians, Relayer-Abhängigkeit oder eine zu weit gefasste Session. Bewerte deshalb Code, Owner, Upgrade- und Recovery-Rechte gemeinsam.

6. EIP-7702: Delegation ist sicherheitskritisch

EIP-7702 erlaubt einem EOA, Code an eine andere Adresse zu delegieren. Die Spezifikation warnt, dass eine schlecht implementierte Delegation einem Angreifer weitreichende Kontrolle geben kann. Replay-Schutz, Ziel, Calldata, Wert, Gas, Initialisierung und Speicherlayout gehören deshalb in die Prüfung.

Eine Wallet sollte Nutzer nicht dazu bringen, beliebigen vorgeschlagenen Code zu autorisieren. Prüfe die Implementierung, den Widerrufsweg und alle Module, bevor eine Delegation bestätigt wird.

7. Einen Account-Abstraction-Weg in sechs Schritten prüfen

Account-Typ und Netzwerk bestimmen: Prüfe, ob du einen EOA, einen eigenständigen Smart Contract Account oder einen EIP-7702-delegierten Account verwendest und auf welchem Netzwerk er bereitsteht.
Autorisierung und Signer verstehen: Kläre, welche Schlüssel, Passkeys, Geräte, Owner oder Module eine Aktion freigeben und wie ihre Berechtigungen begrenzt sind.
Recovery und Upgrade getrennt prüfen: Dokumentiere, wie Schlüssel ersetzt, Owner geändert, Module aktualisiert oder eine Delegation widerrufen werden kann und welche Partei dabei Macht erhält.
Gebührenweg vollständig lesen: Prüfe, ob der Account selbst zahlt, ein Paymaster nur unter Bedingungen sponsert oder ein Token- beziehungsweise Drittanbieterweg zusätzliche Kosten erzeugt.
Gebündelte Calls einzeln kontrollieren: Eine Bestätigung kann mehrere Aufrufe enthalten. Prüfe Ziel, Methode, Betrag, Token-Berechtigung und Ergebnis jedes Calls.
Ausfall- und Wechselweg testen: Teste mit kleinem Wert, was bei Bundler-, Paymaster-, Frontend-, Signer- oder Recovery-Ausfall geschieht und wie du den Anbieter oder Account-Weg wechselst.

8. ChainATM richtig einordnen

Das standardmäßig eingebettete ChainATM Wallet wird von Privy bereitgestellt. Privy dokumentiert Embedded Wallets und separat aktivierbare Smart Wallets. Daraus folgt ohne aktuelle Implementierungs- und Produktbelege nicht, dass ChainATM einen Smart Account, ERC-4337, EIP-7702, einen Paymaster, Gas-Sponsoring, Batching oder ein bestimmtes Recovery-Modul nutzt.

Diese Seite ist kein Verfügbarkeitsnachweis. Prüfe im aktuellen Produktweg Account, Netzwerk, Signer, Freigabe, Gebührenzahler, Calls und Recovery. Eine getippte oder gesprochene Anfrage ist keine Freigabe.

Offizielle Quellen

Häufige Fragen

Was ist Account Abstraction einfach erklärt?

Account Abstraction beschreibt Modelle, bei denen ein Account seine Autorisierungslogik programmierbarer gestalten kann. Statt ausschließlich der festen EOA-Regel zu folgen, kann Account-Code zum Beispiel mehrere Owner, austauschbare Schlüssel oder begrenzte Berechtigungen prüfen. Welche Funktionen tatsächlich existieren, bestimmt die konkrete Implementierung.

Was ist der Unterschied zwischen EOA und Smart Account?

Ein EOA wird auf Protokollebene durch einen privaten Schlüssel und die feste Signaturregel kontrolliert. Ein Smart Contract Account ist Code auf dem Netzwerk und kann eigene Validierungs- und Ausführungsregeln besitzen. Ein EIP-7702-delegierter EOA ist ein weiterer Fall: Die Adresse bleibt ein EOA, verweist aber für Codeausführung auf eine delegierte Implementierung.

Wie funktioniert ERC-4337?

Der Nutzer oder die Wallet erzeugt eine UserOperation. Ein Bundler validiert sie nach den ERC-4337-Regeln, kann mehrere UserOperations bündeln und sendet eine normale Transaktion an den EntryPoint-Vertrag. Der EntryPoint lässt den Smart Account seine Autorisierung prüfen und führt danach die zulässigen Calls aus.

Signiert ein Bundler für den Nutzer?

Nein, nicht allein aufgrund seiner Bundler-Rolle. Der Bundler simuliert, bündelt und übermittelt UserOperations. Die Bedeutung des Signaturfelds und die Autorisierungsprüfung bestimmt die Smart-Account-Implementierung. Ein Betreiber kann zusätzliche Rollen haben, aber das muss separat belegt und bewertet werden.

Sind Transaktionen mit Paymaster kostenlos?

Nicht automatisch. Ein Paymaster erklärt sich unter eigener Logik bereit, die Netzwerkgebühr zu übernehmen, und muss dafür Mittel beim EntryPoint hinterlegt haben. Er kann Bedingungen, Limits, Zulassungsregeln oder einen anderen Zahlungsweg verwenden. Prüfe deshalb Sponsoring, Gegenleistung, Drittanbieterkosten und Ausfallverhalten im konkreten Ablauf.

Braucht ein Smart Account keine Seed Phrase oder Private Keys?

Account Abstraction beseitigt Autorisierungsgeheimnisse nicht. Ein Smart Account kann mehrere Schlüssel, Passkeys, Geräte, Guardians oder andere Module verwenden und einen Schlüsselwechsel erlauben. Ob eine Seed Phrase sichtbar ist, wie Recovery funktioniert und wer Faktoren kontrolliert, hängt von Wallet, Signer und Account-Code ab.

Sind Passkeys, Social Recovery und Session Keys Teil von ERC-4337?

ERC-4337 ermöglicht programmierbare Account-Validierung, schreibt diese Funktionen aber nicht für jeden Account vor. Passkeys, mehrere Owner, Recovery-Module, Session-Berechtigungen und Limits müssen von der konkreten Account- und Wallet-Implementierung unterstützt und sicher konfiguriert werden.

Ist Account Abstraction automatisch sicherer oder günstiger?

Nein. Programmierbare Regeln können bestimmte Risiken reduzieren, vergrößern aber auch Code-, Modul-, Upgrade-, Recovery-, Relayer- und Bedienrisiken. Batching oder Sponsoring kann die Nutzererfahrung verändern, beweist aber weder niedrigere Gesamtkosten noch sichere Ausführung. Prüfe die vollständige Vorschau und den Account-Code.

Nutzt ChainATM ERC-4337 oder Smart Accounts?

Diese Seite belegt das nicht. Das standardmäßig eingebettete ChainATM Wallet wird von Privy bereitgestellt. Privys dokumentierte Smart-Wallet-Funktion ist separat zu aktivieren; daraus darf ohne aktuelle Implementierungs- und Produktbelege kein ChainATM Smart Account, Paymaster, Gas-Sponsoring oder Recovery-Modul abgeleitet werden.