EIP-7702: broen som ble værende, og slik styrer du den

Da Pectra-oppgraderingen gikk live på Ethereum 7. mai 2025, fikk vanlige lommebøker en ny evne nesten over natten: en helt alminnelig konto (en EOA, styrt av én privat nøkkel) kunne låne kode fra en smartkontrakt og oppføre seg som en smartkonto. Mekanismen heter EIP-7702, og den ble solgt som en bro. En midlertidig løsning som skulle gi brukerne batch-transaksjoner, gassbetaling i stablecoins og session keys mens Ethereum bygde den ordentlige varianten: native account abstraction rett inn i protokollen.

Halvannet år senere ser broen ut til å bli stående. Den native landingen som skulle avløse 7702, har glidd ut igjen: Base utsatte Cobalt-oppgraderingen, som skulle bringe EIP-8130 til mainnet i september 2026, til «TBD», og Ethereums eget forslag EIP-8141 sikter mot en Hegota-fork sent i 2026 som ingen har datofestet. I mellomtiden peker allerede titalls millioner adresser på en 7702-delegering. Det gjør denne midlertidige broen til noe som ligner permanent infrastruktur, og det betyr at du bør vite hvordan du styrer den.

Denne guiden gjør to ting. Først forklarer den hvorfor 7702 gikk fra stopgap til standard. Deretter blir den praktisk: hvordan du sjekker om din egen adresse har en delegering, hvordan du leser hva den peker på, hvordan du nullstiller den, og hvorfor det å nullstille ikke er det samme som å redde en nøkkel som allerede er lekket. ETH handles rundt 2 400 dollar (omtrent 22 300 kroner med en dollarkurs nær 9,30) mens dette skrives, ifølge CoinDesk, men mekanikken under gjelder uansett pris.

Kort fortalt: hva EIP-7702 faktisk gjør

EIP-7702 innfører en ny transaksjonstype, 0x04, som lar en EOA signere en autorisasjon om å sette kode på sin egen adresse. Autorisasjonen er en liten datastruktur (chain_id, adresse, nonce og en signatur) som peker på en smartkontrakt. Når transaksjonen er inkludert i en blokk, får kontoen din en kort markør i on-chain-koden: sekvensen 0xef0100 fulgt av en 20-byte adresse, til sammen 23 byte. Alle som leser kontoen din, ser da at den delegerer til den kontrakten. Ethereum-stiftelsens Pectra-side beskriver oppgraderingen som brakte dette til mainnet.

Poenget er at nøkkelen din ikke endrer seg. Adressen din endrer seg ikke. Du beholder den samme private nøkkelen du alltid har hatt, men adressen kan nå kjøre kontraktslogikk: sende flere handlinger i én transaksjon (batching), la noen andre betale gassen, eller gi en app en tidsbegrenset fullmakt (en session key). Delegeringen er reverserbar; du kan når som helst signere en ny autorisasjon som peker på nulladressen, og dermed fjerne koden igjen.

Den er også kjedespesifikk. En delegering på Ethereum mainnet gjelder ikke automatisk på Base eller Arbitrum, med mindre autorisasjonen ble signert med chain_id satt til 0, noe som åpner for gjenbruk (replay) på tvers av kjeder, en risiko vi kommer tilbake til. Alt dette er grunnen til at 7702 er så vanskelig å angre på: den krever ingen ny adresse, ingen migrering av midler, ingen ny seed-frase. Den legger bare et lag oppå det som allerede finnes.

Broen som skulle rives

For å skjønne hvorfor 7702 skulle være midlertidig, må man tilbake til debatten om account abstraction. Ethereum har snakket om å gjøre kontoer programmerbare siden 2016. Den første seriøse leveransen var ERC-4337, som gikk live i mars 2023 uten å endre protokollen: en egen «mempool» av UserOperations, egne aktører (bundlere) som pakker dem, og en singleton-kontrakt kalt EntryPoint. Problemet var at 4337 krever at du flytter midlene dine til en helt ny smartkontraktkonto med en ny adresse. De hundrevis av millioner EOA-ene som allerede fantes, ble stående utenfor.

EIP-7702 var svaret på nettopp det. Forslaget kom fra Vitalik Buterin, Sam Wilson, Ansgar Dietrichs og Matt Garnett (lightclient) i mai 2024, som en enklere avløser for det mer inngripende EIP-3074. Ingen nye opcodes, ingen ny adresse: bare la eksisterende kontoer emulere en smartkonto. Ethereum-kjerneutvikler Marius van der Wijden beskrev det overfor DL News som akkurat det, en måte for eksisterende lommebøker å etterligne funksjonene til account abstraction-lommebøker, og la til at forslaget fortsatt var tidlig og at man måtte vurdere alle de ru kantene. Alex Jupiter, senior produktsjef i MetaMask, kalte i samme sak 7702 en del av ett samlet account abstraction-veikart.

Ordet «bro» var med fra starten. 7702 skulle bære brukerne over til den dagen native account abstraction lå i selve protokollen, og da skulle den etter planen bli overflødig. Det er den dagen som stadig utsettes, og forskjellen mellom «midlertidig verktøy» og «varig infrastruktur» avgjøres av hvor lang den utsettelsen blir.

Landingen som glapp: Cobalt, EIP-8130 og Hegota

I sommer så det ut som om den native landingen var nær. Base, Coinbases Layer 2, annonserte at Cobalt-oppgraderingen skulle bringe native account abstraction via EIP-8130 til mainnet i september 2026, sammen med Optimism og WalletConnect. Vi gikk gjennom den landingen i en egen sak om Base, Cobalt og EIP-8130. EIP-8130 er en mer avgrenset variant enn 7702: en egen transaksjonstype (0x79), en on-chain «Keystore»-kontrakt for kontoinnstillinger, og faste autentiseringsmetoder (secp256k1, P-256, WebAuthn). Tallene var lovende. En native USDC-overføring falt fra rundt 125 000 til 46 000 gass, over 60 prosent billigere, ifølge Base sin egen ingeniørblogg.

Så glapp det. Base publiserte en egen Cobalt-side der aktiveringen på både mainnet og Sepolia nå står oppført som «TBD», og EIP-8130 forblir eksperimentell på Vibenet-devnettet, noe som korrigerer den tidligere september-forventningen, skriver Crypto Briefing. Den andre veien til native kontoer, Ethereums eget EIP-8141 («frame transactions», transaksjonstype 0x06), ble foreslått i februar 2026 og tatt inn til vurdering for Hegota-forken sent i 2026, men er ikke hovedsaken i den oppgraderingen, og klientteam har flagget kompleksiteten, ifølge CCN.

Selv de som bygger på området, er uenige om veien. Pedro Gomes, grunnlegger av WalletConnect, skrev at han etter måneder på EIP-8141 var blitt overbevist om at EIP-8130 er den bedre veien til native account abstraction: enklere, mer portabel, og fokusert på det lommebøker faktisk trenger (innlegget hans ligger på X). Når infrastrukturbyggerne fortsatt diskuterer hvilken standard som skal vinne, er det et signal om at ingen native landing er rett rundt hjørnet. Og hver måned uten en landing er en måned til der 7702 er den eneste smartkonto-modellen som faktisk virker for en vanlig EOA i dag.

Adopsjonen som gjør 7702 vanskelig å angre

Grunnen til at 7702 sannsynligvis blir værende, er at den allerede er over alt. BundleBear, som sporer bruken, viser over 54,5 millioner aktive delegeringer og nesten 99,4 millioner set-code-transaksjoner. Det kumulative autorisasjonstallet er langt høyere, over 237 millioner, men det tallet er kraftig blåst opp av sweeper-kontrakter som re-autoriserer tusenvis av kompromitterte adresser, så de aktive delegeringene er det mer ærlige målet på reell bruk.

På lommeboksiden var Ambire først ute. MetaMask bruker 7702 som sin primære oppgraderingsvei, og Rabby, Trust Wallet og OKX Wallet støtter det. På børssiden var noen av de tidligste og største kildene til delegeringer nettopp børser som brukte 7702 til å effektivisere utbetalinger og innsamling av små restbeløp. Bransjen anslår godt over 200 millioner smartlommebøker totalt når man teller alle varianter.

Poenget er skala. Et lag som er rullet ut til titalls millioner aktive kontoer, river man ikke bort selv om en penere standard dukker opp. Native account abstraction vil måtte leve side om side med 7702, ikke erstatte den med et pennestrøk. For deg som bruker betyr det at 7702 ikke er en overgangsdetalj du kan ignorere til den forsvinner; den er en del av lommeboken din på ubestemt tid, og bør behandles deretter.

Har du en delegering? Slik sjekker du den

Det praktiske spørsmålet for en vanlig bruker er enkelt: har adressen min en delegering, og hva peker den på? Det finnes flere måter å finne det ut på, og du trenger ikke å koble til lommeboken bare for å se etter.

• revoke.cash har en egen «delegations»-fane på kontosiden der du limer inn en adresse og ser delegeringene dine på tvers av EVM-kjeder. Merk deg at du kan se dem der, men ikke fjerne dem derfra; mer om det under.
• BaseScan og andre Etherscan-varianter har en egen EIP-7702-sjekker som svarer «Detected» eller «Not Detected» for en adresse.
• I en blokkutforsker ser du delegeringen direkte: åpne kontoen, gå til «Contract»-fanen, og let etter designatoren 0xef0100 fulgt av en adresse. Den adressen er kontrakten kontoen din låner kode fra.

Fordi delegeringer er kjedespesifikke, må du sjekke hver kjede der du har hatt aktivitet. En ren adresse på mainnet kan ha en delegering på Base eller Arbitrum, spesielt hvis du en gang signerte noe som så ut som en «oppgradering» eller en «gassfri» transaksjon. En rask sjekk her er billig forsikring; å oppdage en ukjent delegering seint er dyrt.

Slik leser du hva delegeringen peker på

Å se at du har en delegering, er ikke nok; du bør vite hva den peker på. Adressen etter 0xef0100 er en implementasjonskontrakt, og det er der all logikken bor. Hvis den peker på implementasjonen til en kjent lommebokleverandør (MetaMask, Ambire, Rabby og andre publiserer adressene sine), er du sannsynligvis der du skal være.

Moderne smartkontoer er dessuten ofte modulære: selve kontoen er tynn, og funksjoner som utgiftstak, whitelists eller social recovery installeres som separate moduler. Vi har gått gjennom den modulære arkitekturen, standardstriden mellom ERC-7579 og ERC-6900, i egen sak. Poenget her er at en legitim delegering peker på en revidert, kjent implementasjon, mens en ondsinnet peker på en kontrakt hvis eneste jobb er å tømme kontoen.

Hvis designatoren peker på en adresse du ikke kjenner igjen, og du ikke bevisst satte opp en smartkonto, er det et rødt flagg. Da er neste steg å nullstille, og helst å behandle nøkkelen som kompromittert samtidig.

Slik nullstiller du en delegering

Å nullstille en delegering betyr å signere en ny 7702-autorisasjon som peker på nulladressen (0x0000…0000). Det fjerner koden fra kontoen og gjør den til en helt vanlig EOA igjen. Slik gjør du det i praksis:

1. Bekreft først hvilken kjede delegeringen ligger på (se forrige seksjon). Du nullstiller per kjede.
2. Gå inn i selve lommeboken. Eksterne apper som revoke.cash kan vise delegeringen, men kan ikke fjerne den; de fleste lommebøker tillater ikke at en tredjepart rører delegeringen.
3. I MetaMask: åpne «Account details», bla ned til «Smart account», og velg «Disable» ved delegeringen. I Rabby ligger tilsvarende under godkjenninger merket EIP-7702.
4. Signer transaksjonen som peker på nulladressen. Du betaler et lite gassbeløp.
5. Verifiser i en blokkutforsker at 0xef0100-designatoren er borte, eller at revoke.cash og BaseScan nå viser «Not Detected».

Tabellen under oppsummerer hvilke verktøy som gjør hva. Kort sagt: eksterne verktøy ser, men bare lommeboken selv kan fjerne.

Å bytte lommebokleverandør uten å miste kontoen

En ting mange ikke tenker på: hva om du vil bytte fra én smartkonto-leverandør til en annen? Fordi to leverandører kan lagre data på samme sted i kontoens minne, kan et naivt bytte føre til en «storage collision», der den nye implementasjonen leser gammel data feil. Løsningen som er under arbeid, heter ERC-7779 («Interoperable Delegated Accounts»): en standard for å re-delegere og rydde opp i lagringen slik at en 7702-EOA kan flytte mellom leverandører uten å miste midler eller havne i en kollisjon, forklarer Cointelegraph. Den utvikles av blant andre Ethereum Foundation, Trust Wallet, Safe, Alchemy og Rhinestone.

For deg som bruker er poenget: så lenge 7702 er standarden, blir portabilitet mellom lommebøker et eget lite fagfelt. Inntil ERC-7779 er bredt støttet, er den tryggeste måten å «bytte» på ofte å nullstille til null først, og deretter delegere på nytt fra den nye lommeboken. Det er tregere, men det unngår at to implementasjoner slåss om det samme lagringsområdet.

Å nullstille redder ikke en lekket nøkkel

Her er den viktigste misforståelsen å rydde av veien: å fjerne en ondsinnet delegering redder deg ikke hvis den private nøkkelen din allerede er kompromittert. 7702 endrer ikke det grunnleggende: den som har nøkkelen, kontrollerer kontoen. Taylor Monahan, sikkerhetsforsker i MetaMask, har vært tydelig på nettopp dette (sitert av Cryptopolitan): det er egentlig ikke et 7702-problem, men det samme problemet krypto har hatt siden dag én, at sluttbrukere sliter med å sikre de private nøklene sine. 7702 gjør bare at det å tømme en adresse blir mer kostnadseffektivt og mindre tungvint for angriperen.

Konkret: hvis en angriper har nøkkelen din, kan de bare signere en ny delegering rett etter at du har nullstilt, i en evig kamp du taper fordi de kan automatisere det. Det er akkurat det sweeper-kontraktene gjør. Wintermute fant at over 97 prosent av de tidlige 7702-delegeringene pekte på den samme, kopierte «CrimeEnjoyor»-bytekoden, rapporterte CoinDesk: rundt 2,88 ETH ble brukt til å autorisere omtrent 79 000 adresser, og én enkelt kontrakt håndterte over 52 000 av dem. Den gode nyheten fra samme analyse var at det stort sett ikke var lønnsomt, fordi kontoene som ble feid, allerede var tomme eller kompromittert fra før. Det var ikke en feil i 7702, men en industrialisering av tømming av allerede tapte nøkler.

Lærdommen: hvis du oppdager en delegering du ikke satte opp selv, behandle nøkkelen som kompromittert. Flytt alt av verdi til en helt ny adresse, helst fra en hardware-lommebok eller en delt-nøkkel-løsning (vi har sammenlignet MPC og multisig i egen sak), før eller samtidig som du nullstiller, ikke etterpå.

Phishing-økonomien: hva ett år med data viser

Dataene fra det første året er nå tydelige. Den dyreste enkelthendelsen: en investor mistet 1,54 millioner dollar i én eneste 7702-batch-transaksjon i slutten av august 2025, inkludert wstETH, cbBTC og NFT-er, etter å ha signert det som så ut som en ufarlig godkjenning, ifølge Cryptopolitan. En annen bruker mistet rundt 1 million dollar i tokens og NFT-er etter å ha signert en batch forkledd som en Uniswap-swap. I august 2025 alene ble over 12 millioner dollar tappet fra mer enn 15 000 lommebøker, i stor grad via 7702-utnyttelser, rapporterte AMBCrypto med tall fra Scam Sniffer.

En fersk akademisk måling setter tall på mønsteret. I forskningsartikkelen «EIP-7702 Phishing Attack» analyserte Minfeng Qi og kolleger over 150 000 autoriserings- og utførelseshendelser fra rundt 26 000 adresser (arbeidet ligger på arXiv). De fant at én signert autorisasjons-tuple kan gi en angriper ubetinget og vedvarende kontroll over kontoen, via tre utløsningsveier (brukerdrevet, angriperdrevet og protokollutløst), og at aktiviteten er sterkt sentralisert rundt et lite antall kontraktsfamilier knyttet til kriminell virksomhet.

Det ligner mistenkelig på et rug pull i lommebok-form, og forsvaret er det samme som mot rene svindelprosjekter: ikke signer noe du ikke forstår. Vi har skrevet om hvordan du oppdager en rug pull før du taper pengene, og de samme instinktene gjelder her. Når pengene først er borte, er sporet på blokkjeden det eneste man har igjen; kryptoforensikk kan følge midlene, men sjelden hente dem tilbake. Den nøkterne konteksten er at samlede phishing-tap faktisk falt kraftig i 2025 (Scam Sniffer anslo en nedgang på rundt 83 prosent), men 7702-baserte batch-signaturer var en av kategoriene som vokste. Verktøyet er nytt; problemet, at folk signerer blindt, er gammelt.

Risikokart: hva som faktisk kan gå galt

Ikke alle risikoene ved en 7702-delegering ligner på hverandre, og de rammer ulike parter. Oversikten under skiller mellom det brukeren kan gjøre noe med, og det som er utviklerens ansvar.

Det som går igjen i den øverste raden, er mennesket, ikke matematikken. De fleste 7702-tapene skjer fordi noen signerte noe de ikke forsto, ikke fordi kryptografien sviktet. Det er godt nytt på lang sikt (tydeligere signering hjelper) og dårlig nytt på kort sikt (angriperne vet det også).

Børser og forvaring: broen sett fra innsiden

For børser og forvarere er 7702 en operasjonell hodepine like mye som en brukerfunksjon. En innskuddsadresse som plutselig har en delegering, kan oppføre seg annerledes enn en ren EOA: en innkommende overføring kan utløse kontraktslogikk. Derfor screener flere plattformer nå innskudds- og uttaksadresser for 0xef0100-designatoren (de 23 bytene) før de behandler en transaksjon, og noen avviser eller flagger adresser som delegerer til ukjente kontrakter.

For en norsk bruker er det verdt å skille to ting. En børs eller forvarer som opererer i Norge, er en tilbyder av kryptoeiendelstjenester (CASP) under MiCA, som er innlemmet i norsk rett gjennom kryptoeiendelsloven og håndheves av Finanstilsynet. Din egen selvforvarte lommebok, derimot, med eller uten en 7702-delegering, faller utenfor det regelverket: du er din egen forvarer, og ingen tilsynsmyndighet kan tilbakestille en delegering for deg. Det legger hele ansvaret for å sjekke og rydde på deg.

Norge: skatt og selvforvaring når broen blir stående

Skattemessig endrer ikke 7702 noe grunnleggende. Skatteetaten behandler gevinst og tap ved realisasjon av kryptoeiendeler likt, enten adressen er en ren EOA eller en smartkonto; det er disposisjonen (salg, bytte, bruk som betaling) som utløser skatt, ikke hvilken kontotype du bruker. Gevinst skattlegges som alminnelig inntekt (22 prosent), og du fører det i skattemeldingen.

To praktiske konsekvenser er verdt å merke seg når broen blir stående. For det første: hvis du bruker en 7702-funksjon til å betale gass i en stablecoin, er selve stablecoin-betalingen i prinsippet en realisasjon, med en liten gevinst eller et lite tap som må regnes ut. Det høres bagatellmessig ut, men mange småbetalinger blir til et regnskapsarbeid. For det andre: fra 1. januar 2026 rapporterer norske tilbydere systematisk kontoopplysninger under CARF-regelverket, så antakelsen om at aktivitet på børs er «usynlig», holder ikke lenger. Selvforvarte smartkontoer rapporteres ikke på samme måte, men enhver bro mellom en selvforvart konto og en norsk børs er synlig.

Når native kontoer endelig kommer: hva skjer med delegeringen din

Så hva skjer med 7702-delegeringen din den dagen native account abstraction faktisk lander, enten via EIP-8130 på Base eller EIP-8141 på Ethereum? Det korte svaret: ingenting skjer automatisk. Nøkkelen og adressen din er de samme; en native konto er en ny måte å konfigurere kontoen på, ikke en tvangsmigrering. Du vil sannsynligvis få valget mellom å beholde 7702-delegeringen, å nullstille den til null og gå over til en native konfigurasjon, eller å la de to leve side om side en stund. ERC-7779 finnes nettopp for å gjøre den overgangen ryddig.

Men den dagen har en lei tendens til å bli utsatt. Så lenge Cobalt står på «TBD» og Hegota er et «kanskje sent i 2026», er 7702 ikke en ventesal; den er stuen. Broen som skulle rives, er blitt stedet folk bor. Den nøkterne konklusjonen for en vanlig bruker i 2026 er derfor ikke å vente på noe penere, men å lære seg å leve med det som finnes: vit om du har en delegering, vit hva den peker på, vit hvordan du nullstiller den, og husk at ingen av delene redder en nøkkel som allerede er lekket. Gjør du det, er en 7702-smartkonto et av de mest nyttige lagene som er lagt til en Ethereum-adresse på år, ikke en felle.

Ofte stilte spørsmål

Hvordan vet jeg om adressen min har en EIP-7702-delegering?

Lim adressen inn i delegations-fanen på revoke.cash, bruk en 7702-sjekker som BaseScan sin, eller se etter designatoren 0xef0100 i «Contract»-fanen i en blokkutforsker. Sjekk hver kjede for seg, siden delegeringer er kjedespesifikke, og en ren adresse på mainnet kan ha en delegering på Base eller Arbitrum.

Hvordan fjerner jeg en delegering jeg ikke satte opp selv?

Du signerer en ny autorisasjon som peker på nulladressen (0x0000…0000) inne i selve lommeboken, for eksempel i MetaMask under «Account details» og «Smart account». Eksterne apper kan vise delegeringen, men ikke fjerne den. Hvis nøkkelen kan være kompromittert, flytt midlene til en ny adresse først.

Er EIP-7702 farlig?

7702 er ikke usikkert i seg selv; de fleste tapene skyldes at brukere signerer blindt, ikke en feil i standarden. Risikoen ligger i å godkjenne en delegering (ofte forkledd som en «oppgradering» eller «gassfri» transaksjon) som gir en angriper kontroll. Sikker bruk handler om å lese hva du signerer, og å bruke lommebøker med tydelig signering.

Blir EIP-7702 erstattet av native account abstraction?

Ikke med det første. Base sin Cobalt-oppgradering (EIP-8130) er utsatt til «TBD», og Ethereums EIP-8141 sikter tidligst mot Hegota-forken sent i 2026. Selv når native kontoer kommer, vil de leve side om side med 7702, ikke slette de titalls millioner delegeringene som allerede finnes.

Påvirker en 7702-smartkonto skatten min i Norge?

Nei, ikke kontotypen i seg selv. Skatteetaten skattlegger gevinst ved realisasjon likt for EOA og smartkonto (22 prosent som alminnelig inntekt). Men å betale gass i en stablecoin teller som en realisasjon, og fra 1. januar 2026 rapporteres kontoopplysninger hos norske tilbydere under CARF.

Jonas Ellingsen skriver om lommebøker, selvforvaring og Ethereum-infrastruktur for HOGE Wire.