EIP-7702 på børsen: når innskuddsadresser kjører kode

En innskuddsadresse har alltid vært det kjedeligste objektet en børs eier. Du får en tildelt, du sender kryptoen din dit, og noen minutter senere feier børsen beløpet videre til et kaldt hvelv. Adressen selv gjorde ingenting; den var en postkasse uten hjerne, en streng med heksadesimaler som bare kunne holde en saldo og vente på at noen brukte privatnøkkelen. Den antakelsen, at en Ethereum-adresse er treg og livløs helt til eieren signerer, lå under nesten alt en handelsplass gjorde med innskudd og uttak. EIP-7702 rev den bort.

Siden Pectra-oppgraderingen gikk live på Ethereum-hovednettet 7. mai 2025, kan en helt vanlig konto (en externally owned account, eller EOA) bære kode. Ikke ved å bli erstattet av en ny kontrakt, men ved å peke på en. Én signatur, og adressen oppfører seg som en smartkonto: den kan bunte flere handlinger i én transaksjon, la noen andre betale gassen, eller gi en økt-nøkkel lov til å handle på egen hånd. For en bruker er det praktisk. For en børs som forvalter hundretusener av innskuddsadresser, er det en helt ny klasse av spørsmål, og noen av dem er ubehagelige. I høst ga et åpent kildekodeprosjekt oss det klareste innblikket så langt i hvordan et innskuddssystem faktisk må bygges om for å leve med kontoer som kjører kode. Denne artikkelen handler om den ombyggingen, sett fra pulten som må kreditere, feie og forvare.

Hva EIP-7702 endret for en børs

Det tekniske trikset i EIP-7702 er at det oppgraderer en konto på stedet. En eldre modell for smartkontoer, ERC-4337, krever at du flytter midlene dine til en ny kontraktsadresse med sin egen logikk. Det gir friksjon: ny adresse, ny finansiering, nye innskuddsrutiner. EIP-7702 dropper flyttingen. Adressen din beholder samme nøkkel og samme streng, men får en peker til en kontrakt lagt oppå seg. Det er derfor lommeboksleverandører tok det i bruk så raskt, og det er også derfor det traff børsene i flanken: den gamle antakelsen om at en innskuddsadresse er inert, at den ikke kan gjøre noe av seg selv, holder ikke lenger.

Marius van der Wijden, kjerneutvikler i Ethereum, oppsummerte forbeholdet tidlig: «It’s still a very early proposal, so we need to evaluate all the rough edges». De skarpe kantene han advarte om er ikke akademiske for en handelsplass. En konto som kan kjøre kode er en konto som kan flytte penger uten et nytt, synlig uttak, og det er nøyaktig den evnen et innskuddssystem er bygget for å kontrollere. Native account abstraction skulle etter planen ta over, men som vi kommer tilbake til på slutten, sprakk det samarbeidet 15. september 2026, og det gjør 7702 mer varig enn navnet «midlertidig bro» skulle tilsi. For den lengre konteksten rundt den splittelsen har vi skrevet om fragmenteringen ingen fikser ennå.

Anatomien i en 7702-delegering

For å forstå hva en børs faktisk må se etter, må vi ned i mekanikken. En 7702-delegering settes opp med en ny transaksjonstype, 0x04 (SET_CODE_TX_TYPE). Inne i transaksjonen ligger en autorisasjonsliste, der hvert element er en tuppel: [chain_id, address, nonce, y_parity, r, s]. Kontoeieren signerer denne tuppelen med et eget domeneskille, MAGIC 0x05, slik at en 7702-autorisasjon ikke kan forveksles med en vanlig transaksjonssignatur. Når autorisasjonen er inkludert, skrives det 23 byte med kode til kontoen: prefikset 0xef0100 pluss den 20-byte lange kontraktsadressen kontoen nå peker på. Det er hele delegeringen, en peker, ikke en kopi av kontrakten.

To detaljer er avgjørende for en pult som leser kjeden. Den ene er at Ethereum reserverer 0xef-prefikset: EIP-3541 hindrer at vanlige kontrakter kan starte med 0xef, så en 7702-designator kan aldri forveksles med ordinær kontraktskode. Den andre er nullstilling: en delegering til nulladressen fjerner koden og gjør kontoen til en ren EOA igjen. Til slutt finnes en felle i chain_id: settes den til 0, gjelder signaturen på alle EVM-kjeder samtidig, noe som åpner for kryss-kjede-replay. Spesifikasjonen selv, EIP-7702, staver ut alt dette. Tabellen under oversetter feltene til det en børs faktisk må lese før den krediterer eller feier.

Hvorfor innskuddsadressen ikke lenger er en død postkasse

En typisk børs gir hver bruker sin egen innskuddsadresse, ofte tusenvis eller millioner av dem. Modellen er enkel: brukeren sender inn, en overvåkningsmotor oppdager saldoen, og en feiemekanisme (en sweeper) flytter beløpet fra innskuddsadressen til en sentral varm eller kald konto. Hele arkitekturen hviler på at innskuddsadressen er passiv mellom disse stegene. Den holder penger, den gjør ingenting, og den venter på at børsens egen nøkkelinfrastruktur skal signere feiingen.

Med 7702 er den passiviteten ikke garantert lenger, og bruddet oppstår på tre punkter. Ved oppdagelse: en innskuddsadresse kan allerede være en smartkonto, styrt av kode børsen ikke skrev. Ved feiing: hvis adressen peker på en fiendtlig kontrakt, kan den kontrakten reagere på at penger ankommer. Ved uttak: en mottaksadresse en kunde oppgir kan i sin tur være delegert, slik at midler oppfører seg annerledes enn en ren overføring skulle tilsi. Ingen av disse er hypotetiske. De følger direkte av at 0xef0100-koden kan ligge på en hvilken som helst adresse, når som helst, uten at børsen ble spurt.

Uttakssiden fortjener en egen advarsel. Når en kunde oppgir en adresse for uttak, har børsen tradisjonelt behandlet den som en passiv mottaker. Men en mottaksadresse kan selv være delegert, slik at den kjører kode i det midlene ankommer. I beste fall er det kundens egen smartkonto som bunter eller videresender; i verste fall er det en kontrakt som gjør noe kunden ikke forstår, eller som en angriper kontrollerer. En forvarer som vil være grundig, screener derfor ikke bare adressene den feier fra, men også adressene den sender til, og markerer uttak til ukjente delegerte kontrakter for manuell gjennomgang.

Sweeper-problemet: koden som tømmer adressen idet pengene lander

Den ubehageligste varianten er innskuddsadressen som allerede er kapret. Tenk deg at en kunde en gang signerte en ondsinnet 7702-autorisasjon (i et falskt DeFi-grensesnitt, for eksempel), og at adressen kunden nå bruker til innskudd peker på en angripers sweeper-kontrakt. Da er ikke pengene trygge et sekund. Relay, en av infrastrukturtjenestene som håndterer slike saker, er utvetydig i sin veiledning: en ondsinnet kontrakt kan tømme tokens i det øyeblikket de ankommer. Feiingen skjer i samme blokk som innskuddet, før børsen rekker å kreditere noe som helst.

Det snur logikken i et innskuddssystem på hodet. Før var det trygt å anta at penger som lå på en innskuddsadresse ville bli der til børsen flyttet dem. Nå må systemet regne med at en adresse kan ha en innebygd konkurrent, en kontrakt som prøver å komme først. En børs som krediterer en kunde basert på at pengene «kom frem», og deretter oppdager at en sweeper allerede dro dem videre, sitter igjen med tapet. Løsningen er ikke å gjette, men å lese koden på adressen før noe krediteres. Og det er akkurat det ferske, åpne kildekode nå viser hvordan man gjør i stor skala.

Kappløpet mellom innskudd og sweeper er ubarmhjertig fordi det avgjøres på blokknivå. Idet en overføring til en kapret adresse bekreftes, kan sweeper-kontrakten ligge først i samme eller neste blokk og dra midlene videre før noen menneskelig kontroll rekker å reagere. For en børs som venter på et visst antall bekreftelser før kreditering, kan pengene være borte lenge før tellingen er ferdig. Det er derfor lesing av designatoren må skje før kreditering, ikke etter: en adresse som allerede peker på en ukjent kontrakt skal aldri regnes som et trygt innskudd, uansett hvor mange bekreftelser overføringen har fått.

Slik tilpasser et innskuddssystem seg: ckETH-eksemplet

Det tydeligste offentlige eksemplet kommer fra dfinity, som driver ckETH-minteren, et innskudds- og feiesystem som lar Ethereum-verdier brukes på Internet Computer. Fordi koden er åpen, kan vi lese nøyaktig hvordan et reelt produksjonssystem bygges om for 7702. To endringer er verdt å studere, for de er en mal for hva enhver innskuddspult må gjøre.

Den første endringen løser leseproblemet. I stedet for å spørre kjeden om hver innskuddsadresse enkeltvis, la utviklerne til en deployless batch-leser som henter delegeringsstatus for mange adresser i ett eneste eth_call. Programmet bruker EXTCODECOPY til å kopiere det første kodeordet fra hver adresse, og klassifiserer resultatet i tre kategorier: ikke delegert, delegert til en bestemt kontrakt, eller annen kode. Fordi EIP-3541 holder vanlige kontrakter ute av 0xef-rommet, kan en designator aldri forveksles med kontraktskode; batcheren legger et null-ord foran resultatet for å respektere nettopp den regelen, og klarer opptil 767 adresser per kall. En pult som skal sjekke hundretusener av adresser før feiing, får da svaret i noen få forespørsler i stedet for hundretusener.

Den andre endringen løser gassproblemet. Når en innskuddsadresse allerede er delegert til systemets egen, godkjente sweeper, er det bortkastet å sende en ny autorisasjonstuppel hver gang. Den nye feie-logikken leser delegeringen til hver køet adresse i det samme batchede kallet, på samme blokkhøyde som saldoskanningen, og velger transaksjonstype deretter: adresser som allerede peker på riktig sweeper feies uten tuppel, som en vanlig EIP-1559 type-2-transaksjon, mens adresser som trenger en fersk delegering forblir type-4. Gassbudsjettet teller autorisasjonskostnaden bare for elementene som faktisk bærer en tuppel, og sparer dermed rundt 25 000 gass per adresse som allerede er delegert. Adresser med ukjent kode feies ikke blindt; de utelates og logges, og adresser delegert til en annen kontrakt beholder foreløpig sin nonce-0-tuppel i påvente av en egen rotasjon. Dette er ikke teori. Det er en fungerende beskrivelse av hvordan en innskuddspult må tenke i en 7702-verden: les først, klassifiser, og la kodens tilstand bestemme handlingen.

Verdt å merke seg er hvorfor batchingen betyr så mye i praksis. En stor børs kan ha titalls millioner innskuddsadresser i omløp, og å spørre kjeden om hver enkelt før hver feierunde ville vært både tregt og dyrt i RPC-kall. Ved å pakke opptil 767 adresser inn i ett kall, og lese på samme blokkhøyde som saldoskanningen allerede bruker, får systemet et konsistent øyeblikksbilde uten å doble antallet forespørsler. Konsistensen er ikke kosmetisk: leser du saldo og delegeringsstatus på to forskjellige blokker, risikerer du å feie basert på en tilstand som ikke lenger gjelder. Det er den slags detalj som skiller et innskuddssystem som overlever 7702 fra ett som krediterer feil.

Å screene designatoren: hvitliste i begge retninger

Å lese koden er bare halve jobben; den andre halvparten er å bestemme hva man gjør med svaret. Her lander bransjen på en hvitliste som virker i begge retninger. En delegering til en kontrakt børsen kjenner og har godkjent (for eksempel dens egen sweeper eller en kjent lommeboksleverandørs reviderte kontrakt) kan behandles som trygg. En delegering til noe ukjent eller svartelistet må flagges. Curvegrid, som bygde en av de tidlige 7702-sjekkerne, formulerer den mentale modellen presist: å godta en delegering er nærmere å installere programvare enn å godkjenne en betaling. Verktøyet deres viser grønt for kjente, godkjente kontrakter, spørsmålstegn for ukjente, og oransje for kontrakter knyttet til svindel. Enhver kan slå opp en adresse selv på eip7702.app og se hvilken kontrakt den peker på.

Utfordringen er at en hvitliste bare er så god som vedlikeholdet. Nye lommeboksleverandører ruller ut nye delegeringskontrakter, reviderte kontrakter oppdateres, og angripere bytter sweeper-adresser raskere enn noen enkelt børs rekker å katalogisere. Derfor beveger bransjen seg mot delte kilder: felles registre over kjente delegeringsmål, trussellister over adresser knyttet til drenering, og leverandører som Blockaid og Scam Sniffer som mater sanntidsvarsler inn i lommebøker og pulter. Ingen aktør ser hele bildet alene, og en 7702-designator som er ufarlig i én kontekst kan være fiendtlig i en annen.

Poenget med å screene i begge retninger er at risikoen ikke bare ligger i innkommende innskudd. En kunde som oppgir en delegert adresse for uttak, kan uten å vite det sende midlene inn i en kontrakt som oppfører seg annerledes enn en ren mottaker. Derfor må pulten klassifisere både adresser den feier fra og adresser den sender til. Tabellen under viser de tre tilstandene en adresse kan ha, sett fra forvaringssiden, og den tilhørende handlingen.

Forvarernes svar: MPC og 7702

De institusjonelle forvarerne, de som holder krypto for børser, fond og selskaper, har landet på en litt annen tilnærming enn en ren handelsplass. Fireblocks, en av de største, har skrevet åpent om hvordan de tenker rundt 7702. Arik Galansky, VP Technology i Fireblocks, koker risikoen ned til én setning: «A single malicious delegation is all that is needed». Rådet som følger er konservativt: deleger bare til kontrakter som er fullstendig revidert og tillitsfulle, behandle en delegert kontrakt som en oppgradering av kontoens egen logikk, og reserver 7702 for varme lommebøker med rutineoperasjoner og mindre beløp, mens store verdier holdes på adresser helt uten smartkontrakt-eksponering. Det er hot/warm/cold-tenkningen, oversatt til en 7702-virkelighet.

Fireblocks argumenterer også for at 7702 og MPC (multi-party computation, der en privatnøkkel deles opp slik at ingen enkelt maskin holder hele) utfyller hverandre: MPC fjerner det ene feilpunktet en enkelt nøkkel utgjør, mens 7702 gir MPC-kontoen batching, gassabstraksjon og økt-nøkler. Men merk nyansen i Galanskys råd: «fullstendig revidert» er ikke det samme som «trygt». En revidert kontrakt kan fortsatt ha logikkfeil, og bransjen har rikelig med eksempler på reviderte kontrakter som ble tømt. Vi har skrevet om hvor lite et stempel er verdt i falske kryptoaudits. For den bredere sammenligningen av hvem som faktisk holder nøklene, fra BitGo til Coinbase til bankene, se vår gjennomgang av kryptoforvarerne i 2026.

Gassfrie innskudd og hvem som betaler

En av de mest brukervennlige egenskapene 7702 låser opp, er at noen andre kan betale gassen. En ny kunde med bare USDC og null ETH kan likevel gjøre sin første handling, fordi en paymaster dekker gassen. Circle bygde nettopp dette: med deres paymaster kan en EOA midlertidig anta oppførselen til en smartkontraktskonto og betale gass i USDC i stedet for ETH. For onboarding er det gull; brukeren trenger aldri å skaffe «gass-ETH» først.

Men gratis er aldri gratis. Paymasteren tar typisk et påslag (Circle har ligget rundt ti prosent), og økonomien har sine egne angrepsflater: en ondsinnet bruker kan prøve å tappe en sponsors gassbudsjett (griefing), og en paymaster som subsidierer feil kan gå tom. For en børs som vil tilby gassfrie innskudd som et konkurransefortrinn, blir spørsmålet «hvem betaler gassen» et reelt regnskapsspørsmål, ikke en teknisk kuriositet. Det er også et norsk skattespørsmål, som vi kommer til: å betale gass i en stablecoin er en disposisjon.

Adopsjonen, med et forbehold

Hvor utbredt er dette egentlig? Tallene ser enorme ut, men de må leses med et forbehold. Ifølge BundleBear er det per 19. september 2026 nær 249 millioner kumulative autorisasjoner og over 105 millioner set-code-transaksjoner. Den ærlige adopsjonsmåleren er imidlertid antallet kontoer som faktisk er delegert akkurat nå: rundt 58,9 millioner. Gapet mellom de to skyldes i stor grad sweepere som re-autoriserer de samme tomme adressene om og om igjen, så det kumulative tallet er kunstig oppblåst. Lommebøker som MetaMask Smart Accounts, Ambire, Rabby, Trust Wallet og OKX Wallet har gjort 7702 til en standard oppgraderingsvei, så en voksende andel av vanlige brukere sitter nå på en smartkonto uten å tenke over det.

For en børs betyr det at «adressen kan kjøre kode» ikke er et kantscenario, men snart normaltilfellet. Andelen innskudd som kommer fra, eller lander på, en delegert adresse vokser måned for måned. Et innskuddssystem som fortsatt antar at alle adresser er rene EOA-er, jobber mot en virkelighet som er i ferd med å forsvinne.

Skyggesiden: hva tallene faktisk sier

De store adopsjonstallene skjuler en mørk understrøm. Da 7702 var nytt, fant handelsfirmaet Wintermute at over 97 prosent av de tidlige delegeringene pekte på gjenbrukt sweeper-kode, kallenavnet CrimeEnjoyor, der én kopiert bytekode utgjorde majoriteten av alle delegeringer. Rundt 2,88 ETH ble brukt til å autorisere omtrent 79 000 adresser, og én enkelt kontrakt håndterte over 52 000 av dem. Det viktige forbeholdet: dette var ikke lønnsomt for angriperne, fordi adressene stort sett var tomme eller allerede kompromitterte, og det er ikke en feil i 7702, men en gjenbruk av evnen til å feie.

En fagfellevurdert studie presentert på USENIX Security ’26 (av Mingyuan Huang med flere) satte tall på bildet: av 3 664 166 analyserte autorisasjoner var over 63 prosent knyttet til ondsinnede kontrakter, med 924 bekreftede ondsinnede kontrakter og et anslag på 2,36 millioner dollar i realiserte tap pluss 10,14 millioner dollar i eksponering fra eldre kontrakter. Studien er nyttig nettopp fordi den skiller mellom transaksjonstelling og faktiske tap. Det dyreste enkelttilfellet vi kjenner er en bruker som mistet 1,54 millioner dollar (rundt 14 millioner kroner) i én phishing-transaksjon 24. august 2025, der wstETH, cbBTC og NFT-er ble tappet via et falskt DeFi-grensesnitt og brolagt videre. Samtidig falt de samlede phishing-tapene i 2025 med 83 prosent til rundt 83,85 millioner dollar (i overkant av 780 millioner kroner), ifølge Scam Sniffer. Rekordutbetalingene til hvithatt-forskere har ikke stoppet tyveriene; vi har sett på det paradokset i bug bounty i 2026. Tabellen samler de viktigste risikovektorene og forsvaret mot hver.

Signeringsskjermen og hvorfor du bør tilbakekalle riktig

Nesten alle 7702-tapene har én ting til felles: offeret signerte noe det ikke forsto. En 7702-autorisasjon flytter ingen penger i seg selv; den installerer kode. Derfor ser den harmløs ut på skjermen, og derfor er signeringsøyeblikket det egentlige angrepspunktet, ikke protokollen. Bybit-tyveriet i februar 2025 var den dyre læringen om blindsignering: signeringen skjedde på en internett-tilkoblet maskin, og maskinvarelommeboken viste bare en hash, ikke handlingen. Svaret bransjen bygger er clear signing, standardisert som ERC-7730, som Ledger startet i 2023 og som fikk styringen overført til Ethereum Foundation i mai 2026. Ideen er å oversette en kryptisk signeringsforespørsel til lesbar tekst, slik at brukeren ser at hun er i ferd med å installere kode, ikke bare «godkjenne».

Simulering (der lommeboken viser hva en transaksjon vil gjøre før du signerer) er et nyttig lag, men det er et lag, ikke en garanti; tilstandsavhengige kontrakter kan vise et ufarlig resultat i simuleringen og oppføre seg annerledes i utførelsen. Nettopp derfor er tilbakekalling verdt en advarsel. Hvis en konto først er kompromittert, hjelper det ikke å fjerne delegeringen: angriperen har nøkkelen og kan bare delegere på nytt. Verktøy som revoke.cash kan vise en 7702-delegering, men ikke tilbakekalle den, og en null-tilbakestilling fra en kapret nøkkel er falsk trygghet. Rådet fra Relay og de fleste forvarere er brutalt enkelt: flytt til en helt ny lommebok med en fersk nøkkel. Enhver bruker kan selv slå opp sine autorisasjoner i Etherscans autorisasjonsliste. For en pult som vil gjøre dette riktig, er rekkefølgen fast:

1. Les designatoren før du krediterer eller feier: de første 32 bytene skal enten være tomme eller 0xef0100 pluss en kontrakt du kjenner.
2. Hvitlist kontrakter i begge retninger, og godta bare delegeringer til reviderte kontrakter; flagg og logg alt annet.
3. Feie allerede delegerte adresser uten ny fullmakt der du kan (type-2 i stedet for type-4), og feie aldri en adresse med ukjent kode blindt.
4. Behandle en kapret konto som tapt: tilbakekalling er ikke en kur, flytt til en ny lommebok med fersk nøkkel.
5. Krev clear signing og simulering på signeringsskjermen, men husk at simulering er et lag, ikke en garanti.

Norge: Finanstilsynet, Skatteetaten og CARF

For en norsk leser er ansvarslinjene verdt å presisere. MiCA er innlemmet i EØS-avtalen, og kryptoeiendelsloven trådte i kraft 1. juli 2025. Finanstilsynet fører tilsyn med tilbydere av kryptoeiendelstjenester (CASP-er): børser, forvarere og meglere. Din egen selvforvaring, inkludert en 7702-smartkonto, faller derimot utenfor. Det er ikke lommeboken din som er regulert, men handelsplassen eller forvareren du bruker. For CASP-en følger et ansvar (MiCA artikkel 75) og krav til operasjonell IKT-motstandsdyktighet under DORA, og det er nettopp derfor deposit-screening og feie-logikk ikke er valgfritt pynt, men en del av pliktene et regulert foretak har.

Skattemessig er det en felle mange overser. Å betale gass i en stablecoin, slik en paymaster-modell inviterer til, er en realisasjon av den stablecoinen hos Skatteetaten, med gevinstbeskatning på alminnelig inntekt. Betaler du gass hundre ganger, har du hundre små disposisjoner å holde styr på. Fra 2026 rapporterer dessuten norske tilbydere systematisk under CARF (Crypto-Asset Reporting Framework), så antakelsen om at kjedeaktivitet er usynlig for myndighetene holder ikke lenger. Og et poeng som skiller krypto fra kortbetalinger: det finnes ingen chargeback. Krediterer en børs et innskudd som viste seg å bli feid av en sweeper, finnes ingen bank å reversere transaksjonen hos. Merk også at kryptoderivater (futures, evigvarende kontrakter) reguleres under MiFID II, ikke MiCA, og faller utenfor denne 7702-diskusjonen om spot-innskudd. Poenget for en norsk aktør er at hele 7702-kjeden, fra hvem som betaler gassen til hvem som feier innskuddet, må dokumenteres på en måte som tåler både Finanstilsynets og Skatteetatens blikk.

Broen som ble værende: da native AA sprakk 15. september

EIP-7702 ble solgt som en midlertidig bro: en overgang til vi fikk ekte, protokollnativ account abstraction. Den overgangen ble mer permanent 15. september 2026. Da bekreftet Derek Chiang, grunnlegger av lommebokfirmaet ZeroDev og med i forsøket på å samle de to leirene, at arbeidet med å slå Ethereums og Bases native-forslag sammen til én standard er lagt dødt. «While we identified a number of technical solutions, they all required one side or the other to compromise at least a little bit on their core goals», forklarte han. Prioriteringene sprikte for mye: Ethereum vektlegger sensurmotstand, personvern og sikkerhet, mens Base optimaliserer for skala, tilpasning og etterlevelse.

Resultatet er to konkurrerende protokollnære lommebokdesign: EIP-8141 («frame transactions») for Ethereums Hegotá-oppgradering, og EIP-8130 (en ny transaksjonstype med et on-chain Keystore) på Base-siden, der forslaget dessuten er flyttet til en senere Base-fork og fortsatt bare kjører på devnet. For børser og forvarere er konklusjonen paradoksalt beroligende: siden ingen enkelt native-standard vinner med det første, forblir 7702 og designatoren 0xef0100 fellesnevneren alle må forholde seg til. Den neste Ethereum-oppgraderingen, Glamsterdam, bytter heller ikke ut 7702, men repriser gassen kontoene bruker (blant annet ved å revidere den flate 21 000-gass-kostnaden for en overføring), noe ethvert innskudds- og feiesystem må teste mot. Broen ble altså værende, og pulten som leser kode før den krediterer, er den som er best rustet.

Bunnlinjen

EIP-7702 gjorde den kjedeligste tingen en børs eier, innskuddsadressen, til noe som kan handle på egen hånd. Det er ikke en katastrofe, men det er slutten på en bekvem antakelse. Systemene som klarer overgangen best, gjør tre ting: de leser koden på en adresse før de krediterer eller feier, de hvitlister kontrakter i begge retninger, og de behandler en kapret nøkkel som tapt i stedet for å stole på tilbakekalling. Den åpne ckETH-koden viser at dette er praktisk gjennomførbart i stor skala, og at gevinsten (færre autorisasjoner, sparte gass, tryggere feiing) er reell. Men det svakeste leddet er fortsatt mennesket foran signeringsskjermen som klikker «godkjenn» uten å lese. Ingen protokolloppgradering fikser det. Både børsen som krediterer og brukeren som signerer må lære seg å lese hva en adresse faktisk er, før pengene beveger seg. For hvordan drenering ser ut fra offerets side, er DeFi rug pull i 2026 en nyttig påminnelse om hvem som ender som utgangslikviditet.

Ofte stilte spørsmål

Kan en børs se om innskuddsadressen min er en smartkonto?

Ja. En 7702-delegering ligger som 23 byte kode på adressen, prefikset 0xef0100 pluss kontraktsadressen den peker på. En børs kan lese de første bytene av koden med et enkelt kall, gjerne hundrevis av adresser i én forespørsel, slik den åpne ckETH-koden fra dfinity gjør før den feier.

Er det trygt å bruke EIP-7702 på en adresse jeg sender innskudd fra?

EIP-7702 er ikke usikkert i seg selv, men risikoen ligger i hvilken kontrakt du delegerer til og hva du faktisk signerer. Deleger bare til reviderte kontrakter du stoler på, hold store beløp på en adresse uten delegering, og signer på en maskinvarelommebok med clear signing.

Hva skjer hvis innskuddsadressen min allerede er delegert til en sweeper?

Da kan en ondsinnet kontrakt tømme beløpet i samme blokk som det lander. Å tilbakekalle delegeringen hjelper ikke hvis privatnøkkelen allerede er kompromittert; du må flytte til en helt ny lommebok med en fersk nøkkel, slik Relay og flere forvarere anbefaler.

Regulerer Finanstilsynet min egen smartkonto?

Nei. Selvforvaring, inkludert 7702-smartkontoer, faller utenfor MiCA og Finanstilsynets tilsyn med kryptoforetak; det er børsen eller forvareren som er regulert som CASP. Men å betale gass i en stablecoin kan telle som realisasjon hos Skatteetaten, og fra 2026 rapporterer norske tilbydere systematisk under CARF.

Erstatter native account abstraction EIP-7702?

Ikke med det første. Ethereum og Base ga 15. september 2026 opp forsøket på å samle seg om én native standard, så EIP-8141 og EIP-8130 går hver sin vei. Inntil videre er 7702 og designatoren 0xef0100 fellesnevneren børser og forvarere må håndtere.

Jonas Ellingsen dekker lommebøker, børser og kontoabstraksjon for HOGE Wire.