EIP-7702 macht Wallet UX zur Produktentscheidung
Account Abstraction klang lange nach Wallet-Infrastruktur. 2026 wird daraus ein Produktdesign-Thema, weil klassische Externally Owned Accounts über EIP-7702 Smart-Account-Verhalten erhalten können, während ERC-4337-Infrastruktur weiter Smart Wallets, User Operations, Bundler und Paymasters ermöglicht. Für Nutzer ist das Versprechen einfach: weniger verwirrende Transaktionen, weniger Gas-Reibung und bessere Recovery. Für Produktteams wird die Verantwortung größer: Die App muss erklären, was passiert, bevor eine Signatur das Verhalten eines Accounts verändert.
Die Suchintention hinter EIP-7702 ist praktisch. Teams fragen nicht nur, was der Vorschlag technisch macht. Sie wollen wissen, wie Wallet-Upgrades, gebündelte Aktionen, gesponserte Gas-Kosten und Recovery-Flows in einer echten App aussehen sollten, ohne jede Interaktion in Protokollunterricht zu verwandeln.
Den Account-Zustand vor der Transaktion gestalten
Das erste UX-Problem ist der Account-Zustand. Ein Nutzer kann mit einem klassischen EOA, einer Smart Wallet, einem delegierten EIP-7702-Account, einer Wallet mit Account-Abstraction-Support nur auf bestimmten Chains oder einer Wallet mit eigener Advanced-Feature-Oberfläche kommen. Das Produkt sollte diese Unterschiede nicht hinter einem generischen Connect-Button verstecken und den Nutzer dann beim Signieren überraschen.
Ein guter Flow trennt Verbindung, Capability-Erkennung und Aktionsvorschau. Die Oberfläche kann zeigen, ob Batching, Gas-Sponsoring oder Recovery verfügbar ist, bevor der Nutzer eine teure Aktion startet. Falls ein Upgrade oder eine Delegation nötig ist, sollte die App Nutzen, Vertrag, Chain, Widerrufspfad und verbleibende Einzelgenehmigungen klar erklären.
- Aktuellen Account-Modus verständlich zeigen: Standard-Wallet, Smart Wallet oder aktualisierter Account.
- Vor dem Wallet-Prompt erklären, warum ein Upgrade angefragt wird.
- Chain, Vertrag und Wallet-Capability im Flow benennen.
- Fallback für Wallets behalten, die dieselben Account-Abstraction-Features nicht unterstützen.
- Widerruf, Support und Recovery nach Aktivierung sichtbar machen.
Batching muss wie eine Nutzerabsicht lesbar sein
Gebündelte Transaktionen sind einer der sichtbarsten UX-Gewinne. Statt genehmigen, signieren, warten und erneut signieren kann der Nutzer eine mehrstufige Aktion in einem Flow abschließen. Das hilft nur, wenn der Batch verständlich ist. Eine Batch-Vorschau sollte wie ein Beleg der Absicht wirken, nicht wie ein komprimiertes technisches Log.
Ein Staking-, Checkout- oder Marketplace-Flow kann zum Beispiel Token Approval, Contract Interaction und Fee Handling enthalten. Die UI sollte diese Schritte zum erwarteten Ergebnis gruppieren und technische Details trotzdem ausklappbar lassen. Der Nutzer braucht genug Information, um einen gefährlichen Zusatzschritt vor der Signatur zu erkennen.
- Den Batch als ein Ergebnis zusammenfassen: kaufen, abonnieren, claimen, staken oder Zugriff aktualisieren.
- Asset-Bewegungen, Berechtigungen und irreversible Schritte getrennt zeigen.
- Offene Approvals, Delegate Permissions oder Contract-Upgrades hervorheben.
- Simulationsergebnisse und Fehlerzustände vor dem Wallet-Prompt sichtbar halten.
- Nach Abschluss zeigen, was sich geändert hat und welche Berechtigungen aktiv bleiben.
Gas-Sponsoring braucht Produktregeln
Paymasters können Onboarding deutlich leichter machen, weil ein Nutzer ein Produkt ausprobieren kann, ohne vorher ETH zu besitzen. Das heißt aber nicht, dass jede Transaktion gesponsert werden sollte. Gas-Sponsoring ist gleichzeitig Geschäftsregel, Risikokontrolle und Support-Thema.
Ein guter Produktplan definiert Sponsoring-Grenzen früh: welche Aktionen abgedeckt sind, für welche Nutzer, auf welchen Chains, mit welchen Abuse-Limits und was passiert, wenn Sponsoring nicht verfügbar ist. Nutzer sollten nicht erst im letzten Schritt erfahren, dass eine Transaktion plötzlich native Gas-Kosten braucht, weil sich Quote, Region, Wallet oder Risikoregel geändert haben.
Sicherheitswarnungen müssen zum neuen Risiko passen
EIP-7702 und Smart-Account-Flows verbessern Bedienbarkeit, verändern aber auch die Form von Consent. Eine bösartige Delegation, ein versteckter Batch oder eine unklare Berechtigung kann gefährlicher sein als eine vertraute Einzelgenehmigung. Wallet und App teilen sich die Verantwortung, dieses Risiko lesbar zu machen.
Produkttexte sollten beide Extreme vermeiden: Sie sollten Nutzer nicht mit Protokolljargon erschrecken und nicht jede Advanced-Account-Aktion in einen freundlichen grünen Button pressen. Der bessere Weg ist progressive Disclosure: zuerst eine klare menschliche Zusammenfassung, danach Contract-, Berechtigungs- und Widerrufsdetails für Nutzer, die prüfen wollen.
- Account-Upgrades, Delegationsänderungen und breite Berechtigungen als High-Attention-Momente behandeln.
- Normales Signieren, Spending Approval und Änderungen am Account-Verhalten visuell unterscheiden.
- Mehrere Asset-Bewegungen nicht in einer optimistischen Erfolgsmeldung verstecken.
- Wallet-Capability, Signaturanfrage und abgeschlossenen Transaktionszustand für Support protokollieren.
- Support-Skripte für Nutzer vorbereiten, die ungewohnte Wallet-Warnungen sehen.
Ein praktischer Build-Plan für Web3-Produkte
Für EDS Labs Projekte ist der richtige Startpunkt eine Capability Map. Welche Wallets und Chains sind für den ersten Release wichtig? Welche Flows profitieren wirklich von Batching? Wo lohnt sich Gas-Sponsoring trotz operativer Kosten? Welchen Recovery-Pfad muss das Produkt erklären? Diese Entscheidungen gehören in die Produktspezifikation, bevor Smart Contracts, Frontend-State und Support-Material auseinanderlaufen.
Das Ziel ist nicht, jedes Account-Abstraction-Feature sichtbar zu machen. Das Ziel ist, den sichersten nützlichen Pfad einfach wirken zu lassen: Wallet verbinden, Account-Zustand verstehen, eine klare Absicht prüfen, mit Vertrauen signieren und Fehler beheben, ohne raten zu müssen, was on-chain passiert ist.