Ethereum en Base werken op dinsdag 15 september niet langer toe naar een native standaard voor slimme wallets. Volgens Derek Chiang van Ethlabs, aangehaald door crypto.news, liep de poging om Base-voorstel EIP-8130 te verenigen met Ethereumvoorstel EIP-8141 vorige week vast. Beide voorstellen blijven concepten, maar de route voor walletbouwers wordt minder eenduidig.
| Wat je moet weten |
|---|
| 1Ethereum en Base stoppen de poging om EIP-8130 en EIP-8141 tot een standaard te brengen. |
| 2Beide voorstellen blijven concepten; er is dus geen directe wijziging voor wallets vandaag. |
| 3EIP-8141 werkt met programmeerbare frames, EIP-8130 met keystore-accounts en expliciete authenticators. |
| 4Wallets en apps moeten mogelijk twee native routes ondersteunen als beide ontwerpen doorgaan. |
De aanleiding is een bericht van Chiang op X over de account-abstraction samenwerking rond EIP-8130 en EIP-8141. Hij stelde dat de auteurs vorige week zijn gestopt met het zoeken naar een gedeelde specificatie. Daarmee is de technische discussie niet klaar, maar wel verschoven: de voorstellen bewegen voorlopig naast elkaar verder.
De kern is dat Ethereum met EIP-8141 een programmeerbare frame-transactie wil gebruiken, terwijl Base met EIP-8130 kiest voor keystore-accounts die hun authenticator vooraf aangeven. Daardoor verschuift de praktische last naar wallets en apps: zij moeten mogelijk herkennen welke transactieroute per netwerk nodig is, zonder dat gebruikers vandaag hun wallet hoeven aan te passen.
Wat precies vastliep
Ethlabs schreef op 7 september nog dat het juist een werkgroep had opgezet om fragmentatie in het EVM-ecosysteem te voorkomen. In die weekupdate stond dat Base EIP-8130 naar voren schoof, terwijl Ethereum werkte aan EIP-8141, ook bekend als Frame Transactions. Het doel was om de voordelen van beide ontwerpen te combineren.
Die poging is volgens de nieuwe berichtgeving niet gelukt. Het verschil zit niet alleen in naamgeving, maar in de plaats waar validatie en flexibiliteit worden gelegd. Ethereum wil met EIP-8141 een transactietype waarin meerdere frames validatie, gasbetaling en uitvoering kunnen afhandelen. Base legt met EIP-8130 juist nadruk op een onchain accountconfiguratie en een vooraf genoemde authenticator, zodat nodes transacties voorspelbaar kunnen beoordelen.
Twee ontwerpen, twee prioriteiten
De EIP-8141 specificatie beschrijft een frame-transactie als een reeks frames die onder meer validatie, gasbetaling en uitvoering scheiden. Dat moet walletfuncties als sleutelrotatie, batchtransacties en alternatieve fee-betaling native mogelijk maken.
De EIP-8130 specificatie kiest een andere route. Accounts verwijzen naar een keystore en transacties noemen expliciet welke authenticator wordt gebruikt. Volgens het voorstel moet dat custom authenticatie, batching en gas-sponsoring mogelijk maken, terwijl validatie voorspelbaar blijft voor verschillende EVM-ketens.
Voor Nederlandse gebruikers klinkt dat technisch, maar het raakt uiteindelijk aan gewone walletvragen: kan een wallet op meerdere netwerken dezelfde manier van inloggen, betalen en transacties bundelen aanbieden? Als de standaarden uiteenlopen, ligt meer integratiewerk bij walletmakers, apps en infrastructuurpartijen.
Geen directe verandering voor gebruikers
Belangrijk is dat beide voorstellen nog draftstatus hebben. Er is vandaag geen walletmigratie, geen verplicht netwerkbesluit en geen harde datum waarop gebruikers iets moeten aanpassen. De relevantie zit in de routekaart: als Ethereum en Base hun eigen pad houden, kan de smart-wallet ervaring per netwerk sterker verschillen.
CryptoFocus schreef eerder over de gevolgen van gas betalen zonder ETH bij EIP-8141. Dit nieuwe conflict maakt die discussie breder. Het gaat niet alleen om wie gas betaalt, maar om welk transactiemodel de basis wordt voor wallets die minder op seedphrases en losse handelingen leunen.
De volgende signalen om te volgen zijn concrete Hegota-planning voor EIP-8141, Base-updates rond EIP-8130 en vooral walletondersteuning. Pas wanneer grote wallets aangeven welke route zij native ondersteunen, wordt duidelijk of dit een tijdelijke standaardenruzie blijft of een echte splitsing in gebruikerservaring.
