EIP-7702 etter Pectra: adopsjonskartet og børsenes dans

I mai 2025 gjorde Ethereum en endring som så teknisk kjedelig ut på papiret, men som stille har flyttet grensen for hva en kryptolommebok faktisk er. Pectra-oppgraderingen skrudde på EIP-7702, en mekanisme som lar en helt vanlig konto (en EOA, altså en «externally owned account») låne kode fra en smartkontrakt og oppføre seg som en smartkonto, uten å flytte en eneste token til en ny adresse. Femten måneder senere er dette ikke lenger en fotnote for protokollutviklere. Ved inngangen til høsten 2026 har rundt 49 millioner kontoer på Ethereum en aktiv 7702-delegering, ifølge sporingsdataene til BundleBear, og de store lommebøkene bruker mekanismen som sin foretrukne oppgraderingsvei.

For deg som handler på børs eller oppbevarer ETH selv, betyr det noe helt konkret: kontoen din kan allerede være en smartkonto, enten du har lagt merke til det eller ikke. Ether omsettes i skrivende stund for rundt 1 934 dollar, i underkant av 18 400 kroner med en dollarkurs på cirka 9,53, og markedsverdien ligger over 233 milliarder dollar, godt over 2 200 milliarder kroner, ifølge CoinGecko. Det er disse verdiene som nå ligger bak en kontomodell de fleste tok i bruk uten å velge den aktivt.

Vi har tidligere forklart hva som skjer når lommeboken din blir en smartkonto, og vi har gått grundig gjennom hvordan en smartkonto tømmes, og hvordan du stopper det. Denne artikkelen tar et annet grep. Den ser på hvor adopsjonen faktisk står i august 2026, hvordan lommebøker og børser har rullet mekanismen ut i praksis, hva den mye omtalte «sweeper»-økonomien egentlig kaster av seg, og hvor veien går videre mot ekte account abstraction.

Kort oppsummert: hva EIP-7702 gjør, og hvorfor det angår deg

EIP-7702 gir en vanlig Ethereum-konto de egenskapene som tidligere krevde en egen smartkontraktlommebok. Med én signert autorisasjon kan kontoen din peke på en delegatkontrakt og dermed kjøre kode. Den offisielle Pectra-veiledningen på ethereum.org beskriver de praktiske gevinstene: du kan samle flere handlinger i én atomisk transaksjon, betale gass i en annen token enn ETH eller la en tredjepart sponse gassen, sette opp øktnøkler («session keys») for et spill eller en applikasjon, og legge på utgiftsgrenser og sosial gjenoppretting.

Et konkret eksempel: i dag krever et token-bytte på en desentralisert børs ofte to signaturer, først en «approve», så selve byttet. Med en 7702-delegert konto kan de to slås sammen til én atomisk transaksjon, slik at enten går begge gjennom eller ingen. Med en gasstasjon-modell (en «paymaster») kan en applikasjon dessuten dekke gassen for deg, slik at du kan handle uten å eie ETH i det hele tatt. Det er denne typen hverdagsforbedringer som har fått lommebøkene til å haste med å ta mekanismen i bruk.

Det avgjørende, og det som ofte misforstås, er at privatnøkkelen beholder full kontroll. Ethereum.org sier det rett ut: å delegere til en Safe gjør ikke kontoen din til en multisig, for det finnes fortsatt én nøkkel som kan overstyre enhver signeringsregel. Delegeringen legger til funksjonalitet; den flytter ikke eierskap. For lommebok- og børsbrukere er dette både styrken og faren: samme nøkkel som før styrer alt, men nøkkelen kan nå autorisere langt mer i én enkelt signatur.

Adopsjonskartet i august 2026: den stille migrasjonen

Tallene er store, men de må leses riktig. Tabellen under viser de sentrale måltallene slik BundleBear rapporterer dem i skrivende stund.

BundleBear skiller mellom to størrelser som ofte blandes sammen. Antallet kumulative autorisasjoner (over 225 millioner) teller hver eneste gang en adresse har blitt delegert, og dette tallet er kraftig oppblåst av automatiserte «sweeper»-kontrakter som re-autoriserer titusenvis av allerede kompromitterte adresser. Det tallet som best beskriver reell bruk, er antallet aktive delegerte smartkontoer, som ligger rundt 49,3 millioner. Set-code-transaksjonene, altså de faktiske type 0x04-transaksjonene som skriver delegeringen til kjeden, passerer 94 millioner.

Retningen er likevel tydelig. Fra i overkant av 11 000 delegeringer den første uken etter Pectra har mekanismen vokst til å bli en standardkomponent i lommeboksstakken. Alex Jupiter, senior produktsjef i MetaMask, beskrev tidlig overfor DL News hvordan 7702 samler de to tidligere veiene til account abstraction, EIP-3074 og ERC-4337, i «one unified Account Abstraction roadmap». Det er nettopp denne samlingen som forklarer hvorfor adopsjonen har gått raskere enn mange ventet: lommebøkene slapp å velge spor, og kunne bygge videre på det de allerede hadde.

Mekanikken på tjuetre byte: slik blir en EOA en smartkonto

Under panseret er EIP-7702 overraskende kompakt. Selve spesifikasjonen innfører en ny transaksjonstype, type 4 (0x04), med en autorisasjonsliste. Hvert element i listen er en tuppel som består av chain_id, adressen til delegatkontrakten, en nonce og signaturkomponentene (y_parity, r og s). Brukeren signerer en melding som starter med en magisk byte, 0x05, etterfulgt av en RLP-kodet pakke med chain_id, adresse og nonce.

Når transaksjonen er utført, endres kode-feltet til kontoen din på kjeden. Det får en spesiell markør: byte-sekvensen 0xef0100 etterfulgt av de 20 byteene som utgjør delegatadressen, til sammen 23 byte. Ser du denne markøren i en blokkutforsker, vet du at kontoen er delegert. For å nullstille delegeringen signerer du en ny autorisasjon som peker på nulladressen, og kode-feltet tømmes.

Det er noen skarpe kanter her. En signatur med chain_id satt til 0 gjelder på alle kjeder samtidig, noe som åpner for replay på tvers av nettverk. Og fordi en EOA nå kan kjøre kode, holder ikke lenger den gamle antakelsen om at msg.sender er lik tx.origin. Pectra-veiledningen på ethereum.org er tydelig på at delegatkontrakter må bygges med reentrancy-vern og beskyttede init-funksjoner, og at man bare bør delegere til uforanderlige kontrakter satt opp med CREATE2.

Et poeng som ofte overrasker, er at en konto bare kan peke på én delegatkontrakt om gangen. Vil du bytte til en annen, skriver du rett og slett over den forrige markøren med en ny autorisasjon; det finnes ingen liste over flere samtidige delegater på samme konto. Nonce-verdien i autorisasjonen sørger for at en gammel, signert delegering ikke uten videre kan spilles av på nytt senere, forutsatt at chain_id er satt riktig. Denne enkelheten er bevisst: jo færre bevegelige deler, desto mindre er det som kan gå galt i en mekanisme som nå sitter på titalls millioner kontoer.

EOA, ERC-4337 og EIP-7702: tre kontomodeller side om side

EIP-7702 er ikke en erstatning for ERC-4337, men et bindeledd. ERC-4337 bygde smartkontolommebøker helt utenom protokollen, med egne kontraktadresser og en «EntryPoint». EIP-7702 lar en eksisterende EOA låne den samme logikken uten å bytte adresse. Forslaget avløste også det tilbaketrukne EIP-3074, som ville løst mye av det samme, men med nye opcodes og en mer begrenset modell. Tabellen under viser hvordan de tre modellene skiller seg fra hverandre for en vanlig bruker.

I praksis betyr dette at en 7702-delegert EOA gir deg mange av fordelene fra en 4337-lommebok (batch, gassabstraksjon, øktnøkler) samtidig som du beholder den adressen børsen din allerede kjenner, og den samme seed-frasen. Det er også kjernen i risikoen: superkreftene og angrepsflaten følges ad, og den samme signaturen som gjør hverdagen enklere, kan i verste fall gi bort langt mer enn en enkel overføring.

Lommebøkene: hvem skrudde på delegeringen

Adopsjonen har vært ujevn, men de tunge aktørene er på plass. MetaMask bruker 7702 som sin primære oppgraderingsvei og delegerer til en 4337-kompatibel kontrakt, mens Ambire og OKX Wallet var blant de tidligste. Safe lar en EOA peke på Safe-logikk, uten at kontoen dermed blir en ekte multisig. Tabellen gir et grovt bilde av hvor de mest brukte lommebøkene står.

For deg som bruker maskinvarelommebok er bildet litt mer nyansert. En 7702-delegering styres fortsatt av den samme private nøkkelen, så en Ledger eller Trezor beskytter deg like godt (eller like dårlig) mot at nøkkelen lekker. Men signeringsopplevelsen blir mer krevende: en autorisasjon ser annerledes ut enn en vanlig overføring, og evnen til å lese hva du faktisk godkjenner blir viktigere. Vi har sett nærmere på hvordan de ulike enhetene håndterer dette i vår gjennomgang av maskinvarelommebøker gjennom hele eierskapet.

Batch, øktnøkler og spill: hva 7702 låser opp i praksis

Det er lett å drukne i byte-sekvenser og glemme hvorfor noen gadd å bygge dette. Den enkleste gevinsten er batching. I stedet for å godkjenne en token og deretter bytte den i to atskilte steg, med to signaturer og to gassbetalinger, kan en 7702-konto pakke begge inn i én atomisk operasjon. Enten lykkes hele pakken, eller så ruller alt tilbake. For en bruker føles det som at «godkjenn og bytt» endelig ble til én knapp, og for en børs betyr det at en enkelt innkommende transaksjon kan inneholde flere handlinger på én gang.

Den andre store gevinsten er øktnøkler («session keys»). En applikasjon, for eksempel et blokkjede-spill eller en handelsapp, kan be om en begrenset nøkkel som bare får lov til å gjøre bestemte ting, innenfor bestemte grenser, i en avgrenset periode. Da slipper du å signere hver eneste handling manuelt, samtidig som skaden er begrenset hvis økten skulle misbrukes. For spill, der hundrevis av små transaksjoner ødelegger flyten dersom hver enkelt krever en signatur, er dette forskjellen på noe spillbart og noe uspillbart. Det er også her gass-sponsing kommer inn: en utvikler kan la spilleren komme i gang uten å eie ETH i det hele tatt.

Den tredje gevinsten er sikkerhetsnett: utgiftsgrenser, tillatelseslister og sosial gjenoppretting. En 7702-konto kan settes opp slik at store uttak krever en ekstra bekreftelse, eller slik at en betrodd kontakt kan hjelpe deg å gjenopprette tilgang uten noen gang å holde nøkkelen din. Ingen av delene er magi, og alt avhenger av at delegatkontrakten er godt bygget, men de peker på hvorfor account abstraction har vært etterlengtet så lenge: mekanismen flytter Ethereum fra «én nøkkel, alt eller ingenting» til noe som ligner en vanlig konto med innstillinger.

Børsenes forsiktige dans: innskudd, uttak og custody

Her ligger den egentlige nyheten for wallets-og-børser-sporet. For en sentralisert børs er en innskuddsadresse som regel en kontrollert EOA. Når EOA-er nå kan bære kode, må børsene forholde seg til at en innskudds- eller uttaksadresse kan ha en delegeringsmarkør knyttet til seg. I de fleste tilfeller er dette uproblematisk: en delegert EOA har samme adresse som før, og innskudd og uttak går som normalt.

Det operasjonelle poenget er at delegeringen er nesten usynlig i den vanlige inn- og utbetalingsflyten, og det er nettopp derfor den både er praktisk og en overvåkingsutfordring. Custody-avdelinger og compliance-team screener nå de 23 byteene i kode-feltet for å se hvilken kontrakt en adresse peker på, før store uttak slippes gjennom. En innskuddstransaksjon som kommer fra en delegert konto, kan dessuten være en batch der flere handlinger er pakket sammen, noe overvåkingssystemer må kunne tolke riktig for ikke å feillese hva som faktisk skjedde.

Ta et konkret tilfelle: en kunde tar ut ETH til en adresse som allerede er delegert til en smartkonto-kontrakt. For børsen ser adressen ut som en helt vanlig mottaker, og uttaket går gjennom som normalt. Men hvis den samme kunden senere setter inn midler fra en batch-transaksjon, må børsens systemer forstå at flere handlinger er slått sammen, slik at riktig beløp krediteres riktig konto. Det er små ting hver for seg, men i sum tvinger de fram oppgraderinger i overvåkings- og avstemmingssystemer som ikke var bygget for kontoer som kan bære kode.

For forvaltere er ansvarsbildet skjerpet. Under MiCA hviler det et tydelig ansvar på tjenesteytere som oppbevarer kunders kryptoeiendeler, og en delegert konto som oppfører seg uventet, er akkurat den typen operasjonell risiko regelverket forventer at et foretak håndterer. Ikke overraskende har de børsene som har vært tidligst ute, stort sett introdusert 7702-funksjoner i sine selvforvaltede lommebøker, der brukeren selv holder nøkkelen, og ikke i selve custody-laget, der forsiktigheten er størst og endringene minst.

Sweeper-økonomien: mye støy, lite penger

Ingen del av 7702-historien har fått flere overskrifter enn «sweeper»-kontraktene. Kort tid etter Pectra fant analyseselskapet Wintermute at over 97 prosent av de tidlige delegeringene pekte på nøyaktig samme gjenbrukte kode, en kontrakt som fikk kallenavnet CrimeEnjoyor. Den er kort, enkel og kopiert i det uendelige, og den gjør én ting: den feier automatisk ut ETH fra en kompromittert konto i det sekundet midler kommer inn.

Overskriften «97 prosent av delegeringene er ondsinnet» høres alarmerende ut, men den beskriver volum, ikke verdi. I en gjennomgang gjengitt av CoinDesk konkluderte Wintermute med at disse kontraktene knapt tjente penger. Rundt 2,9 ETH var på det tidspunktet fordelt på om lag 79 000 adresser, og én enkelt kontrakt sto for over 52 000 av dem. Det tilsvarer noen få titusen kroner spredt over titusenvis av allerede tomme eller tidligere hacket lommebøker. Poenget fra Wintermute var tydelig: dette er ikke en svakhet i EIP-7702, men gammelt nøkkeltyveri pakket i ny innpakning.

Wintermute svarte forresten på en uvanlig måte. Selskapet lagde sin egen CrimeEnjoyor-merking som injiserer lesbare advarsler direkte inn i de ondsinnede kontraktene, slik at en bruker som slår dem opp, ser en beskjed i klartekst om at kontrakten automatisk feier ut alle midler, og at man ikke bør sende noe dit. Denne distinksjonen er verdt å holde fast ved når man leser en obduksjon av et angrep. Vi har skrevet en egen guide til hvordan du leser obduksjonen av et hack, og et gjennomgangstema der er nettopp å skille mekanismen som ble misbrukt fra den underliggende feilen. I sweeper-tilfellet er den underliggende feilen nesten alltid en nøkkel som allerede var på avveie.

Når det gjør vondt: Inferno Drainer og den blinde signaturen

Sweeperne er billig masseproduksjon. Den dyre varianten er målrettet phishing, og her har 7702 gitt etablerte drainer-operasjoner et nytt våpen. Sikkerhetsselskaper som Scam Sniffer og SlowMist har dokumentert at drainer-sett som Inferno Drainer nå pakker 7702-autorisasjoner inn i det som ser ut som en helt vanlig godkjenning. I ett tilfelle omtalt av AMBCrypto mistet et offer rundt 150 000 dollar, i overkant av 1,4 millioner kroner, i én eneste pakket transaksjon.

Angrepet lever av blind signering. Når du blir bedt om å godkjenne noe du ikke kan lese fullt ut, og det du egentlig signerer er en autorisasjon som gir en angriperkontrakt lov til å handle på vegne av kontoen din, er skaden gjort i det du bekrefter. Det er derfor lesbar signering, altså at lommeboken viser deg i klartekst hva en autorisasjon faktisk gjør, er den enkeltfunksjonen som betyr mest for vanlige brukere. En maskinvarelommebok hjelper mot lekkede nøkler, men mot blind signering hjelper først og fremst en lommebok som nekter å vise deg en autorisasjon uten forklaring.

Samtidig er det viktig å ikke overdrive. Det samlede bildet peker faktisk nedover. Ifølge en gjennomgang fra Scam Sniffer, gjengitt av Cointelegraph, falt de totale phishing-tapene med 83 prosent i 2025, til rundt 83,85 millioner dollar (i størrelsesorden 800 millioner kroner), fordelt på om lag 106 000 ofre. EIP-7702 skapte altså ikke en ny epidemi; den ga eksisterende drainere en ny nyttelast. Marius van der Wijden, kjerneutvikler i Ethereum-miljøet, oppsummerte holdningen godt allerede da forslaget ble lagt fram, overfor DL News: «It’s still a very early proposal, so we need to evaluate all the rough edges.»

Slik leser og tilbakekaller du din egen delegering

Å sjekke din egen konto tar under et minutt. Slå opp adressen din i en blokkutforsker som Etherscan og se på kode-feltet. Er kontoen en ren EOA, er feltet tomt. Er den delegert, ser du markøren 0xef0100 etterfulgt av adressen til delegatkontrakten. Da kan du slå opp den kontrakten og se om det er en du kjenner igjen, for eksempel den offisielle delegaten til lommeboken din, eller noe du ikke har noe forhold til.

Vil du fjerne en delegering, tilbakekaller du den ved å signere en ny 7702-autorisasjon som peker på nulladressen (adressen som bare består av nuller). Det nullstiller kode-feltet og gjør kontoen til en vanlig EOA igjen. En fornuftig hygiene er å delegere kun til kontrakter lommeboksleverandøren din faktisk tilbyr, tilbakekalle alt du ikke kjenner igjen, og aldri godkjenne en autorisasjon du ikke får lest i klartekst. Gjør du dette til en fast rutine, mister en eventuell drainer det viktigste den trenger: en delegering du ikke har oversikt over.

Risikoene revisorene ser etter

For utviklere og revisorer er 7702 en ny angrepsflate å teste. De samme temaene går igjen i gjennomganger fra sikkerhetsmiljøer som SlowMist og Fireblocks, og de er verdt å kjenne til også som bruker, fordi de forklarer hvorfor rådet om å «deleger bare til kontrakter du stoler på» ikke bare er en frase.

Lagringskollisjon er kanskje den mest tekniske: fordi delegatkontrakten kjører i kontoens egen lagringskontekst, kan den skrive over felt på uventede måter hvis den ikke bruker adskilte lagringsområder. Løsningen bransjen har landet på, er namespaced storage etter ERC-7201, som gir hver modul sin egen lagringsplass. De øvrige punktene, front-running av init, replay med chain_id=0, blind signering og bortfallet av tx.origin-antakelsen, er alle dokumentert i den offisielle Pectra-veiledningen, som er blitt en de facto sjekkliste for alle som bygger en delegatkontrakt.

Regelverket i Norge: Finanstilsynet, MiCA og skattemeldingen

Hvor passer en delegert smartkonto inn i norsk regelverk? Kryptoeiendelsloven, som gjennomfører EUs MiCA-forordning i norsk rett, trådte i kraft 1. juli 2025 og gjelder i Norge via EØS-avtalen. Finanstilsynet fører tilsyn med kryptoeiendelstjenesteytere (CASP-er), altså børser, vekslere og oppbevaringstjenester, ikke med selve protokollen eller med koden i en smartkontrakt. Et konkret tegn på at rammeverket er i drift, er at norske foretak nå kan få CASP-tillatelse under det nye regimet.

Det viktige skillet for 7702 er selvforvaltning. Delegerer du din egen EOA med din egen nøkkel, holder du fortsatt kryptoeiendelene selv, og du faller utenfor CASP-perimeteren på samme måte som med en vanlig selvforvaltet lommebok. Det er tjenesteyteren, ikke deg som privatperson, som bærer MiCA-pliktene. En delegert konto er altså ikke plutselig underlagt tilsyn fordi den har fått en delegeringsmarkør.

På skattesiden endrer 7702 lite i seg selv. Å delegere flytter ikke eierskap og utløser normalt ingen realisasjon; det er selve kjøp, salg, veksling eller bruk som betaling som er skattepliktige hendelser, akkurat som før. Det store som endrer seg i 2026, er rapporteringen: Skatteetaten begynner å motta systematiske opplysninger fra kryptotilbydere under det nye CARF-regelverket. En selvforvaltet, on-chain delegert konto rapporteres ikke automatisk, så plikten til selv å føre opp beholdning og gevinst i skattemeldingen ligger fortsatt hos deg.

For foretakene som faktisk er underlagt tilsyn, kommer 7702 på toppen av et allerede tett regelverk. MiCA stiller krav til oppbevaring og ansvar, og EUs DORA-regelverk stiller krav til operasjonell IT-motstandsdyktighet. En delegert innskuddsadresse som oppfører seg uventet, er nettopp den typen hendelse et foretak må kunne oppdage, håndtere og rapportere. For deg som privatperson er budskapet enklere: så lenge du holder din egen nøkkel, er det du, og ikke et tilsyn, som har ansvaret for hva kontoen din delegerer til.

Veien videre: Fusaka, Glamsterdam og native account abstraction

EIP-7702 er ikke endestasjonen, men en bro. Etter Pectra kom Fusaka-oppgraderingen, som ble aktivert 3. desember 2025 og først og fremst handlet om PeerDAS og mer datakapasitet for Layer 2. Neste planlagte harde gaffel er Glamsterdam. Ingen av disse handler direkte om kontomodellen, men de rydder plass på veikartet for det som er det egentlige målet: ekte, innebygd account abstraction.

Det målet har et navn i forslagsform: EIP-7701, native account abstraction, som vil bygge smartkontologikken inn i selve protokollen i stedet for å lime den på med ERC-4337 eller låne den via 7702. Nyere forslag som EIP-8141 (Frame Transactions) trekker i samme retning. Foreløpig er ingen av dem tidfestet til en bestemt hard gaffel; de ligger på det lengre veikartet, mens 7702 er broen som holder frem til de er klare.

Hva ville egentlig endre seg for deg med native account abstraction? Mest av alt at smartkonto-egenskapene ikke lenger måtte lånes via en delegatkontrakt, men var en innebygd del av protokollen, med ryddigere regler for gass, validering og gjenoppretting. For vanlige brukere ville det trolig merkes som færre skarpe kanter og mindre blind signering, ikke som en ny revolusjon. Nettopp derfor omtaler mange 7702 som en overgangsteknologi: god nok til å tas i bruk av titalls millioner i dag, men ikke det endelige svaret.

For lommebøker og børser betyr dette at 7702 ikke er en midlertidig løsning som forsvinner over natten. Vi har sett nærmere på hva som skjer når abstraksjonen flyttes helt inn i protokollen, i vår gjennomgang av kappløpet om native account abstraction. Frem til da er en 7702-delegert EOA den mest utbredte måten en vanlig konto får smartkonto-egenskaper på, og den modellen som avgjør hvordan lommebøker og børser møter kundene sine akkurat nå.

Sjekkliste før du signerer en delegering

• Deleger bare til kontrakter lommeboksleverandøren din tilbyr, helst uforanderlige og satt opp med CREATE2.
• Les hva du signerer; en 7702-autorisasjon er ikke det samme som en vanlig «approve» eller overføring.
• Unngå signaturer med chain_id satt til 0, som kan spilles av på tvers av kjeder.
• Sjekk kode-feltet på adressen din i en blokkutforsker; markøren 0xef0100 betyr at kontoen er delegert.
• Tilbakekall ukjente delegeringer ved å delegere til nulladressen.
• Bruk maskinvarelommebok for større beløp, og bekreft at du kan lese autorisasjonen i klartekst.
• Følger du med på innskudd og uttak mot børs, husk at en batch kan skjule flere handlinger i én transaksjon.

Ofte stilte spørsmål

Er kontoen min allerede en EIP-7702-smartkonto?

Kanskje. Hvis du bruker en oppdatert versjon av MetaMask, Ambire, OKX Wallet eller en annen lommebok som har skrudd på funksjonen, og du har godkjent en oppgradering, kan kontoen din være delegert. Du sjekker det enkelt ved å slå opp adressen din i en blokkutforsker og se etter markøren 0xef0100 i kode-feltet. Er feltet tomt, er kontoen fortsatt en vanlig EOA.

Er EIP-7702 trygt å bruke?

Mekanismen i seg selv regnes som trygg, og Wintermute konkluderte med at de omtalte «sweeper»-kontraktene utnytter allerede stjålne nøkler, ikke en feil i 7702. Risikoen ligger i hvordan du bruker den: å signere en autorisasjon du ikke kan lese, eller å delegere til en ukjent kontrakt, er der skaden skjer. Deleger bare til kontrakter lommeboken din tilbyr, og les alltid det du godkjenner.

Koster det gass å delegere, og er det skattepliktig i Norge?

Å sette opp eller fjerne en delegering er en transaksjon på Ethereum og koster derfor gass i ETH. Selve delegeringen flytter ikke eierskap og utløser normalt ingen realisasjon skattemessig; det er kjøp, salg, veksling eller bruk som betaling som er skattepliktige hendelser. Du fører fortsatt beholdning og gevinst selv i skattemeldingen, og Skatteetaten mottar fra 2026 også opplysninger direkte fra kryptotilbydere.

Hva er forskjellen på EIP-7702 og ERC-4337?

ERC-4337 bygger en smartkontolommebok utenfor protokollen, med en egen kontraktadresse. EIP-7702 lar en eksisterende vanlig konto (EOA) låne den samme logikken uten å bytte adresse eller seed-frase. De to utfyller hverandre: mange lommebøker delegerer en 7702-konto til en 4337-kompatibel kontrakt, slik at du får batch, gassabstraksjon og øktnøkler samtidig som du beholder adressen børsen din allerede kjenner.

Hvordan tilbakekaller jeg en delegering?

Du tilbakekaller en delegering ved å signere en ny 7702-autorisasjon som peker på nulladressen, altså adressen som bare består av nuller. Det tømmer kode-feltet og gjør kontoen til en vanlig EOA igjen. Sjekk gjerne først i en blokkutforsker hvilken kontrakt du er delegert til, slik at du vet hva du fjerner.

Av Jonas Ellingsen, senior redaktør for lommebøker og børser i HOGE Wire.