Account abstraction 2026: native-drömmen sprack i två

Drömmen om account abstraction har alltid handlat om en enda sak: att få en självförvarad kryptoplånbok att kännas lika enkel som ett vanligt konto. Betala nätverksavgifter utan att först skaffa ETH, logga in med en passkey i telefonen istället för en tolv ord lång fröfras, och låta kontot utföra flera steg i en och samma signatur. I ett par år pekade nästan alla mot samma slutmål: native account abstraction, inbyggt direkt i Ethereums protokoll. Den 15 september 2026 sprack det målet i två.

Ethereums kärnutvecklare och Base, Coinbases layer 2, slutade samordna sina två konkurrerande förslag och gick skilda vägar. Det ena, EIP-8141, bär Ethereum-lägrets prioriteringar. Det andra, EIP-8130, bär Bases. Kvar står plånbokstillverkarna, och i förlängningen du som användare, med två inkompatibla sätt att bygga ett smart konto på. Den här analysen förklarar vad som hände, varför det hände, och vad splittringen betyder rent praktiskt för den som förvarar krypto från Sverige.

Vad hände den 15 september 2026

Enligt The Block och The Defiant lade utvecklarna ned försöket att förena de två förslagen under veckan innan. Derek Chiang, grundare av plånboksinfrastrukturbolaget ZeroDev och numera verksam vid Ethlabs, var en av dem som arbetade med att jämka ihop dem. Hans slutsats var kort: det gick inte. ”While we identified a number of technical solutions, they all required one side or the other to compromise at least a little bit on their core goals”, skrev han. ”So separate ways we went, putting the burden on wallets to deal with the fragmentation that ensues.”

Bägge förslagen vill samma sak på ytan: göra plånböcker enklare, låta användaren betala avgifter utan att hålla ETH och signera med en telefon-passkey. Men de bygger på oförenliga världsbilder. Ethereum-lägret sätter censurmotstånd, integritet och säkerhet främst. Base optimerar för skala, anpassningsbarhet och regelefterlevnad. Utvecklarna hittade tekniska brygglösningar, men varje lösning krävde att endera sidan gav upp något centralt. Så de valde att skeppa var sin design. Chiang lämnade ändå en öppning: ”If they execute well, and if the wallet community can bridge over the fragmentation, we may well end up with the best possible UX for the end users.”

Försöket att ena förslagen var ingen fotnot. Under sommaren 2026 satt utvecklare från båda lägren och letade efter en gemensam nämnare, ett format som kunde bära både Ethereums krav på censurmotstånd och Bases krav på förutsägbar prestanda. Att arbetet till slut lades ned säger något om hur djupt oenigheten sitter: det handlar inte om vem som har den snyggaste koden, utan om vilka egenskaper ett globalt avvecklingslager ska sätta först. Ethereums kärna ser sig som neutral infrastruktur som ingen ska kunna stänga av; en konsument-L2 som Base optimerar för genomströmning och för att kunna möta regelkrav. Bägge målen är rimliga, men de drar åt olika håll i just den kod som avgör hur en transaktion valideras.

Det är den optimistiska tolkningen. Den mindre optimistiska är att en teknik som skulle förenkla självförvaring nu riskerar att göra den mer splittrad, åtminstone under övergångsåren. För att förstå varför en till synes teknisk oenighet spelar roll för din plånbok behöver vi backa och gå igenom vad account abstraction faktiskt är.

Account abstraction, kort förklarat

På Ethereum har det historiskt funnits två sorters konton. Det ena är ett externt ägt konto, ett så kallat EOA (externally owned account), som styrs av en privat nyckel. Det är den kontotyp de flesta känner: en fröfras skapar en nyckel, nyckeln signerar transaktioner, och tappar du nyckeln är pengarna borta. Det andra är smarta kontrakt, som styrs av kod men inte kan starta en egen transaktion. Account abstraction suddar ut gränsen: idén är att låta ett konto styras av godtycklig kod i stället för av en enda fast nyckel, så att reglerna för vem som får göra vad, och hur avgifter betalas, blir programmerbara.

Skillnaden låter teknisk men är avgörande i vardagen. Ett vanligt EOA kan bara göra en sak i taget och kräver att du håller ETH för att betala varje transaktions avgift; tappar du din fröfras finns ingen kundtjänst att ringa. Ett smart konto kan i stället bunta ihop flera steg, låta någon annan betala avgiften och bygga in räddningsvägar om en nyckel går förlorad. Det är den skillnaden hela account abstraction-rörelsen försöker göra till standard, och det är därför striden om hur den ska byggas in i protokollet spelar roll långt bortom utvecklarforumen.

I praktiken innebär det saker som utgiftsgränser, social återställning utan fröfras, sessionsnycklar som gäller en begränsad tid, och betalning av gas i en stablecoin. Ingen av funktionerna är magi; de är kod som körs vid signeringstillfället. Tabellen nedan sammanfattar de fyra modeller som är aktuella 2026.

Notera den sista raden. Native account abstraction var tänkt att vara slutmålet, den punkt där de tidigare lösningarna smälte ihop i ett rent protokoll. Det var den raden som sprack den 15 september.

Tre vägar till ett smart konto

Den första vägen är ERC-4337, som blev final i mars 2023 och byggde account abstraction ovanpå Ethereum utan att ändra själva protokollet. I stället för vanliga transaktioner skickar användaren ett UserOperation-objekt till en separat mempool; specialiserade aktörer som kallas bundlers buntar ihop dem och skickar dem genom ett gemensamt EntryPoint-kontrakt. En paymaster kan gå in och betala gasen. Det fungerar, men det kräver en hel infrastruktur bredvid kedjan.

Den infrastrukturen har mognat i flera steg. EntryPoint-kontraktet, hjärtat i 4337, har gått från version 0.6 till 0.7 och vidare till 0.8, där den senaste versionen numera förstår EIP-7702 direkt. Det betyder att de två spåren inte konkurrerar utan allt oftare samverkar: ett uppgraderat EOA kan använda samma paymasters och buntningsinfrastruktur som ett rent 4337-konto. För användaren är skillnaden osynlig, men den förklarar varför branschen kunde skjuta upp native account abstraction så länge; de befintliga lösningarna räckte längre än många trott.

Den andra vägen är EIP-7702, som gick live i Pectra-uppgraderingen den 7 maj 2025. Den låter ett vanligt EOA peka på ett kontrakt och tillfälligt låna dess kod via en ny transaktionstyp (0x04). På kedjan syns det som en liten pekare, en så kallad delegation designator på formen 0xef0100 följt av en kontraktsadress, totalt 23 byte. Poängen är att din befintliga adress och nyckel blir kvar; du behöver inte flytta tillgångar till ett nytt kontraktskonto som med 4337. Det gjorde 7702 till den snabbaste vägen till smarta funktioner, och adoptionen har varit stor, vilket vi återkommer till.

Den tredje vägen är native account abstraction, där logiken flyttas in i protokollet självt. Ingen sido-mempool, inga externa bundlers, inga separata EntryPoint-kontrakt; vanliga noder hanterar smarta konton direkt. Det är den rena lösningen, och det var där både Ethereum och Base var på väg, var för sig, tills de insåg att de inte kunde mötas.

Varför native skulle bli slutmålet

Varför bry sig om att göra account abstraction native över huvud taget, när 4337 och 7702 redan fungerar? Svaret handlar om beroenden. Både 4337 och delar av 7702-stacken lutar sig mot infrastruktur utanför kedjan: bundlers, paymasters och relayer. Den infrastrukturen är koncentrerad. Enligt operatörsdata från BundleBear har ett fåtal aktörer, med Pimlico och Alchemy i spetsen, hanterat mer än hälften av alla UserOperations under 2026. När ett litet antal mellanhänder står mellan din plånbok och kedjan blir de en möjlig flaskhals.

Vitalik Buterin har återkommande beskrivit relay-beroendet som en källa till skörhet, en punkt där en användare kan sakna alternativ väg in i ett block om mellanhänderna vägrar. Botemedlet han förespråkar heter FOCIL, en mekanism som slumpar fram validerare som tvingas inkludera transaktioner, plus native account abstraction som gör att noder kan hantera smarta konton utan externa buntare alls. Native var med andra ord inte en kosmetisk uppgradering utan ett försök att ta bort en hel klass av mellanhänder.

Inkluderingslistor som FOCIL, formaliserat som EIP-7805, är tänkta att garantera att en transaktion kommer med i ett block inom ett par slottar även om de dominerande byggarna helst hade utelämnat den. Kombinerat med native account abstraction skulle det ge en självförvarad plånbok en väg till kedjan som inte går via en handfull kommersiella relayer. Det är den principiella kärnan i varför Ethereum-lägret vägrar kompromissa bort valideringsflexibiliteten: förlorar man den, förlorar man också möjligheten att bygga in framtida signaturtyper och integritetslösningar utan att fråga någon om lov.

Det var också tänkt att vara en enande rörelse. Alex Jupiter, senior produktchef på MetaMask, beskrev för DL News hur de olika förslagen skulle mynna ut i ”one unified Account Abstraction roadmap”. Ironin är att just den enande färdplanen är det som nu delats i två. Redan då manade Ethereum-kärnutvecklaren Marius van der Wijden till tålamod: ”It’s still a very early proposal, so we need to evaluate all the rough edges”, sa han om vägen framåt. De skarpa kanterna visade sig vara politiska lika mycket som tekniska. Vilka som bygger de här standarderna, och vilka värderingar de bär med sig, blev själva stridsfrågan; för en bredare bild av kulturerna bakom koden är vår genomgång av var byggarna bygger en bra ingång.

Sprickan: EIP-8130 mot EIP-8141

De två förslagen skiljer sig i grunden. EIP-8141, Ethereum-lägrets design, bygger på så kallade frames: programmerbara block i en transaktion som validerar avsändare, godkänner den som betalar gasen och kör själva handlingen. Eftersom valideringen är godtycklig EVM-kod kan den stödja integritet och framtida signatursystem, inklusive kvantsäkra scheman. Baksidan är att valideringskostnaden blir dynamisk och svår att förutsäga, vilket skapar problem för layer 2-kedjor som vill ha hög genomströmning.

EIP-8130, Bases design, går motsatt väg. Den introducerar en ny transaktionstyp plus ett Keystore-kontrakt på kedjan som lagrar kontots autentiseringsval och gassponsring. I stället för godtycklig kod deklareras fasta autentiserare per transaktion (secp256k1, P-256, WebAuthn eller delegat), vilket ger förutsägbara valideringskostnader. Det passar Bases prioriteringar: skala, anpassningsbarhet och regelefterlevnad. Chiang sammanfattade skillnaden i handling: bägge sidor kunde inte få det de ville ha samtidigt.

Inte alla i plånboksbranschen sörjer splittringen. Pedro Gomes, grundare av WalletConnect, hade redan efter månader på EIP-8141 landat i att han var ”convinced EIP-8130 is the better path for native account abstraction”, och kallade den ”simpler, more portable, and focused on what wallets actually need”. Men att en av lägren har starka anhängare löser inte grundproblemet: det finns nu två native-format i stället för ett. Tabellen nedan ställer dem mot varandra.

Värt att förstå är varför kvantsäkerhet dyker upp i den här debatten. Dagens signaturer bygger på elliptiska kurvor som en tillräckligt kraftfull kvantdator i teorin kan knäcka. EIP-8141:s godtyckliga validering gör det möjligt att byta ut signaturschemat i efterhand, till exempel till ett kvantsäkert alternativ, utan att röra själva protokollet. EIP-8130:s fasta uppsättning autentiserare är enklare och billigare men mindre framtidssäker på just den punkten. Det är en klassisk avvägning mellan flexibilitet och förutsägbarhet, och de två lägren landade på var sin sida.

Den sista raden döljer en egen historia. EIP-8130 var ett tag inplanerat till Bases Cobalt-uppgradering, men flyttades i en sammanslagen kodändring den 8 september 2026 till en ny fork kallad Zenith, utan aktiveringsdatum på vare sig mainnet eller testnätet Sepolia. Med andra ord: även Bases egen tidsplan för native AA har glidit. Det som skulle skeppa i höst finns nu bara på ett utvecklarnätverk.

Frågan är hur långt splittringen sprider sig. EIP-8130 är tänkt att kunna antas av andra kedjor som bygger på OP Stack, vilket skulle ge Bases modell ett bredare fotfäste bortom Base självt. EIP-8141 å sin sida är kopplat till Ethereums egen uppgraderingscykel och har diskuterats för en kommande fork som utvecklare informellt kallar Hegotá, som ligger efter Glamsterdam i kön. Ingen av tidslinjerna är spikad, och just den osäkerheten är en del av poängen: när två oförenliga standarder båda är ett par år från bred mainnet-användning är det enda man kan säga med säkerhet att 7702 får bära lasten under tiden.

Glamsterdam prissätter om gasen, men levererar inte native AA

Samtidigt rullar Ethereums egen färdplan vidare, och nästa mainnet-fork heter Glamsterdam. Den planeras till andra halvan av 2026 och är just nu i sin sista testnätsfas mot ett mål på 200 miljoner i gasgräns, enligt The Defiant. Rubrikförändringarna är dock inte account abstraction. De är EIP-7732 (ePBS, som drar in byggandet av block i själva protokollet och minskar den hävstång sofistikerade aktörer har över vanliga validerare), EIP-7928 (block-level access lists för parallell exekvering) och ett paket omprisningar av gas.

ePBS förtjänar en förklaring, eftersom den rör samma skörhet som native account abstraction skulle lösa. Idag byggs många block av specialiserade byggare via externa relayer, och det är just det beroendet Buterin pekat ut som en risk. Genom att baka in separationen mellan den som föreslår ett block och den som bygger det i protokollet får validerare betalt även när någon annan sätter ihop blocket, vilket minskar de stora aktörernas hävstång. Det gör inte account abstraction native i sig, men det angriper samma centraliseringsproblem från ett annat håll.

Omprisningen är värd att stanna vid, för den berör alla smarta konton. Paketet höjer kostnaden för att skapa ny state, för calldata och för åtkomstlistor, och ser samtidigt över den fasta avgiften på 21 000 gas för en enkel överföring. Ethereum Foundation har uttryckligen varnat att verktyg med hårdkodade gasantaganden (plånböcker, indexerare, gasuppskattare) kan gå sönder när schablonerna ändras. Poängen för den här artikeln: den fork som faktiskt landar 2026 ändrar vad ditt 7702-konto betalar i gas, utan att ge det native account abstraction. Slutmålet skjuts framåt medan grunden under fötterna på dig prissätts om.

Bron som blev permanent

EIP-7702 marknadsfördes länge som en bro: en tillfällig lösning som skulle bära användarna fram till dess native AA var på plats. Med native nu splittrat och framskjutet blir bron i stället den bärande konstruktionen. Och den bär tungt. Per BundleBear fanns den 17 september 2026 drygt 58,4 miljoner aktiva delegerade smarta konton, över 104 miljoner set-code-transaktioner och nära 248 miljoner kumulativa auktoriseringar. Den sista siffran ska tas med en nypa salt; en stor del är återanvänd sweeper-kod och inte äkta användarplånböcker, så det ärligare måttet är antalet aktiva delegeringar.

Ethereum självt handlades den 17 september 2026 kring 2 430 dollar, ungefär 23 400 kronor per ETH, enligt CoinDesk, med ett marknadsvärde nära 296 miljarder dollar. Priset spelar mindre roll för den här historien än volymen av smarta konton, men det sätter skalan: en teknik som rör tiotals miljoner konton på ett nätverk värt hundratals miljarder kronor är inte längre ett experiment, den är infrastruktur. Och infrastruktur byter man inte ut i en handvändning, vilket är precis varför en tillfällig bro kan bli permanent.

Även ERC-4337 rullar vidare i miljardklassen räknat i UserOperations. MetaMask Smart Accounts använder 7702 som primär uppgraderingsväg, Safe dominerar bland organisationer och kassor, Ambire var först med en 7702-baserad webbläsarplånbok och Coinbases Base Account kombinerar 4337 med passkeys. Poängen är att den ”tillfälliga” lösningen redan är den mest använda. När native fördröjs och splittras är det 7702 och 4337 som fortsätter att göra jobbet, sannolikt i flera år till.

Att bron blir permanent har en konkret konsekvens för dig: det lönar sig att lära sig läsa den. Ett 7702-konto bär sin delegering öppet på kedjan, och med en blockutforskare eller en tjänst som eip7702.app kan du se exakt vilket kontrakt din adress pekar på. Skulle du någon gång ha godkänt en delegering du inte litar på går den att nollställa genom att peka om till nulladressen. Det är inte en funktion man rör varje dag, men i en värld där din vanliga adress nu kan bära programmerbar kod är det en av de nya baskunskaperna för självförvaring.

Fragmenteringen landar i plånboken

Chiangs formulering var träffsäker: bördan hamnar på plånböckerna. Om båda native-förslagen skeppas som tänkt måste plånboks- och app-utvecklare stödja två skilda transaktionsformat och välja rätt transport och valideringsregler för varje kedja. Det är ett lager av komplexitet ovanpå den fragmentering som redan finns mellan mainnet och en handfull layer 2-kedjor. Ett smart konto på Base kan komma att bete sig annorlunda än samma konto på Ethereum L1.

Det finns också en debatt om plånböckernas incitament. Buterin har argumenterat för att varje användare på sikt borde ha en enda huvudrot för återställning som täcker hela deras liv på kedjan, ett svar på att nyckelhanteringen annars fragmenteras lika mycket som formaten. Kritiker påpekar att en enda rot också blir en enda felpunkt. Samtidigt fungerar många plånböcker kommersiellt som förlustledare: de tjänar pengar på byten och orderflöde inne i appen, vilket ger dem svag anledning att låta andra appar abstrahera bort dem. Den som vill förstå hur den här ekonomin flyttat friktionen neråt i stacken hittar mer i vår genomgång av plånbokens onboarding 2026. Nettot av allt detta är att komplexiteten pressas ut mot kanten, och kanten är du.

Fragmenteringen har också en mindre synlig sida. När transaktioner dirigeras genom buntar och delegeringar blir det svårare att spåra vem som gjorde vad, något som redan ställt till det för poängprogram och airdrop-mätning där en adress plötsligt beter sig olika beroende på vilken plånbok som styr den. Sessionsnycklar, som låter en app agera å dina vägnar under en begränsad tid, saknar dessutom en gemensam standard för hur de ska fungera över olika konton. Två native-format ovanpå det gör inte saken enklare. Det är den sortens friktion som sällan syns i ett pressmeddelande men som utvecklare får lägga veckor på att jämna ut.

Vad splittringen betyder för dig som svensk användare

Du kommer aldrig att se ett EIP-nummer i din plånbok, men du kommer att känna effekterna. Gaslös betalning kan fungera på en kedja men inte på en annan. En funktion som sessionsnycklar kan finnas i en app och saknas i nästa. Ett smart konto du satt upp på Base kan uppföra sig annorlunda när du använder samma adress på Ethereum. Under de närmaste åren blir valet av plånbok viktigare, inte mindre viktigt, eftersom det avgör vilka av de här funktionerna du faktiskt får och på vilka kedjor.

Ta ett vardagsexempel. Att skicka en stablecoin på en billig layer 2 kan kosta appen som sponsrar gasen några ören, medan samma sponsrade transaktion på Ethereums mainnet kan landa på tiotals kronor när nätet är belastat. Det är därför nästan all account abstraction i praktiken samlas på layer 2, och det är också där de två native-standarderna kommer att mötas eller krocka först. För dig innebär det att en och samma plånbok kan erbjuda gaslösa överföringar på Base men be dig hålla ETH för avgifter på mainnet, en skillnad som inte beror på plånboken utan på vilket lager du befinner dig på.

Det praktiska rådet 2026 är odramatiskt: räkna med att 4337 och 7702 är det du kommer att använda under överskådlig tid, och behandla native account abstraction som något som kommer senare, om det kommer. Välj en plånbok som är öppen med vilken delegering den använder, som helst pekar på ett granskat, hårdkodat kontrakt (som MetaMask gör), och som har en tydlig återställningsmodell. Undvik att jaga varje ny funktion över varje ny kedja bara för att den finns. Fragmenteringen är verklig, men den drabbar mest den som sprider sina tillgångar tunt över många experimentella uppsättningar.

Säkerheten sitter i nycklarna, inte i protokollet

En viktig sak att hålla isär: splittringen mellan 8130 och 8141 handlar om användarvänlighet och standarder, inte om en ny sårbarhet. Men account abstraction flyttar behörigheten in i kod, och därmed flyttas den verkliga attackytan till signeringsögonblicket. Det är inte protokollet som brukar fallera, utan människan framför skärmen som godkänner något hon inte kan läsa.

Mönstren är väldokumenterade. Efter Pectra fann Wintermute att över 97 procent av de tidiga 7702-delegeringarna pekade på återanvänd sweeper-kod, cirka 2,88 ETH som auktoriserats mot ungefär 79 000 adresser (mest redan tömda plånböcker, alltså inte lönsamt och inte ett fel i 7702). Samtidigt förlorade ett enskilt phishing-offer 1,54 miljoner dollar i en enda 7702-transaktion i augusti 2025. Radiant Capital, ett DeFi-låneprotokoll, tömdes på omkring 50 miljoner dollar sedan angripare (senare kopplade till Nordkorea) matat in skadlig kod i signeringsgränssnittet för en Safe-multisig; hela obduktionen finns i vår text om läxan från Radiant-hacket. Den goda nyheten är att de totala phishing-förlusterna föll kraftigt 2025, med omkring 83 procent enligt Scam Sniffer, till cirka 83,85 miljoner dollar.

Den gemensamma nämnaren i de här fallen är inte en trasig kedja utan en signatur som användaren inte kunde tyda. Två motmedel har vuxit fram. Det ena är clear signing, formaliserat som ERC-7730, där plånboken översätter en kryptisk transaktion till läsbar text om vad som faktiskt godkänns; standarden överfördes till Ethereum Foundations förvaltning under 2026. Det andra är förhandssimulering, där plånboken kör transaktionen i en sandlåda och visar utfallet innan du signerar. Bägge höjer ribban, men forskning har visat att simuleringar kan luras av kontrakt som beter sig annorlunda i skarpt läge, så de bör ses som ett lager av försvar, inte en garanti.

Verktyg som clear signing (ERC-7730) och förhandssimulering hjälper, men de är lager, inte garantier. En hårdvaruplånbok som verkligen visar vad du signerar är fortfarande det starkaste enskilda skyddet; vår recension som testar hela kedjan går igenom var de faktiskt håller. Och för den som vill förstå gråzonen mellan tjuv och white-hat när en stöld väl är ett faktum är vår genomgång av kryptohackens post-mortem läsvärd.

Börsen, förvararen och det svenska regelverket

Splittringen påverkar även dem som förvarar krypto åt andra. Börser och förvarare måste screena den 23 byte långa delegation designatorn (0xef0100) på insättnings- och uttagsadresser, eftersom ett delegerat konto kan bete sig annorlunda än ett vanligt EOA. Institutionella aktörer löser ofta detta med MPC-baserad förvaring i stället för en enda nyckel. Samtidigt suddar inbäddade plånböcker (från exempelvis Coinbase och Stripe-ägda Privy) ut gränsen mellan börskonto och självförvaring: nycklarna ligger i en säker enklav som leverantören säger sig inte kunna komma åt, men upplevelsen är den av ett vanligt konto.

Det väcker en principiell fråga som splittringen gör mer aktuell: är en inbäddad plånbok verkligen självförvaring? Tekniskt sett kan användaren ofta exportera sin nyckel, och leverantören hävdar att den inte kan röra tillgångarna. Men i praktiken sköter en tredje part inloggning, återställning och ibland gassponsring, vilket placerar upplevelsen någonstans mellan ett börskonto och en ren hårdvaruplånbok. När de underliggande standarderna dessutom är två i stället för en, blir det ännu viktigare att förstå exakt var i det spektrumet en viss produkt hamnar innan man lägger in några större belopp.

För svenska användare gäller att självförvaring, inklusive smarta konton, ligger utanför MiCA och därmed utanför Finansinspektionens tillsyn av kryptotillgångstjänster. Det är först när en tredje part tar hand om nycklar, återställning eller gassponsring som du närmar dig gränsen för en reglerad tjänsteleverantör (CASP). Sedan den 1 oktober 2025 måste varje kryptoföretag som riktar sig till svenska kunder antingen ha ansökt om tillstånd hos FI eller upphöra. Kryptoderivat, till skillnad från spothandel, faller under MiFID II och inte under MiCA. Skattemässigt spelar det ingen roll om du använder ett EOA eller ett smart konto: Skatteverket beskattar vinst och förlust på samma sätt, och att betala gas i en stablecoin kan i sig utlösa en beskattningsbar avyttring. Att ett konto är ”smart” ändrar alltså varken tillsynen eller deklarationen.

Så navigerar du splittringen

Sammanfattningsvis, en kort checklista för den som vill hålla sig lugn medan standarderna bråkar:

• Räkna med att 4337 och 7702 är det du använder de närmaste åren; native AA kommer senare, om det kommer.
• Välj en plånbok som är öppen med vilken delegering den pekar på, helst ett granskat och hårdkodat kontrakt.
• Kontrollera din egen 7702-delegering (via en tjänst som eip7702.app) och nollställ den vid behov till nulladressen.
• Blindsignera aldrig stora belopp; använd en hårdvaruplånbok som visar handlingen, inte bara en hash.
• Kom ihåg att gaslöst och sessionsnycklar kan finnas på en kedja men saknas på en annan; kontrollera vilken kedja du är på.
• Behandla inbäddade plånböcker som självförvaring med förbehåll, och läs villkoren för återställning.
• Spara underlag för Skatteverket; en stablecoin-betald gasavgift kan vara en avyttring.

Den 15 september var ingen katastrof. Ingen förlorade pengar, ingen kedja stannade. Men det var ett tydligt besked om att den snygga, enande slutpunkten för account abstraction inte är nära, och att den praktiska verkligheten under de kommande åren är två läger, en bro som blev permanent, och en plånbok som får bära skillnaden. För dig som användare är det goda i det att din nuvarande uppsättning fortsätter att fungera. Det mindre goda är att enkelheten som utlovades får vänta.

Frequently Asked Questions

Vad är account abstraction, enkelt förklarat?

Account abstraction låter en kryptoplånbok styras av programmerbar kod i stället för av en enda fast privat nyckel. Det gör funktioner som utgiftsgränser, social återställning utan fröfras, sessionsnycklar och betalning av gas i en stablecoin möjliga. Målet är att en självförvarad plånbok ska kännas lika enkel som ett vanligt konto.

Vad är skillnaden mellan EIP-8130 och EIP-8141?

EIP-8141 är Ethereum-lägrets förslag och bygger på frames med godtycklig EVM-validering; det prioriterar censurmotstånd, integritet och kvantsäkra signaturer, men får dynamiska valideringskostnader. EIP-8130 är Bases förslag med en ny transaktionstyp och ett Keystore-kontrakt och fasta autentiserare; det prioriterar skala, förutsägbara kostnader och regelefterlevnad. Sedan den 15 september 2026 skeppas de som separata standarder.

Måste jag göra något nu när standarderna splittrades?

Nej, ingenting akut. Din nuvarande plånbok som bygger på ERC-4337 eller EIP-7702 fortsätter att fungera precis som förut. Splittringen påverkar främst plånboks- och app-utvecklare, som nu kan behöva stödja två native-format. På sikt kan det innebära att vissa funktioner finns på en kedja men inte på en annan.

Är ett smart konto reglerat av Finansinspektionen?

Ren självförvaring, inklusive smarta konton, ligger utanför MiCA och därmed utanför Finansinspektionens tillsyn av kryptotillgångstjänster. Det är först när en tredje part hanterar nycklar, återställning eller gassponsring åt dig som gränsen mot en reglerad tjänsteleverantör (CASP) närmar sig. Skattemässigt behandlar Skatteverket vinst och förlust likadant oavsett om du använder ett EOA eller ett smart konto.

Kommer native account abstraction någonsin?

Troligen, men inte snart och inte som en enda standard. Bases EIP-8130 har flyttats till en oschemalagd fork kallad Zenith och finns bara på ett utvecklarnätverk, medan Ethereums EIP-8141 övervägs för en senare uppgradering. Nästa mainnet-fork, Glamsterdam, prissätter om gas men innehåller inte native AA. Under tiden bär EIP-7702 och ERC-4337 lasten.

Yuki Tanaka är senior redaktör på HOGE Wire och bevakar plånböcker, börser och kontoabstraktion.