EIP-7702 mellan kedjorna: ditt smarta konto följer inte med

Du gjorde uppgraderingen på Ethereum. Du buntade ihop ett godkännande och en swap i en enda transaktion, betalade avgiften i en stablecoin och satte en sessionsnyckel så att spelet slapp be dig signera vid varje drag. Plånboken kändes äntligen som ett riktigt konto. Sedan flyttade du över lite kapital till Arbitrum, öppnade samma adress där, och allt var borta. Ingen batchning, ingen gassponsring, ingen sessionsnyckel. Samma adress, samma nyckel, men ett helt vanligt konto igen.

Det är ingen bugg. Det är så EIP-7702 är byggt. Den delegering som gör din EOA smart bor på en enskild kedja, inte i din privata nyckel och inte i din adress. På Ethereum mainnet pekar ditt konto mot en smart kontraktslogik; på Arbitrum, Base eller Optimism gör det inte det förrän du uttryckligen upprepar samma steg där. Detta är den obekväma sanningen bakom allt prat om ett konto som fungerar överallt, och den blir bara mer aktuell nu när färdplanen för native kontoabstraktion har splittrats i två läger.

Den här artikeln är motstycket till löftet. Om löftet om ett smart konto och tio kedjor handlar om drömmen om chain abstraction, handlar den här texten om varför en EIP-7702-delegering i praktiken stannar hemma, vad chain_id noll faktiskt betyder, varför börserna måste läsa dina konton olika beroende på kedja, och vilka vägar som kan göra portabiliteten verklig. Vi håller oss till verifierbara fakta och pekar på källorna längs vägen.

Vad EIP-7702 faktiskt gör (kort repetition)

EIP-7702 aktiverades i Ethereums Pectra-uppgradering den 7 maj 2025 och införde en ny transaktionstyp, 0x04, som ibland kallas set-code. Med den kan en vanlig plånbok (en EOA) peka mot koden i ett smart kontrakt utan att du byter adress eller flyttar dina tillgångar. Tekniskt sker det genom att kontots kod sätts till en så kallad delegeringspekare: byten 0xef0100 följt av adressen till det kontrakt som ska köra logiken. Hela pekaren är 23 byte, tre prefixbyte plus en 20 byte lång adress, och specifikationen beskriver den svart på vitt.

När pekaren väl är satt beter sig kontot som ett smart konto: det kan bunta flera anrop i en transaktion, låta någon annan betala gasen, sätta tidsbegränsade sessionsnycklar och lägga in enkla spärrar. Delegeringen är återkallelig; signerar du en ny auktorisering mot nulladressen nollställs kontot till en vanlig EOA igen. Ethereum-kärnutvecklaren Marius van der Wijden har beskrivit greppet som ett sätt att låta befintliga plånböcker efterlikna funktionerna hos kontoabstraktionsplånböcker, samtidigt som han manat branschen att noga utvärdera alla dess skarpa kanter. Det är de skarpa kanterna, och särskilt de som uppstår mellan kedjor, som den här texten handlar om.

Adoptionen ser vid första anblick enorm ut. BundleBear räknar i skrivande stund över 60 miljoner aktiva delegeringar och långt över 100 miljoner set-code-transaktioner. (Som referens handlas ether i slutet av september 2026 kring 2 690 dollar, och med en dollarkurs runt 9,92 kronor motsvarar det omkring 26 700 kronor.) Men de siffrorna behöver läsas med försiktighet, vilket vi återkommer till: en stor del av auktoriseringarna är automatiska sweeper-kontrakt, inte människor som medvetet uppgraderat sin dagliga plånbok.

Delegeringen bor på en kedja, inte i din nyckel

Här är kärnan i hela problemet. Din privata nyckel är universell: samma nyckel styr samma adress på Ethereum, Arbitrum, Base, Optimism och alla andra EVM-kedjor. Men EIP-7702-delegeringen är inte en egenskap hos nyckeln, den är ett tillstånd som skrivs in i kontots kod på en bestämd kedja. Delegeringspekaren 0xef0100 plus adress lagras i state på just den kedja där du körde din set-code-transaktion. Ethereum vet ingenting om vad som står i Arbitrums state, och tvärtom.

Konsekvensen är rak. Uppgraderar du din adress på mainnet är du ett smart konto på mainnet, punkt. På varje annan kedja är samma adress en tom EOA tills du signerar en ny auktorisering och skickar in den där. Det finns ingen automatisk spridning, ingen synk, ingen delad kontoprofil som följer med. Delegeringen reser inte med dig; du bygger om den, kedja för kedja.

Det bryter mot hur de flesta användare tänker om sin plånbok. Vi är vana vid att en adress är en adress: det som gäller på en kedja borde gälla på nästa. Med vanliga EOA:er stämmer den intuitionen, eftersom en tom EOA fungerar likadant överallt. I samma sekund du gör kontot smart via 7702 slutar intuitionen gälla, för nu bär adressen på en egenskap som är lokal. Det är också därför en fråga som låter trivial, alltså om ditt konto är smart eller inte, plötsligt kräver ett följdsvar: på vilken kedja?

För en enskild spelare är det förvirrande. För en gaslös onboarding där hela poängen är att användaren aldrig ska tänka på infrastruktur är det ett reellt hinder: appen måste antingen se till att delegeringen finns på rätt kedja innan användaren gör något, eller hantera fallet där den saknas. Och för en börs som tar emot insättningar från samma adress på flera kedjor blir det en driftsfråga, som vi strax ska se.

chain_id noll: giltig överallt, och dess baksida

Specifikationen erbjuder en genväg. Varje auktorisering innehåller ett fält för chain_id, och reglerna säger att en nod ska godta auktoriseringen om chain_id antingen är den aktuella kedjans identifierare eller noll. Sätter du chain_id till noll blir auktoriseringen giltig på alla kedjor samtidigt. EIP-7702 uttrycker det rakt: när universell utrullning föredras sätter man helt enkelt chain_id till noll.

Det låter som lösningen på portabilitetsproblemet, och för vissa uppsättningar är det praktiskt. Men det byter ett bekvämt problem mot ett farligt. En auktorisering med chain_id noll kan spelas upp (replay) på vilken kedja som helst, av vem som helst som har den signerade tupeln. Och det som gör replay riktigt otäckt i just det här fallet är vad specifikationen själv varnar för: du signerar en pekare till en adress, men vilken kod som faktiskt ligger på den adressen kan skilja sig från kedja till kedja.

Tänk igenom det. På mainnet kanske adressen X är ett granskat, välkänt smart konto-kontrakt. På en annan kedja kan exakt samma adress vara tom, eller värre, innehålla helt annan kod som någon medvetet deployat dit. Med en chain_id noll-auktorisering säger du i praktiken: kör vad som än råkar ligga på X, på vilken kedja som helst, nu och i framtiden. Om ett kontrakt deployas till samma adress på en kedja där det tidigare var tomt kan din redan signerade auktorisering plötsligt peka mot kod du aldrig granskat. Specifikationen rekommenderar därför att man begränsar räckvidden genom att ange ett specifikt chain_id när man är osäker.

Här sitter alltså användaren i en klämma som sällan syns i marknadsföringen av smarta konton. Ett specifikt chain_id ger säkerhet men ingen portabilitet: du måste auktorisera på nytt för varje kedja. chain_id noll ger portabilitet men öppnar en replay- och fel-kod-risk. Det finns ingen inställning som ger dig båda delarna gratis, och de flesta plånboksgränssnitt döljer valet helt, vilket betyder att användaren sällan ens vet vilket läge hen befinner sig i.

Samma adress, olika kedja: fyra scenarier

Tabellen nedan visar hur en och samma adress kan bete sig helt olika beroende på kedja och hur auktoriseringen är signerad. Det är samma nyckel och samma adress i alla fyra fallen.

Sista raden förtjänar en extra tanke. Städar du upp en gammal eller misstänkt delegering på mainnet är det lätt att andas ut och tro att saken är utagerad. Men om du någon gång auktoriserat samma logik på en annan kedja lever den kvar där tills du nollställer den där också. Rensning är, precis som allt annat i 7702, en handling per kedja.

Varför börserna bryr sig: insättningar och 23-bytes-screening

För en centraliserad börs är en EIP-7702-delegering inte en abstrakt designfråga, den är en driftsfråga med pengar i botten. Börser tar emot insättningar till adresser och skickar ut uttag från dem, och de har i åratal byggt sina system runt en enkel skiljelinje: adresser som är EOA:er beter sig på ett sätt, adresser med kontraktskod på ett annat. En delegerad EOA suddar ut den linjen. Den ser ut som en vanlig plånbok, men den har kod, och den koden kan bunta anrop, dra in tredjepartslogik och göra saker en klassisk EOA aldrig kunde.

Praktiken som har växt fram är att skanna efter själva delegeringspekaren. Eftersom varje delegerad EOA har kod som börjar med de 23 byten 0xef0100 plus en adress kan en börs upptäcka delegerade konton genom att läsa kontots kod och matcha mot det mönstret. Utifrån det kan de välja policy: tillåta insättningar från delegerade konton men granska mottagarkontraktet, kräva extra bekräftelser, eller i vissa fall behandla sådana insättningar annorlunda. Poängen är att börsen måste veta att kontot är delegerat innan den agerar.

Och nu kopplar vi tillbaka till kedjeproblemet. Eftersom delegeringen är lokal per kedja måste den här screeningen köras per kedja. En och samma kundadress kan vara en oskyldig EOA på en kedja och ett delegerat smart konto på en annan. Börsen kan inte skanna adressen en gång och dra en slutsats som gäller överallt; den måste läsa varje kedjas state för sig. För en aktör som stödjer insättningar på ett dussin kedjor blir det ett dussin separata kontroller för samma kund.

Det här är precis den sortens komplexitet som ligger bakom att börser rör sig försiktigt runt smarta konton. Frågorna staplas: hur hanterar vi ett uttag till en adress som är delegerad på målkedjan men inte på vår? Vad gör vi om delegeringen ändras mellan att kunden får sin insättningsadress och att pengarna faktiskt kommer in? Hur skiljer vi en legitim uppgradering från en sweeper som väntar på att tömma kontot? Inget av det är olösligt, men allt kräver kod, tester och en riskmodell som tänker per kedja, inte per adress.

Sweepers, CrimeEnjoyor och vad adoptionssiffrorna döljer

Innan någon läser 60 miljoner delegeringar som 60 miljoner glada användare av smarta konton är det värt att veta vad de flesta av dem faktiskt är. Redan under de första veckorna efter Pectra konstaterade handelsfirman Wintermute att en förkrossande majoritet av alla tidiga delegeringar pekade mot en enda sorts kontrakt: automatiska sweepers som tömmer en komprometterad plånbok i samma ögonblick som pengar landar på den. Wintermutes bedömning var att långt över nio av tio delegeringar var just sådana, ofta en igenkänd variant som fått smeknamnet CrimeEnjoyor, och att själva EIP:n trots det är säker att använda, eftersom sweepern bara aktiveras på konton vars nyckel redan läckt.

Det förändrar hur man ska läsa BundleBears kurvor. De kumulativa auktoriseringarna, som nu ligger i hundratals miljoner, är kraftigt uppblåsta av att samma sweeper-mönster deployas om och om igen mot tusentals adresser. Siffran som faktiskt betyder något är antalet levande delegeringar just nu, och även där ingår en stor del automatik. Riktig, medveten användning av smarta konton för batchning, gassponsring och sessionsnycklar växer, men den är en mindre del av totalen än rubriksiffrorna antyder.

Kedjeperspektivet gör bilden ännu grumligare. Sweepers deployas där pengarna finns, och de gör det per kedja precis som allt annat i 7702. En läckt nyckel kan ha en sweeper-delegering på flera kedjor samtidigt, var och en redo att fånga inkommande medel. För den som försöker mäta hur många riktiga smarta konton som finns är det alltså inte bara sweepers som stör bilden, utan också att varje konto kan räknas flera gånger, en gång per kedja det rör sig på.

Löftet om chain abstraction möter verkligheten

Branschens svar på all den här friktionen har ett samlingsnamn: chain abstraction. Idén är att användaren ska slippa veta vilken kedja hen är på; plånboken eller appen sköter bryggor, gasavgifter och saldon i bakgrunden så att det känns som ett enda konto med en enda balans. Det är ett vackert mål, och vi har ägnat det en egen genomgång i löftet om ett smart konto och tio kedjor. Men det är viktigt att skilja på vad som abstraheras bort och vad som faktiskt finns kvar under ytan.

Det plånböckerna löser idag är framför allt gas och saldon. Bitget Wallet byggde till exempel in stöd för EIP-7702 och lät användare betala nätverksavgifter i USDT, USDC eller den egna token över ett antal kedjor, så att man kan använda flera nätverk utan att någonsin behöva skaffa rätt gastoken. Bitget Wallets marknadschef Jamie Elkaleh beskrev poängen som att föra självförvaret närmare bekvämligheten hos en centraliserad börs. Det är en verklig förbättring av upplevelsen.

Men lägg märke till vad som inte abstraheras bort: själva delegeringen. Att en plånbok betalar din gas i en stablecoin på fem kedjor betyder inte att din 7702-uppgradering finns på alla fem. Gasabstraktion och kontoportabilitet är två skilda saker. Du kan mycket väl ha en smidig, kedjeagnostisk avgiftsupplevelse ovanpå ett konto som fortfarande bara är smart på en enda kedja. Abstraktionen döljer friktionen; den tar inte bort det underliggande faktumet att delegeringen är lokal.

Det är den springande punkten. Chain abstraction är ett UX-lager, inte en egenskap hos protokollet. Så länge det som gör kontot smart lagras separat på varje kedja kommer abstraktionen alltid att vara en konstruktion som någon måste bygga, underhålla och stå för. När den konstruktionen fungerar märks den inte. När den fallerar, till exempel för att en kedja saknar din delegering i ett kritiskt ögonblick, faller du tillbaka till den kedjebundna verkligheten utan förvarning.

Native kontoabstraktion splittras: EIP-8141 mot EIP-8130

Om chain abstraction är plåstret på ytan är native kontoabstraktion den föreslagna operationen på djupet: att bygga in smarta konton direkt i protokollet så att man slipper både ERC-4337:s separata infrastruktur och 7702:s delegeringspekare. Problemet är att branschen just nu har slutat komma överens om hur den operationen ska gå till.

Den 14 september 2026 bekräftade utvecklare att Ethereum och Coinbases layer 2 Base hade övergett månader av gemensamt arbete på en enad standard för native kontoabstraktion. Derek Chiang, grundare av ZeroDev och numera hos Ethlabs, tillkännagav uppbrottet och sammanfattade det som att de lösningar man hittade alla krävde att den ena eller andra sidan kompromissade åtminstone lite på sina kärnmål, och att man därför gick skilda vägar och lade bördan på plånböckerna att hantera fragmenteringen som följer.

De två spåren skiljer sig i filosofi. Ethereums EIP-8141, kallad Frame Transactions, är tänkt till den framtida Hegotá-uppgraderingen och prioriterar censurmotstånd och säkerhet; Vitalik Buterin har beskrivit den som nära optimal. Bases EIP-8130 bygger i stället på en on-chain keystore och siktar på Bases Cobalt-uppgradering, med skala och regelefterlevnad som ledstjärnor. EIP-8130 introducerar en ny transaktionstyp och en keystore som lagrar varje kontos godkända signerare, och stöds av Coinbase, Optimism och WalletConnect. Cobalt var planerad till slutet av september 2026, men förslaget var i mitten av månaden fortfarande experimentellt på ett devnet, så tidtabellen kan glida.

För portabiliteten är innebörden dubbel. Å ena sidan är båda spåren försök att göra smarta konton till en förstklassig medborgare på respektive kedja, vilket på sikt är bättre än dagens delegeringspekare. Å andra sidan betyder två olika standarder att en plånbok som vill fungera överallt kan behöva stödja två skilda native transaktionstyper utöver 7702 och 4337. Fragmenteringen som 7702 redan skapar per kedja riskerar alltså att fördjupas, inte försvinna, när L1 och den största L2:n drar åt olika håll. Det är en utveckling som får den som drömmer om ett enda spelkonto för nästa miljard spelare att tänka ett varv till.

Keystore-rollups: den långsiktiga vägen till portabilitet

Finns det då någon lösning som faktiskt låter ett konto vara sig självt över alla kedjor? Den mest lovande idén heter keystore-rollup, och det är ingen slump att Bases native-spår bygger på just en keystore. Grundtanken, som Vitalik Buterin skissat i sin minimala keystore-rollup, är att flytta det som definierar kontot, alltså vilka nycklar och vilka guardians som får styra det, till en enda dedikerad plats, och sedan låta konton på alla andra kedjor läsa därifrån.

Mekaniken bygger på bevis. En keystore-rollup gör en sak och bara en sak: lagrar och uppdaterar kontons nycklar och regler, vilket gör den liten, granskningsbar och billig. Konton på andra kedjor autentiserar sedan mot den via bevis, till exempel zero-knowledge-bevis eller Merkle-bevis över dess state, så att samma regler kan gälla ett konto på vilken kedja som helst. Byter du nyckel eller lägger till en guardian på ett ställe kan alla dina konton hämta den uppdateringen i stället för att du ska behöva göra om ändringen manuellt på var och en. Teamen bakom Scroll och Base har delat konkreta specar; Scrolls variant lagrar data på L1 men låter den uppdateras billigt från deras rollup via en ny precompile för att läsa L1-state.

Det här är, om det lyckas, den riktiga fixen: inte att kopiera delegeringen till varje kedja, utan att låta alla kedjor peka mot en gemensam sanning om vem du är. Base har beskrivit hur en keystore kan ge cross-chain-konsistens för konton, och Vitalik har lyft fram synken av nycklar och guardians över L2:er som en central pusselbit för sömlös interoperabilitet.

Men notera ironin i tidslinjen. Just som keystore-idén mognar och Base gör den till sin native-standard splittras den bredare native-AA-agendan i två läger. En keystore-rollup löser portabiliteten inom ett ekosystem som delar dess antaganden; den löser den inte automatiskt mellan Ethereums Frame Transactions-spår och Bases keystore-spår. Portabilitet kräver enighet om formatet, och enigheten är just nu på väg åt fel håll.

Glamsterdam och nedräkningen till 6 oktober

Medan native-AA-striden utspelar sig rullar Ethereums vanliga uppgraderingscykel vidare, och nästa milstolpe är nära. Glamsterdam, nätverkets kommande hardfork, ska först testas på testnätet Sepolia, och utvecklarna siktar på den 6 oktober 2026, preliminärt klockan 13:53 UTC. Mainnet är fortfarande otidsatt men väntas någon gång under fjärde kvartalet, och Ethereums egen färdplan säger rakt ut att datumet inte är bekräftat.

Glamsterdams tyngsta inslag är enshrined proposer-builder separation, ePBS, definierad i EIP-7732. Den flyttar in överlämningen mellan den som föreslår ett block och den som bygger det i själva protokollet, vilket minskar beroendet av externa relays och vidgar fönstret för datapropagering från runt två sekunder till närmare nio. Syftet är högre kapacitet och fler blobbar för layer 2, inte kontoportabilitet, så uppgraderingen löser inte direkt problemet den här artikeln handlar om. Men den sätter riktningen för L1: mer genomströmning, mindre beroende av mellanhänder.

Testet är inte utan gnissel. Utvecklare har varnat för att värdelös test-ETH kan låta illasinnade byggare gång på gång vinna blockauktioner och sedan hålla inne exekveringsdatan, ett beteende som stör testnätet men inte utgör något direkt hot mot användarnas medel på mainnet. Att den sortens auktionsdynamik ens diskuteras säger något om hur mycket av Ethereums framtid som handlar om vem som får ordna transaktioner, ett tema som går igen i vår genomgång av EIP-7702 och MEV.

För den som följer smarta konton är Glamsterdam värd att hålla ögonen på av en indirekt anledning. Ju mer L1 optimeras för genomströmning och blobbar, desto mer aktivitet flyttar ut till layer 2, och desto viktigare blir just den kedjeövergripande kontofrågan. En värld där mer sker på fler kedjor är en värld där 7702:s kedjebundna delegering känns i fler situationer, inte färre.

Färdplanen och fragmenteringen i en tabell

Så här ser tidslinjen ut för de bitar som tillsammans avgör hur portabelt ditt smarta konto blir, från det som redan är på plats till det som fortfarande är förslag.

Två saker framträder. Det som är live idag, Pectra och Fusaka, ger dig kraftfulla konton och mer kapacitet men löser inte portabiliteten. Och det som skulle kunna lösa den, native standarder och keystore-rollups, är antingen forskning eller på väg åt två olika håll. Mellan dessa poler lever användaren och börsen med 7702:s kedjebundna verklighet, sannolikt under lång tid framöver.

Säkerhet över kedjor: replay, fel kod och phishing

Kedjebundenheten är inte bara en bekvämlighetsfråga, den är en säkerhetsfråga. Vi har redan nämnt replay-risken med chain_id noll, men det är värt att stanna vid vad den innebär i praktiken. En signerad auktorisering är ett litet objekt som kan skickas in av vem som helst. Är den signerad brett, alltså med chain_id noll, kan den skickas in på en kedja du aldrig tänkt använda, och där kan den aktivera en delegering du trodde hörde hemma någon annanstans.

Lägg till fel-kod-problemet. Eftersom samma adress kan husera olika kod på olika kedjor är en pekare som är trygg på mainnet inte automatiskt trygg någon annanstans. En angripare som kontrollerar vilken kod som ligger på måladressen på en mindre bevakad kedja kan förvandla din breda auktorisering till ett verktyg mot dig. Det är exakt därför specifikationen manar till att begränsa räckvidden när man är osäker, och därför breda auktoriseringar bör behandlas som ett medvetet val, inte en bekvämlighet man klickar förbi.

Sedan har vi den mänskliga faktorn. Blindsignering, alltså att godkänna en transaktion vars innebörd man inte kan läsa, är den enskilt största riskkällan för smarta konton, och kedjeförvirring gör den värre. En phishing-sida kan visa upp en till synes ofarlig signering och i själva verket be dig auktorisera en delegering, eller be om en bred chain_id noll-signatur som gäller överallt. Principen som skyddar dig är enkel att formulera och svår att leva efter: läs vad du signerar, och var extra vaksam när en signatur inte tydligt hör hemma på en specifik kedja. Smarta konton väcker dessutom helt andra långsiktiga frågor, som hur de kan bli en flyktväg undan kvanthotet mot dagens kryptografi, men det är en annan historia.

Finansinspektionen, MiCA och självförvar över kedjor

Var landar då allt det här regulatoriskt för en svensk användare? Huvudregeln är enkel och viktig att förstå: EIP-7702 handlar om självförvar. Ett delegerat konto som du styr med din egen nyckel är fortfarande din plånbok, och självförvarade plånböcker faller utanför det som MiCA reglerar. MiCA och Finansinspektionen riktar in sig på tjänsteleverantörerna, alltså börser, växlare och förvaringsinstitut (CASP:er), inte på det protokoll eller den kontraktslogik du väljer att peka din EOA mot.

Det spelar roll för hur man ska tänka på kedjefrågan. När du auktoriserar en delegering på Ethereum, Arbitrum eller Base gör du det på egen hand, utan mellanhand, och ingen svensk tillståndsplikt utlöses av själva handlingen. I samma stund du använder en börs för att köpa, sälja eller förvara är det börsen som omfattas av regelverket. Sedan den 1 oktober 2025 måste varje kryptobolag som vill fortsätta betjäna svenska kunder ha ansökt om tillstånd hos FI eller avveckla verksamheten, och FI uppmanar konsumenter att bara vända sig till bolag som sökt eller fått tillstånd.

MiCA delar in kryptotillgångar i tre slag, e-pengatoken, tillgångsanknuten token och andra kryptotillgångar, och det är den indelningen som avgör vilka regler som gäller för en utgivare eller tjänst. Värt att komma ihåg för den mer avancerade användaren: kryptoderivat, som terminer och eviga kontrakt, är finansiella instrument under MiFID II och övervakas av marknadsmyndigheten, inte under MiCA. ESMA har dessutom klargjort gränsen mot finansiella instrument för nytto- och speltokens, ett besked från den 19 mars 2025 som är relevant för allt som rör spel och konton på kedjan.

Den praktiska slutsatsen är att kedjebundenheten i 7702 inte skapar någon ny tillståndsplikt för dig som privatperson, men den lägger ansvar på dig. Med självförvar följer att du själv bär risken för replay, blindsignering och felaktiga delegeringar, per kedja. FI:s återkommande påminnelse om att krypto är komplext och volatilt gäller i högsta grad här: ju smartare kontot blir, desto fler val måste du förstå.

Så hanterar du verkligheten idag

Tills native standarder och keystore-rollups mognar är den bästa strategin att arbeta med kedjebundenheten i stället för att bli överraskad av den. Här är en praktisk checklista, först för dig som användare och sedan för den som driver en tjänst.

1. Utgå från att din delegering bara finns på den kedja där du satte den. Ska du vara ett smart konto på flera kedjor, planera för att auktorisera på var och en.
2. Undvik breda chain_id noll-auktoriseringar om du inte förstår exakt vad de innebär. De ger portabilitet men öppnar för replay och för att koden på måladressen kan skilja sig mellan kedjor.
3. Kontrollera att målkontraktet faktiskt finns och är det du tror på varje kedja innan du auktoriserar där. Samma adress är ingen garanti för samma kod.
4. Läs vad du signerar. Var särskilt vaksam på signeringar som inte tydligt hör hemma på en specifik kedja, det är ett tecken på en bred auktorisering.
5. När du städar upp en gammal delegering, kom ihåg att göra det per kedja. En nollställning på mainnet rör inte Arbitrum.
6. Bevaka din nyckelhantering långsiktigt; ett smart konto är bara så säkert som nyckeln bakom det, oavsett hur många kedjor det finns på.

För en börs eller plånboksutvecklare blir listan en annan. Skanna efter delegeringspekaren per kedja, inte per adress. Anta att en kunds adress kan vara EOA på en kedja och smart konto på en annan, och bygg riskmodellen därefter. Var tydlig i gränssnittet om vilken kedja en uppgradering gäller, så att användaren inte tror att den spridit sig. Och följ noga hur EIP-8141 och EIP-8130 utvecklas, för den dag två native transaktionstyper finns i produktion kommer stödet för dem att bli en konkurrensfråga, inte en teknisk detalj.

Summan av det hela: EIP-7702 gav oss smarta konton utan migration, vilket var en elegant lösning på ett svårt problem. Men elegansen har ett pris, och priset heter portabilitet. Ditt konto blev smart, men det blev smart på en kedja i taget, och tills branschen enas om något bättre är det den verkligheten både du och din börs behöver planera för.

Vanliga frågor

Varför är mitt smarta konto en vanlig EOA på Arbitrum?

Därför att EIP-7702-delegeringen lagras per kedja. Du uppgraderade kontot på Ethereum mainnet, men på Arbitrum har adressen ingen delegeringspekare förrän du signerar en ny auktorisering och skickar in den där. Din nyckel är universell, men det som gör kontot smart är kedjelokalt.

Vad betyder chain_id noll i en EIP-7702-auktorisering?

Det gör auktoriseringen giltig på alla kedjor samtidigt. Det är bekvämt för portabilitet, men öppnar för att signaturen spelas upp på andra kedjor och för att koden på måladressen kan skilja sig mellan kedjor. Specifikationen rekommenderar att man begränsar räckvidden med ett specifikt chain_id när man är osäker.

Är EIP-7702 farligt att använda?

Själva EIP:n bedöms som säker; riskerna ligger i blindsignering, breda chain_id noll-auktoriseringar och phishing. Wintermute konstaterade att en stor majoritet av de tidiga delegeringarna var automatiska sweeper-kontrakt på redan komprometterade nycklar, inte ett fel i protokollet.

Löser native kontoabstraktion portabiliteten?

Den kan göra smarta konton förstklassiga per kedja, men Ethereum och Base gick i september 2026 skilda vägar med EIP-8141 respektive EIP-8130, så två format kan komma att samexistera. Keystore-rollups, som låter kedjor läsa nycklar och regler från en gemensam källa, framstår som den mer lovande vägen till äkta cross-chain-portabilitet.

Hur påverkar EIP-7702 svenska börser och Finansinspektionen?

Självförvarade delegerade konton faller utanför MiCA, så själva uppgraderingen utlöser ingen tillståndsplikt. Börser och andra tjänsteleverantörer omfattas däremot, och sedan den 1 oktober 2025 måste de ha ansökt om tillstånd hos Finansinspektionen. Börserna behöver dessutom skanna efter delegeringspekaren per kedja.

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