EIP-7702 stopper ved kjedegrensen: én delegering per kjede i 2026

Du gjorde det kanskje i sommer: trykket på «oppgrader til smartkonto» i lommeboken, signerte én gang, og plutselig kunne adressen din bunte flere handlinger i én transaksjon og betale gass i en stablecoin. Det du sannsynligvis ikke fikk tydelig beskjed om, er at oppgraderingen bare gjaldt på én kjede. EIP-7702, forslaget som gjorde helt vanlige Ethereum-adresser om til programmerbare smartkontoer da Pectra gikk live 7. mai 2025, virker nemlig kjede for kjede. En delegering du satte på Ethereum mainnet, finnes ikke på Arbitrum, Base eller Optimism før noen setter den der også.

For norske brukere som flytter verdier mellom nettverk, veksler på tvers av kjeder og signerer noe nytt nesten hver uke, er dette mer enn en teknisk kuriositet. Det avgjør hvor smartkontoen faktisk fungerer, hvor den ikke gjør det, og hvor en gammel signatur kan dukke opp igjen. Her går vi gjennom hvorfor 7702-delegeringen stopper ved kjedegrensen, hva chain_id lik null egentlig betyr, hvordan gassabstraksjon prøver å skjule fragmenteringen, og hva veien mot native kontoabstraksjon (og oppgraderingen Glamsterdam) kommer til å endre. Ether handlet rundt 2.700 dollar da dette ble skrevet, om lag 25.600 kroner med en dollarkurs på cirka 9,48.

Kort oppsummert: én signatur stopper ved kjedegrensen

Poenget kan koke ned til en enkel regel: en 7702-delegering er kjedespesifikk, med mindre du bevisst gjør den universell. Her er hovedpunktene før vi går i dybden.

• En EIP-7702-delegering endrer koden til adressen din bare på den kjeden der set-code-transaksjonen blir inkludert. Ingen andre kjeder berøres automatisk.
• Feltet chain_id i autorisasjonen bestemmer rekkevidden. Settes det til et bestemt kjede-ID, gjelder signaturen bare der; settes det til null, er den gyldig på alle EVM-kjeder samtidig.
• chain_id lik null er bekvemt, men det åpner for replay: den samme signaturen kan gjenbrukes på kjeder du aldri hadde i tankene.
• Tilbakekalling skjer også per kjede. Fjerner du delegeringen på Ethereum, ligger den fortsatt aktiv på Base hvis du en gang skrudde den på der.
• Eiendeler krysser broer; fullmakter gjør det ikke. Bunting, gass-sponsing og session keys følger ikke med når du flytter tokens til en L2.
• Native kontoabstraksjon (EIP-8141) og Glamsterdam skal på sikt gjøre fragmenteringen mindre merkbar, men foreløpig må du forholde deg til én smartkonto per kjede.

Hva EIP-7702 gjør med en helt vanlig adresse

En vanlig Ethereum-adresse, en såkalt EOA (externally owned account), styres av én privat nøkkel og kan ikke selv kjøre programkode. En smartkontrakt-konto kan kjøre kode, men har tradisjonelt ingen nøkkel du kan signere med direkte. EIP-7702 bygger bro mellom de to: en ny transaksjonstype, type 0x04, lar en EOA peke til koden i en smartkontrakt uten å bytte adresse eller nøkkel. Adressen din beholder alt den hadde, men får i tillegg oppførselen til kontrakten den peker på.

Måten det skjer på, er verdt å forstå, for den forklarer hele kjede-poenget. Når du oppgraderer, signerer du en autorisasjon: en liten datastruktur med feltene chain_id, adressen til koden du vil delegere til, en nonce, og en signatur. Klienten pakker dette inn i en set-code-transaksjon, og etterpå får kontoen din en spesiell markør i kodefeltet: bytene 0xef0100 fulgt av de 20 bytene som utgjør adressen til delegatet. Signaturen bruker et eget prefiks, MAGIC-byten 0x05, slik at en 7702-signatur ikke kan forveksles med en vanlig transaksjon. Alt dette er dokumentert i selve standarden.

Det viktige er at delegeringen er reversibel og lettvekts. Du kan når som helst peke koden et nytt sted, eller nulle den ut helt. Du beholder samme adresse, samme historikk og samme nøkkel. Det er derfor 7702 ble kalt oppgraderingen som slapp unna migreringen: ingen ny adresse, ingen flytting av midler, bare en peker som slås av og på. Men den samme letheten skjuler et forbehold folk ofte overser, nemlig at pekeren bare gjelder på nøyaktig én kjede.

Derfor bor delegeringen på én kjede om gangen

Ethereum og alle de EVM-kompatible kjedene rundt (Arbitrum, Base, Optimism, Polygon, BNB Chain og resten) er separate tilstandsmaskiner. Hver av dem fører sin egen kontobok. Kodefeltet til adressen din på Ethereum mainnet er en helt annen verdi enn kodefeltet til den identiske adressen på Base, selv om de deler både adresse og privat nøkkel. En set-code-transaksjon endrer kodefeltet bare på den kjeden der den blir inkludert i en blokk.

Konsekvensen er enkel å si, men lett å glemme i praksis: en delegering du satte på mainnet, eksisterer ikke på Arbitrum før noen sender en 7702-transaksjon også der. Lommeboken din kan vise deg den samme adressen på tvers av et nettverksvalg, og du kan lure på hvorfor den fungerte som en smartkonto i går og som en vanlig adresse i dag. Svaret er som regel at du byttet kjede. Delegeringen fulgte ikke med, fordi den aldri var ment å følge med.

Dette skiller 7702 skarpt fra hvordan folk intuitivt tenker om en «oppgradert lommebok». Vi er vant til at en app-innstilling gjelder overalt når vi har skrudd den på. En 7702-delegering er ikke en innstilling i lommeboken; den er en tilstand i blokkjeden, og blokkjedene deler ikke tilstand. Vil du ha smartkonto-funksjoner på fem kjeder, må delegeringen settes fem ganger, én transaksjon per kjede, hver med sin egen nonce og sitt eget gassforbruk.

Det er her mange lommebøker gjør en jobb i kulissene som brukeren aldri ser: de re-autoriserer stille på hver nye kjede du besøker, slik at opplevelsen føles sømløs. Det er en god brukeropplevelse, men det endrer ikke det underliggende faktumet. Under panseret er det fortsatt én delegering per kjede, og det får følger for sikkerhet, tilbakekalling og hvordan børser må granske adressen din.

chain_id = 0: snarveien som gjelder overalt (og faren ved den)

Feltet chain_id i autorisasjonen er nøkkelen til hele historien. Standarden slår fast at en klient skal «Verify the chain ID is 0 or the ID of the current chain». Med andre ord: settes chain_id til et konkret kjede-ID, er signaturen bare gyldig på akkurat den kjeden. Settes den til 0, er den gyldig på enhver EVM-kjede som støtter 7702. Utviklerne kalte dette «universal deployment», og hensikten er grei: én signatur du kan bruke overalt.

Bekvemmeligheten har en bakside som heter replay. En autorisasjon med chain_id lik 0 er en signatur som ikke er bundet til noe bestemt nettverk. Den kan sendes inn på nytt, av hvem som helst som har fått tak i den, på en kjede du aldri hadde tenkt å bruke. Har du signert en universell delegering til en kontrakt du stolte på, kan den samme delegeringen aktiveres på en helt annen kjede uten at du løfter en finger.

Det finnes en sperre, men den er svakere enn mange tror. Autorisasjonen inneholder en nonce som må stemme med kontoens nonce på kjeden der transaksjonen utføres. På en adresse som har vært aktiv en stund, vil nonce-tellerne som regel ha løpt fra hverandre mellom kjedene, og da faller replay-en bort av seg selv. Men på ferske adresser som ikke har sendt transaksjoner ennå, står telleren på null på alle kjeder samtidig. Da er en signatur med nonce 0 og chain_id lik 0 gyldig på tvers av alle disse kjedene på én gang.

Legg til at tilbakekalling også skjer per kjede, så tegner det seg et ubehagelig bilde: du kan fjerne en delegering på Ethereum i god tro, mens den samme universelle signaturen fremdeles kan brukes til å slå delegeringen på igjen på en kjede der du aldri ryddet opp. Tommelfingerregelen fra sikkerhetsfolk er derfor enkel: unngå chain_id lik 0 med mindre du har en konkret grunn, og foretrekk kjedespesifikke autorisasjoner selv om de koster en ekstra signatur.

Eiendeler krysser broen, men fullmaktene dine gjør det ikke

Den vanligste misforståelsen følger rett av det forrige. Når du flytter tokens fra Ethereum til en L2, sender du verdier over en bro. Det brukerne ofte antar, er at «lommeboken min» følger med i samme slengen. Det gjør den ikke. Broen flytter eiendeler; den flytter ikke fullmakter. På L2-en møter du din egen adresse som en helt vanlig konto, uten bunting, uten gass-sponsing og uten session keys, helt til du delegerer på nytt der.

Dette er ikke bare en bekvemmelighetssak. Broer er blant de mest utsatte delene av kryptoinfrastrukturen, og de samme feilene gjentar seg fordi angriperne går etter nøkler og tillatelser snarere enn selve koden, noe vi har skrevet om i gjennomgangen av hvorfor bro-hackene gjentar seg. Når du antar at smartkonto-beskyttelsen din gjelder på begge sider av broen, kan du senke skuldrene på feil tidspunkt. En guard-kontrakt som stopper mistenkelige overføringer på mainnet, finnes rett og slett ikke på den nye kjeden før du har satt den opp der.

Den mentale modellen som holder, er å tenke på hver kjede som et eget rom. Nøkkelen din åpner alle rommene, men møblene du satte inn i ett rom, står ikke automatisk i de andre. Vil du ha samme oppsett overalt, må du bære det inn, rom for rom. For aktive brukere som sprer seg over mange nettverk, betyr det at antallet steder å holde styr på vokser fort, og at et angrep på ett rom ikke nødvendigvis oppdages i et annet.

Gassabstraksjon: slik gjøres delegeringen «bærbar»

Siden fragmenteringen er dårlig brukeropplevelse, har lommebøkene bygget lag som skjuler den. Det tydeligste eksemplet er gassabstraksjon. I oktober 2025 rullet Bitget Wallet ut en funksjon, drevet av EIP-7702, som lar brukere betale gass i stablecoins i stedet for i hver kjedes eget token. Ifølge The Block dekker funksjonen betaling i USDT, USDC eller BGB på Ethereum, Solana, Base, TRON, Polygon, Arbitrum, BNB Chain og Optimism, uten at brukeren trenger å aktivere noe eller holde separate saldoer.

Jamie Elkaleh, markedssjef i Bitget Wallet, beskrev målet som å la folk «transact across chains without ever managing gas tokens». Det er en presis oppsummering av hva abstraksjonslaget gjør: det får delegeringen til å føles bærbar selv om den i realiteten settes opp på nytt bak kulissene, kjede for kjede. Poenget med å betale gass i en stablecoin er nettopp at brukeren slipper å tenke på hvilken kjede hun er på, og det er samme problem vi tok for oss da vi så på hvem som egentlig betaler gassen i en 7702-verden.

Det er verdt å merke seg en nyanse i tabellen under: 7702-mekanismen gjelder bare på EVM-kjeder. Solana og TRON er ikke EVM-kompatible, så der finnes ingen 0xef0100-delegering i det hele tatt. At Bitget likevel tilbyr stablecoin-gass på disse kjedene, skjer gjennom en annen mekanisme i lommeboken, ikke gjennom 7702. Det understreker poenget: bærbarheten er noe som lages i app-laget, ikke noe protokollen gir deg gratis.

Børsene må granske hver kjede for seg

For børser og forvaringstjenester er kjede-for-kjede-logikken en operasjonell hodepine. En innskuddsadresse som ser ren ut på én kjede, kan være delegert til en kontrakt på en annen. Fordi 7702 lar en EOA kjøre kode, må mottakssystemene deres nå sjekke om en adresse bærer 0xef0100-markøren før de behandler et innskudd, og den sjekken må gjøres separat på hver kjede børsen støtter.

Vi har gått grundig gjennom dette i artikkelen om hva som skjer når innskuddsadresser kjører kode, men kjede-vinklingen er verdt å gjenta: en børs kan ikke nøye seg med å hviteliste eller svarteliste en delegering én gang og anta at bildet er komplett. En adresse kan være en vanlig EOA på Ethereum, en delegert smartkonto på Arbitrum, og noe helt tredje på Base. Screeningen må kjøres per nettverk, og en universell chain_id-0-autorisasjon gjør risikovurderingen ekstra vrien fordi den kan dukke opp overalt.

For norske brukere som veksler på registrerte plattformer, er den praktiske følgen at uttak og innskudd kan bli behandlet ulikt fra kjede til kjede. En plattform kan tillate innskudd fra delegerte adresser på ett nettverk og blokkere det på et annet, avhengig av hvor moden screeningen deres er. Det er ikke vilkårlighet; det er en direkte konsekvens av at delegeringen bor på én kjede om gangen.

Sikkerhet: tilbakekalling og replay skjer per kjede

Sikkerhetsbildet for 7702 har vært todelt fra start, og kjede-dimensjonen gjør det ikke enklere. Den gode nyheten først: de aller fleste tidlige delegeringene var ikke angrep i vanlig forstand. Analyseselskapet Wintermute fant at over 97 prosent av de første delegeringene pekte til nesten identiske «CrimeEnjoyor»-kontrakter, altså feiekoster som automatisk tømmer allerede kompromitterte adresser for rester, ifølge CoinDesk. Mekanismen i seg selv var ikke ødelagt; problemet var at nøklene allerede var lekket.

Det peker på den egentlige risikoen. Taylor Monahan, sikkerhetsforsker i MetaMask, sa det rett ut: «It’s not actually a 7702 issue, its the same issue crypto has had since day one: end users struggle to secure their private keys», gjengitt av Cryptopolitan. Med chain_id lik 0 blir denne gamle utfordringen bredere: én phishing-signatur kan aktivere en ondsinnet delegering på flere kjeder samtidig, og fordi tilbakekalling skjer per kjede, kan et offer tro at det har ryddet opp selv om faren ligger igjen et annet sted.

Den generelle trenden er heldigvis positiv. Scam Sniffer rapporterte at tap til phishing og drainere falt 83 prosent i 2025, til rundt 83,85 millioner dollar, gjengitt av Cointelegraph. Men batch-signatur-svindel knyttet til 7702 var et av unntakene som vokste. Kombinasjonen av blindsignering (at du godkjenner noe du ikke kan lese) og universelle autorisasjoner er nettopp den giftige miksen brukere bør være mest på vakt mot. Smartkontoen er også et mål og et skjold i MEV-sammenheng, noe vi gikk gjennom i stykket om smartkontoen som mål og skjold, og hvis du først mister kontrollen, blir spørsmålet om gjenoppretting av en smartkonto raskt akutt.

Adopsjonen i tall: nesten 60 millioner delegeringer

Hvor utbredt er dette egentlig? Tallene er store, men de må leses med varsomhet. Dashbordet BundleBear viser hundrevis av millioner autorisasjoner kumulativt, men det tallet er kraftig blåst opp av nettopp feiekost-kontraktene som signerer i store bulker. Det mer meningsfulle målet, antallet aktive delegeringer akkurat nå, ligger på i underkant av 60 millioner. Det er fortsatt et betydelig tall for en funksjon som ble født i mai 2025.

På infrastruktursiden har standardverktøyene tatt 7702 inn i varmen. EntryPoint-kontrakten som driver ERC-4337, fikk innebygd 7702-støtte i versjon 0.8, ifølge utgivelsene til eth-infinitism, slik at de to sporene for kontoabstraksjon kan spille sammen. På lommeboksiden har MetaMask, Ambire, OKX og Bitget alle rullet ut 7702-baserte oppgraderinger, ofte med den re-autoriseringen kjede for kjede vi har beskrevet skjult under en enkel bryter.

Poenget for denne artikkelen er at bak de imponerende adopsjonstallene ligger den samme fragmenteringen. En «aktiv delegering» er alltid en delegering på én bestemt kjede. De 60 millionene er ikke 60 millioner brukere med sømløse kontoer overalt; de er summen av delegeringer spredt utover mange separate kontobøker.

Veien mot native kontoer: Glamsterdam og EIP-8141

Fragmenteringen er ikke en permanent tilstand, men fiksen er fortsatt et stykke unna. Den neste store oppgraderingen, Glamsterdam, tar sikte på testnettet Sepolia 6. oktober 2026 klokken 13:53 UTC, ifølge CryptoPotato, etter at kjerneutviklerne låste datoen på koordineringsmøtet 17. september. Deretter står Hoodi for tur rundt 27. oktober, mens en aktivering på mainnet er merket Q4 2026 uten at datoen er fastsatt.

Glamsterdam handler ikke primært om kontoabstraksjon; hovedpostene er ePBS (EIP-7732) og BAL-er (EIP-7928) for henholdsvis blokkbygging og parallell utføring, ifølge Ethereums veikart. Men den er en milepæl på veien mot en større ambisjon: native kontoabstraksjon, der kontoer er programmerbare på protokollnivå og ikke via en delegeringspeker satt kjede for kjede. Forslaget EIP-8141, som Vitalik Buterin har omtalt som en samlepakke for gjenstående AA-problemer, sikter mot en senere fork (Hegotá), tidligst i 2027.

Blant utviklerne er tonen edruelig. Marius van der Wijden, kjerneutvikler i Ethereum, har omtalt 7702 som et forslag med «rough edges» som fortsatt må vurderes, mens Alex Jupiter i MetaMask har beskrevet ambisjonen som «one unified Account Abstraction roadmap», begge gjengitt av DL News. Den samlede retningen er tydelig: 7702 var alltid ment som en bro, ikke som endestasjonen, og native kontoabstraksjon skal etter planen gjøre oppsettingen kjede for kjede mindre synlig for vanlige brukere.

Slik leser og tilbakekaller du delegeringen, kjede for kjede

Frem til den dagen kommer, må du forholde deg til dagens virkelighet. Det gode er at det er fullt mulig å ha kontroll, så lenge du husker at alt gjøres per kjede.

• 1. Sjekk hver kjede for seg. Slå opp adressen din i utforskeren for hvert nettverk du bruker (Etherscan for Ethereum, Arbiscan for Arbitrum, Basescan for Base og så videre). Bærer kodefeltet markøren 0xef0100 fulgt av en adresse, er kontoen delegert på nettopp den kjeden.
• 2. Identifiser hva du peker på. Adressen etter 0xef0100 er kontrakten du har delegert til. Kjenner du den ikke igjen, er det et rødt flagg, spesielt hvis du aldri bevisst har oppgradert på den kjeden.
• 3. Vær ekstra oppmerksom på universelle signaturer. Har lommeboken bedt deg signere en autorisasjon med chain_id lik 0, gjelder den overalt. Behandle den som følsom, og unngå den når du kan velge en kjedespesifikk variant.
• 4. Tilbakekall der det trengs, kjede for kjede. Du fjerner en delegering ved å sette den til nulladressen i en ny 7702-transaksjon. Husk at dette bare virker på kjeden du gjør det på; har du delegert på fem kjeder, må du rydde fem steder.
• 5. Gjenta ved mistanke. Etter en mistenkelig signering bør du sjekke alle kjedene du er aktiv på, ikke bare den du nettopp brukte, siden en universell autorisasjon kan ha landet flere steder.

Hva det betyr for norske brukere: Finanstilsynet og Skatteetaten

Hvor passer så det norske regelverket inn? Kort sagt regulerer det tjenestene rundt smartkontoen, ikke selve delegeringen. Kryptoeiendelsloven, som gjennomfører EUs MiCA-forordning i norsk rett via EØS, trådte i kraft 1. juli 2025, og Finanstilsynet fører tilsyn med kryptoeiendelstjenesteytere (CASP-er) som børser og forvarere. En 7702-delegering du setter selv, er selvforvaring og faller dermed utenfor dette tilsynet; det er tilbyderen, ikke protokollen eller din egen konto, som er regulert.

På skattesiden er bildet uendret av at du bruker en smartkonto. Skatteetaten behandler kryptoeiendeler som formuesobjekter: gevinst skattlegges som kapitalinntekt med 22 prosent, og beholdningen inngår i grunnlaget for formuesskatt til markedsverdi per 1. januar året etter inntektsåret. Fra 1. januar 2026 gjelder dessuten CARF, den internasjonale rapporteringsstandarden fra OECD, som pålegger veksling- og forvaringstilbydere å rapportere opplysninger direkte til skattemyndighetene.

Kjede-for-kjede-poenget har en skattemessig hale her også. Å flytte verdier mellom kjeder kan i noen tilfeller utløse en realisasjon, avhengig av hvordan det gjøres (for eksempel hvis du veksler til et annet token underveis), og fordi aktiviteten din er spredt over mange nettverk, blir god bokføring per kjede ekstra viktig når skattemeldingen skal fylles ut. Selvforvaring fritar deg ikke for rapporteringsplikten; den flytter bare ansvaret over på deg.

Bunnlinjen

EIP-7702 ga oss noe verdifullt: vanlige adresser som kan oppføre seg som smartkontoer, uten migrering og uten ny adresse. Men gaven kom med en fotnote som er lett å overse. Delegeringen din er ikke en global bryter; den er en tilstand på én kjede, satt av én signatur, og den snarveien som får den til å «gjelde overalt» er samtidig den som kan slå tilbake gjennom replay.

Den praktiske lærdommen er nøktern. Tenk på hver kjede som et eget rom, sjekk delegeringene dine der du faktisk er aktiv, foretrekk kjedespesifikke autorisasjoner fremfor universelle, og ikke anta at et opprydningstiltak på én kjede gjelder på alle. Native kontoabstraksjon skal etter hvert gjøre dette mindre synlig, og Glamsterdam er et skritt på veien, men frem til da er regelen den samme: én delegering, én kjede.

Ofte stilte spørsmål

Gjelder EIP-7702-delegeringen min på alle kjeder?

Nei. En delegering endrer koden til adressen din bare på den kjeden der set-code-transaksjonen ble inkludert. Aktiverte du smartkontoen på Ethereum, er den samme adressen fortsatt en vanlig konto på Arbitrum eller Base helt til du autoriserer der også.

Hva betyr chain_id lik null i en 7702-autorisasjon?

Det gjør autorisasjonen universell, altså gyldig på enhver EVM-kjede. Det sparer deg for å signere på hver kjede, men den samme signaturen kan gjenbrukes på kjeder du ikke hadde tenkt på, så det er en bekvemmelighet med en risiko-hale.

Følger smartkonto-funksjonene med når jeg flytter tokens til en L2?

Nei. Du flytter eiendeler over broen, men ikke fullmaktene. Bunting, gass-sponsing og session keys er knyttet til delegeringen på den enkelte kjeden, og på L2-en har du en helt vanlig adresse til du delegerer på nytt der.

Hvordan tilbakekaller jeg en delegering, og gjelder det overalt?

Du tilbakekaller ved å sette delegeringen til nulladressen i en ny 7702-transaksjon, men det virker bare på kjeden der du gjør det. Har du aktivert kontoen på flere kjeder, må du tilbakekalle på hver enkelt.

Er EIP-7702-smartkontoer underlagt Finanstilsynet i Norge?

Selve delegeringen er selvforvaring og faller utenfor MiCA og Finanstilsynets tilsyn med kryptoeiendelstjenesteytere. Bruker du en børs eller en forvaringstjeneste, er det tilbyderen som er regulert, ikke protokollen, og Skatteetaten skal uansett ha rapport om gevinst og formue.

Skrevet av Yuki Tanaka, som dekker lommebøker, børser og kontoabstraksjon for HOGE Wire.