{"id":431,"date":"2026-09-19T13:05:55","date_gmt":"2026-09-19T13:05:55","guid":{"rendered":"https:\/\/hoge.gg\/no\/eip-7702-borsen-innskuddsadresser-kode-2026\/"},"modified":"2026-09-19T13:05:55","modified_gmt":"2026-09-19T13:05:55","slug":"eip-7702-borsen-innskuddsadresser-kode-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/eip-7702-borsen-innskuddsadresser-kode-2026\/","title":{"rendered":"EIP-7702 p\u00e5 b\u00f8rsen: n\u00e5r innskuddsadresser kj\u00f8rer kode"},"content":{"rendered":"

En innskuddsadresse har alltid v\u00e6rt det kjedeligste objektet en b\u00f8rs eier. Du f\u00e5r en tildelt, du sender kryptoen din dit, og noen minutter senere feier b\u00f8rsen bel\u00f8pet 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\u00e5 at noen brukte privatn\u00f8kkelen. Den antakelsen, at en Ethereum-adresse er treg og livl\u00f8s helt til eieren signerer, l\u00e5 under nesten alt en handelsplass gjorde med innskudd og uttak. EIP-7702 rev den bort.<\/p>

Siden Pectra-oppgraderingen gikk live p\u00e5 Ethereum-hovednettet 7. mai 2025, kan en helt vanlig konto (en externally owned account, eller EOA) b\u00e6re kode. Ikke ved \u00e5 bli erstattet av en ny kontrakt, men ved \u00e5 peke p\u00e5 en. \u00c9n signatur, og adressen oppf\u00f8rer seg som en smartkonto: den kan bunte flere handlinger i \u00e9n transaksjon, la noen andre betale gassen, eller gi en \u00f8kt-n\u00f8kkel lov til \u00e5 handle p\u00e5 egen h\u00e5nd. For en bruker er det praktisk. For en b\u00f8rs som forvalter hundretusener av innskuddsadresser, er det en helt ny klasse av sp\u00f8rsm\u00e5l, og noen av dem er ubehagelige. I h\u00f8st ga et \u00e5pent kildekodeprosjekt oss det klareste innblikket s\u00e5 langt i hvordan et innskuddssystem faktisk m\u00e5 bygges om for \u00e5 leve med kontoer som kj\u00f8rer kode. Denne artikkelen handler om den ombyggingen, sett fra pulten som m\u00e5 kreditere, feie og forvare.<\/p>

Hva EIP-7702 endret for en b\u00f8rs<\/h2>

Det tekniske trikset i EIP-7702 er at det oppgraderer en konto p\u00e5 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\u00f8kkel og samme streng, men f\u00e5r en peker til en kontrakt lagt opp\u00e5 seg. Det er derfor lommeboksleverand\u00f8rer tok det i bruk s\u00e5 raskt, og det er ogs\u00e5 derfor det traff b\u00f8rsene i flanken: den gamle antakelsen om at en innskuddsadresse er inert, at den ikke kan gj\u00f8re noe av seg selv, holder ikke lenger.<\/p>

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

Anatomien i en 7702-delegering<\/h2>

For \u00e5 forst\u00e5 hva en b\u00f8rs faktisk m\u00e5 se etter, m\u00e5 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\u00e5r autorisasjonen er inkludert, skrives det 23 byte med kode til kontoen: prefikset 0xef0100 pluss den 20-byte lange kontraktsadressen kontoen n\u00e5 peker p\u00e5. Det er hele delegeringen, en peker, ikke en kopi av kontrakten.<\/p>

To detaljer er avgj\u00f8rende 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\u00e5 en 7702-designator kan aldri forveksles med ordin\u00e6r kontraktskode. Den andre er nullstilling: en delegering til nulladressen fjerner koden og gj\u00f8r kontoen til en ren EOA igjen. Til slutt finnes en felle i chain_id: settes den til 0, gjelder signaturen p\u00e5 alle EVM-kjeder samtidig, noe som \u00e5pner for kryss-kjede-replay. Spesifikasjonen selv, EIP-7702<\/a>, staver ut alt dette. Tabellen under oversetter feltene til det en b\u00f8rs faktisk m\u00e5 lese f\u00f8r den krediterer eller feier.<\/p>

Felt<\/th>Hva det er<\/th>Hva b\u00f8rsen m\u00e5 lese<\/th><\/tr><\/thead>
Transaksjonstype 0x04<\/td>SET_CODE_TX_TYPE, som installerer kode p\u00e5 en EOA<\/td>At et innskudd kan komme fra, eller lande p\u00e5, en adresse som allerede er en smartkonto<\/td><\/tr>
Autorisasjonsliste<\/td>Tuppelen [chain_id, address, nonce, y_parity, r, s], signert med MAGIC 0x05<\/td>Hvilken kontrakt kontoen peker p\u00e5, og om signaturen gjelder alle kjeder (chain_id = 0)<\/td><\/tr>
Designator 0xef0100 \u2016 adresse<\/td>23 byte kode: prefiks 0xef0100 pluss 20-byte kontraktsadresse<\/td>De f\u00f8rste 32 bytene av koden; alt annet enn 0xef0100 er et varsel<\/td><\/tr>
Nullstilling<\/td>Delegering til nulladressen fjerner koden<\/td>Om en adresse nettopp er av-delegert eller re-delegert til noe nytt<\/td><\/tr>
chain_id = 0<\/td>Signatur uten kjede-binding kan spilles av overalt<\/td>Kryss-kjede-replay: samme delegering kan dukke opp p\u00e5 flere kjeder<\/td><\/tr><\/tbody><\/table><\/figure>

Hvorfor innskuddsadressen ikke lenger er en d\u00f8d postkasse<\/h2>

En typisk b\u00f8rs gir hver bruker sin egen innskuddsadresse, ofte tusenvis eller millioner av dem. Modellen er enkel: brukeren sender inn, en overv\u00e5kningsmotor oppdager saldoen, og en feiemekanisme (en sweeper) flytter bel\u00f8pet fra innskuddsadressen til en sentral varm eller kald konto. Hele arkitekturen hviler p\u00e5 at innskuddsadressen er passiv mellom disse stegene. Den holder penger, den gj\u00f8r ingenting, og den venter p\u00e5 at b\u00f8rsens egen n\u00f8kkelinfrastruktur skal signere feiingen.<\/p>

Med 7702 er den passiviteten ikke garantert lenger, og bruddet oppst\u00e5r p\u00e5 tre punkter. Ved oppdagelse: en innskuddsadresse kan allerede v\u00e6re en smartkonto, styrt av kode b\u00f8rsen ikke skrev. Ved feiing: hvis adressen peker p\u00e5 en fiendtlig kontrakt, kan den kontrakten reagere p\u00e5 at penger ankommer. Ved uttak: en mottaksadresse en kunde oppgir kan i sin tur v\u00e6re delegert, slik at midler oppf\u00f8rer seg annerledes enn en ren overf\u00f8ring skulle tilsi. Ingen av disse er hypotetiske. De f\u00f8lger direkte av at 0xef0100-koden kan ligge p\u00e5 en hvilken som helst adresse, n\u00e5r som helst, uten at b\u00f8rsen ble spurt.<\/p>

Uttakssiden fortjener en egen advarsel. N\u00e5r en kunde oppgir en adresse for uttak, har b\u00f8rsen tradisjonelt behandlet den som en passiv mottaker. Men en mottaksadresse kan selv v\u00e6re delegert, slik at den kj\u00f8rer 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\u00f8r noe kunden ikke forst\u00e5r, eller som en angriper kontrollerer. En forvarer som vil v\u00e6re grundig, screener derfor ikke bare adressene den feier fra, men ogs\u00e5 adressene den sender til, og markerer uttak til ukjente delegerte kontrakter for manuell gjennomgang.<\/p>

Sweeper-problemet: koden som t\u00f8mmer adressen idet pengene lander<\/h2>

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\u00e5 bruker til innskudd peker p\u00e5 en angripers sweeper-kontrakt. Da er ikke pengene trygge et sekund. Relay, en av infrastrukturtjenestene som h\u00e5ndterer slike saker, er utvetydig i sin veiledning: en ondsinnet kontrakt kan t\u00f8mme tokens i det \u00f8yeblikket de ankommer<\/a>. Feiingen skjer i samme blokk som innskuddet, f\u00f8r b\u00f8rsen rekker \u00e5 kreditere noe som helst.<\/p>

Det snur logikken i et innskuddssystem p\u00e5 hodet. F\u00f8r var det trygt \u00e5 anta at penger som l\u00e5 p\u00e5 en innskuddsadresse ville bli der til b\u00f8rsen flyttet dem. N\u00e5 m\u00e5 systemet regne med at en adresse kan ha en innebygd konkurrent, en kontrakt som pr\u00f8ver \u00e5 komme f\u00f8rst. En b\u00f8rs som krediterer en kunde basert p\u00e5 at pengene \u00abkom frem\u00bb, og deretter oppdager at en sweeper allerede dro dem videre, sitter igjen med tapet. L\u00f8sningen er ikke \u00e5 gjette, men \u00e5 lese koden p\u00e5 adressen f\u00f8r noe krediteres. Og det er akkurat det ferske, \u00e5pne kildekode n\u00e5 viser hvordan man gj\u00f8r i stor skala.<\/p>

Kappl\u00f8pet mellom innskudd og sweeper er ubarmhjertig fordi det avgj\u00f8res p\u00e5 blokkniv\u00e5. Idet en overf\u00f8ring til en kapret adresse bekreftes, kan sweeper-kontrakten ligge f\u00f8rst i samme eller neste blokk og dra midlene videre f\u00f8r noen menneskelig kontroll rekker \u00e5 reagere. For en b\u00f8rs som venter p\u00e5 et visst antall bekreftelser f\u00f8r kreditering, kan pengene v\u00e6re borte lenge f\u00f8r tellingen er ferdig. Det er derfor lesing av designatoren m\u00e5 skje f\u00f8r kreditering, ikke etter: en adresse som allerede peker p\u00e5 en ukjent kontrakt skal aldri regnes som et trygt innskudd, uansett hvor mange bekreftelser overf\u00f8ringen har f\u00e5tt.<\/p>

Slik tilpasser et innskuddssystem seg: ckETH-eksemplet<\/h2>

Det tydeligste offentlige eksemplet kommer fra dfinity, som driver ckETH-minteren, et innskudds- og feiesystem som lar Ethereum-verdier brukes p\u00e5 Internet Computer. Fordi koden er \u00e5pen, kan vi lese n\u00f8yaktig hvordan et reelt produksjonssystem bygges om for 7702. To endringer er verdt \u00e5 studere, for de er en mal for hva enhver innskuddspult m\u00e5 gj\u00f8re.<\/p>

Den f\u00f8rste endringen l\u00f8ser leseproblemet. I stedet for \u00e5 sp\u00f8rre kjeden om hver innskuddsadresse enkeltvis, la utviklerne til en deployless batch-leser<\/a> som henter delegeringsstatus for mange adresser i ett eneste eth_call. Programmet bruker EXTCODECOPY til \u00e5 kopiere det f\u00f8rste 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 \u00e5 respektere nettopp den regelen, og klarer opptil 767 adresser per kall. En pult som skal sjekke hundretusener av adresser f\u00f8r feiing, f\u00e5r da svaret i noen f\u00e5 foresp\u00f8rsler i stedet for hundretusener.<\/p>

Den andre endringen l\u00f8ser gassproblemet. N\u00e5r en innskuddsadresse allerede er delegert til systemets egen, godkjente sweeper, er det bortkastet \u00e5 sende en ny autorisasjonstuppel hver gang. Den nye feie-logikken<\/a> leser delegeringen til hver k\u00f8et adresse i det samme batchede kallet, p\u00e5 samme blokkh\u00f8yde som saldoskanningen, og velger transaksjonstype deretter: adresser som allerede peker p\u00e5 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\u00e6rer 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\u00f8pig sin nonce-0-tuppel i p\u00e5vente av en egen rotasjon. Dette er ikke teori. Det er en fungerende beskrivelse av hvordan en innskuddspult m\u00e5 tenke i en 7702-verden: les f\u00f8rst, klassifiser, og la kodens tilstand bestemme handlingen.<\/p>

Verdt \u00e5 merke seg er hvorfor batchingen betyr s\u00e5 mye i praksis. En stor b\u00f8rs kan ha titalls millioner innskuddsadresser i oml\u00f8p, og \u00e5 sp\u00f8rre kjeden om hver enkelt f\u00f8r hver feierunde ville v\u00e6rt b\u00e5de tregt og dyrt i RPC-kall. Ved \u00e5 pakke opptil 767 adresser inn i ett kall, og lese p\u00e5 samme blokkh\u00f8yde som saldoskanningen allerede bruker, f\u00e5r systemet et konsistent \u00f8yeblikksbilde uten \u00e5 doble antallet foresp\u00f8rsler. Konsistensen er ikke kosmetisk: leser du saldo og delegeringsstatus p\u00e5 to forskjellige blokker, risikerer du \u00e5 feie basert p\u00e5 en tilstand som ikke lenger gjelder. Det er den slags detalj som skiller et innskuddssystem som overlever 7702 fra ett som krediterer feil.<\/p>

\u00c5 screene designatoren: hvitliste i begge retninger<\/h2>

\u00c5 lese koden er bare halve jobben; den andre halvparten er \u00e5 bestemme hva man gj\u00f8r med svaret. Her lander bransjen p\u00e5 en hvitliste som virker i begge retninger. En delegering til en kontrakt b\u00f8rsen kjenner og har godkjent (for eksempel dens egen sweeper eller en kjent lommeboksleverand\u00f8rs reviderte kontrakt) kan behandles som trygg. En delegering til noe ukjent eller svartelistet m\u00e5 flagges. Curvegrid, som bygde en av de tidlige 7702-sjekkerne, formulerer den mentale modellen presist: \u00e5 godta en delegering er n\u00e6rmere \u00e5 installere programvare enn \u00e5 godkjenne en betaling<\/a>. Verkt\u00f8yet deres viser gr\u00f8nt for kjente, godkjente kontrakter, sp\u00f8rsm\u00e5lstegn for ukjente, og oransje for kontrakter knyttet til svindel. Enhver kan sl\u00e5 opp en adresse selv p\u00e5 eip7702.app<\/a> og se hvilken kontrakt den peker p\u00e5.<\/p>

Utfordringen er at en hvitliste bare er s\u00e5 god som vedlikeholdet. Nye lommeboksleverand\u00f8rer ruller ut nye delegeringskontrakter, reviderte kontrakter oppdateres, og angripere bytter sweeper-adresser raskere enn noen enkelt b\u00f8rs rekker \u00e5 katalogisere. Derfor beveger bransjen seg mot delte kilder: felles registre over kjente delegeringsm\u00e5l, trussellister over adresser knyttet til drenering, og leverand\u00f8rer som Blockaid og Scam Sniffer som mater sanntidsvarsler inn i lommeb\u00f8ker og pulter. Ingen akt\u00f8r ser hele bildet alene, og en 7702-designator som er ufarlig i \u00e9n kontekst kan v\u00e6re fiendtlig i en annen.<\/p>

Poenget med \u00e5 screene i begge retninger er at risikoen ikke bare ligger i innkommende innskudd. En kunde som oppgir en delegert adresse for uttak, kan uten \u00e5 vite det sende midlene inn i en kontrakt som oppf\u00f8rer seg annerledes enn en ren mottaker. Derfor m\u00e5 pulten klassifisere b\u00e5de 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\u00f8rende handlingen.<\/p>

Slik ser adressen ut<\/th>Hva det betyr<\/th>Hva pulten gj\u00f8r<\/th><\/tr><\/thead>
Ingen kode (ren EOA)<\/td>Klassisk innskuddsadresse, ingen delegering<\/td>Feier som f\u00f8r, med en vanlig type-2-transaksjon<\/td><\/tr>
0xef0100 peker p\u00e5 en kjent, godkjent kontrakt<\/td>Smartkonto styrt av kode pulten stoler p\u00e5 (f.eks. b\u00f8rsens egen sweeper)<\/td>Feier uten ny fullmakt; sparer autorisasjonsgassen<\/td><\/tr>
0xef0100 peker p\u00e5 en ukjent eller svartelistet kontrakt<\/td>Kontoen kan v\u00e6re kapret av en sweeper<\/td>Flagg, ikke krediter blindt; logg og behandle innskuddet som mistenkelig<\/td><\/tr><\/tbody><\/table><\/figure>

Forvarernes svar: MPC og 7702<\/h2>

De institusjonelle forvarerne, de som holder krypto for b\u00f8rser, fond og selskaper, har landet p\u00e5 en litt annen tiln\u00e6rming enn en ren handelsplass. Fireblocks, en av de st\u00f8rste, har skrevet \u00e5pent om hvordan de tenker rundt 7702. Arik Galansky, VP Technology i Fireblocks, koker risikoen ned til \u00e9n setning: \u00abA single malicious delegation is all that is needed\u00bb<\/a>. R\u00e5det som f\u00f8lger 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\u00f8ker med rutineoperasjoner og mindre bel\u00f8p, mens store verdier holdes p\u00e5 adresser helt uten smartkontrakt-eksponering. Det er hot\/warm\/cold-tenkningen, oversatt til en 7702-virkelighet.<\/p>

Fireblocks argumenterer ogs\u00e5 for at 7702 og MPC (multi-party computation, der en privatn\u00f8kkel deles opp slik at ingen enkelt maskin holder hele) utfyller hverandre: MPC fjerner det ene feilpunktet en enkelt n\u00f8kkel utgj\u00f8r, mens 7702 gir MPC-kontoen batching, gassabstraksjon og \u00f8kt-n\u00f8kler<\/a>. Men merk nyansen i Galanskys r\u00e5d: \u00abfullstendig revidert\u00bb er ikke det samme som \u00abtrygt\u00bb. En revidert kontrakt kan fortsatt ha logikkfeil, og bransjen har rikelig med eksempler p\u00e5 reviderte kontrakter som ble t\u00f8mt. Vi har skrevet om hvor lite et stempel er verdt i falske kryptoaudits<\/a>. For den bredere sammenligningen av hvem som faktisk holder n\u00f8klene, fra BitGo til Coinbase til bankene, se v\u00e5r gjennomgang av kryptoforvarerne i 2026<\/a>.<\/p>

Gassfrie innskudd og hvem som betaler<\/h2>

En av de mest brukervennlige egenskapene 7702 l\u00e5ser opp, er at noen andre kan betale gassen. En ny kunde med bare USDC og null ETH kan likevel gj\u00f8re sin f\u00f8rste handling, fordi en paymaster dekker gassen. Circle bygde nettopp dette: med deres paymaster kan en EOA midlertidig anta oppf\u00f8rselen til en smartkontraktskonto<\/a> og betale gass i USDC i stedet for ETH. For onboarding er det gull; brukeren trenger aldri \u00e5 skaffe \u00abgass-ETH\u00bb f\u00f8rst.<\/p>

Men gratis er aldri gratis. Paymasteren tar typisk et p\u00e5slag (Circle har ligget rundt ti prosent), og \u00f8konomien har sine egne angrepsflater: en ondsinnet bruker kan pr\u00f8ve \u00e5 tappe en sponsors gassbudsjett (griefing), og en paymaster som subsidierer feil kan g\u00e5 tom. For en b\u00f8rs som vil tilby gassfrie innskudd som et konkurransefortrinn, blir sp\u00f8rsm\u00e5let \u00abhvem betaler gassen\u00bb et reelt regnskapssp\u00f8rsm\u00e5l, ikke en teknisk kuriositet. Det er ogs\u00e5 et norsk skattesp\u00f8rsm\u00e5l, som vi kommer til: \u00e5 betale gass i en stablecoin er en disposisjon.<\/p>

Adopsjonen, med et forbehold<\/h2>

Hvor utbredt er dette egentlig? Tallene ser enorme ut, men de m\u00e5 leses med et forbehold. If\u00f8lge BundleBear<\/a> er det per 19. september 2026 n\u00e6r 249 millioner kumulative autorisasjoner og over 105 millioner set-code-transaksjoner. Den \u00e6rlige adopsjonsm\u00e5leren er imidlertid antallet kontoer som faktisk er delegert akkurat n\u00e5: 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\u00e5 det kumulative tallet er kunstig oppbl\u00e5st. Lommeb\u00f8ker som MetaMask Smart Accounts, Ambire, Rabby, Trust Wallet og OKX Wallet har gjort 7702 til en standard oppgraderingsvei, s\u00e5 en voksende andel av vanlige brukere sitter n\u00e5 p\u00e5 en smartkonto uten \u00e5 tenke over det.<\/p>

For en b\u00f8rs betyr det at \u00abadressen kan kj\u00f8re kode\u00bb ikke er et kantscenario, men snart normaltilfellet. Andelen innskudd som kommer fra, eller lander p\u00e5, en delegert adresse vokser m\u00e5ned for m\u00e5ned. Et innskuddssystem som fortsatt antar at alle adresser er rene EOA-er, jobber mot en virkelighet som er i ferd med \u00e5 forsvinne.<\/p>

Skyggesiden: hva tallene faktisk sier<\/h2>

De store adopsjonstallene skjuler en m\u00f8rk understr\u00f8m. Da 7702 var nytt, fant handelsfirmaet Wintermute at over 97 prosent av de tidlige delegeringene pekte p\u00e5 gjenbrukt sweeper-kode<\/a>, kallenavnet CrimeEnjoyor, der \u00e9n kopiert bytekode utgjorde majoriteten av alle delegeringer. Rundt 2,88 ETH ble brukt til \u00e5 autorisere omtrent 79 000 adresser, og \u00e9n enkelt kontrakt h\u00e5ndterte over 52 000 av dem. Det viktige forbeholdet: dette var ikke l\u00f8nnsomt 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 \u00e5 feie.<\/p>

En fagfellevurdert studie presentert p\u00e5 USENIX Security ’26 (av Mingyuan Huang med flere) satte tall p\u00e5 bildet: av 3 664 166 analyserte autorisasjoner var over 63 prosent knyttet til ondsinnede kontrakter, med 924 bekreftede ondsinnede kontrakter og et anslag p\u00e5 2,36 millioner dollar i realiserte tap pluss 10,14 millioner dollar i eksponering fra eldre kontrakter. Studien<\/a> 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 \u00e9n 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)<\/a>, if\u00f8lge Scam Sniffer. Rekordutbetalingene til hvithatt-forskere har ikke stoppet tyveriene; vi har sett p\u00e5 det paradokset i bug bounty i 2026<\/a>. Tabellen samler de viktigste risikovektorene og forsvaret mot hver.<\/p>

Risikovektor<\/th>Hva som skjer<\/th>Forsvar<\/th><\/tr><\/thead>
Sweeper p\u00e5 innskuddsadresse<\/td>Ondsinnet delegering t\u00f8mmer bel\u00f8pet i samme blokk det lander<\/td>Les designatoren f\u00f8r kreditering; hvitliste kontrakter i begge retninger<\/td><\/tr>
Blindsignering<\/td>Brukeren godkjenner en autorisasjon uten \u00e5 se hva den installerer<\/td>Clear signing (ERC-7730), simulering, maskinvarelommebok<\/td><\/tr>
chain_id = 0 replay<\/td>\u00c9n signatur gjenbrukes p\u00e5 flere kjeder<\/td>Krev kjede-bundet signatur; overv\u00e5k p\u00e5 tvers av kjeder<\/td><\/tr>
Storage-kollisjon i urevidert kontrakt<\/td>Delegering til en kontrakt med feil lagringslayout korrumperer tilstand<\/td>Deleger bare til reviderte kontrakter med ERC-7201-navnerom<\/td><\/tr>
\u00abRevidert = trygt\u00bb-fellen<\/td>En revidert kontrakt kan fortsatt ha logikkfeil<\/td>Revisjon reduserer risiko, men fjerner den ikke<\/td><\/tr><\/tbody><\/table><\/figure>

Signeringsskjermen og hvorfor du b\u00f8r tilbakekalle riktig<\/h2>

Nesten alle 7702-tapene har \u00e9n 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\u00f8s ut p\u00e5 skjermen, og derfor er signerings\u00f8yeblikket det egentlige angrepspunktet, ikke protokollen. Bybit-tyveriet i februar 2025 var den dyre l\u00e6ringen om blindsignering: signeringen skjedde p\u00e5 en internett-tilkoblet maskin, og maskinvarelommeboken viste bare en hash, ikke handlingen. Svaret bransjen bygger er clear signing, standardisert som ERC-7730<\/a>, som Ledger startet i 2023 og som fikk styringen overf\u00f8rt til Ethereum Foundation i mai 2026. Ideen er \u00e5 oversette en kryptisk signeringsforesp\u00f8rsel til lesbar tekst, slik at brukeren ser at hun er i ferd med \u00e5 installere kode, ikke bare \u00abgodkjenne\u00bb.<\/p>

Simulering (der lommeboken viser hva en transaksjon vil gj\u00f8re f\u00f8r 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\u00f8re seg annerledes i utf\u00f8relsen. Nettopp derfor er tilbakekalling verdt en advarsel. Hvis en konto f\u00f8rst er kompromittert, hjelper det ikke \u00e5 fjerne delegeringen: angriperen har n\u00f8kkelen og kan bare delegere p\u00e5 nytt. Verkt\u00f8y som revoke.cash kan vise en 7702-delegering, men ikke tilbakekalle den<\/a>, og en null-tilbakestilling fra en kapret n\u00f8kkel er falsk trygghet. R\u00e5det fra Relay og de fleste forvarere er brutalt enkelt: flytt til en helt ny lommebok med en fersk n\u00f8kkel. Enhver bruker kan selv sl\u00e5 opp sine autorisasjoner i Etherscans autorisasjonsliste<\/a>. For en pult som vil gj\u00f8re dette riktig, er rekkef\u00f8lgen fast:<\/p>

  1. Les designatoren f\u00f8r du krediterer eller feier: de f\u00f8rste 32 bytene skal enten v\u00e6re tomme eller 0xef0100 pluss en kontrakt du kjenner.<\/li>
  2. Hvitlist kontrakter i begge retninger, og godta bare delegeringer til reviderte kontrakter; flagg og logg alt annet.<\/li>
  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.<\/li>
  4. Behandle en kapret konto som tapt: tilbakekalling er ikke en kur, flytt til en ny lommebok med fersk n\u00f8kkel.<\/li>
  5. Krev clear signing og simulering p\u00e5 signeringsskjermen, men husk at simulering er et lag, ikke en garanti.<\/li><\/ol>

    Norge: Finanstilsynet, Skatteetaten og CARF<\/h2>

    For en norsk leser er ansvarslinjene verdt \u00e5 presisere. MiCA er innlemmet i E\u00d8S-avtalen, og kryptoeiendelsloven tr\u00e5dte i kraft 1. juli 2025. Finanstilsynet<\/a> f\u00f8rer tilsyn med tilbydere av kryptoeiendelstjenester (CASP-er): b\u00f8rser, 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\u00f8lger 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.<\/p>

    Skattemessig er det en felle mange overser. \u00c5 betale gass i en stablecoin, slik en paymaster-modell inviterer til, er en realisasjon av den stablecoinen hos Skatteetaten<\/a>, med gevinstbeskatning p\u00e5 alminnelig inntekt. Betaler du gass hundre ganger, har du hundre sm\u00e5 disposisjoner \u00e5 holde styr p\u00e5. Fra 2026 rapporterer dessuten norske tilbydere systematisk under CARF (Crypto-Asset Reporting Framework), s\u00e5 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\u00f8rs et innskudd som viste seg \u00e5 bli feid av en sweeper, finnes ingen bank \u00e5 reversere transaksjonen hos. Merk ogs\u00e5 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\u00f8r er at hele 7702-kjeden, fra hvem som betaler gassen til hvem som feier innskuddet, m\u00e5 dokumenteres p\u00e5 en m\u00e5te som t\u00e5ler b\u00e5de Finanstilsynets og Skatteetatens blikk.<\/p>

    Broen som ble v\u00e6rende: da native AA sprakk 15. september<\/h2>

    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\u00f8ket p\u00e5 \u00e5 samle de to leirene, at arbeidet med \u00e5 sl\u00e5 Ethereums og Bases native-forslag sammen til \u00e9n standard er lagt d\u00f8dt. \u00abWhile 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\u00bb<\/a>, forklarte han. Prioriteringene sprikte for mye: Ethereum vektlegger sensurmotstand, personvern og sikkerhet, mens Base optimaliserer for skala, tilpasning og etterlevelse.<\/p>

    Resultatet er to konkurrerende protokolln\u00e6re lommebokdesign: EIP-8141 (\u00abframe transactions\u00bb) for Ethereums Hegot\u00e1-oppgradering, og EIP-8130 (en ny transaksjonstype med et on-chain Keystore) p\u00e5 Base-siden, der forslaget dessuten er flyttet til en senere Base-fork og fortsatt bare kj\u00f8rer p\u00e5 devnet. For b\u00f8rser og forvarere er konklusjonen paradoksalt beroligende: siden ingen enkelt native-standard vinner med det f\u00f8rste, forblir 7702 og designatoren 0xef0100 fellesnevneren alle m\u00e5 forholde seg til. Den neste Ethereum-oppgraderingen, Glamsterdam, bytter heller ikke ut 7702, men repriser gassen kontoene bruker (blant annet ved \u00e5 revidere den flate 21 000-gass-kostnaden for en overf\u00f8ring), noe ethvert innskudds- og feiesystem m\u00e5 teste mot. Broen ble alts\u00e5 v\u00e6rende, og pulten som leser kode f\u00f8r den krediterer, er den som er best rustet.<\/p>

    Bunnlinjen<\/h2>

    EIP-7702 gjorde den kjedeligste tingen en b\u00f8rs eier, innskuddsadressen, til noe som kan handle p\u00e5 egen h\u00e5nd. Det er ikke en katastrofe, men det er slutten p\u00e5 en bekvem antakelse. Systemene som klarer overgangen best, gj\u00f8r tre ting: de leser koden p\u00e5 en adresse f\u00f8r de krediterer eller feier, de hvitlister kontrakter i begge retninger, og de behandler en kapret n\u00f8kkel som tapt i stedet for \u00e5 stole p\u00e5 tilbakekalling. Den \u00e5pne ckETH-koden viser at dette er praktisk gjennomf\u00f8rbart i stor skala, og at gevinsten (f\u00e6rre autorisasjoner, sparte gass, tryggere feiing) er reell. Men det svakeste leddet er fortsatt mennesket foran signeringsskjermen som klikker \u00abgodkjenn\u00bb uten \u00e5 lese. Ingen protokolloppgradering fikser det. B\u00e5de b\u00f8rsen som krediterer og brukeren som signerer m\u00e5 l\u00e6re seg \u00e5 lese hva en adresse faktisk er, f\u00f8r pengene beveger seg. For hvordan drenering ser ut fra offerets side, er DeFi rug pull i 2026<\/a> en nyttig p\u00e5minnelse om hvem som ender som utgangslikviditet.<\/p>

    Ofte stilte sp\u00f8rsm\u00e5l<\/h2>

    Kan en b\u00f8rs se om innskuddsadressen min er en smartkonto?<\/h3>

    Ja. En 7702-delegering ligger som 23 byte kode p\u00e5 adressen, prefikset 0xef0100 pluss kontraktsadressen den peker p\u00e5. En b\u00f8rs kan lese de f\u00f8rste bytene av koden med et enkelt kall, gjerne hundrevis av adresser i \u00e9n foresp\u00f8rsel, slik den \u00e5pne ckETH-koden fra dfinity gj\u00f8r f\u00f8r den feier.<\/p>

    Er det trygt \u00e5 bruke EIP-7702 p\u00e5 en adresse jeg sender innskudd fra?<\/h3>

    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\u00e5, hold store bel\u00f8p p\u00e5 en adresse uten delegering, og signer p\u00e5 en maskinvarelommebok med clear signing.<\/p>

    Hva skjer hvis innskuddsadressen min allerede er delegert til en sweeper?<\/h3>

    Da kan en ondsinnet kontrakt t\u00f8mme bel\u00f8pet i samme blokk som det lander. \u00c5 tilbakekalle delegeringen hjelper ikke hvis privatn\u00f8kkelen allerede er kompromittert; du m\u00e5 flytte til en helt ny lommebok med en fersk n\u00f8kkel, slik Relay og flere forvarere anbefaler.<\/p>

    Regulerer Finanstilsynet min egen smartkonto?<\/h3>

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

    Erstatter native account abstraction EIP-7702?<\/h3>

    Ikke med det f\u00f8rste. Ethereum og Base ga 15. september 2026 opp fors\u00f8ket p\u00e5 \u00e5 samle seg om \u00e9n native standard, s\u00e5 EIP-8141 og EIP-8130 g\u00e5r hver sin vei. Inntil videre er 7702 og designatoren 0xef0100 fellesnevneren b\u00f8rser og forvarere m\u00e5 h\u00e5ndtere.<\/p>