{"id":505,"date":"2026-09-26T04:58:28","date_gmt":"2026-09-26T04:58:28","guid":{"rendered":"https:\/\/hoge.gg\/se\/eip-7702-mellan-kedjorna-portabilitet-smart-konto-2026\/"},"modified":"2026-09-26T04:58:28","modified_gmt":"2026-09-26T04:58:28","slug":"eip-7702-mellan-kedjorna-portabilitet-smart-konto-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/se\/eip-7702-mellan-kedjorna-portabilitet-smart-konto-2026\/","title":{"rendered":"EIP-7702 mellan kedjorna: ditt smarta konto f\u00f6ljer inte med"},"content":{"rendered":"

Du gjorde uppgraderingen p\u00e5 Ethereum. Du buntade ihop ett godk\u00e4nnande och en swap i en enda transaktion, betalade avgiften i en stablecoin och satte en sessionsnyckel s\u00e5 att spelet slapp be dig signera vid varje drag. Pl\u00e5nboken k\u00e4ndes \u00e4ntligen som ett riktigt konto. Sedan flyttade du \u00f6ver lite kapital till Arbitrum, \u00f6ppnade samma adress d\u00e4r, och allt var borta. Ingen batchning, ingen gassponsring, ingen sessionsnyckel. Samma adress, samma nyckel, men ett helt vanligt konto igen.<\/p>

Det \u00e4r ingen bugg. Det \u00e4r s\u00e5 EIP-7702 \u00e4r byggt. Den delegering som g\u00f6r din EOA smart bor p\u00e5 en enskild kedja, inte i din privata nyckel och inte i din adress. P\u00e5 Ethereum mainnet pekar ditt konto mot en smart kontraktslogik; p\u00e5 Arbitrum, Base eller Optimism g\u00f6r det inte det f\u00f6rr\u00e4n du uttryckligen upprepar samma steg d\u00e4r. Detta \u00e4r den obekv\u00e4ma sanningen bakom allt prat om ett konto som fungerar \u00f6verallt, och den blir bara mer aktuell nu n\u00e4r f\u00e4rdplanen f\u00f6r native kontoabstraktion har splittrats i tv\u00e5 l\u00e4ger.<\/p>

Den h\u00e4r artikeln \u00e4r motstycket till l\u00f6ftet. Om l\u00f6ftet om ett smart konto och tio kedjor<\/a> handlar om dr\u00f6mmen om chain abstraction, handlar den h\u00e4r texten om varf\u00f6r en EIP-7702-delegering i praktiken stannar hemma, vad chain_id noll faktiskt betyder, varf\u00f6r b\u00f6rserna m\u00e5ste l\u00e4sa dina konton olika beroende p\u00e5 kedja, och vilka v\u00e4gar som kan g\u00f6ra portabiliteten verklig. Vi h\u00e5ller oss till verifierbara fakta och pekar p\u00e5 k\u00e4llorna l\u00e4ngs v\u00e4gen.<\/p>

Vad EIP-7702 faktiskt g\u00f6r (kort repetition)<\/h2>

EIP-7702 aktiverades i Ethereums Pectra-uppgradering den 7 maj 2025 och inf\u00f6rde en ny transaktionstyp, 0x04, som ibland kallas set-code. Med den kan en vanlig pl\u00e5nbok (en EOA) peka mot koden i ett smart kontrakt utan att du byter adress eller flyttar dina tillg\u00e5ngar. Tekniskt sker det genom att kontots kod s\u00e4tts till en s\u00e5 kallad delegeringspekare: byten 0xef0100<\/code> f\u00f6ljt av adressen till det kontrakt som ska k\u00f6ra logiken. Hela pekaren \u00e4r 23 byte, tre prefixbyte plus en 20 byte l\u00e5ng adress, och specifikationen<\/a> beskriver den svart p\u00e5 vitt.<\/p>

N\u00e4r pekaren v\u00e4l \u00e4r satt beter sig kontot som ett smart konto: det kan bunta flera anrop i en transaktion, l\u00e5ta n\u00e5gon annan betala gasen, s\u00e4tta tidsbegr\u00e4nsade sessionsnycklar och l\u00e4gga in enkla sp\u00e4rrar. Delegeringen \u00e4r \u00e5terkallelig; signerar du en ny auktorisering mot nulladressen nollst\u00e4lls kontot till en vanlig EOA igen. Ethereum-k\u00e4rnutvecklaren Marius van der Wijden har beskrivit greppet som ett s\u00e4tt att l\u00e5ta befintliga pl\u00e5nb\u00f6cker efterlikna funktionerna hos kontoabstraktionspl\u00e5nb\u00f6cker<\/a>, samtidigt som han manat branschen att noga utv\u00e4rdera alla dess skarpa kanter. Det \u00e4r de skarpa kanterna, och s\u00e4rskilt de som uppst\u00e5r mellan kedjor, som den h\u00e4r texten handlar om.<\/p>

Adoptionen ser vid f\u00f6rsta anblick enorm ut. BundleBear r\u00e4knar i skrivande stund \u00f6ver 60 miljoner aktiva delegeringar<\/a> och l\u00e5ngt \u00f6ver 100 miljoner set-code-transaktioner. (Som referens handlas ether i slutet av september 2026 kring 2 690 dollar<\/a>, och med en dollarkurs runt 9,92 kronor<\/a> motsvarar det omkring 26 700 kronor.) Men de siffrorna beh\u00f6ver l\u00e4sas med f\u00f6rsiktighet, vilket vi \u00e5terkommer till: en stor del av auktoriseringarna \u00e4r automatiska sweeper-kontrakt, inte m\u00e4nniskor som medvetet uppgraderat sin dagliga pl\u00e5nbok.<\/p>

Delegeringen bor p\u00e5 en kedja, inte i din nyckel<\/h2>

H\u00e4r \u00e4r k\u00e4rnan i hela problemet. Din privata nyckel \u00e4r universell: samma nyckel styr samma adress p\u00e5 Ethereum, Arbitrum, Base, Optimism och alla andra EVM-kedjor. Men EIP-7702-delegeringen \u00e4r inte en egenskap hos nyckeln, den \u00e4r ett tillst\u00e5nd som skrivs in i kontots kod p\u00e5 en best\u00e4md kedja. Delegeringspekaren 0xef0100<\/code> plus adress lagras i state p\u00e5 just den kedja d\u00e4r du k\u00f6rde din set-code-transaktion. Ethereum vet ingenting om vad som st\u00e5r i Arbitrums state, och tv\u00e4rtom.<\/p>

Konsekvensen \u00e4r rak. Uppgraderar du din adress p\u00e5 mainnet \u00e4r du ett smart konto p\u00e5 mainnet, punkt. P\u00e5 varje annan kedja \u00e4r samma adress en tom EOA tills du signerar en ny auktorisering och skickar in den d\u00e4r. Det finns ingen automatisk spridning, ingen synk, ingen delad kontoprofil som f\u00f6ljer med. Delegeringen reser inte med dig; du bygger om den, kedja f\u00f6r kedja.<\/p>

Det bryter mot hur de flesta anv\u00e4ndare t\u00e4nker om sin pl\u00e5nbok. Vi \u00e4r vana vid att en adress \u00e4r en adress: det som g\u00e4ller p\u00e5 en kedja borde g\u00e4lla p\u00e5 n\u00e4sta. Med vanliga EOA:er st\u00e4mmer den intuitionen, eftersom en tom EOA fungerar likadant \u00f6verallt. I samma sekund du g\u00f6r kontot smart via 7702 slutar intuitionen g\u00e4lla, f\u00f6r nu b\u00e4r adressen p\u00e5 en egenskap som \u00e4r lokal. Det \u00e4r ocks\u00e5 d\u00e4rf\u00f6r en fr\u00e5ga som l\u00e5ter trivial, allts\u00e5 om ditt konto \u00e4r smart eller inte, pl\u00f6tsligt kr\u00e4ver ett f\u00f6ljdsvar: p\u00e5 vilken kedja?<\/p>

F\u00f6r en enskild spelare \u00e4r det f\u00f6rvirrande. F\u00f6r en gasl\u00f6s onboarding<\/a> d\u00e4r hela po\u00e4ngen \u00e4r att anv\u00e4ndaren aldrig ska t\u00e4nka p\u00e5 infrastruktur \u00e4r det ett reellt hinder: appen m\u00e5ste antingen se till att delegeringen finns p\u00e5 r\u00e4tt kedja innan anv\u00e4ndaren g\u00f6r n\u00e5got, eller hantera fallet d\u00e4r den saknas. Och f\u00f6r en b\u00f6rs som tar emot ins\u00e4ttningar fr\u00e5n samma adress p\u00e5 flera kedjor blir det en driftsfr\u00e5ga, som vi strax ska se.<\/p>

chain_id noll: giltig \u00f6verallt, och dess baksida<\/h2>

Specifikationen erbjuder en genv\u00e4g. Varje auktorisering inneh\u00e5ller ett f\u00e4lt f\u00f6r chain_id, och reglerna s\u00e4ger att en nod ska godta auktoriseringen om chain_id antingen \u00e4r den aktuella kedjans identifierare eller noll. S\u00e4tter du chain_id till noll blir auktoriseringen giltig p\u00e5 alla kedjor samtidigt. EIP-7702 uttrycker det rakt: n\u00e4r universell utrullning f\u00f6redras s\u00e4tter man helt enkelt chain_id till noll.<\/p>

Det l\u00e5ter som l\u00f6sningen p\u00e5 portabilitetsproblemet, och f\u00f6r vissa upps\u00e4ttningar \u00e4r det praktiskt. Men det byter ett bekv\u00e4mt problem mot ett farligt. En auktorisering med chain_id noll kan spelas upp (replay) p\u00e5 vilken kedja som helst, av vem som helst som har den signerade tupeln. Och det som g\u00f6r replay riktigt ot\u00e4ckt i just det h\u00e4r fallet \u00e4r vad specifikationen sj\u00e4lv varnar f\u00f6r: du signerar en pekare till en adress, men vilken kod som faktiskt ligger p\u00e5 den adressen kan skilja sig fr\u00e5n kedja till kedja.<\/p>

T\u00e4nk igenom det. P\u00e5 mainnet kanske adressen X \u00e4r ett granskat, v\u00e4lk\u00e4nt smart konto-kontrakt. P\u00e5 en annan kedja kan exakt samma adress vara tom, eller v\u00e4rre, inneh\u00e5lla helt annan kod som n\u00e5gon medvetet deployat dit. Med en chain_id noll-auktorisering s\u00e4ger du i praktiken: k\u00f6r vad som \u00e4n r\u00e5kar ligga p\u00e5 X, p\u00e5 vilken kedja som helst, nu och i framtiden. Om ett kontrakt deployas till samma adress p\u00e5 en kedja d\u00e4r det tidigare var tomt kan din redan signerade auktorisering pl\u00f6tsligt peka mot kod du aldrig granskat. Specifikationen rekommenderar d\u00e4rf\u00f6r att man begr\u00e4nsar r\u00e4ckvidden genom att ange ett specifikt chain_id n\u00e4r man \u00e4r os\u00e4ker.<\/p>

H\u00e4r sitter allts\u00e5 anv\u00e4ndaren i en kl\u00e4mma som s\u00e4llan syns i marknadsf\u00f6ringen av smarta konton. Ett specifikt chain_id ger s\u00e4kerhet men ingen portabilitet: du m\u00e5ste auktorisera p\u00e5 nytt f\u00f6r varje kedja. chain_id noll ger portabilitet men \u00f6ppnar en replay- och fel-kod-risk. Det finns ingen inst\u00e4llning som ger dig b\u00e5da delarna gratis, och de flesta pl\u00e5nboksgr\u00e4nssnitt d\u00f6ljer valet helt, vilket betyder att anv\u00e4ndaren s\u00e4llan ens vet vilket l\u00e4ge hen befinner sig i.<\/p>

Samma adress, olika kedja: fyra scenarier<\/h2>

Tabellen nedan visar hur en och samma adress kan bete sig helt olika beroende p\u00e5 kedja och hur auktoriseringen \u00e4r signerad. Det \u00e4r samma nyckel och samma adress i alla fyra fallen.<\/p>

Situation<\/th>chain_id i auktoriseringen<\/th>Vad som h\u00e4nder<\/th>Risk eller notering<\/th><\/tr><\/thead>
Uppgraderad p\u00e5 mainnet, inget gjort p\u00e5 Arbitrum<\/td>Mainnets ID<\/td>Smart konto p\u00e5 mainnet, vanlig EOA p\u00e5 Arbitrum<\/td>Ingen extra risk, men noll portabilitet<\/td><\/tr>
Auktorisering signerad brett<\/td>0<\/td>Samma delegering giltig p\u00e5 alla EVM-kedjor<\/td>Kan spelas upp; koden p\u00e5 adressen kan skilja sig per kedja<\/td><\/tr>
Samma adress, kontrakt saknas p\u00e5 m\u00e5lkedjan<\/td>0<\/td>Pekare mot tom adress; anrop kan misslyckas eller bete sig ov\u00e4ntat<\/td>En framtida deploy till adressen kan \u00e4ndra beteendet<\/td><\/tr>
Delegering \u00e5terkallad p\u00e5 en kedja<\/td>M\u00e5lkedjans ID<\/td>Nollst\u00e4lld till EOA d\u00e4r, men kan vara kvar smart p\u00e5 andra kedjor<\/td>L\u00e4tt att tro att kontot \u00e4r rensat \u00f6verallt<\/td><\/tr><\/tbody><\/table><\/figure>

Sista raden f\u00f6rtj\u00e4nar en extra tanke. St\u00e4dar du upp en gammal eller misst\u00e4nkt delegering p\u00e5 mainnet \u00e4r det l\u00e4tt att andas ut och tro att saken \u00e4r utagerad. Men om du n\u00e5gon g\u00e5ng auktoriserat samma logik p\u00e5 en annan kedja lever den kvar d\u00e4r tills du nollst\u00e4ller den d\u00e4r ocks\u00e5. Rensning \u00e4r, precis som allt annat i 7702, en handling per kedja.<\/p>

Varf\u00f6r b\u00f6rserna bryr sig: ins\u00e4ttningar och 23-bytes-screening<\/h2>

F\u00f6r en centraliserad b\u00f6rs \u00e4r en EIP-7702-delegering inte en abstrakt designfr\u00e5ga, den \u00e4r en driftsfr\u00e5ga med pengar i botten. B\u00f6rser tar emot ins\u00e4ttningar till adresser och skickar ut uttag fr\u00e5n dem, och de har i \u00e5ratal byggt sina system runt en enkel skiljelinje: adresser som \u00e4r EOA:er beter sig p\u00e5 ett s\u00e4tt, adresser med kontraktskod p\u00e5 ett annat. En delegerad EOA suddar ut den linjen. Den ser ut som en vanlig pl\u00e5nbok, men den har kod, och den koden kan bunta anrop, dra in tredjepartslogik och g\u00f6ra saker en klassisk EOA aldrig kunde.<\/p>

Praktiken som har v\u00e4xt fram \u00e4r att skanna efter sj\u00e4lva delegeringspekaren. Eftersom varje delegerad EOA har kod som b\u00f6rjar med de 23 byten 0xef0100<\/code> plus en adress kan en b\u00f6rs uppt\u00e4cka delegerade konton genom att l\u00e4sa kontots kod och matcha mot det m\u00f6nstret. Utifr\u00e5n det kan de v\u00e4lja policy: till\u00e5ta ins\u00e4ttningar fr\u00e5n delegerade konton men granska mottagarkontraktet, kr\u00e4va extra bekr\u00e4ftelser, eller i vissa fall behandla s\u00e5dana ins\u00e4ttningar annorlunda. Po\u00e4ngen \u00e4r att b\u00f6rsen m\u00e5ste veta att kontot \u00e4r delegerat innan den agerar.<\/p>

Och nu kopplar vi tillbaka till kedjeproblemet. Eftersom delegeringen \u00e4r lokal per kedja m\u00e5ste den h\u00e4r screeningen k\u00f6ras per kedja. En och samma kundadress kan vara en oskyldig EOA p\u00e5 en kedja och ett delegerat smart konto p\u00e5 en annan. B\u00f6rsen kan inte skanna adressen en g\u00e5ng och dra en slutsats som g\u00e4ller \u00f6verallt; den m\u00e5ste l\u00e4sa varje kedjas state f\u00f6r sig. F\u00f6r en akt\u00f6r som st\u00f6djer ins\u00e4ttningar p\u00e5 ett dussin kedjor blir det ett dussin separata kontroller f\u00f6r samma kund.<\/p>

Det h\u00e4r \u00e4r precis den sortens komplexitet som ligger bakom att b\u00f6rser r\u00f6r sig f\u00f6rsiktigt runt smarta konton. Fr\u00e5gorna staplas: hur hanterar vi ett uttag till en adress som \u00e4r delegerad p\u00e5 m\u00e5lkedjan men inte p\u00e5 v\u00e5r? Vad g\u00f6r vi om delegeringen \u00e4ndras mellan att kunden f\u00e5r sin ins\u00e4ttningsadress och att pengarna faktiskt kommer in? Hur skiljer vi en legitim uppgradering fr\u00e5n en sweeper som v\u00e4ntar p\u00e5 att t\u00f6mma kontot? Inget av det \u00e4r ol\u00f6sligt, men allt kr\u00e4ver kod, tester och en riskmodell som t\u00e4nker per kedja, inte per adress.<\/p>

Sweepers, CrimeEnjoyor och vad adoptionssiffrorna d\u00f6ljer<\/h2>

Innan n\u00e5gon l\u00e4ser 60 miljoner delegeringar som 60 miljoner glada anv\u00e4ndare av smarta konton \u00e4r det v\u00e4rt att veta vad de flesta av dem faktiskt \u00e4r. Redan under de f\u00f6rsta veckorna efter Pectra konstaterade handelsfirman Wintermute att en f\u00f6rkrossande majoritet av alla tidiga delegeringar pekade mot en enda sorts kontrakt: automatiska sweepers som t\u00f6mmer en komprometterad pl\u00e5nbok i samma \u00f6gonblick som pengar landar p\u00e5 den. Wintermutes bed\u00f6mning var att l\u00e5ngt \u00f6ver nio av tio delegeringar var just s\u00e5dana, ofta en igenk\u00e4nd variant som f\u00e5tt smeknamnet CrimeEnjoyor, och att sj\u00e4lva EIP:n trots det \u00e4r s\u00e4ker att anv\u00e4nda<\/a>, eftersom sweepern bara aktiveras p\u00e5 konton vars nyckel redan l\u00e4ckt.<\/p>

Det f\u00f6r\u00e4ndrar hur man ska l\u00e4sa BundleBears kurvor. De kumulativa auktoriseringarna, som nu ligger i hundratals miljoner, \u00e4r kraftigt uppbl\u00e5sta av att samma sweeper-m\u00f6nster deployas om och om igen mot tusentals adresser. Siffran som faktiskt betyder n\u00e5got \u00e4r antalet levande delegeringar just nu, och \u00e4ven d\u00e4r ing\u00e5r en stor del automatik. Riktig, medveten anv\u00e4ndning av smarta konton f\u00f6r batchning, gassponsring och sessionsnycklar v\u00e4xer, men den \u00e4r en mindre del av totalen \u00e4n rubriksiffrorna antyder.<\/p>

Kedjeperspektivet g\u00f6r bilden \u00e4nnu grumligare. Sweepers deployas d\u00e4r pengarna finns, och de g\u00f6r det per kedja precis som allt annat i 7702. En l\u00e4ckt nyckel kan ha en sweeper-delegering p\u00e5 flera kedjor samtidigt, var och en redo att f\u00e5nga inkommande medel. F\u00f6r den som f\u00f6rs\u00f6ker m\u00e4ta hur m\u00e5nga riktiga smarta konton som finns \u00e4r det allts\u00e5 inte bara sweepers som st\u00f6r bilden, utan ocks\u00e5 att varje konto kan r\u00e4knas flera g\u00e5nger, en g\u00e5ng per kedja det r\u00f6r sig p\u00e5.<\/p>

L\u00f6ftet om chain abstraction m\u00f6ter verkligheten<\/h2>

Branschens svar p\u00e5 all den h\u00e4r friktionen har ett samlingsnamn: chain abstraction. Id\u00e9n \u00e4r att anv\u00e4ndaren ska slippa veta vilken kedja hen \u00e4r p\u00e5; pl\u00e5nboken eller appen sk\u00f6ter bryggor, gasavgifter och saldon i bakgrunden s\u00e5 att det k\u00e4nns som ett enda konto med en enda balans. Det \u00e4r ett vackert m\u00e5l, och vi har \u00e4gnat det en egen genomg\u00e5ng i l\u00f6ftet om ett smart konto och tio kedjor<\/a>. Men det \u00e4r viktigt att skilja p\u00e5 vad som abstraheras bort och vad som faktiskt finns kvar under ytan.<\/p>

Det pl\u00e5nb\u00f6ckerna l\u00f6ser idag \u00e4r framf\u00f6r allt gas och saldon. Bitget Wallet byggde till exempel in st\u00f6d f\u00f6r EIP-7702 och l\u00e4t anv\u00e4ndare betala n\u00e4tverksavgifter i USDT, USDC eller den egna token \u00f6ver ett antal kedjor, s\u00e5 att man kan anv\u00e4nda flera n\u00e4tverk utan att n\u00e5gonsin beh\u00f6va skaffa r\u00e4tt gastoken<\/a>. Bitget Wallets marknadschef Jamie Elkaleh beskrev po\u00e4ngen som att f\u00f6ra sj\u00e4lvf\u00f6rvaret n\u00e4rmare bekv\u00e4mligheten hos en centraliserad b\u00f6rs. Det \u00e4r en verklig f\u00f6rb\u00e4ttring av upplevelsen.<\/p>

Men l\u00e4gg m\u00e4rke till vad som inte abstraheras bort: sj\u00e4lva delegeringen. Att en pl\u00e5nbok betalar din gas i en stablecoin p\u00e5 fem kedjor betyder inte att din 7702-uppgradering finns p\u00e5 alla fem. Gasabstraktion och kontoportabilitet \u00e4r tv\u00e5 skilda saker. Du kan mycket v\u00e4l ha en smidig, kedjeagnostisk avgiftsupplevelse ovanp\u00e5 ett konto som fortfarande bara \u00e4r smart p\u00e5 en enda kedja. Abstraktionen d\u00f6ljer friktionen; den tar inte bort det underliggande faktumet att delegeringen \u00e4r lokal.<\/p>

Det \u00e4r den springande punkten. Chain abstraction \u00e4r ett UX-lager, inte en egenskap hos protokollet. S\u00e5 l\u00e4nge det som g\u00f6r kontot smart lagras separat p\u00e5 varje kedja kommer abstraktionen alltid att vara en konstruktion som n\u00e5gon m\u00e5ste bygga, underh\u00e5lla och st\u00e5 f\u00f6r. N\u00e4r den konstruktionen fungerar m\u00e4rks den inte. N\u00e4r den fallerar, till exempel f\u00f6r att en kedja saknar din delegering i ett kritiskt \u00f6gonblick, faller du tillbaka till den kedjebundna verkligheten utan f\u00f6rvarning.<\/p>

Native kontoabstraktion splittras: EIP-8141 mot EIP-8130<\/h2>

Om chain abstraction \u00e4r pl\u00e5stret p\u00e5 ytan \u00e4r native kontoabstraktion den f\u00f6reslagna operationen p\u00e5 djupet: att bygga in smarta konton direkt i protokollet s\u00e5 att man slipper b\u00e5de ERC-4337:s separata infrastruktur och 7702:s delegeringspekare. Problemet \u00e4r att branschen just nu har slutat komma \u00f6verens om hur den operationen ska g\u00e5 till.<\/p>

Den 14 september 2026 bekr\u00e4ftade utvecklare att Ethereum och Coinbases layer 2 Base hade \u00f6vergett m\u00e5nader av gemensamt arbete p\u00e5 en enad standard f\u00f6r native kontoabstraktion. Derek Chiang, grundare av ZeroDev och numera hos Ethlabs, tillk\u00e4nnagav uppbrottet och sammanfattade det som att de l\u00f6sningar man hittade alla kr\u00e4vde att den ena eller andra sidan kompromissade \u00e5tminstone lite p\u00e5 sina k\u00e4rnm\u00e5l, och att man d\u00e4rf\u00f6r gick skilda v\u00e4gar och lade b\u00f6rdan p\u00e5 pl\u00e5nb\u00f6ckerna<\/a> att hantera fragmenteringen som f\u00f6ljer.<\/p>

De tv\u00e5 sp\u00e5ren skiljer sig i filosofi. Ethereums EIP-8141<\/a>, kallad Frame Transactions, \u00e4r t\u00e4nkt till den framtida Hegot\u00e1-uppgraderingen och prioriterar censurmotst\u00e5nd och s\u00e4kerhet; Vitalik Buterin har beskrivit den som n\u00e4ra optimal. Bases EIP-8130 bygger i st\u00e4llet p\u00e5 en on-chain keystore och siktar p\u00e5 Bases Cobalt-uppgradering, med skala och regelefterlevnad som ledstj\u00e4rnor. EIP-8130 introducerar en ny transaktionstyp och en keystore som lagrar varje kontos godk\u00e4nda signerare, och st\u00f6ds av Coinbase, Optimism och WalletConnect. Cobalt var planerad till slutet av september 2026, men f\u00f6rslaget var i mitten av m\u00e5naden fortfarande experimentellt p\u00e5 ett devnet, s\u00e5 tidtabellen kan glida.<\/p>

F\u00f6r portabiliteten \u00e4r inneb\u00f6rden dubbel. \u00c5 ena sidan \u00e4r b\u00e5da sp\u00e5ren f\u00f6rs\u00f6k att g\u00f6ra smarta konton till en f\u00f6rstklassig medborgare p\u00e5 respektive kedja, vilket p\u00e5 sikt \u00e4r b\u00e4ttre \u00e4n dagens delegeringspekare. \u00c5 andra sidan betyder tv\u00e5 olika standarder att en pl\u00e5nbok som vill fungera \u00f6verallt kan beh\u00f6va st\u00f6dja tv\u00e5 skilda native transaktionstyper ut\u00f6ver 7702 och 4337. Fragmenteringen som 7702 redan skapar per kedja riskerar allts\u00e5 att f\u00f6rdjupas, inte f\u00f6rsvinna, n\u00e4r L1 och den st\u00f6rsta L2:n drar \u00e5t olika h\u00e5ll. Det \u00e4r en utveckling som f\u00e5r den som dr\u00f6mmer om ett enda spelkonto f\u00f6r n\u00e4sta miljard spelare<\/a> att t\u00e4nka ett varv till.<\/p>

Keystore-rollups: den l\u00e5ngsiktiga v\u00e4gen till portabilitet<\/h2>

Finns det d\u00e5 n\u00e5gon l\u00f6sning som faktiskt l\u00e5ter ett konto vara sig sj\u00e4lvt \u00f6ver alla kedjor? Den mest lovande id\u00e9n heter keystore-rollup, och det \u00e4r ingen slump att Bases native-sp\u00e5r bygger p\u00e5 just en keystore. Grundtanken, som Vitalik Buterin skissat i sin minimala keystore-rollup, \u00e4r att flytta det som definierar kontot, allts\u00e5 vilka nycklar och vilka guardians som f\u00e5r styra det, till en enda dedikerad plats, och sedan l\u00e5ta konton p\u00e5 alla andra kedjor l\u00e4sa d\u00e4rifr\u00e5n.<\/p>

Mekaniken bygger p\u00e5 bevis. En keystore-rollup g\u00f6r en sak och bara en sak: lagrar och uppdaterar kontons nycklar och regler, vilket g\u00f6r den liten, granskningsbar och billig. Konton p\u00e5 andra kedjor autentiserar sedan mot den via bevis, till exempel zero-knowledge-bevis eller Merkle-bevis \u00f6ver dess state, s\u00e5 att samma regler kan g\u00e4lla ett konto p\u00e5 vilken kedja som helst. Byter du nyckel eller l\u00e4gger till en guardian p\u00e5 ett st\u00e4lle kan alla dina konton h\u00e4mta den uppdateringen i st\u00e4llet f\u00f6r att du ska beh\u00f6va g\u00f6ra om \u00e4ndringen manuellt p\u00e5 var och en. Teamen bakom Scroll och Base har delat konkreta specar; Scrolls variant lagrar data p\u00e5 L1 men l\u00e5ter den uppdateras billigt fr\u00e5n deras rollup<\/a> via en ny precompile f\u00f6r att l\u00e4sa L1-state.<\/p>

Det h\u00e4r \u00e4r, om det lyckas, den riktiga fixen: inte att kopiera delegeringen till varje kedja, utan att l\u00e5ta alla kedjor peka mot en gemensam sanning om vem du \u00e4r. Base har beskrivit hur en keystore kan ge cross-chain-konsistens<\/a> f\u00f6r konton, och Vitalik har lyft fram synken av nycklar och guardians \u00f6ver L2:er<\/a> som en central pusselbit f\u00f6r s\u00f6ml\u00f6s interoperabilitet.<\/p>

Men notera ironin i tidslinjen. Just som keystore-id\u00e9n mognar och Base g\u00f6r den till sin native-standard splittras den bredare native-AA-agendan i tv\u00e5 l\u00e4ger. En keystore-rollup l\u00f6ser portabiliteten inom ett ekosystem som delar dess antaganden; den l\u00f6ser den inte automatiskt mellan Ethereums Frame Transactions-sp\u00e5r och Bases keystore-sp\u00e5r. Portabilitet kr\u00e4ver enighet om formatet, och enigheten \u00e4r just nu p\u00e5 v\u00e4g \u00e5t fel h\u00e5ll.<\/p>

Glamsterdam och nedr\u00e4kningen till 6 oktober<\/h2>

Medan native-AA-striden utspelar sig rullar Ethereums vanliga uppgraderingscykel vidare, och n\u00e4sta milstolpe \u00e4r n\u00e4ra. Glamsterdam, n\u00e4tverkets kommande hardfork, ska f\u00f6rst testas p\u00e5 testn\u00e4tet Sepolia, och utvecklarna siktar p\u00e5 den 6 oktober 2026<\/a>, prelimin\u00e4rt klockan 13:53 UTC. Mainnet \u00e4r fortfarande otidsatt men v\u00e4ntas n\u00e5gon g\u00e5ng under fj\u00e4rde kvartalet, och Ethereums egen f\u00e4rdplan<\/a> s\u00e4ger rakt ut att datumet inte \u00e4r bekr\u00e4ftat.<\/p>

Glamsterdams tyngsta inslag \u00e4r enshrined proposer-builder separation, ePBS, definierad i EIP-7732. Den flyttar in \u00f6verl\u00e4mningen mellan den som f\u00f6resl\u00e5r ett block och den som bygger det i sj\u00e4lva protokollet, vilket minskar beroendet av externa relays och vidgar f\u00f6nstret f\u00f6r datapropagering fr\u00e5n runt tv\u00e5 sekunder till n\u00e4rmare nio. Syftet \u00e4r h\u00f6gre kapacitet och fler blobbar f\u00f6r layer 2, inte kontoportabilitet, s\u00e5 uppgraderingen l\u00f6ser inte direkt problemet den h\u00e4r artikeln handlar om. Men den s\u00e4tter riktningen f\u00f6r L1: mer genomstr\u00f6mning, mindre beroende av mellanh\u00e4nder.<\/p>

Testet \u00e4r inte utan gnissel. Utvecklare har varnat f\u00f6r att v\u00e4rdel\u00f6s test-ETH kan l\u00e5ta illasinnade byggare g\u00e5ng p\u00e5 g\u00e5ng vinna blockauktioner och sedan h\u00e5lla inne exekveringsdatan, ett beteende som st\u00f6r testn\u00e4tet men inte utg\u00f6r n\u00e5got direkt hot mot anv\u00e4ndarnas medel p\u00e5 mainnet<\/a>. Att den sortens auktionsdynamik ens diskuteras s\u00e4ger n\u00e5got om hur mycket av Ethereums framtid som handlar om vem som f\u00e5r ordna transaktioner, ett tema som g\u00e5r igen i v\u00e5r genomg\u00e5ng av EIP-7702 och MEV<\/a>.<\/p>

F\u00f6r den som f\u00f6ljer smarta konton \u00e4r Glamsterdam v\u00e4rd att h\u00e5lla \u00f6gonen p\u00e5 av en indirekt anledning. Ju mer L1 optimeras f\u00f6r genomstr\u00f6mning och blobbar, desto mer aktivitet flyttar ut till layer 2, och desto viktigare blir just den kedje\u00f6vergripande kontofr\u00e5gan. En v\u00e4rld d\u00e4r mer sker p\u00e5 fler kedjor \u00e4r en v\u00e4rld d\u00e4r 7702:s kedjebundna delegering k\u00e4nns i fler situationer, inte f\u00e4rre.<\/p>

F\u00e4rdplanen och fragmenteringen i en tabell<\/h2>

S\u00e5 h\u00e4r ser tidslinjen ut f\u00f6r de bitar som tillsammans avg\u00f6r hur portabelt ditt smarta konto blir, fr\u00e5n det som redan \u00e4r p\u00e5 plats till det som fortfarande \u00e4r f\u00f6rslag.<\/p>

Steg<\/th>Vad det \u00e4r<\/th>Status (sep 2026)<\/th>Inneb\u00f6rd f\u00f6r portabilitet<\/th><\/tr><\/thead>
Pectra \/ EIP-7702<\/td>Set-code, delegerad EOA<\/td>Live sedan 7 maj 2025<\/td>Smart konto, men bundet per kedja<\/td><\/tr>
Fusaka<\/td>PeerDAS, mer datakapacitet<\/td>Live sedan 3 dec 2025<\/td>Mer L2-aktivitet, g\u00f6r kedjefr\u00e5gan viktigare<\/td><\/tr>
Glamsterdam (ePBS, EIP-7732)<\/td>Inbyggd proposer-builder-separation<\/td>Sepolia-test 6 okt 2026, mainnet Q4 otidsatt<\/td>Kapacitet, inte portabilitet direkt<\/td><\/tr>
EIP-8141 (Frame Transactions)<\/td>Ethereums native kontoabstraktion<\/td>Utkast, siktar p\u00e5 Hegot\u00e1<\/td>Native konto p\u00e5 L1, eget format<\/td><\/tr>
EIP-8130 (keystore)<\/td>Bases native kontoabstraktion<\/td>Experimentellt, Cobalt planerad sen sep 2026<\/td>Native konto p\u00e5 Base, keystore-baserat<\/td><\/tr>
Keystore-rollup<\/td>Gemensam k\u00e4lla f\u00f6r nycklar och regler<\/td>Forskning och specar (Scroll, Base)<\/td>Den m\u00f6jliga riktiga fixen f\u00f6r cross-chain<\/td><\/tr><\/tbody><\/table><\/figure>

Tv\u00e5 saker framtr\u00e4der. Det som \u00e4r live idag, Pectra och Fusaka<\/a>, ger dig kraftfulla konton och mer kapacitet men l\u00f6ser inte portabiliteten. Och det som skulle kunna l\u00f6sa den, native standarder och keystore-rollups, \u00e4r antingen forskning eller p\u00e5 v\u00e4g \u00e5t tv\u00e5 olika h\u00e5ll. Mellan dessa poler lever anv\u00e4ndaren och b\u00f6rsen med 7702:s kedjebundna verklighet, sannolikt under l\u00e5ng tid fram\u00f6ver.<\/p>

S\u00e4kerhet \u00f6ver kedjor: replay, fel kod och phishing<\/h2>

Kedjebundenheten \u00e4r inte bara en bekv\u00e4mlighetsfr\u00e5ga, den \u00e4r en s\u00e4kerhetsfr\u00e5ga. Vi har redan n\u00e4mnt replay-risken med chain_id noll, men det \u00e4r v\u00e4rt att stanna vid vad den inneb\u00e4r i praktiken. En signerad auktorisering \u00e4r ett litet objekt som kan skickas in av vem som helst. \u00c4r den signerad brett, allts\u00e5 med chain_id noll, kan den skickas in p\u00e5 en kedja du aldrig t\u00e4nkt anv\u00e4nda, och d\u00e4r kan den aktivera en delegering du trodde h\u00f6rde hemma n\u00e5gon annanstans.<\/p>

L\u00e4gg till fel-kod-problemet. Eftersom samma adress kan husera olika kod p\u00e5 olika kedjor \u00e4r en pekare som \u00e4r trygg p\u00e5 mainnet inte automatiskt trygg n\u00e5gon annanstans. En angripare som kontrollerar vilken kod som ligger p\u00e5 m\u00e5ladressen p\u00e5 en mindre bevakad kedja kan f\u00f6rvandla din breda auktorisering till ett verktyg mot dig. Det \u00e4r exakt d\u00e4rf\u00f6r specifikationen manar till att begr\u00e4nsa r\u00e4ckvidden n\u00e4r man \u00e4r os\u00e4ker, och d\u00e4rf\u00f6r breda auktoriseringar b\u00f6r behandlas som ett medvetet val, inte en bekv\u00e4mlighet man klickar f\u00f6rbi.<\/p>

Sedan har vi den m\u00e4nskliga faktorn. Blindsignering, allts\u00e5 att godk\u00e4nna en transaktion vars inneb\u00f6rd man inte kan l\u00e4sa, \u00e4r den enskilt st\u00f6rsta riskk\u00e4llan f\u00f6r smarta konton, och kedjef\u00f6rvirring g\u00f6r den v\u00e4rre. En phishing-sida kan visa upp en till synes ofarlig signering och i sj\u00e4lva verket be dig auktorisera en delegering, eller be om en bred chain_id noll-signatur som g\u00e4ller \u00f6verallt. Principen som skyddar dig \u00e4r enkel att formulera och sv\u00e5r att leva efter: l\u00e4s vad du signerar, och var extra vaksam n\u00e4r en signatur inte tydligt h\u00f6r hemma p\u00e5 en specifik kedja. Smarta konton v\u00e4cker dessutom helt andra l\u00e5ngsiktiga fr\u00e5gor, som hur de kan bli en flyktv\u00e4g undan kvanthotet<\/a> mot dagens kryptografi, men det \u00e4r en annan historia.<\/p>

Finansinspektionen, MiCA och sj\u00e4lvf\u00f6rvar \u00f6ver kedjor<\/h2>

Var landar d\u00e5 allt det h\u00e4r regulatoriskt f\u00f6r en svensk anv\u00e4ndare? Huvudregeln \u00e4r enkel och viktig att f\u00f6rst\u00e5: EIP-7702 handlar om sj\u00e4lvf\u00f6rvar. Ett delegerat konto som du styr med din egen nyckel \u00e4r fortfarande din pl\u00e5nbok, och sj\u00e4lvf\u00f6rvarade pl\u00e5nb\u00f6cker faller utanf\u00f6r det som MiCA reglerar. MiCA och Finansinspektionen riktar in sig p\u00e5 tj\u00e4nsteleverant\u00f6rerna, allts\u00e5 b\u00f6rser, v\u00e4xlare och f\u00f6rvaringsinstitut (CASP:er), inte p\u00e5 det protokoll eller den kontraktslogik du v\u00e4ljer att peka din EOA mot.<\/p>

Det spelar roll f\u00f6r hur man ska t\u00e4nka p\u00e5 kedjefr\u00e5gan. N\u00e4r du auktoriserar en delegering p\u00e5 Ethereum, Arbitrum eller Base g\u00f6r du det p\u00e5 egen hand, utan mellanhand, och ingen svensk tillst\u00e5ndsplikt utl\u00f6ses av sj\u00e4lva handlingen. I samma stund du anv\u00e4nder en b\u00f6rs f\u00f6r att k\u00f6pa, s\u00e4lja eller f\u00f6rvara \u00e4r det b\u00f6rsen som omfattas av regelverket. Sedan den 1 oktober 2025 m\u00e5ste varje kryptobolag som vill forts\u00e4tta betj\u00e4na svenska kunder ha ans\u00f6kt om tillst\u00e5nd hos FI<\/a> eller avveckla verksamheten, och FI uppmanar konsumenter att bara v\u00e4nda sig till bolag som s\u00f6kt eller f\u00e5tt tillst\u00e5nd.<\/p>

MiCA delar in kryptotillg\u00e5ngar i tre slag, e-pengatoken, tillg\u00e5ngsanknuten token och andra kryptotillg\u00e5ngar, och det \u00e4r den indelningen<\/a> som avg\u00f6r vilka regler som g\u00e4ller f\u00f6r en utgivare eller tj\u00e4nst. V\u00e4rt att komma ih\u00e5g f\u00f6r den mer avancerade anv\u00e4ndaren: kryptoderivat, som terminer och eviga kontrakt, \u00e4r finansiella instrument under MiFID II och \u00f6vervakas av marknadsmyndigheten, inte under MiCA. ESMA har dessutom klargjort gr\u00e4nsen mot finansiella instrument f\u00f6r nytto- och speltokens, ett besked fr\u00e5n den 19 mars 2025 som \u00e4r relevant f\u00f6r allt som r\u00f6r spel och konton p\u00e5 kedjan.<\/p>

Den praktiska slutsatsen \u00e4r att kedjebundenheten i 7702 inte skapar n\u00e5gon ny tillst\u00e5ndsplikt f\u00f6r dig som privatperson, men den l\u00e4gger ansvar p\u00e5 dig. Med sj\u00e4lvf\u00f6rvar f\u00f6ljer att du sj\u00e4lv b\u00e4r risken f\u00f6r replay, blindsignering och felaktiga delegeringar, per kedja. FI:s \u00e5terkommande p\u00e5minnelse om att krypto \u00e4r komplext och volatilt g\u00e4ller i h\u00f6gsta grad h\u00e4r: ju smartare kontot blir, desto fler val m\u00e5ste du f\u00f6rst\u00e5.<\/p>

S\u00e5 hanterar du verkligheten idag<\/h2>

Tills native standarder och keystore-rollups mognar \u00e4r den b\u00e4sta strategin att arbeta med kedjebundenheten i st\u00e4llet f\u00f6r att bli \u00f6verraskad av den. H\u00e4r \u00e4r en praktisk checklista, f\u00f6rst f\u00f6r dig som anv\u00e4ndare och sedan f\u00f6r den som driver en tj\u00e4nst.<\/p>

  1. Utg\u00e5 fr\u00e5n att din delegering bara finns p\u00e5 den kedja d\u00e4r du satte den. Ska du vara ett smart konto p\u00e5 flera kedjor, planera f\u00f6r att auktorisera p\u00e5 var och en.<\/li>
  2. Undvik breda chain_id noll-auktoriseringar om du inte f\u00f6rst\u00e5r exakt vad de inneb\u00e4r. De ger portabilitet men \u00f6ppnar f\u00f6r replay och f\u00f6r att koden p\u00e5 m\u00e5ladressen kan skilja sig mellan kedjor.<\/li>
  3. Kontrollera att m\u00e5lkontraktet faktiskt finns och \u00e4r det du tror p\u00e5 varje kedja innan du auktoriserar d\u00e4r. Samma adress \u00e4r ingen garanti f\u00f6r samma kod.<\/li>
  4. L\u00e4s vad du signerar. Var s\u00e4rskilt vaksam p\u00e5 signeringar som inte tydligt h\u00f6r hemma p\u00e5 en specifik kedja, det \u00e4r ett tecken p\u00e5 en bred auktorisering.<\/li>
  5. N\u00e4r du st\u00e4dar upp en gammal delegering, kom ih\u00e5g att g\u00f6ra det per kedja. En nollst\u00e4llning p\u00e5 mainnet r\u00f6r inte Arbitrum.<\/li>
  6. Bevaka din nyckelhantering l\u00e5ngsiktigt; ett smart konto \u00e4r bara s\u00e5 s\u00e4kert som nyckeln bakom det, oavsett hur m\u00e5nga kedjor det finns p\u00e5.<\/li><\/ol>

    F\u00f6r en b\u00f6rs eller pl\u00e5nboksutvecklare blir listan en annan. Skanna efter delegeringspekaren per kedja, inte per adress. Anta att en kunds adress kan vara EOA p\u00e5 en kedja och smart konto p\u00e5 en annan, och bygg riskmodellen d\u00e4refter. Var tydlig i gr\u00e4nssnittet om vilken kedja en uppgradering g\u00e4ller, s\u00e5 att anv\u00e4ndaren inte tror att den spridit sig. Och f\u00f6lj noga hur EIP-8141 och EIP-8130 utvecklas, f\u00f6r den dag tv\u00e5 native transaktionstyper finns i produktion kommer st\u00f6det f\u00f6r dem att bli en konkurrensfr\u00e5ga, inte en teknisk detalj.<\/p>

    Summan av det hela: EIP-7702 gav oss smarta konton utan migration, vilket var en elegant l\u00f6sning p\u00e5 ett sv\u00e5rt problem. Men elegansen har ett pris, och priset heter portabilitet. Ditt konto blev smart, men det blev smart p\u00e5 en kedja i taget, och tills branschen enas om n\u00e5got b\u00e4ttre \u00e4r det den verkligheten b\u00e5de du och din b\u00f6rs beh\u00f6ver planera f\u00f6r.<\/p>

    Vanliga fr\u00e5gor<\/h2>

    Varf\u00f6r \u00e4r mitt smarta konto en vanlig EOA p\u00e5 Arbitrum?<\/h3>

    D\u00e4rf\u00f6r att EIP-7702-delegeringen lagras per kedja. Du uppgraderade kontot p\u00e5 Ethereum mainnet, men p\u00e5 Arbitrum har adressen ingen delegeringspekare f\u00f6rr\u00e4n du signerar en ny auktorisering och skickar in den d\u00e4r. Din nyckel \u00e4r universell, men det som g\u00f6r kontot smart \u00e4r kedjelokalt.<\/p>

    Vad betyder chain_id noll i en EIP-7702-auktorisering?<\/h3>

    Det g\u00f6r auktoriseringen giltig p\u00e5 alla kedjor samtidigt. Det \u00e4r bekv\u00e4mt f\u00f6r portabilitet, men \u00f6ppnar f\u00f6r att signaturen spelas upp p\u00e5 andra kedjor och f\u00f6r att koden p\u00e5 m\u00e5ladressen kan skilja sig mellan kedjor. Specifikationen rekommenderar att man begr\u00e4nsar r\u00e4ckvidden med ett specifikt chain_id n\u00e4r man \u00e4r os\u00e4ker.<\/p>

    \u00c4r EIP-7702 farligt att anv\u00e4nda?<\/h3>

    Sj\u00e4lva EIP:n bed\u00f6ms som s\u00e4ker; 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\u00e5 redan komprometterade nycklar, inte ett fel i protokollet.<\/p>

    L\u00f6ser native kontoabstraktion portabiliteten?<\/h3>

    Den kan g\u00f6ra smarta konton f\u00f6rstklassiga per kedja, men Ethereum och Base gick i september 2026 skilda v\u00e4gar med EIP-8141 respektive EIP-8130, s\u00e5 tv\u00e5 format kan komma att samexistera. Keystore-rollups, som l\u00e5ter kedjor l\u00e4sa nycklar och regler fr\u00e5n en gemensam k\u00e4lla, framst\u00e5r som den mer lovande v\u00e4gen till \u00e4kta cross-chain-portabilitet.<\/p>

    Hur p\u00e5verkar EIP-7702 svenska b\u00f6rser och Finansinspektionen?<\/h3>

    Sj\u00e4lvf\u00f6rvarade delegerade konton faller utanf\u00f6r MiCA, s\u00e5 sj\u00e4lva uppgraderingen utl\u00f6ser ingen tillst\u00e5ndsplikt. B\u00f6rser och andra tj\u00e4nsteleverant\u00f6rer omfattas d\u00e4remot, och sedan den 1 oktober 2025 m\u00e5ste de ha ans\u00f6kt om tillst\u00e5nd hos Finansinspektionen. B\u00f6rserna beh\u00f6ver dessutom skanna efter delegeringspekaren per kedja.<\/p>