--- title: "Account Abstraction in Produktion" canonical: https://wavect.io/de/blog/account-abstraction-erc4337-production/ language: de description: "Was ERC-4337 Account Abstraction in Produktion löst, was nicht und welche neuen Angriffsflächen es einführt. Gasless UX, Social Recovery." image: "https://wavect.io/img/blog/headers/header_account-abstraction-erc4337-production.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min Lesezeit · 26. Mai 2026 [**Weiter**](/de/blog/smart-contract-security-checklist-pre-audit/) # Account Abstraction (ERC-4337) in Produktion: Was es wirklich löst, was nicht TL;DR Account Abstraction (ERC-4337) ist ein UX-Fortschritt, kein Security-Fortschritt: Es löst Gasless UX, Batching, Social Recovery, Session Keys und Passkeys, aber nicht Bundler-Zentralisierung, Paymaster-Ökonomie oder Guardian-Vertrauen, und es bringt neue Angriffsflächen mit, die ein eigenes Audit brauchen. Die pragmatische Position 2026: Default zu AA für Consumer-Produkte, EOA für technische Nutzer, EIP-7702 wenn du nur einen Teil des AA-Werkzeugkastens brauchst. ERC-4337 ist lange genug live, um kein Gedankenexperiment mehr zu sein. Wir haben [Account-Abstraction](/de/glossary/account-abstraction/) -Wallets in Produktion für Kunden ausgeliefert (siehe [unsere AA-Case-Study](/de/case-studies/account-abstraction/) und [MetaMask-Snap-Arbeit](/de/case-studies/metamask-snap/)). Die ehrliche Zusammenfassung: AA ist ein UX-Fortschritt, kein Security-Fortschritt. Es räumt eine lange Liste von Papercuts weg, über die sich Nutzer beschweren, und handelt sich dafür eine kürzere Liste neuer Angriffsflächen ein, über die sich Engineers beschweren. Dieser Beitrag zerlegt genau das: was es löst, was nicht, und die Fragen, die wir von Kunden hören, bevor sie sich entscheiden. ## Was ist ERC-4337 in einem Absatz? Ein Standard, der es einem Smart Contract erlaubt, als Account eines Nutzers zu agieren, ohne das zugrundeliegende [EVM](/de/glossary/evm/) -Protokoll zu ändern. Der Nutzer signiert eine UserOperation, ein Bundler verpackt sie, ein Paymaster zahlt optional das Gas, und ein Entry-Point-Contract validiert und führt sie aus. Das Endergebnis: Der Nutzer braucht kein ETH, um zu transagieren, kann statt einer Seed-Phrase einen Passkey oder Social Recovery verwenden und mehrere Aktionen in einer einzigen Freigabe bündeln. ERC-4337 ist der Standard; spezifische Wallet-Implementierungen (Safe, Kernel, Biconomy, Alchemys Light Account, ZeroDev) legen Features darüber. ## Was löst AA in Produktion wirklich? - **Gasless UX via Paymaster.** Der Nutzer hält kein ETH. Jemand anderes (du, ein Sponsor-Contract, ein Token-in-Token-Swap) zahlt das Gas. Diese einzelne Änderung schließt die größte Onboarding-Lücke in EVM-Produkten. - **Batched Transactions.** Approve plus Swap in einer Signatur. Approve plus Deposit plus Stake in einer Signatur. Weniger Prompts, weniger abgebrochene Flows. - **Social Recovery.** Guardians können den Signing-Key rotieren, ohne die Funds zu bewegen. Nutzer verlieren keine Wallets mehr wegen verlorener Seed-Phrasen. - **Session Keys.** Zeitbegrenzte, scope-begrenzte Signing-Rechte. Der Nutzer signiert einmal, die dApp kann innerhalb der Grenzen ohne weitere Prompts handeln. Ein enormer Gewinn für Games und High-Frequency-Produkte. - **Rollenbasierte Spending Policies.** "Trade bis 500 $ pro Tag auf diesem DEX, alles andere braucht eine Guardian-Signatur." Echte Policy-Engines im Wallet, nicht in der App. - **Passkeys und WebAuthn.** Signieren mit Fingerabdruck oder Device-Passkey statt Seed-Phrase. Massiver UX-Gewinn für nicht-crypto-native Nutzer. ## Was löst AA nicht? - **Bundler-Zentralisierung.** Der meiste Produktions-Traffic läuft über eine Handvoll Bundler-Operatoren. Zensur- und Uptime-Risiko konzentrieren sich dort. - **Paymaster-Ökonomie.** Irgendwer zahlt am Ende das Gas. Wenn das du bist, brauchst du ein Budget, eine Quota und eine Sybil-Protection-Strategie. - **Social-Engineering-Recovery-Angriffe.** Wenn dein Recovery-Flow einer E-Mail oder Telefonnummer vertraut, ist das dein neues schwächstes Glied. Recovery klingt sicher; es ist nur so sicher wie die Guardians, die du wählst. - **Multi-Chain-Wallet-UX.** Jede Chain hat ihren eigenen AA-Deployment, ihren eigenen Bundler, ihren eigenen Paymaster. Das nutzerseitige Wallet versteckt das; das Engineering-Team spürt es. - **dApp-Signing-UX-Verwirrung.** EIP-712 Typed Data ist für die meisten Nutzer immer noch verwirrend. AA ändert nicht, was der Nutzer signieren soll. - **Das fundamentale "Was macht diese Transaktion"-Problem.** Eine gebatchte UserOperation ist schwerer sicher anzuzeigen als ein einzelner Transfer. UX-Arbeit ist weiterhin nötig. ## Welche neuen Angriffsflächen führt AA ein? Nicht "kleiner". Einfach "anders". Erwähnenswert, weil wir sie in Engagements sehen, die ein ernsthaftes Threat Model übersprungen haben. 1. **Paymaster-Spoofing.** Wenn deine Paymaster-Validierungslogik schlampig ist, kann ein Angreifer das Paymaster-Budget leeren, indem er gesponserte Ops triggert, die nicht hätten qualifizieren dürfen. 2. **Signature-Aggregator-Eigenheiten.** Aggregierte Signaturschemata haben subtile Malleability- und Replay-Überlegungen. Sie brauchen ihren eigenen Audit. 3. **Init-Code-Phishing.** Das erste Deployment eines Wallets enthält Init-Code. Eine bösartige dApp kann Init-Code vorschlagen, der das Wallet ab Tag eins backdoored. 4. **UserOperation-Simulation-Drift.** Der State, den der Bundler bei der Simulation sieht, muss nicht dem Execution-State entsprechen. Schlecht gehandhabt wird das zum Griefing-Vektor. 5. **Session-Key-Over-Scoping.** Leicht zu vergeben, leicht zu vergessen. Wir haben dApps gesehen, die Session Keys mit breiterem Scope angefragt haben, als sie tatsächlich brauchten. 6. **Guardian-Kollusion.** Social Recovery verlagert das Vertrauen von der Seed-Phrase auf das Guardian-Set. Wähle entsprechend. ## Schneller Vergleich: EOA vs AA | Punkt | EOA (heute) | AA (ERC-4337) | | --- | --- | --- | | Seed-Phrase nötig | Ja | Nein (Passkey, Social oder Hybrid) | | Nutzer hält Gas-Token | Ja | Optional (Paymaster deckt ab) | | Batch in einer Signatur | Nein | Ja | | Recovery bei Key-Verlust | Nein (Game over) | Ja (Guardians oder Hybrid) | | Kosten pro Transaktion | Niedriger | Höher (Entry-Point-Overhead) | | Audit-Fläche | Klein | Größer (Wallet-Contract + Paymaster) | | Zensur-Risiko | Validator-Ebene | Validator + Bundler-Ebene | ![Kevin Riedl](/img/team/kevin.webp) "AA ist UX-Fortschritt, kein Security-Fortschritt. Behandle es so, und du wirst es richtig scopen." ## Q&A: Brauchen wir noch EOAs? Ja, vorerst. EOAs sind immer noch einfacher, günstiger pro Transaktion und haben eine viel kleinere Audit-Fläche. Für hochfrequente Transaktionen mit niedrigem Einsatz von technischen Nutzern sind EOAs in Ordnung. Für Consumer-Onboarding ist AA das richtige Default. Wir liefern häufig Hybrid-Produkte aus: AA für den Consumer-Flow, EOA für Power-User- oder Operator-Flows. ## Q&A: Ist AA günstiger oder einfach schöner? Pro Transaktion kostet AA mehr Gas als ein EOA, weil der Entry-Point und der Wallet-Contract zusätzliche Validierungsarbeit leisten. Die User Experience ist günstiger (weniger Signatur-Prompts, kein Vorab-Kauf von ETH nötig). Die Gebühren-Ökonomie kippt erst, wenn du genug Operations in eine UserOperation batchst, sodass die Kosten pro Op unter das EOA-Äquivalent fallen. Beim Batching geht die Gas-Rechnung auf. ## Q&A: Können wir unseren eigenen Bundler betreiben? Ja. Mehrere Open-Source-Bundler existieren (Pimlicos Alto, Stackup, ETH-Infinitism-Referenz). Einen eigenen Bundler zu betreiben gibt dir Zensurresistenz und vorhersagbare Performance. Es gibt dir auch eine 24/7-Ops-Last, eine Node-Infrastruktur-Rechnung und ein Ziel für DDoS. Für die meisten Produkte ist ein gehosteter Bundler die pragmatische Antwort. Für Produkte, bei denen Zensurresistenz ein Kernversprechen ist, ist Self-Hosting die Arbeit wert. ## Q&A: Was ist mit EIP-7702? EIP-7702 (seit Pectra live) gibt EOAs die Möglichkeit, sich temporär wie Smart Accounts zu verhalten. Das ändert die Rechnung: Für viele Produkte, die AA hauptsächlich für Batching und gesponsertes Gas wollten, liefert EIP-7702 den meisten UX-Gewinn ohne neuen Wallet-Contract. ERC-4337 ist immer noch die richtige Antwort für volle Social Recovery, Session Keys und policy-reiche Wallets. Wir helfen Kunden, zwischen beiden zu entscheiden, basierend auf dem Produkt, nicht dem Trend. ## Q&A: Wie interagiert AA mit [Smart Contracts](/de/glossary/smart-contract/) auf anderen Chains? Jede Chain braucht ihr eigenes AA-Deployment. Die Entry-Point-Adresse, Bundler und Paymaster-Contracts sind pro Chain. Nutzer sehen ein Wallet; Engineering sieht N Deployments. Tools wie Cross-Chain-Wallet-Abstraktionen holen auf, sind aber noch grob. Plane dafür ein. ## Q&A: Brauchen wir einen Custom-Wallet-Contract? Meist nein. Safe, Kernel, Light Account und ähnliche Implementierungen sind gut auditiert und decken 90 % realer Produktbedürfnisse ab. Custom-Wallet-Contracts sind angebracht, wenn du eine spezifische Policy-Engine, ein Signaturschema oder ein Recovery-Modell hast, das die bestehenden Implementierungen nicht unterstützen. Custom ist teurer und trägt eine schwerere Audit-Last. Siehe unseren [Blockchain-Engineering-Service](/de/services/blockchain/), wie wir das scopen. Wenn eine konkrete Operation zwischen Wallet, Bundler, Paymaster und EntryPoint fehlschlägt, füge das genaue Artefakt in den kostenlosen [ERC-4337 UserOperation Debugger](/de/tools/erc-4337-useroperation-debugger/) ein. Er trennt gepackte Felder und AAxx-Fehler lokal, ohne einen weiteren RPC-Request zu senden. ## Fazit ERC-4337 in Produktion ist ein Werkzeug, keine Religion. Es löst eine echte, messbare Liste von UX-Problemen: Gas, Batching, Recovery, Session Keys, Passkeys. Es löst nicht Bundler-Zentralisierung, Paymaster-Ökonomie oder das menschliche Problem, den richtigen Guardians zu vertrauen. Es führt eine neue Audit-Fläche ein, die mit derselben Ernsthaftigkeit behandelt werden muss wie jede andere Smart-Contract-Arbeit. Die pragmatische Position 2026 ist diese: Default zu AA für consumerorientierte Produkte, bei denen Onboarding-Friction der Burggraben ist. Default zu EOA für technische Nutzer und Operatoren. Greife zu EIP-7702, wenn du nur einen Teil des AA-Werkzeugkastens brauchst. Was auch immer du wählst, modelliere die Bedrohungen, auditiere Wallet-Contract und Paymaster gemeinsam und plane die Ops-Kosten für Bundler ein. UX-Fortschritt ist echter Fortschritt; verwechsle ihn nur nicht mit einem kostenlosen Mittagessen. Teams, die AA gut ausliefern, behandeln es als Produktentscheidung mit Engineering-Zähnen. Teams, die es schlecht ausliefern, behandeln es als Marketing-Häkchen. ## Das könnte dich auch interessieren.. [**Ethereum-Gas-Preise** Warum Gas-Gebühren für die Produktökonomie wichtig sind und wie wir darum herum designen.](/de/blog/ethereum-gas-prices/) [**Wavect vs eine klassische Dev-Agentur** Generalisten verkaufen Kapazität, wir verkaufen Produkturteil plus die Engineering-Leistung, die auch ausliefert.](/de/compare/wavect-vs-dev-agencies/) Blockchain-Infrastruktur ## In diesem Cluster weiterlesen Netzwerke, Smart Contracts, Payments und Produktionsarchitektur für Web3-Systeme. [Mit dem Grundlagenartikel starten**Ethereum-zu-Solana-Migrationskosten**](/de/blog/ethereum-to-solana-migration-cost/) - [Native Rollups vs. Based Rollups](/de/blog/native-rollups-vs-based-rollups/) - [Tokenomics-Implementierung 2026: Vom Modell zur Produktion](/de/blog/tokenomics-implementation-infrastructure-2026/) - [Top 10 Web3- und Smart-Contract-Auditoren in Deutschland (2026)](/de/blog/top-smart-contract-auditors-germany/) - [x402-Zahlungen 2026: Coinbase, Stripe & Alternativen](/de/blog/x402-payments-comparison-2026/) - [Open USD erklärt: Was ein Konsortium-Stablecoin verändert](/de/blog/open-usd-stablecoin-explained-2026/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min Lesezeit · 26. Mai 2026 [**Weiter**](/de/blog/smart-contract-security-checklist-pre-audit/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/account-abstraction-erc4337-production/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/de/blog/account-abstraction-erc4337-production/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Account Abstraction (ERC-4337) ist ein UX-Fortschritt, kein Security-Fortschritt: Es löst Gasless UX, Batching, Social Recovery, Session Keys und Passkeys, aber nicht Bundler-Zentralisierung, Paymaster-Ökonomie oder Guardian-Vertrauen, und es bringt neue Angriffsflächen mit, die ein eigenes Audit brauchen. Die pragmatische Position 2026: Default zu AA für Consumer-Produkte, EOA für technische Nutzer, EIP-7702 wenn du nur einen Teil des AA-Werkzeugkastens brauchst.", "articleBody": " Blog-Übersicht/Web3 und Datenschutz/Blockchain-Infrastruktur Account Abstraction (ERC-4337) in Produktion: Was es wirklich löst, was nicht TL;DR Account Abstraction (ERC-4337) ist ein UX-Fortschritt, kein Security-Fortschritt: Es löst Gasless UX, Batching, Social Recovery, Session Keys und Passkeys, aber nicht Bundler-Zentralisierung, Paymaster-Ökonomie oder Guardian-Vertrauen, und es bringt neue Angriffsflächen mit, die ein eigenes Audit brauchen. Die pragmatische Position 2026: Default zu AA für Consumer-Produkte, EOA für technische Nutzer, EIP-7702 wenn du nur einen Teil des AA-Werkzeugkastens brauchst. ERC-4337 ist lange genug live, um kein Gedankenexperiment mehr zu sein. Wir haben Account-Abstraction-Wallets in Produktion für Kunden ausgeliefert (siehe unsere AA-Case-Study und MetaMask-Snap-Arbeit). Die ehrliche Zusammenfassung: AA ist ein UX-Fortschritt, kein Security-Fortschritt. Es räumt eine lange Liste von Papercuts weg, über die sich Nutzer beschweren, und handelt sich dafür eine kürzere Liste neuer Angriffsflächen ein, über die sich Engineers beschweren. Dieser Beitrag zerlegt genau das: was es löst, was nicht, und die Fragen, die wir von Kunden hören, bevor sie sich entscheiden. Was ist ERC-4337 in einem Absatz? Ein Standard, der es einem Smart Contract erlaubt, als Account eines Nutzers zu agieren, ohne das zugrundeliegende EVM-Protokoll zu ändern. Der Nutzer signiert eine UserOperation, ein Bundler verpackt sie, ein Paymaster zahlt optional das Gas, und ein Entry-Point-Contract validiert und führt sie aus. Das Endergebnis: Der Nutzer braucht kein ETH, um zu transagieren, kann statt einer Seed-Phrase einen Passkey oder Social Recovery verwenden und mehrere Aktionen in einer einzigen Freigabe bündeln. ERC-4337 ist der Standard; spezifische Wallet-Implementierungen (Safe, Kernel, Biconomy, Alchemys Light Account, ZeroDev) legen Features darüber. Was löst AA in Produktion wirklich? Gasless UX via Paymaster. Der Nutzer hält kein ETH. Jemand anderes (du, ein Sponsor-Contract, ein Token-in-Token-Swap) zahlt das Gas. Diese einzelne Änderung schließt die größte Onboarding-Lücke in EVM-Produkten. Batched Transactions. Approve plus Swap in einer Signatur. Approve plus Deposit plus Stake in einer Signatur. Weniger Prompts, weniger abgebrochene Flows. Social Recovery. Guardians können den Signing-Key rotieren, ohne die Funds zu bewegen. Nutzer verlieren keine Wallets mehr wegen verlorener Seed-Phrasen. Session Keys. Zeitbegrenzte, scope-begrenzte Signing-Rechte. Der Nutzer signiert einmal, die dApp kann innerhalb der Grenzen ohne weitere Prompts handeln. Ein enormer Gewinn für Games und High-Frequency-Produkte. Rollenbasierte Spending Policies. \"Trade bis 500 $ pro Tag auf diesem DEX, alles andere braucht eine Guardian-Signatur.\" Echte Policy-Engines im Wallet, nicht in der App. Passkeys und WebAuthn. Signieren mit Fingerabdruck oder Device-Passkey statt Seed-Phrase. Massiver UX-Gewinn für nicht-crypto-native Nutzer. Was löst AA nicht? Bundler-Zentralisierung. Der meiste Produktions-Traffic läuft über eine Handvoll Bundler-Operatoren. Zensur- und Uptime-Risiko konzentrieren sich dort. Paymaster-Ökonomie. Irgendwer zahlt am Ende das Gas. Wenn das du bist, brauchst du ein Budget, eine Quota und eine Sybil-Protection-Strategie. Social-Engineering-Recovery-Angriffe. Wenn dein Recovery-Flow einer E-Mail oder Telefonnummer vertraut, ist das dein neues schwächstes Glied. Recovery klingt sicher; es ist nur so sicher wie die Guardians, die du wählst. Multi-Chain-Wallet-UX. Jede Chain hat ihren eigenen AA-Deployment, ihren eigenen Bundler, ihren eigenen Paymaster. Das nutzerseitige Wallet versteckt das; das Engineering-Team spürt es. dApp-Signing-UX-Verwirrung. EIP-712 Typed Data ist für die meisten Nutzer immer noch verwirrend. AA ändert nicht, was der Nutzer signieren soll. Das fundamentale \"Was macht diese Transaktion\"-Problem. Eine gebatchte UserOperation ist schwerer sicher anzuzeigen als ein einzelner Transfer. UX-Arbeit ist weiterhin nötig. Welche neuen Angriffsflächen führt AA ein? Nicht \"kleiner\". Einfach \"anders\". Erwähnenswert, weil wir sie in Engagements sehen, die ein ernsthaftes Threat Model übersprungen haben. Paymaster-Spoofing. Wenn deine Paymaster-Validierungslogik schlampig ist, kann ein Angreifer das Paymaster-Budget leeren, indem er gesponserte Ops triggert, die nicht hätten qualifizieren dürfen. Signature-Aggregator-Eigenheiten. Aggregierte Signaturschemata haben subtile Malleability- und Replay-Überlegungen. Sie brauchen ihren eigenen Audit. Init-Code-Phishing. Das erste Deployment eines Wallets enthält Init-Code. Eine bösartige dApp kann Init-Code vorschlagen, der das Wallet ab Tag eins backdoored. UserOperation-Simulation-Drift. Der State, den der Bundler bei der Simulation sieht, muss nicht dem Execution-State entsprechen. Schlecht gehandhabt wird das zum Griefing-Vektor. Session-Key-Over-Scoping. Leicht zu vergeben, leicht zu vergessen. Wir haben dApps gesehen, die Session Keys mit", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-07", "datePublished": "2026-05-26", "description": "Account Abstraction (ERC-4337) ist ein UX-Fortschritt, kein Security-Fortschritt: Es löst Gasless UX, Batching, Social Recovery, Session Keys und Passkeys, aber nicht Bundler-Zentralisierung, Paymaster-Ökonomie oder Guardian-Vertrauen, und es bringt neue Angriffsflächen mit, die ein eigenes Audit brauchen. Die pragmatische Position 2026: Default zu AA für Consumer-Produkte, EOA für technische Nutzer, EIP-7702 wenn du nur einen Teil des AA-Werkzeugkastens brauchst.", "headline": "Account Abstraction in Produktion", "image": "https://wavect.io/img/blog/headers/header_account-abstraction-erc4337-production.svg", "inLanguage": "de", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/account-abstraction-erc4337-production/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/account-abstraction-erc4337-production/", "wordCount": 1460 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/web3-privacy/", "name": "Web3 und Datenschutz", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/blockchain-infrastructure/", "name": "Blockchain-Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/account-abstraction-erc4337-production/", "name": "Account Abstraction in Produktion | ", "position": 5 } ] } ```