{"id":211,"date":"2026-08-11T13:10:38","date_gmt":"2026-08-11T13:10:38","guid":{"rendered":"https:\/\/hoge.gg\/no\/eip-7702-lommebok-smartkonto-2026\/"},"modified":"2026-08-11T13:10:38","modified_gmt":"2026-08-11T13:10:38","slug":"eip-7702-lommebok-smartkonto-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/eip-7702-lommebok-smartkonto-2026\/","title":{"rendered":"EIP-7702 i 2026: da lommeboken din ble en smartkonto"},"content":{"rendered":"

Den stille oppgraderingen som gjorde lommeboken din smart<\/h2>

Da Ethereum rullet ut Pectra-oppgraderingen 7. mai 2025, handlet de fleste overskriftene om validatorer, staking og blob-kapasitet. Endringen som til slutt kom til \u00e5 ber\u00f8re flest vanlige brukere, gjemte seg bak et sperrete navn: EIP-7702. P\u00e5 under ett \u00e5r har forslaget gjort den helt ordin\u00e6re Ethereum-lommeboken om fra en passiv n\u00f8kkel til noe som kan opptre som en smartkontrakt, med samlede transaksjoner, betaling av gass i stablecoin og innebygd kontogjenoppretting innen rekkevidde for adresser som allerede eksisterer.<\/p>

Den samme mekanismen ga svindlerne et nytt verkt\u00f8y nesten umiddelbart. I ukene etter oppgraderingen fant analyseselskapet Wintermute<\/a> at over 97 prosent av de tidligste delegeringene pekte mot gjenbrukt, ondsinnet kode. L\u00e6rdommen tegnet seg raskt: en smartkonto er bare s\u00e5 trygg som signaturen du gir den.<\/p>

Denne gjennomgangen tar for seg hva EIP-7702 faktisk er, hvordan set-code-transaksjonen fungerer helt ned p\u00e5 byte-niv\u00e5, hvor stor adopsjonen har blitt, hvorfor \u00abCrimeEnjoyor\u00bb ble et begrep i bransjen, og hva alt dette betyr for deg som forvalter dine egne n\u00f8kler i et marked der Finanstilsynet n\u00e5 f\u00f8rer tilsyn med kryptob\u00f8rser, men verken kan eller skal f\u00f8re tilsyn med lommeboken p\u00e5 telefonen din.<\/p>

Bakteppet er at Ethereum lenge har levd med en todelt virkelighet. Avanserte brukere, DAO-er og selskaper tok i bruk smartkontrakt-lommeb\u00f8ker med multisig, utgiftstak og gjenoppretting, mens vanlige folk satt igjen med en enkel privatn\u00f8kkel og alle farene som f\u00f8lger med den: mister du den, mister du alt, og signerer du feil, finnes det ingen angreknapp. EIP-7702 er fors\u00f8ket p\u00e5 \u00e5 tette det gapet uten \u00e5 be hundrevis av millioner mennesker om \u00e5 opprette en ny konto.<\/p>

Nettopp derfor er dette en av de mest konsekvensrike endringene for vanlige lommeb\u00f8ker p\u00e5 flere \u00e5r. Den ber\u00f8rer ikke bare teknologer, men alle som en gang har klikket \u00abbekreft\u00bb i en lommebok uten helt \u00e5 vite hva som skjedde. \u00c5 forst\u00e5 hvordan mekanismen virker, er derfor ingen akademisk \u00f8velse; det er praktisk selvforsvar i et marked der ansvaret til slutt ligger hos deg.<\/p>

Hva EIP-7702 egentlig er<\/h2>

Ethereum har historisk hatt to kontotyper. Den ene er den eksternt eide kontoen (EOA), som styres av en privatn\u00f8kkel og ikke inneholder programkode. Den andre er kontraktskontoen, som inneholder kode, men ikke har noen n\u00f8kkel og bare kan handle n\u00e5r noen kaller p\u00e5 den. Nesten alle vanlige brukere har en EOA: det er adressen du f\u00e5r n\u00e5r du oppretter en lommebok i MetaMask, Rabby eller Phantom.<\/p>

I over et ti\u00e5r var dette skillet en kilde til friksjon. Smartkontrakt-lommeb\u00f8ker fantes, men de krevde at du opprettet en ny adresse, flyttet midlene dine dit og betalte for \u00e5 ta i bruk kontrakten. De aller fleste valgte derfor den enkle EOA-en og levde med begrensningene: \u00e9n handling per signatur, ingen utgiftstak, ingen gjenoppretting hvis n\u00f8kkelen forsvant.<\/p>

EIP-7702, som offisielt heter \u00abSet EOA account code\u00bb, visker ut skillet. Forslaget lar en EOA peke mot koden til en kontrakt og kj\u00f8re den som om koden var dens egen, samtidig som adressen, saldoen, historikken og transaksjonstelleren (nonce) beholdes. Delegeringen er reversibel: du kan sl\u00e5 den av igjen, og du kan bytte hvilken kontrakt kontoen peker mot. Resultatet er at hele Ethereums installerte base av EOA-er, hundrevis av millioner adresser, kan oppgraderes der de st\u00e5r. Du trenger ikke overtale brukerne til \u00e5 opprette en ny konto; du trenger bare \u00e9n signatur.<\/p>

En vanlig misforst\u00e5else er at kontoen bare blir en smartkonto \u00abfor \u00e9n transaksjon\u00bb. Det stemmer for selve set-code-transaksjonen, men delegeringen som skrives inn i kodefeltet blir st\u00e5ende helt til du aktivt endrer eller fjerner den. Med andre ord kan kontoen din v\u00e6re en smartkonto p\u00e5 ubestemt tid, og det er b\u00e5de styrken og faren ved mekanismen. Den som forst\u00e5r dette, skj\u00f8nner ogs\u00e5 hvorfor en enkelt uforsiktig signatur kan f\u00e5 varige f\u00f8lger, og hvorfor det \u00e5 kunne nullstille en delegering er like viktig som \u00e5 kunne opprette den.<\/p>

Fra EIP-3074 til Pectra: en kort forhistorie<\/h2>

Ideen om \u00e5 gi EOA-er superkrefter er ikke ny. Et tidligere forslag, EIP-3074, ville innf\u00f8rt to nye opkoder (AUTH og AUTHCALL) som lot en egen kontrakt handle p\u00e5 vegne av en konto. Kritikerne mente l\u00f8sningen var for inngripende og trakk i feil retning i forhold til Ethereums langsiktige m\u00e5l om innebygd account abstraction. Forslaget ble til slutt lagt til side.<\/p>

I mai 2024 la Vitalik Buterin, Sam Wilson, Ansgar Dietrichs og utvikleren kjent som lightclient<\/a> frem EIP-7702 som et lettere alternativ. Det innf\u00f8rte ingen nye opkoder, holdt seg forenlig med det langsiktige veikartet for account abstraction, og gjenbrukte mekanikk som allerede fantes. Forslaget n\u00e5dde status som \u00abFinal\u00bb i standardsporet og ble aktivert p\u00e5 Ethereums hovednett i Pectra-oppgraderingen 7. mai 2025<\/a>, en av de mest omfattende oppdateringene i nettverkets historie med elleve EIP-er samlet i \u00e9n utrulling.<\/p>

Selv arkitektene bak var forsiktige. Marius van der Wijden, kjerneutvikler i Ethereum, omtalte tidlig 7702 som umodent og understreket overfor DL News<\/a> at det var \u00abet veldig tidlig forslag, s\u00e5 vi m\u00e5 vurdere alle de skarpe kantene\u00bb. Den advarselen skulle vise seg profetisk.<\/p>

Valget av en lettvektsl\u00f8sning var bevisst. Der EIP-3074 ville ha bygget et helt nytt tillitsforhold mellom kontoer og s\u00e5kalte invokers, gjenbrukte 7702 den samme signaturmekanikken brukerne allerede kjente fra vanlige transaksjoner. Det gjorde forslaget enklere \u00e5 revidere, enklere \u00e5 rulle ut sammen med resten av Pectra, og lettere \u00e5 forene med det langsiktige m\u00e5let om at account abstraction til slutt skal bakes rett inn i protokollen. Prisen var at mye av ansvaret for \u00e5 bruke kraften trygt ble flyttet over p\u00e5 lommeb\u00f8kene og brukerne selv.<\/p>

Anatomien til en set-code-transaksjon<\/h2>

Under panseret innf\u00f8rer EIP-7702 en ny transaksjonstype med kode 0x04, kjent som SET_CODE_TX_TYPE. Det som skiller den fra en vanlig overf\u00f8ring, er et felt kalt authorization_list: en liste med \u00e9n eller flere fullmakter, hver formet som tuppelen [chain_id, address, nonce, y_parity, r, s]. Hver fullmakt er en egen signatur som i praksis sier at kontoen min skal peke mot denne kontrakten.<\/p>

Signaturen dekker meldingen keccak(0x05 || rlp(chain_id, address, nonce)). Byten 0x05, kalt MAGIC, s\u00f8rger for at en 7702-fullmakt aldri kan forveksles med en ordin\u00e6r transaksjonssignatur. N\u00e5r fullmakten godtas, skriver nettverket en delegeringsmark\u00f8r inn i kontoens kodefelt: de tre bytene 0xef0100 etterfulgt av den 20 byte lange adressen til m\u00e5lkontrakten, 23 byte til sammen. Fra da av ser enhver som sl\u00e5r opp adressen i en block explorer at den peker mot en bestemt kontrakt.<\/p>

To detaljer er verdt \u00e5 merke seg. For det f\u00f8rste nullstilles en delegering ved \u00e5 signere en ny fullmakt til nulladressen; da blir kontoen en ren EOA igjen. For det andre kan chain_id settes til 0, noe som gj\u00f8r fullmakten gyldig p\u00e5 alle kjeder samtidig. Det er bekvemt for utviklere, men \u00e5pner for at en signatur gjenbrukes (replay) p\u00e5 et nettverk du ikke hadde tenkt p\u00e5.<\/p>

I praksis skjer det slik: lommeboken din lager en fullmakt som peker mot en implementasjonskontrakt, du signerer den, og fullmakten legges enten inn i din egen transaksjon eller sendes av en annen part som betaler gassen. N\u00e5r blokken bekreftes, f\u00e5r adressen din delegeringsmark\u00f8ren, og fra da av kj\u00f8rer kontoen logikken i den kontrakten hver gang den kalles. Det hele er offentlig og etterpr\u00f8vbart i en block explorer, og det er faktisk en fordel: du kan n\u00e5r som helst kontrollere n\u00f8yaktig hvilken kontrakt kontoen din peker mot, og reagere hvis det er noe du ikke kjenner igjen.<\/p>

Denne \u00e5penheten er en av grunnene til at 7702 regnes som et fornuftig kompromiss. Ingenting skjuler seg: mark\u00f8ren 0xef0100 er en klar, standardisert m\u00e5te \u00e5 signalisere at en konto har delegert kode, og verkt\u00f8y som lommeb\u00f8ker og explorers kan advare deg hvis en adresse plutselig peker mot noe kjent ondsinnet. Problemet oppst\u00e5r ikke fordi delegeringen er hemmelig, men fordi mange brukere ikke vet at de b\u00f8r se etter den.<\/p>

Komponent<\/th>Verdi eller format<\/th>Funksjon<\/th><\/tr><\/thead>
Transaksjonstype<\/td>0x04 (SET_CODE_TX_TYPE)<\/td>Ny transaksjonstype innf\u00f8rt i Pectra<\/td><\/tr>
authorization_list<\/td>Tupler [chain_id, address, nonce, y_parity, r, s]<\/td>\u00c9n eller flere signerte fullmakter i samme transaksjon<\/td><\/tr>
Signert melding<\/td>keccak(0x05 || rlp(chain_id, address, nonce))<\/td>Byten 0x05 (MAGIC) skiller fullmakten fra vanlige signaturer<\/td><\/tr>
Delegeringsmark\u00f8r<\/td>0xef0100 + 20 byte adresse (23 byte)<\/td>Skrives inn i kontoens kodefelt og peker mot kontrakten<\/td><\/tr>
Nullstilling<\/td>Fullmakt til nulladressen<\/td>Fjerner delegeringen; kontoen blir en ren EOA igjen<\/td><\/tr>
chain_id = 0<\/td>Gyldig p\u00e5 alle kjeder<\/td>Bekvemt, men \u00e5pner for replay p\u00e5 tvers av nettverk<\/td><\/tr><\/tbody><\/table><\/figure>

EIP-7702 og ERC-4337: samarbeid, ikke konkurranse<\/h2>

Det er lett \u00e5 tro at EIP-7702 erstatter ERC-4337, den eldre standarden for account abstraction. Det gj\u00f8r den ikke. ERC-4337, som ble endelig i mars 2023, bygde et parallelt system opp\u00e5 Ethereum: brukerne sender \u00abUserOperations\u00bb til en egen mempool, \u00abbundlere\u00bb pakker dem sammen, og en felles EntryPoint-kontrakt utf\u00f8rer dem, alt uten \u00e5 endre selve protokollen. Ulempen var at man m\u00e5tte ta i bruk en helt ny smartkontrakt-lommebok p\u00e5 en ny adresse.<\/p>

7702 fyller nettopp dette hullet ved \u00e5 la din eksisterende adresse koble seg p\u00e5 4337-verdenen uten \u00e5 flytte midlene. De to standardene er i ferd med \u00e5 smelte sammen: nyere versjoner av EntryPoint-kontrakten har lagt til innebygd st\u00f8tte for 7702, blant annet gjennom en referansekonto kalt Simple7702Account. Alex Jupiter, senior produktsjef i MetaMask, beskrev overfor DL News 7702 som veien mot \u00abett samlet veikart for account abstraction\u00bb, en str\u00f8mlinjeformet m\u00e5te \u00e5 ta i bruk alle funksjonene uten risikoen som l\u00e5 i EIP-3074.<\/p>

For en dypere gjennomgang av hvordan smartkontoer fungerer i praksis, har vi tidligere sett p\u00e5 hvordan account abstraction tar over i 2026<\/a>. Poenget her er at 7702 er broen: den kobler dagens lommeb\u00f8ker til morgendagens arkitektur uten \u00e5 tvinge noen til \u00e5 begynne p\u00e5 nytt.<\/p>

I praksis betyr sammensmeltingen at infrastrukturen fra 4337, alts\u00e5 bundlere som pakker transaksjoner og paymastere som dekker gass, n\u00e5 ogs\u00e5 kan betjene helt vanlige adresser. En bruker med en 7702-oppgradert EOA kan dermed nyte godt av sponset gass og batching uten \u00e5 vite eller bry seg om at det er ERC-4337-maskineri under panseret. For utviklere er gevinsten at de kan bygge for ett samlet \u00f8kosystem i stedet for to atskilte verdener, og for brukeren forsvinner mye av det tekniske sjargonget som lenge har skremt nykommere bort.<\/p>

Hva smartkontoen faktisk kan gj\u00f8re for deg<\/h2>

Den mest umiddelbare gevinsten er batching, alts\u00e5 \u00e5 sl\u00e5 sammen flere handlinger til \u00e9n transaksjon og \u00e9n signatur. Der du f\u00f8r m\u00e5tte godkjenne en token og deretter bytte den i to separate steg, kan begge n\u00e5 skje i samme signatur. Det sparer tid, reduserer antall bekreftelser, og fjerner en klassisk felle der en \u00e5pen \u00abapprove\u00bb blir liggende p\u00e5 ubestemt tid.<\/p>

Nesten like viktig er gassbetaling i stablecoin. Med en paymaster kan noen andre dekke gassen, eller du kan betale den i USDC i stedet for ETH. Circle Paymaster<\/a> st\u00f8tter b\u00e5de 4337-kontoer og EOA-er som f\u00f8lger EIP-7702, er live p\u00e5 Arbitrum og Base, og tar et p\u00e5slag p\u00e5 rundt 10 prosent for tjenesten. For en ny bruker betyr det at man kan gjennomf\u00f8re sin f\u00f8rste transaksjon uten f\u00f8rst \u00e5 m\u00e5tte skaffe ETH til gass, et av de seigeste hindrene i kryptoonboarding.<\/p>

Videre \u00e5pner 7702 for \u00f8ktn\u00f8kler (session keys) med tidsavgrensede fullmakter, utgiftstak, og sosial gjenoppretting der betrodde kontakter kan hjelpe deg tilbake inn hvis du mister tilgangen. Et konkret eksempel: en spillbruker kan gi et spill lov til \u00e5 utf\u00f8re mange sm\u00e5 transaksjoner i en time uten \u00e5 m\u00e5tte signere hver eneste \u00e9n, mens en hardkodet grense hindrer at kontoen t\u00f8mmes hvis noe g\u00e5r galt. Mange av disse grepene handler like mye om brukeropplevelse som om sikkerhet, et tema vi har utforsket i gjennomgangen av passkeys, gassfrihet og usynlige kjeder<\/a>.<\/p>

Listen over bruksomr\u00e5der vokser etter hvert som lommeb\u00f8kene modnes. Automatiske betalinger og abonnementer blir mulig n\u00e5r en kontrakt kan f\u00e5 lov til \u00e5 trekke et fast bel\u00f8p innenfor klare grenser. Bedrifter kan sette regler for hvem som f\u00e5r godkjenne hva, og spillutviklere kan gj\u00f8re kjedelogikken usynlig for spilleren. Fellesnevneren er at kompleksiteten flyttes fra brukeren og inn i koden, s\u00e5 lenge koden er til \u00e5 stole p\u00e5. Det siste forbeholdet er ingen detalj, men selve kjernen i sikkerhetsdiskusjonen som f\u00f8lger.<\/p>

Adopsjonen i tall<\/h2>

Adopsjonen har v\u00e6rt rask. If\u00f8lge datatjenesten BundleBear<\/a> var det per 11. august 2026 registrert rundt 218,5 millioner kumulative fullmakter, rundt 46,6 millioner aktive delegerte smartkontoer og over 90,8 millioner set-code-transaksjoner p\u00e5 tvers av nettverkene. Tallene har kr\u00f8pet jevnt oppover gjennom hele \u00e5ret, et tegn p\u00e5 at delegering har g\u00e5tt fra eksperiment til daglig rutine for mange lommeb\u00f8ker.<\/p>

P\u00e5 lommeboksiden var Ambire f\u00f8rst ute med \u00e5 ta i bruk 7702. Siden har MetaMask lansert sine Smart Accounts, mens Rabby, Trust Wallet, TokenPocket og multisig-rammeverket Safe alle har lagt til st\u00f8tte. P\u00e5 b\u00f8rssiden har blant andre OKX Wallet og WhiteBIT integrert standarden; tidlige Dune-tall pekte p\u00e5 WhiteBIT som en av de st\u00f8rste kildene til delegeringer. Hvilken lommebok som passer best avhenger av hva du vektlegger, noe vi har brutt ned i sammenligningen av MetaMask, Phantom og Rabby<\/a>.<\/p>

Tallene b\u00f8r leses med et forbehold: \u00e9n person kan st\u00e5 bak mange adresser, og en aktiv delegering betyr ikke n\u00f8dvendigvis en aktiv bruker. Likevel er retningen tydelig. Mye av veksten skjer p\u00e5 Layer 2-nettverk som Arbitrum og Base, der lav gasskostnad gj\u00f8r det billig \u00e5 eksperimentere med smartkonto-funksjoner. At store lommeb\u00f8ker og b\u00f8rser har rullet ut st\u00f8tte i samme periode, tyder p\u00e5 at 7702 er i ferd med \u00e5 bli en forventet standardfunksjon snarere enn en nisje for spesielt interesserte.<\/p>

Akt\u00f8r<\/th>Kategori<\/th>Merknad<\/th><\/tr><\/thead>
Ambire<\/td>Lommebok<\/td>Regnes som f\u00f8rst ute med 7702-delegering<\/td><\/tr>
MetaMask Smart Accounts<\/td>Lommebok<\/td>7702-vei for et av de st\u00f8rste brukergrunnlagene<\/td><\/tr>
Rabby<\/td>Lommebok<\/td>Kjent for transaksjonssimulering f\u00f8r signering<\/td><\/tr>
Trust Wallet og TokenPocket<\/td>Lommebok<\/td>Mobil-f\u00f8rst-integrasjoner<\/td><\/tr>
Safe<\/td>Smartkonto-rammeverk<\/td>Kombinerer multisig med modulstandarder<\/td><\/tr>
OKX Wallet<\/td>B\u00f8rs-lommebok<\/td>Blant de tidlige integrasjonene<\/td><\/tr>
WhiteBIT<\/td>B\u00f8rs<\/td>H\u00f8yt antall delegeringer i tidlige Dune-tall<\/td><\/tr><\/tbody><\/table><\/figure>

Hva 7702 betyr for b\u00f8rser og forvaring<\/h2>

For b\u00f8rsene g\u00e5r skillet mellom depot (custodial) og selvforvaring rett gjennom hvor relevant 7702 er. P\u00e5 en tradisjonell b\u00f8rskonto er det b\u00f8rsen som holder n\u00f8klene, og der endrer standarden lite for sluttbrukeren. Det interessante skjer i b\u00f8rsenes egne ikke-depotbaserte lommeb\u00f8ker, som OKX Wallet og WhiteBIT, der brukeren styrer n\u00f8klene selv og 7702 kan brukes til \u00e5 gj\u00f8re uttak, bytter og godkjenninger til \u00e9n s\u00f8ml\u00f8s operasjon.<\/p>

For selskaper og DAO-er som forvalter felles midler, peker mye i retning av multisig-rammeverk som Safe, der 7702 og modulstandarder kombineres med krav om flere signaturer. Det gir smartkonto-fleksibilitet uten \u00e5 gi fra seg kontrollen til \u00e9n enkelt n\u00f8kkel. Samtidig reiser sammensmeltingen av EOA-er og kontraktslogikk nye sp\u00f8rsm\u00e5l om hvem som er ansvarlig n\u00e5r noe g\u00e5r galt, sp\u00f8rsm\u00e5l revisjonsbransjen fortsatt jobber med \u00e5 besvare.<\/p>

Konsekvensen er at grensen mellom \u00abb\u00f8rs\u00bb og \u00ablommebok\u00bb blir mer flytende. En bruker kan begynne p\u00e5 en b\u00f8rs, flytte til b\u00f8rsens egen selvforvaltede lommebok, og der ta i bruk de samme smartkonto-funksjonene som en frittst\u00e5ende app tilbyr. For norske brukere gj\u00f8r det sp\u00f8rsm\u00e5let om hvem som egentlig holder n\u00f8klene, viktigere enn noen gang, for det er nettopp dette skillet som avgj\u00f8r hvem som b\u00e6rer ansvaret hvis noe g\u00e5r galt.<\/p>

CrimeEnjoyor: da 97 prosent av delegeringene var feller<\/h2>

Skyggesiden viste seg fort. I en analyse gjengitt av CoinDesk 2. juni 2025<\/a> fant Wintermute at over 97 prosent av de tidligste 7702-delegeringene pekte mot den samme, gjenbrukte byte-koden. Fordi kildekoden inneholdt ordet som en sp\u00f8k, fikk kontrakten kallenavnet \u00abCrimeEnjoyor\u00bb. Rundt 2,88 ETH ble brukt til \u00e5 sette opp fullmakter for omtrent 79 000 adresser, og \u00e9n enkelt adresse h\u00e5ndterte over 52 000 av dem.<\/p>

Wintermute beskrev kontraktene som \u00absweepere\u00bb: kode som automatisk t\u00f8mmer innkommende ETH fra allerede kompromitterte adresser. Det er den avgj\u00f8rende nyansen. CrimeEnjoyor var ikke et angrep p\u00e5 EIP-7702 i seg selv, og det utnyttet ingen feil i standarden. Delegeringene ble satt opp av angripere som allerede hadde ofrenes privatn\u00f8kler, typisk etter en tidligere lekkasje. 7702 gjorde bare t\u00f8mmingen mer effektiv for lommeb\u00f8ker som uansett var tapt.<\/p>

Enda mer talende: kampanjen var ikke engang l\u00f8nnsom. Wintermute fant at den stj\u00e5lne ETH-en i praksis ikke fl\u00f8t videre til angripernes m\u00e5ladresser, fordi de kompromitterte kontoene stort sett allerede var tomme. Konklusjonen fra selskapet var at selve standarden ikke var feilkonstruert, den ble bare umiddelbart vevd inn i eksisterende svindelinfrastruktur.<\/p>

L\u00e6rdommen fra CrimeEnjoyor er likevel ubehagelig tydelig. Idet en ny mekanisme blir tilgjengelig, tester svindlerne den f\u00f8r de fleste vanlige brukere i det hele tatt har h\u00f8rt om den. At de tidlige kampanjene bommet \u00f8konomisk, er en mager tr\u00f8st; det viste bare at angriperne fortsatt lette etter oppskriften. De p\u00e5f\u00f8lgende, langt mer m\u00e5lrettede phishing-angrepene beviste at de til slutt fant den, og at ofrene denne gangen hadde penger \u00e5 tape.<\/p>

Blind signering og drainer-\u00f8konomien<\/h2>

Der CrimeEnjoyor rammet allerede tapte lommeb\u00f8ker, dukket det snart opp angrep mot brukere som fortsatt hadde kontroll. I august 2025 dokumenterte sikkerhetsselskapet Scam Sniffer, gjengitt av Cryptopolitan<\/a>, at et enkelt offer tapte verdier for over 1,54 millioner dollar (i wstETH, cbBTC og NFT-er) etter \u00e5 ha signert \u00e9n ondsinnet EIP-7702-batchtransaksjon. Etablerte drainer-operasjoner som Inferno Drainer og Pink Drainer tilpasset seg raskt og bygde standardens prinsipp om at \u00e9n fullmakt gir varige rettigheter, inn i verkt\u00f8yene sine.<\/p>

Kjernen i problemet er blind signering. En batch-signatur kan se rutinemessig ut i lommeboken, mens den i virkeligheten delegerer hele kontoen din til angriperens kode. Idet du godkjenner, kan kontoen t\u00f8mmes nesten momentant. Fordi delegeringen best\u00e5r til den aktivt nullstilles, holder det med ett \u00f8yeblikks uoppmerksomhet.<\/p>

M\u00f8nsteret er velkjent fra andre deler av kryptomarkedet, der tekniske nyvinninger og svindel utvikler seg i takt. Vi har sett den samme dynamikken i det rettslige etterspillet etter rug pull-svindelen i DeFi<\/a>: verkt\u00f8yene endrer seg, men den menneskelige svakheten angriperne utnytter, forblir den samme.<\/p>

Hvordan kjenner man igjen en farlig batch? Faresignalene er ofte de samme: en tilsynelatende uskyldig handling som plutselig ber om en signatur du ikke forventet, en nettside som haster deg gjennom bekreftelsen, eller en foresp\u00f8rsel der lommeboken viser en r\u00e5 kontraktsadresse i stedet for en tydelig beskrivelse av hva som skjer. Regelen er enkel, om enn vanskelig \u00e5 f\u00f8lge n\u00e5r man har det travelt: signerer du noe du ikke forst\u00e5r, signerer du blindt, og da har du i praksis allerede gitt fra deg kontrollen over kontoen.<\/p>

Gode lommeb\u00f8ker hjelper til her ved \u00e5 oversette den r\u00e5 transaksjonen til lesbar tekst, vise hvilken kontrakt du er i ferd med \u00e5 delegere til, og advare hvis adressen st\u00e5r p\u00e5 en svarteliste. Men verkt\u00f8yene er en hjelp, ikke en garanti. Den siste forsvarslinjen er alltid deg selv, i det sekundet du velger mellom \u00e5 lese n\u00f8ye eller bare trykke videre.<\/p>

Det revisorene ser etter<\/h2>

For sikkerhetsrevisorer som SlowMist og Fireblocks har EIP-7702 skapt en ny sjekkliste. Den mest subtile risikoen er lagringskollisjon: siden den delegerte koden opererer i EOA-ens egne lagringsplasser, kan to ulike implementasjoner skrive over hverandres data hvis de ikke er n\u00f8ye adskilt. L\u00f8sningen er navngitt lagring etter standarden ERC-7201, som gir hver modul sitt eget omr\u00e5de.<\/p>

Videre finnes det ingen constructor eller initcode i en 7702-delegering, slik en vanlig kontrakt har. Oppsettet m\u00e5 derfor ofte gj\u00f8res i et eget kall, som i verste fall kan kapres av en angriper f\u00f8r den legitime brukeren rekker det (front-running). Legg til replay-risikoen ved chain_id lik 0 og den allestedsn\u00e6rv\u00e6rende faren for blind signering, og man forst\u00e5r hvorfor grundige revisjoner og bug bounties er blitt et eget sikkerhetslag i bransjen. Vi har sett n\u00e6rmere p\u00e5 hva slike programmer faktisk betaler i gjennomgangen av bug bounty-utbetalinger i 2026<\/a>.<\/p>

Poenget er ikke at 7702-kontrakter er spesielt usikre, men at de flytter angrepsflaten. En feil i en delt implementasjonskontrakt kan i prinsippet ramme alle adressene som delegerer til den samtidig, p\u00e5 samme m\u00e5te som en s\u00e5rbarhet i et popul\u00e6rt kodebibliotek rammer alt som bruker det. Derfor legger seri\u00f8se team vekt p\u00e5 formell verifisering, gradvis utrulling og \u00e5pen kildekode som mange \u00f8yne kan granske f\u00f8r pengene str\u00f8mmer inn.<\/p>

Risiko<\/th>Hva som kan skje<\/th>Mottiltak<\/th><\/tr><\/thead>
Lagringskollisjon<\/td>Delegert kode deler kontoens lagringsplasser og kan overskrive data<\/td>Navngitt lagring etter ERC-7201<\/td><\/tr>
Front-running ved oppsett<\/td>Uten constructor kan et separat init-kall kapres<\/td>Atomisk oppsett i samme transaksjon<\/td><\/tr>
Replay via chain_id = 0<\/td>En fullmakt gjenbrukes p\u00e5 en kjede den ikke var ment for<\/td>Sett en eksplisitt chain_id<\/td><\/tr>
Blind signering<\/td>Brukeren ser ikke at signaturen delegerer kontoen til angriperens kode<\/td>Clear signing (ERC-7730) og simulering<\/td><\/tr><\/tbody><\/table><\/figure>

Slik beskytter du deg: en praktisk sjekkliste<\/h2>

Det gode er at de fleste 7702-fellene kan unng\u00e5s med noen enkle vaner. Det handler mindre om teknisk kompetanse enn om \u00e5 bremse ned og lese hva du signerer.<\/p>