Hvem sin kode kjører lommeboken din? EIP-7702 i 2026

Da Pectra-oppgraderingen gikk live 7. mai 2025, fikk helt vanlige Ethereum-adresser en ny egenskap over natten. En externally owned account (EOA), altså en helt vanlig lommebokadresse styrt av én privat nøkkel, kunne plutselig peke seg selv mot en smartkontrakt og oppføre seg som en smartkonto, uten å flytte en eneste token til en ny adresse. Halvannet år senere er ikke spørsmålet lenger om du bør oppgradere. Tallene viser at titalls millioner allerede har gjort det. Spørsmålet er et annet, og langt mer ubehagelig: hvem sin kode er det egentlig som kjører når lommeboken din signerer?

Det er lett å tenke på en EIP-7702-delegering som en bryter du skrur på. I praksis er den en peker. Adressen din låner oppførsel fra en kontrakt du sannsynligvis ikke har skrevet selv, og som du kanskje aldri har lest en linje av. Så lenge pekeren står der, kjører den koden med din saldo, din adresse og din lagring. Det gjør delegaten til noe langt viktigere enn en funksjon: den er en tillitsbeslutning, tatt på dine vegne, ofte med ett enkelt trykk i en lommebok-app.

Denne gjennomgangen handler ikke om hvorvidt EIP-7702 er bra eller dårlig. Den handler om delegaten som det den faktisk er, nemlig kode noen andre kontrollerer. Vi ser på hvem folk faktisk peker på (ledertavlen er full av overraskelser), hvorfor en ren sweeper er blant de mest brukte kontraktene på Ethereum, hva en revisjon faktisk dekker, og hvordan du selv leser og bytter delegaten din. Underveis bruker vi ferske tall: ETH ligger rundt 2 690 dollar, i overkant av 25 600 kroner med en dollarkurs på cirka 9,5, ifølge CoinDesk.

Hva EIP-7702 gjør, kort fortalt

EIP-7702 innfører en ny transaksjonstype, type 4, ofte kalt en set-code-transaksjon. I den signerer du en liten datastruktur, en autorisasjon, som består av tre ting: kjede-ID, adressen til delegatkontrakten og et nonce. Signaturen bruker en egen prefiksverdi (MAGIC 0x05) slik at en 7702-autorisasjon aldri kan forveksles med en vanlig transaksjonssignatur. Når den utføres på kjeden, får kontoen din en spesiell kode: byte-sekvensen 0xef0100 etterfulgt av de 20 byte-ene i delegatadressen, til sammen 23 byte. Det er hele hemmeligheten. Spesifikasjonen beskriver resten.

To detaljer er verdt å feste seg ved. For det første kopieres ikke delegatens kode inn i kontoen din. Kontoen din peker bare på den, og logikken kjører i din kontekst: din lagring, din saldo. For det andre beholder du samme adresse og samme private nøkkel som før. Ingen migrering, ingen ny konto. Du kan når som helst fjerne pekeren ved å signere en ny autorisasjon mot nulladressen. Og pekeren gjelder per kjede: det du gjør på Ethereum mainnet, skjer ikke automatisk på Base eller Arbitrum.

En delegering er en avhengighet, ikke en funksjon

I programvare er det en velkjent sannhet at når du importerer et bibliotek, arver du både feilene og oppdateringene til den som skrev det. En 7702-delegering er nøyaktig det samme, med én forskjell som betyr alt: biblioteket kan flytte pengene dine. Når du peker EOA-en din mot en delegat, sier du i praksis at «den koden får handle på mine vegne, med min saldo». Da er det eneste spørsmålet som betyr noe: hvis kode er det?

Adopsjonstallene skjuler dette poenget bak et stort, misvisende tall. BundleBear teller over 256 millioner kumulative autorisasjoner. Men det tallet er kraftig blåst opp av automatiserte bots. Det meningsfulle tallet er antall delegeringer som faktisk er aktive akkurat nå, og det ligger på rundt 61,5 millioner. Forskjellen mellom de to er ikke støy. Den forteller hvor mye av «adopsjonen» som er mennesker som velger en delegat, og hvor mye som er skript som peker tusenvis av kompromitterte adresser mot samme kode.

Sammenligningen med programvareforsyningskjeden er verdt å ta helt ut. Da en enkelt kompromittert npm-pakke kunne ramme titusenvis av prosjekter på én gang, lærte utviklerverdenen at avhengigheter er en angrepsflate, ikke bare en bekvemmelighet. En 7702-delegat er den samme typen avhengighet, men uten byggeserveren og de mange øynene som normalt ser på en pakke før den tas i bruk. Her er det bare deg, én signatur, og en adresse du enten kjenner igjen eller ikke. Jo færre delegater som deler markedet, desto større blir konsekvensen hvis én av dem svikter.

EOA, ERC-4337 og EIP-7702 side om side

Det finnes tre måter å styre penger på Ethereum på i dag. Den gamle EOA-en, den fullverdige smartkontoen bygget på ERC-4337, og mellomtingen som EIP-7702 gir deg: en EOA som låner oppførsel fra en kontrakt. Tabellen under viser hvor de skiller lag.

Den siste raden skaper mest forvirring i praksis, og vi kommer tilbake til den. Men legg merke til den andre raden: i en 7702-verden er det delegaten, ikke protokollen og ikke din egen kontrakt, som bestemmer hva som skjer når du signerer. Derfor er det verdt å se på hvem den delegaten faktisk er.

Ledertavlen: hvis kode peker folk faktisk på?

BundleBear fører også en oversikt over hvilke kontrakter de aktive delegeringene peker mot. Bildet er slående konsentrert. Noen få adresser samler opp mesteparten av alle delegeringene. Øverst ligger flere umerkede kontrakter med millioner av delegeringer hver (den største rundt 6,7 millioner), etterfulgt av en håndfull navngitte som de fleste vil kjenne igjen. Tabellen under viser de merkede, avrundet.

Les den tabellen en gang til. En av de mest brukte kodebasene for smartkontoer på Ethereum er ikke en lommebok. Den er en wallet-drainer. CrimeEnjoyor er navnet handelshuset Wintermute ga en familie av nesten identiske sweeper-kontrakter kort tid etter Pectra. Wintermutes forskningsteam fant at over 97 prosent av de tidlige delegeringene pekte mot kontrakter med nøyaktig samme kode. Som de beskrev den: kontrakten er «short, simple, and widely reused», og den kopierte bytekoden utgjorde flertallet av alle 7702-delegeringene.

Det nyanserte poenget er viktig: dette er ikke et tegn på at 7702 er ødelagt. En sweeper settes opp etter at en privat nøkkel allerede er lekket. Den venter bare på at det skal komme ETH inn på den kompromitterte adressen, og feier den ut automatisk. Wintermute påpekte at det knapt lønte seg: angriperne brukte rundt 2,88 ETH på å autorisere omtrent 79 000 adresser, og én enkelt adresse sto for 52 000 av dem, uten at det kom inn ETH å stjele. Men konsentrasjonen forteller noe uansett. Når millioner av kontoer peker mot samme kode, deler de også samme sprengradius: en feil i én mye brukt delegat blir en systemhendelse, ikke et uhell for én bruker.

Monokultur er nettopp ordet. I biologien er en åker med bare én sort utsatt fordi én sykdom kan ta hele avlingen; i programvare gjelder det samme når millioner av kontoer kjører nøyaktig samme delegatkode. Et alvorlig funn i en mye brukt, ellers legitim delegat ville ikke vært et enkeltstående uhell, men noe som måtte håndteres av titalls millioner brukere samtidig, og oppryddingen ville skjedd én signatur og én kjede av gangen. Det er derfor konsentrasjonen på ledertavlen er verdt å følge med på, selv når kontraktene øverst er trygge i dag.

Det er ikke 7702, det er nøkkelen

Den beste rammen for å forstå ledertavlens skumle tall kommer fra Taylor Monahan, sikkerhetsforsker i MetaMask og en av de mest siterte stemmene på lommeboksikkerhet. Om sweeper-bølgen sa hun til The Block: «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.» Hun la til at «7702 just unlocks a bunch of cool abilities that make sweeping addresses more cost efficient and less tedious.»

Med andre ord: rotårsaken er lekkede nøkler, ikke selve delegeringen. En lekket nøkkel var alltid dødelig. Det 7702 gjør, er å gjøre selve tyveriet billigere, raskere og mer pålitelig enn å kjøre en frontrunning-bot på hver eneste innkommende innbetaling. Men her ligger vrien for akkurat vår vinkling. Hvis den gamle risikoen var «hvis nøkkel», legger 7702 til en ny: «hvis kode». Selv med en trygg nøkkel kan du tømme kontoen din ved å signere én delegering til feil kontrakt, hvis du godkjenner den i blinde.

Tallene rundt dette er blitt bedre kartlagt det siste året. En fagfellevurdert studie lagt frem på USENIX Security-symposiet, ledet av Mingyuan Huang og kolleger, analyserte millioner av 7702-autorisasjoner på tvers av flere kjeder og fant at rundt 63 prosent av autorisasjonene var knyttet til ondsinnede kontrakter, med omtrent 2,36 millioner dollar i realiserte tap. Samtidig peker de bredere tallene nedover: ifølge Scam Sniffer falt de samlede drainer-tapene i 2025 med 83 prosent til rundt 84 millioner dollar. 7702 gjorde ikke kryptotyveri større; det gjorde en bestemt type tyveri mer effektiv.

Kan koden endre seg under deg?

Anta at du har gjort alt riktig og pekt deg mot en navngitt, revidert delegat. Da gjenstår et spørsmål de færreste stiller: kan den koden endre seg etter at du signerte? Svaret avhenger av hvordan delegaten er bygget, og delegatene deler seg grovt i to leirer.

Den ene leiren er den uforanderlige singletonen. Uniswaps Calibur er et godt eksempel: én fast kontrakt på én fast adresse, med støtte for flere nøkkeltyper (secp256k1, P-256 og WebAuthn), og uten mulighet til å bytte ut logikken. Peker du mot en singleton, er den eneste måten oppførselen kan endres på at du selv signerer en ny autorisasjon mot en ny adresse. Den andre leiren er rammeverk og proxy-baserte delegater, som MetaMasks modulære delegation framework. Her kan logikken være lagdelt, og i en ren proxy-modell kan den som eier implementasjonssporet, i prinsippet bytte ut koden uten at du signerer på nytt.

Det er derfor «hvilken delegat» betyr mer enn «7702 ja eller nei». Re-autorisering er den egentlige oppgraderingsveien for en singleton, og det er en funksjon, ikke en mangel: ingen kan flytte deg til ny kode uten din signatur. Vil du vite hva du har, kan du lese delegatens kode på en blokkutforsker og sjekke om den gjør delegatecall til et implementasjonsspor (et tegn på proxy) eller om koden er fast.

I praksis er dette et argument for å foretrekke enkle, uforanderlige delegater når du kan. En singleton uten oppgraderingslogikk har en mindre angrepsflate og et enklere løfte: koden du så på i dag, er koden som kjører i morgen. En proxy gir mer fleksibilitet, men den fleksibiliteten er også en tillit du gir til den som styrer implementasjonssporet. Ingen av delene er galt i seg selv, men de er ulike tillitsmodeller, og du bør vite hvilken du faktisk har valgt.

Hva en revisjon ikke kjøper deg

«Revidert» høres betryggende ut, men det er verdt å være presis på hva en revisjon faktisk er: et øyeblikksbilde av en bestemt versjon av koden, tatt på et bestemt tidspunkt. Calibur ble gjennomgått av OpenZeppelin våren 2025. Rapporten fant 29 punkter, ingen kritiske og ingen alvorlige, men flere medium- og lavalvorlige, blant dem signatur-replay, blindsignering via WebAuthn og for vide administratornøkler. Det er en god rapport. Den forteller deg at koden var ren ved en gitt commit. Den forteller deg ikke at delegaten du peker mot i dag er nøyaktig den koden, og heller ikke at modulene du selv slår på i etterkant, er trygge.

Nettopp modulene er den blinde flekken. Moderne delegater støtter tillegg via standarder som ERC-7579 og delegerte tillatelser via ERC-7710, der du kan gi en app lov til å bruke opptil et visst beløp, eller signere på dine vegne innenfor en ramme. Hver slik modul du aktiverer i ettertid, er en ny tillitsflate som kanskje ligger utenfor den opprinnelige revisjonen. Og spørsmålet om hvem som betaler for stempelet, og hva det egentlig dekker, er verdt å stille høyt; vi har sett nærmere på revisjonsbransjens forretningsmodell i saken om CertiK og hvem som betaler for sikkerhetsstempelet. Ambires AmbireAccount7702, en av de aller første 7702-lommebøkene, er bevisst holdt kort av samme grunn: mindre kode, mindre å revidere, mindre å ta feil av.

DelegProof: ti maskinsjekkede angrepsmønstre

Det ferskeste bidraget til dette bildet er ikke en hendelse, men et bevis. I september 2026 la forskere frem DelegProof, beskrevet som den første maskinsjekkede, symbolske analysen av 7702-autorisasjonens semantikk satt sammen med ERC-4337-EntryPoint-røret. Ved hjelp av modeller i verktøyet Tamarin fant forfatterne ti maskinverifiserte angrepsmønstre, kalibrert mot dokumenterte hendelser som USENIX-studiens funn.

Tre av dem er lærerike. Det første er en «stille svikt» i den mye annonserte midlertidige delegeringen: du tror pekeren forsvinner etter bruk, men gjør det ikke. Det andre er lagringsforvirring på tvers av re-delegering: når du bytter fra én delegat til en annen, kan lagringen den gamle koden satte, krasje med hvordan den nye koden tolker de samme lagringsplassene. Det tredje er et ERC-1271-substitusjonsangrep, der delegaten svarer «ja, den signaturen er gyldig» for noe du aldri mente å godkjenne. Det siste er en påminnelse om at en delegat ikke bare handler; den vitner også om hva som er gyldig på dine vegne.

Lagringspoenget er praktisk viktig. Selv når du «tilbakekaller» ved å delegere til nulladressen, fjernes kodepekeren, men lagringen den gamle delegaten skrev, blir stående, slik OpenZeppelins dokumentasjon advarer om. Delegerer du deretter til en ny kontrakt med et annet lagringsoppsett, kan den lese gammel tilstand feil. Konklusjonen fra DelegProof er ikke at 7702 er farlig i seg selv, men at risikoen ligger i sammensetningen: delegaten, EntryPoint og din gjenværende lagring må passe sammen, og formelle verktøy har først nå begynt å ta igjen virkeligheten.

Slik leser du hvilken kontrakt du peker på

Alt dette er akademisk hvis du ikke kan se din egen delegat. Heldigvis er den offentlig, og det tar under et minutt å sjekke. Åpne adressen din på en blokkutforsker som Etherscan. Har kontoen din en aktiv delegering, vises den som en konto med kode, og koden starter med 0xef0100. De neste 20 byte-ene er delegatadressen din. Kjenner du den ikke igjen, er det i seg selv et faresignal.

Vil du fjerne en delegering, signerer du en ny autorisasjon mot nulladressen med et høyere nonce. Da forsvinner kodepekeren (husk forbeholdet om lagring over). Det store forbeholdet er blindsignering. En gyldig signatur mot feil delegat tømmer kontoen like effektivt som en stjålet nøkkel, og signeringsskjermen viser deg sjelden hva de 20 byte-ene faktisk betyr. Det er den samme mekanismen som har tømt hele selskapshvelv: en formelt gyldig signatur på en ondsinnet nyttelast. Vi har skrevet om hvordan det skjer, og hvordan man beskytter seg, i gjennomgangen av multisig og når gyldige signaturer tømmer hvelvet.

Børsene leser delegaten din

For lommebok- og børsklyngen er det en detalj som fort blir oversett: en innskuddsadresse som er en delegert EOA, oppfører seg ikke nødvendigvis som en vanlig adresse. Delegatens kode kan i prinsippet reagere når det kommer midler inn, for eksempel ved å rute dem videre i samme blokk. Derfor har flere børser begynt å behandle de 23 byte-ene som et signal: de skanner om en innskudds- eller uttaksadresse har en delegering, allowlister kjente og trygge delegater, og flagger eller avviser ukjente.

For deg som bruker betyr det noen konkrete ting. Et uttak til en delegert adresse kan i verste fall lande hos en sweeper hvis nøkkelen bak allerede er kompromittert, og en børs som ser en ukjent delegering på mottaksadressen din, kan holde igjen eller be om ekstra bekreftelse. Motsatt kan en delegert innskuddsadresse som ruter midler videre automatisk, forvirre en børs som forventer at innskudd blir stående til de krediteres. Bruker du samme adresse til både selvforvaring og børs, er det verdt å vite hvilken delegat som står der, før pengene beveger seg.

På institusjonssiden kombineres 7702 stadig oftere med MPC-forvaring, der delegaten blir stedet policyen bor: hvem som kan signere, for hvor mye, og under hvilke betingelser. Resultatet er at opplevelsen din på en børs i økende grad avhenger av hvilken delegat uttaksadressen din peker mot. Koden bak lommeboken er ikke lenger bare din sak; den er blitt en del av det motparten din vurderer før pengene får lov til å bevege seg.

Én delegat per kjede

Her er fellen som overrasker flest. Delegeringen bor ikke i nøkkelen din, men på et bestemt sted: kombinasjonen av adresse og kjede-ID. Delegaten din på Ethereum mainnet finnes ikke på Arbitrum eller Base med mindre du re-autoriserer der. Samme adresse, ulik kjede, potensielt ulik (eller ingen) kode.

Spesifikasjonen tillater også å sette kjede-ID til 0, som betyr «gyldig på alle kjeder». Det er praktisk, men det er også en klassisk felle: samme kodepeker gjelder overalt, men koden som ligger på den adressen, kan være noe helt annet på en annen kjede, eller ikke finnes i det hele tatt. Og oppryddingen er per kjede: nullstiller du på mainnet, står delegeringen fortsatt på Base. Vi har gått grundig gjennom denne kjedegrensen i saken EIP-7702 stopper ved kjedegrensen, og den er verdt å lese før du sprer delegeringer utover flere nettverk.

Norge: Finanstilsynet, Skatteetaten og ansvaret for koden

Hvor passer alt dette inn i norsk regelverk? Kort sagt: en delegert EOA er fortsatt selvforvaring. Du holder nøkkelen selv, og da faller kontoen utenfor det Finanstilsynet fører tilsyn med under kryptoeiendelsloven, som trådte i kraft 1. juli 2025 og gjennomfører MiCA i norsk rett via EØS-avtalen. Finanstilsynet fører tilsyn med tilbydere av kryptoeiendelstjenester (CASP-er) som børser og forvarere; de første norske MiCA-tillatelsene gikk til AK Jensen Norway i februar 2026, senere blant andre Týr Markets og Firi. Delegaten din er ikke en tjenestetilbyder, og ingen har fått i oppdrag å passe på koden du peker mot.

Grensen blir gråere i det øyeblikket en paymaster, en gjenopprettingstjeneste eller en sky-lagret passkey kommer inn i bildet, for da er det plutselig en tredjepart involvert. Skattemessig er det dessuten en felle verdt å understreke: at en delegat pakker ti bytter inn i én transaksjon, gjør ikke ti realisasjoner om til én. Skatteetaten behandler hvert bytte som en skattepliktig realisasjon (gevinst skattlegges som kapitalinntekt med 22 prosent), beholdningen inngår i formuesskatten, og krypto er ikke forhåndsutfylt i skattemeldingen. Fra 1. januar 2026 gjelder også internasjonal rapportering under CARF. Det er nøyaktig samme logikk som i skattemaskinen i DeGods: batching skjuler kompleksitet i grensesnittet, men ikke skattehendelsene bak.

Veien videre: native account abstraction og Glamsterdam

EIP-7702 var alltid ment som en bro, ikke som endestasjonen. Målet er native account abstraction, der validering og betaling er innebygd i protokollen og delegaten forsvinner som eget tillitspunkt. Men veien dit har delt seg. Ethereum-miljøet samler seg om EIP-8141, en «frame»-basert løsning tenkt for en fremtidig Hegotá-fork, mens Base har foreslått en konkurrerende, keystore-basert modell (EIP-8130). I september 2026 ble forsøket på å samkjøre de to lagt bort. Derek Chiang, som står bak ZeroDev og nå jobber i Ethlabs, oppsummerte splittelsen overfor The Block: løsningene de fant, krevde alle at én av sidene ga avkall på noe grunnleggende.

Det er verdt å understreke hva neste store oppgradering faktisk handler om. Glamsterdam, med en Sepolia-fork planlagt rundt 6. oktober 2026, dreier seg om gjennomstrømning og blokkbygging (blant annet ePBS), ikke om native kontoer. Inntil native AA faktisk lander på mainnet, er delegaten fortsatt tillitsflaten din. Ethereum-kjerneutvikler Marius van der Wijden har beskrevet 7702 presist: det lar eksisterende lommebøker «emulate the functions of Account Abstraction wallets», men utviklere må fortsatt «evaluate all the rough edges», sa han til DL News. Vi har fulgt både den stille seieren og splittelsen i en egen gjennomgang av account abstraction i 2026.

Poenget for lommebokeieren er at denne overgangen ikke skjer over natten, og at den ikke er ferdig avklart. Så lenge to leire drar i hver sin retning, vil delegat-modellen fra EIP-7702 leve videre parallelt med de nye forslagene, kanskje i årevis. Det betyr at ferdigheten i å lese og forvalte sin egen delegat ikke er en midlertidig kunnskap du snart kan legge fra deg, men en del av det å eie krypto i selvforvaring i overskuelig fremtid.

Slik velger du hvilken delegat du stoler på

Poenget med hele denne gjennomgangen er å flytte spørsmålet fra «bør jeg bruke 7702» til «hvem sin kode peker jeg på». Her er en praktisk sjekkliste å ta med seg.

1. Les delegatadressen før du signerer. Koden starter med 0xef0100, og de neste 20 byte-ene er delegaten din.
2. Foretrekk navngitt, revidert kode (MetaMask, Ambire, Uniswap Calibur eller Simple7702Account) fremfor en ukjent adresse.
3. Finn ut om delegaten er en uforanderlig singleton eller en oppgraderbar proxy; det avgjør om koden kan endres uten din signatur.
4. Husk at en revisjon er et øyeblikksbilde. Moduler du slår på i etterkant, er ny tillit som kanskje ikke er dekket.
5. Rydd opp per kjede. En gammel delegering på Base forsvinner ikke fordi du nullstiller på mainnet.
6. Beskytt den private nøkkelen. Ingen delegat redder deg fra en lekket nøkkel; det er fortsatt rotårsaken.

Gjort riktig gir EIP-7702 en vanlig adresse ekte smartkonto-egenskaper uten migrering: batch-transaksjoner, betaling av gass i token, session keys og gjenoppretting. Gjort i blinde er det en signatur som overlater pengene dine til kode du aldri leste. Forskjellen ligger ikke i teknologien, men i om du vet hvis kode som kjører.

Ofte stilte spørsmål

Hva er EIP-7702, kort forklart?

EIP-7702 er en Ethereum-funksjon fra Pectra-oppgraderingen (mai 2025) som lar en vanlig adresse (EOA) peke seg mot en smartkontrakt og låne dens egenskaper, som batch-transaksjoner og gassbetaling i token, uten å bytte adresse eller nøkkel. Pekeren lagres som koden 0xef0100 etterfulgt av delegatadressen, og du kan fjerne den når som helst.

Hvordan ser jeg hvilken kontrakt lommeboken min er delegert til?

Åpne adressen din på en blokkutforsker som Etherscan. Har du en aktiv delegering, vises kontoen med kode som starter på 0xef0100, og de neste 20 byte-ene er delegatadressen. Verktøy som Revoke.cash kan også vise delegaten (men bare inspisere), og MetaMask viser smartkonto-status per kjede under kontodetaljer.

Er EIP-7702 trygt å bruke?

Ja, hvis du peker mot navngitt, revidert kode og beskytter den private nøkkelen din. Sweeper-kontrakter som CrimeEnjoyor topper adopsjonstallene, men de settes opp etter at en nøkkel allerede er lekket; de er et symptom på svak nøkkelsikkerhet, ikke en feil i 7702. Den nye risikoen funksjonen legger til, er å signere en delegering til feil kode i blinde.

Hvordan tilbakekaller jeg en EIP-7702-delegering?

Du signerer en ny autorisasjon mot nulladressen med et høyere nonce, noe MetaMask og enkelte verktøy kan gjøre per kjede. Det fjerner kodepekeren, men merk at lagringen den gamle delegaten skrev, ikke nødvendigvis nullstilles, og at du må rydde opp på hver kjede for seg.

Gjelder EIP-7702-delegeringen på alle kjeder?

Nei. En delegering gjelder for kombinasjonen av adresse og kjede, så delegaten din på Ethereum mainnet finnes ikke på Base eller Arbitrum med mindre du re-autoriserer der. Setter du kjede-ID til 0, gjelder pekeren på alle kjeder, men det er en risiko fordi koden på samme adresse kan være ulik fra kjede til kjede.

Av Yuki Tanaka, HOGE Wire. Publisert 28. september 2026.