EIP-7702 blev permanent: när native konton sprack isär 2026

I drygt ett år har EIP-7702 beskrivits som en bro: en smart men medvetet tillfällig lösning som lät vanliga plånböcker bete sig som smarta konton, i väntan på att Ethereum skulle bygga in riktig account abstraction direkt i protokollet. Den 15 september 2026 slutade den beskrivningen att stämma. Utvecklare på Ethereum och teamet bakom Base gav då upp försöket att ena sina två konkurrerande förslag för native konton, EIP-8141 och EIP-8130, och bestämde sig för att gå skilda vägar. Bron är inte längre på väg att ersättas. Den har blivit vägen.

För dig som redan låtit din plånbok delegera till ett smart konto, eller funderar på det, förändrar det här förutsättningarna. Samtidigt förbereder Ethereum sin nästa stora uppgradering, Glamsterdam, som inte lägger till native konton alls utan istället räknar om vad varje transaktion kostar i gas. Den här genomgången tar upp vad som faktiskt hände, varför EIP-7702 nu ser ut att bli permanent infrastruktur snarare än en parentes, och vad det betyder konkret för kostnader, säkerhet och regelverk för svenska användare.

Vad EIP-7702 faktiskt är, i korthet

Ett vanligt Ethereum-konto, en externally owned account (EOA), styrs av en privat nyckel och kan i grunden bara en sak: signera en transaktion i taget. Ett smart konto styrs istället av kod, vilket öppnar för att bunta ihop flera steg, låta någon annan betala gasen, sätta utgiftsgränser och skapa tidsbegränsade nycklar. Historiskt har man behövt välja mellan den enkla EOA:n och ett separat smart kontrakt med ny adress och en flyttprocess.

EIP-7702 tar bort valet. Förslaget, som skrevs av Vitalik Buterin, Sam Wilson, Ansgar Dietrichs och Matt Garnett och gick live i Pectra-uppgraderingen den 7 maj 2025, låter en EOA tillfälligt låna ett smart kontrakts kod medan adressen och nyckeln är kvar. Din adress förblir densamma, din seed-fras fungerar precis som förr, men kontot kan plötsligt utföra allt ett smart konto kan. Ingen migrering, ingen ny adress. Uppgraderingen sker på plats, och den är lika enkel att ångra som att aktivera. Det var just den låga tröskeln som gjorde att EIP-7702 fick fäste snabbt, medan det äldre och tyngre ERC-4337 aldrig nådde bredden bland vanliga användare.

Konkret betyder det några saker som tidigare krävde antingen tur eller teknisk möda. Du kan godkänna och genomföra ett byte i en enda signering istället för två, vilket tar bort det ökända mellansteget där en godkänd token kan utnyttjas. Du kan låta en tjänst betala gasen, så att din allra första transaktion går att göra utan att först köpa ETH. Du kan skapa en sessionsnyckel som bara får spela ett visst spel eller handla upp till ett visst belopp under en timme, utan att exponera huvudnyckeln. Och du kan sätta hårda gränser för vad kontot får göra. Det är samma slags bekvämlighet som gjort centraliserade börser enkla, fast med nycklarna kvar hos dig.

Mekaniken bakom kulisserna

Under huven är EIP-7702 en ny transaktionstyp, 0x04 (SET_CODE_TX_TYPE). Den bär en lista med auktoriseringar, där varje post är en tuppel: chain_id, adressen till det kontrakt du delegerar till, ett nonce och en signatur (y_parity, r, s). När transaktionen körs skrivs en liten markör in på ditt konto: bytesekvensen 0xef0100 följt av kontraktets 20-byte-adress, sammanlagt 23 bytes. Den markören är delegeringen. Så länge den ligger där kör ditt konto det kontraktets kod.

Signaturen som auktoriserar delegeringen bygger på en särskild MAGIC-byte, 0x05, och du nollställer allt genom att delegera om till nolladressen, vilket raderar markören. En detalj är värd att komma ihåg: om chain_id sätts till 0 gäller auktoriseringen på alla EVM-kedjor samtidigt, vilket är bekvämt men också en replay-risk. En annan är att kontraktet du delegerar till delar lagringsutrymme med ditt konto, så dåligt skrivna kontrakt kan skriva över varandras data; standarden ERC-7201 finns för att hålla isär minnet.

Det som gör markören så användbar är att den är läsbar för vem som helst. Vill du veta om en adress är ett smart 7702-konto tittar du efter bytesekvensen 0xef0100 och adressen som följer; pekar den på ett kontrakt du känner igen är allt som det ska, pekar den på något okänt är det en varningssignal. Samma öppenhet som låter en börs granska inkommande adresser låter dig själv kontrollera din egen. Tabellen nedan sammanfattar vad du faktiskt tittar på när du inspekterar en delegering.

Bron som skulle vara tillfällig

För att förstå varför den 15 september är en vändpunkt måste man känna till planen den bröt. Account abstraction har varit ett mål på Ethereum sedan 2016. Den första seriösa ansatsen, EIP-3074, backades så småningom till förmån för en helt annan väg. ERC-4337 kom 2023 och la smarta konton i ett eget lager ovanpå protokollet, med separata aktörer som kallas bundlers och paymasters. Det fungerade, men det krävde ny adress, ny infrastruktur och en migrering som de flesta aldrig gjorde.

EIP-7702 presenterades uttryckligen som en mellanlösning: ett sätt att ge befintliga plånböcker superkrafterna utan att vänta på att protokollet självt skulle byggas om. Det slutmålet, native account abstraction inbyggd i själva Ethereum, skulle komma senare. Marius van der Wijden, kärnutvecklare på Ethereum, sammanfattade läget redan när förslaget var färskt: ”It’s still a very early proposal, so we need to evaluate all the rough edges”. Alex Jupiter, senior produktchef på MetaMask, beskrev i samma artikel EIP-7702 som en pusselbit i ”one unified Account Abstraction roadmap”. Ett drygt år senare är det just enigheten i den färdplanen som har spruckit.

En del av drivkraften bakom native konton var att ERC-4337 lutar sig mot externa aktörer, bundlers och relayer, som paketerar och skickar in transaktionerna. Buterin har pekat på att ett sådant beroende blir en källa till skörhet: om infrastrukturen slutar samarbeta finns ingen alternativ väg in i ett block. Native account abstraction skulle låta vanliga noder hantera smarta konton direkt, utan sidokanaler. Det är en principiellt viktig skillnad, och en del av varför Ethereum-lägret inte ville kompromissa bort flexibiliteten i sitt förslag. Men så länge den lösningen dröjer är det EIP-7702, med alla sina kantigheter, som bär vikten.

Den 15 september då planen sprack

Under 2026 fanns två ledande förslag för hur native konton skulle byggas. Ethereums läger drev EIP-8141, en modell med så kallade frame transactions där valideringen sker i vanlig EVM-kod. Base, Coinbases layer 2, drev EIP-8130, som istället inför en ny transaktionstyp med ett register på kedjan för godkända nyckeltyper. Under en tid pågick ett arbete för att ena de två så att plånböcker skulle slippa hantera två oförenliga standarder. Den 15 september 2026 bekräftades att arbetet lagts ner. De två lägren skickar nu var sin design.

Derek Chiang, grundare av plånboksinfrastrukturbolaget ZeroDev och en av dem som deltog i försöket att sammanjämka förslagen, beskrev utfallet rakt: en enande hade krävt att en av sidorna kompromissade åtminstone en aning, och när det inte gick landade konsekvenserna någon annanstans. Effekten, sa han till The Defiant, var att man slutade ”putting the burden on wallets to deal with the fragmentation that ensues”. Skillnaden handlar inte om en teknisk detalj utan om vad kedjorna prioriterar. Det är i grunden två olika byggarkulturer, ett tema vi tidigare beskrivit i vår genomgång av var byggarna faktiskt bygger.

Att förslagen inte gick att ena berodde inte på ovilja utan på att de optimerar för olika saker. EIP-8141 vill kunna uttrycka nästan vilken valideringslogik som helst i EVM-kod, vilket öppnar för framtida signatursystem och integritetsfunktioner men gör kostnaden svår att förutse i förväg. EIP-8130 gör tvärtom autentiseringstyperna explicita och begränsade, vilket ger en förutsägbar kostnad och en tydlig lista över vad som är tillåtet, till priset av mindre frihet. Det ena är byggt för maximal öppenhet, det andra för en storskalig kedja som vill kunna säga exakt vad som händer innan det händer.

Ethereum värderar flexibilitet, integritet och censurmotstånd, även om det gör valideringskostnaden svår att förutsäga. Base värderar förutsägbarhet, skala och regelefterlevnad, och gör därför de godkända autentiseringstyperna explicita innan körning, i en nivåindelad struktur. Den som vill förstå hur den bredare splittringen ser ut kan läsa vår artikel om hur native-drömmen sprack i två. Tabellen nedan ställer de två förslagen mot varandra.

Base drog EIP-8130 till en egen fork

Splittringen kom inte som en blixt från klar himmel. Base hade planerat att skeppa EIP-8130 i sin Cobalt-uppgradering, men förslaget flyttades ut. Den 8 september 2026 slogs en ändring samman i Bases kodbas, pull request 4924, som flyttar EIP-8130 till en ny och ännu oschemalagd fork som kallas Zenith. Aktiveringstidpunkten är satt till ingenting på samtliga livekedjor, vilket i praktiken betyder att förslaget lever på en devnet utan datum för mainnet.

På Ethereum-sidan är läget likartat. EIP-8141 finns kvar som ett övervägt förslag men har förlorat sin plats som rubrik och pekas mot en senare uppgradering, Hegotá, som ligger bortom nästa fork i tidslinjen. Ingen av de två vägarna till native konton når alltså mainnet i närtid. Det är den nyktra bakgrunden till varför EIP-7702, som redan är live och används, plötsligt ser mindre ut som en tillfällig bro och mer ut som den standard alla kommer att bygga vidare på under lång tid framöver.

Namnen på forkarna säger något om tempot. Base döpte sin till Zenith och Ethereum arbetar mot Hegotá, men bakom de klingande namnen finns en enkel sanning: ingen av dem har ett aktiveringsdatum på mainnet. Under tiden testas Ethereums förändringar på Plataberget, uppkallad efter fjället ovanför Longyearbyen, medan Base kör sitt förslag på en intern devnet. För en användare som vill veta när native konton faktiskt kommer är det enda ärliga svaret att det dröjer, och att det som finns här och nu är EIP-7702.

Glamsterdam lägger inte till native konton, det räknar om gasen

Ethereums nästa stora uppgradering heter Glamsterdam och väntas nå mainnet någon gång under senare delen av 2026. Många antog att account abstraction skulle ingå. Det gör den inte. Glamsterdams två rubrikförändringar är EIP-7732, som delar upp blockbyggandet (kallat ePBS), och EIP-7928, som inför block-level access lists för parallell körning. Arbetet med native konton är flyttat till Hegotá, uppgraderingen därefter, tillsammans med censurmotståndsmekanismen FOCIL.

De två rubrikförändringarna hänger ihop med samma skörhetsproblem som drev native AA. ePBS flyttar in förhandlingen mellan blockbyggare och validerare på kedjan, vilket minskar beroendet av mellanhänder och ska pressa ned mängden MEV som läcker ut. Block-level access lists låter klienterna veta i förväg vilka delar av tillståndet en transaktion rör, så att flera transaktioner kan köras parallellt. Att lägga account abstraction ovanpå allt detta i samma uppgradering bedömdes bli för mycket otestad interaktion på en gång, vilket är den odramatiska förklaringen till varför AA sköts till Hegotá.

Det som däremot berör alla EIP-7702-konton är att Glamsterdam räknar om gasen. Under paraplyet EIP-8007 (Glamsterdam Gas Repricings) ingår en generell omkalibrering, EIP-7904, som justerar priset för de flesta operationer efter vad de faktiskt kostar på modern hårdvara. Enligt de siffror som cirkulerat sänker den kostnaden med runt 78 procent för både enkla överföringar och mer avancerade kontraktsanrop. Samtidigt går ett par kostnader åt andra hållet: EIP-8037 höjer priset för att skapa nya konton och lagringsplatser, och EIP-8038 höjer priset för att läsa sällan använd data. En vanlig överföring till ett konto som redan finns kostar fortfarande 21 000 gas, men en överföring som skapar en helt ny adress kommer att dra extra gas.

Det låter tekniskt, men Ethereum Foundation har varit ovanligt tydlig med att det får praktiska följder. I ett blogginlägg riktat till utvecklare varnar stiftelsen för att kontrakt och verktyg som hårdkodar gaskostnader, eller antar att en överföring alltid kostar exakt 21 000 gas, kommer att gå sönder efter uppgraderingen. Cachade gaskonstanter kommer att underskatta den verkliga kostnaden och leda till misslyckade transaktioner. Förändringarna testas nu på Plataberget, en långlivad publik testnet som Ethereum Foundation forkade till Glamsterdam den 20 augusti 2026.

Vad omprissättningen betyder för ditt smarta konto

Poängen med ett EIP-7702-konto är att göra mer per transaktion: godkänna och byta i ett svep, låta en paymaster betala gasen, köra flera steg i en batch. När gasen räknas om ändras aritmetiken bakom alla de här stegen. Det mesta blir billigare tack vare den generella omkalibreringen, men den som skickar till nya adresser eller rör vid sällan använd lagring får betala mer för just de delarna. För en enskild användare är nettoeffekten oftast lägre avgifter, men det gamla antagandet att en transaktion har en fast, känd kostnad gäller inte längre.

Ta ett vardagligt exempel. Ett 7702-konto som godkänner en token och byter den i samma batch rör vid flera lagringsplatser och gör flera anrop. Efter omkalibreringen blir själva beräkningsarbetet billigare, men om något steg skapar en ny adress eller läser tillstånd som legat orört länge kostar just den delen mer än förr. Nettot beror alltså på vad transaktionen faktiskt gör, inte på en enda fast siffra. För de flesta enkla överföringar och byten pekar allt mot lägre avgifter, men den som bygger på antagandet att gas är konstant kommer att räkna fel just när det gäller.

Det praktiska rådet är enkelt: lita på plånbokens uppskattning i realtid, inte på tumregler du memorerat. Plånböcker och de tjänster som sponsrar gas kommer att behöva uppdatera sina kostnadsmodeller, och de flesta gör det tyst i bakgrunden. Men om du kör egna skript, automatiserade strategier eller ett agentkonto som signerar åt dig, är det värt att kontrollera att inget i din uppsättning förutsätter 21 000 gas som en universell konstant. Bron består, men vägtullen ändras.

Fragmenteringen ingen vill äga

Chiangs poäng om att bördan hamnar på plånböckerna är kärnan i vad splittringen betyder på sikt. När det inte finns en enda native-standard måste varje plånbok själv överbrygga skillnaderna mellan kedjor och konton, så att du som användare inte märker sömmarna. Det är tekniskt möjligt, men det är arbete som ingen egentligen ville ta på sig, och det riskerar att göra upplevelsen ojämn beroende på vilken plånbok och vilken kedja du använder. Hur mycket friktion som göms undan för användaren har blivit ett konkurrensmedel i sig, något vi gick igenom i vår text om hur plånbokens onboarding flyttade friktionen neråt.

Vitalik Buterin har argumenterat för att varje användare på sikt borde ha en enda huvudnyckel för återhämtning som gäller för hela ens liv på Ethereum och dess layer 2-kedjor. Kritiker påpekar att en sådan enda rot också blir en enda felkälla. I den bredare debatten bland byggare lyfts också en obekväm ekonomisk sanning: plånböcker tjänar ofta pengar på byten och orderflöde inne i appen, vilket ger dem svaga incitament att låta andra appar abstrahera bort dem. Fragmentering är delvis en teknisk fråga och delvis en fråga om vems affärsmodell som vinner.

Fragmenteringen syns redan på oväntade ställen. När transaktioner dirigeras genom delegeringar och buntas ihop blir de svårare att spåra för de poängprogram och analysverktyg som blivit standard i branschen. Samma adress kan uppträda olika beroende på vilken plånbok som styr den, vilket gör attribueringen av aktivitet skakig. Det är en påminnelse om att account abstraction inte bara handlar om bekvämlighet för användaren, utan också rör vem som kan mäta, belöna och bygga affärer ovanpå det som händer på kedjan.

Adoptionen fortsätter, med en asterisk

Splittringen har inte bromsat användningen. Enligt BundleBears mätningar fanns i mitten av september runt 58,7 miljoner aktiva delegerade konton, medan antalet set-code-transaktioner passerat 104 miljoner. Det cirkulerar också en betydligt större siffra, knappt 249 miljoner ackumulerade auktoriseringar, men den ska läsas med försiktighet: en stor del av de tidiga auktoriseringarna kommer från automatiska tömningskontrakt (sweepers) som återanvänts om och om igen, inte från vanliga användare. Den ärliga siffran är antalet konton som just nu har en aktiv delegering.

På plånbokssidan har MetaMask Smart Accounts gjort EIP-7702 till sin huvudsakliga uppgraderingsväg, och Ambire var först ut. Rabby, Trust Wallet och OKX Wallet stödjer det, liksom börsen WhiteBIT som var tidig. ETH handlades mitt i september kring 2 450 dollar, vilket med en dollarkurs runt 9,81 kronor motsvarar ungefär 24 000 kronor. Det är den prislapp per token som ligger under alla de här kontona, oavsett hur gasen räknas om.

Att skilja på siffrorna är inte akademiskt. En plånbokstillverkare eller ett riskkapitalbolag som vill visa upp fart kan luta sig mot de knappt 249 miljoner ackumulerade auktoriseringarna, men den siffran blåses upp av sweepers som signerar om och om igen. De runt 58,7 miljoner konton som just nu har en aktiv delegering är en ärligare mätare på hur många som faktiskt använder ett smart konto. Även den ska tas med en nypa salt, eftersom en delegering inte säger något om hur ofta kontot används, men den ligger närmare verkligheten än det stora bruttotalet.

Säkerheten har inte ändrats

Att native konton skjuts upp ändrar ingenting i EIP-7702:s riskbild, för risken sitter inte i protokollet utan i signeringsögonblicket och i nyckelhanteringen. Grundproblemet är att en enda signerad auktorisering kan ge full och bestående kontroll över kontot. En akademisk studie som presenterades vid USENIX Security 2026 gick igenom 22,8 miljarder transaktioner över sju kedjor och fann att 63 procent av de analyserade auktoriseringarna var kopplade till skadliga kontrakt, med 924 distinkta skadliga kontrakt bakom drygt 2,36 miljoner dollar i realiserade förluster och över 10 miljoner dollar i exponering. En separat arXiv-studie kartlade en ny klass av nätfiske där offret luras att signera en enda tuppel som ger angriparen bestående kontroll.

Nätfiskestudien beskriver tre vägar in. I den första luras användaren själv att signera auktoriseringen, ofta bakom ett gränssnitt som utger sig för att vara en känd tjänst. I den andra utnyttjar angriparen en redan komprometterad nyckel för att installera koden. I den tredje aktiveras delegeringen på håll via en kontraktsmekanism. Gemensamt är att en enda signatur räcker och att kontrollen består tills du aktivt nollställer den. Fallet på 1,54 miljoner dollar följde det mönstret: offret möttes av ett förfalskat DeFi-gränssnitt, signerade det som såg ut att vara en vanlig interaktion, och lät därmed en tömmare ta hand om wstETH, cbBTC och ett antal NFT:er i ett svep.

Samtidigt ska proportionerna hållas. Wintermute konstaterade tidigt att över 97 procent av de första delegeringarna använde samma återanvända sweeper-kod, ofta kallad CrimeEnjoyor, men att den inte var särskilt lönsam, eftersom den mest riktade sig mot redan tömda konton. De verkliga smällarna kom från riktat nätfiske: ett enda offer förlorade 1,54 miljoner dollar i en enda transaktion i augusti 2025. På helhetsnivå föll ändå nätfiskeförlusterna med 83 procent under 2025, till omkring 83,85 miljoner dollar. Slutsatsen är densamma som i vår genomgång av läxan från Radiant-hacket: det farliga är vad du godkänner, inte tekniken i sig.

Förvaringsbolaget Fireblocks har uttryckt det som att en enda skadlig delegering är allt som behövs, och att man därför bara bör delegera till fullt granskade och betrodda kontrakt. Att ett kontrakt är granskat är dock ingen garanti, vilket vi utvecklat i artikeln om granskade men ändå hackade projekt. Tabellen nedan sammanfattar de vanligaste riskvektorerna.

Börsen och förvararen i en permanent 7702-värld

När EIP-7702 blir bestående blir också börsernas och förvararnas hantering av det en permanent uppgift, inte en tillfällig anpassning. En handelsplats som tar emot insättningar måste kunna läsa 0xef0100-markören och avgöra om en inkommande adress är delegerad, och i så fall till vad. Den mest konkreta risken är en sweeper som ligger och väntar på en insättningsadress och tömmer den i samma ögonblick som pengar kommer in. Därför screenar seriösa aktörer inkommande och utgående adresser mot den 23-byte-markören och behandlar en oväntad delegering som en varningsflagga.

Problemet blir extra knepigt för börser som ger varje kund en egen insättningsadress och sedan automatiskt drar in medlen till en gemensam kassa. Om en sådan adress är delegerad till ett skadligt kontrakt kan angriparens kod hinna före börsens egen indragning, eller störa den. Det tvingar handelsplatserna att bygga in kontroll av 0xef0100-markören i just de rutiner som tidigare var helt mekaniska. Under DORA, EU:s regelverk för digital operativ motståndskraft, är den sortens driftssäkerhet dessutom inte längre frivillig för reglerade aktörer, utan något tillsynen kan följa upp.

På institutionssidan lutar många åt förvaring baserad på MPC (multi-party computation), där ingen enskild maskin håller hela nyckeln. Fireblocks och andra beskriver EIP-7702 och MPC som komplement snarare än konkurrenter: MPC tar bort den enskilda felkällan, medan 7702 ger batchning, gassponsring och sessionsnycklar ovanpå. För en svensk sparare som förvarar krypto på en börs är den viktiga insikten att ansvaret ser olika ut beroende på om du sitter med nycklarna själv eller inte, något vi återkommer till nedan.

Så läser och återställer du din delegering

Oavsett hur bråket om native konton slutar kan du kontrollera och styra din egen delegering redan idag. Gör så här:

1. Kontrollera om din adress är delegerad. En blockutforskare som Etherscan visar auktoriseringar i sin lista över set-code-transaktioner, och särskilda verktyg som eip7702.app gör samma sak i klartext.
2. Läs vart markören pekar. Notera kontraktsadressen efter 0xef0100 och verifiera att det är ett kontrakt du känner igen, till exempel din plånbokstillverkares eget delegatorkontrakt.
3. Om delegeringen är okänd eller skadlig, flytta tillgångarna först. Är din nyckel möjligen komprometterad räcker det inte att ta bort delegeringen; angriparen kan bara sätta tillbaka den. Flytta värdet till en ny, ren plånbok.
4. Nollställ genom att delegera om till nolladressen. Det görs i plånboken och raderar den installerade koden. Tjänster som revoke.cash kan visa din delegering men inte ta bort den; själva återställningen sker i plånboken.
5. Kom ihåg att delegeringar är kopplade till en specifik kedja. Kontrollera varje kedja du använder separat, och var extra försiktig om en auktorisering satts med chain_id 0.

Finansinspektionen, MiCA och vem som bär ansvaret

För svenska användare är den regulatoriska bilden viktig men ofta missförstådd. EIP-7702 är en förändring i Ethereum-protokollet, och protokollet i sig regleras inte av någon myndighet. MiCA, EU:s regelverk för kryptotillgångar, och Finansinspektionen reglerar leverantörer av kryptotjänster (CASP), det vill säga börser, växlingstjänster och förvarare, inte den kod som ligger på kedjan. Så länge du håller nycklarna själv, även genom ett smart 7702-konto, står du utanför den skyddande ramen, utan konsumentskydd och utan möjlighet att återkalla en transaktion.

Det praktiska ansvaret landar därför i två olika fållor. Använder du en börs eller förvarare gäller MiCA, och sedan den 1 oktober 2025 måste varje kryptoföretag som riktar sig till svenska kunder ha ansökt om tillstånd hos FI eller upphöra. Handlar du med derivat som terminer eller perpetuals räknas de som finansiella instrument under MiFID II, inte under MiCA. ESMA klargjorde dessutom den 19 mars 2025 gränsen mellan nyttotoken och finansiella instrument. Men i det ögonblick du signerar en delegering i din egen plånbok är det du, inte FI eller börsen, som bär hela risken. Det är ett argument för att förstå exakt vad en 7702-auktorisering gör innan du godkänner den.

För börser och förvarare tillkommer också den så kallade travel rule, som kräver att uppgifter om avsändare och mottagare följer med överföringar mellan reglerade aktörer. Ett smart 7702-konto ändrar inte den skyldigheten, men det gör identifieringen av motparter mer teknisk, eftersom en adress kan bete sig olika beroende på vilken kod den lånat för stunden. För dig som privatperson är slutsatsen ändå enkel: väljer du att förvara själv får du full kontroll och fullt ansvar, och det finns ingen kundtjänst som kan backa en signerad delegering.

Vad du ska ta med dig

EIP-7702 började som en genväg och håller på att bli en huvudväg. Splittringen den 15 september betyder inte att native konton är döda, men den betyder att de är avlägsna nog för att bron ska bära trafiken under lång tid. Glamsterdam byter inte ut den utan räknar om vad den kostar att köra på, och den enda del av ekvationen som inte rört sig är säkerheten: en signerad auktorisering är fortfarande en signerad auktorisering, och ansvaret ligger hos den som håller nyckeln.

Det konkreta att göra är därför oförändrat och viktigare än någonsin. Vet vilka delegeringar dina konton har, delegera bara till kontrakt du litar på, håll koll på hur din plånbok räknar gas efter Glamsterdam, och behandla varje signeringsruta som det juridiskt bindande beslut den faktiskt är. Bron är byggd av kod, men det är du som bestämmer vad som får korsa den.

Frequently Asked Questions

Är EIP-7702 permanent nu?

Inget protokollbeslut gör EIP-7702 permanent, men den 15 september 2026 gav Ethereum och Base upp försöket att ena sina native-förslag EIP-8141 och EIP-8130, och Glamsterdam innehåller ingen account abstraction. I praktiken betyder det att den tillfälliga bron blir standarden som består under överskådlig tid.

Vad gör Glamsterdam med min gaskostnad?

Glamsterdam räknar om gasen. EIP-7904 sänker priset för de flesta operationer med runt 78 procent, medan EIP-8037 och EIP-8038 höjer priset för att skapa nya konton och för att läsa sällan använd data. En vanlig överföring till ett befintligt konto kostar fortfarande 21 000 gas, men att skicka till en helt ny adress blir dyrare.

Är EIP-8130 och native konton inställda?

Nej, men de är framskjutna. Base flyttade EIP-8130 från sin Cobalt-uppgradering till en ny, ännu oschemalagd fork som kallas Zenith, och den lever bara på devnet utan datum för mainnet. Ethereums EIP-8141 är flyttad till en icke-rubrik-status för en senare uppgradering, Hegotá.

Har splittringen gjort EIP-7702 osäkrare?

Nej. Risken med EIP-7702 sitter i signeringsögonblicket och i nyckelhanteringen, inte i protokollet, och det ändras inte av att native konton skjuts upp. En enda signerad auktorisering kan ge full kontroll över kontot, så granska alltid vad du signerar och delegera bara till kontrakt du litar på.

Hur återställer jag en EIP-7702-delegering?

Du återställer en delegering genom att låta plånboken delegera om till nolladressen, vilket tar bort den installerade koden. Tjänster som revoke.cash kan visa din delegering men inte ta bort den; själva återställningen sker i plånboken, och om din nyckel kan vara komprometterad bör du flytta tillgångarna till en ny plånbok först.

Av Yuki Tanaka, senior redaktör på HOGE Wire med fokus på plånböcker, börser och Ethereums infrastruktur.