EIP-7702 i 2026: fragmenteringen ingen fikser ennå

Da Pectra slo på EIP-7702 i mai 2025, ble det solgt som en bro. En midlertidig måte å gi vanlige Ethereum-kontoer krefter fra smartkontrakter på, helt til protokollen selv kunne gjøre jobben. Snart halvannet år senere, i september 2026, står broen fortsatt, mens målet på andre siden flytter seg.

Denne måneden skjedde to ting samtidig. Base flyttet stille sitt forslag om native account abstraction, EIP-8130, ut av Cobalt-oppgraderingen og over i en senere oppgradering som ennå ikke har noen dato. Og Ethereum-stiftelsen startet testnettet Platåberget, oppkalt etter fjellplatået over Longyearbyen, for å prøve ut Glamsterdam: en oppgradering hvis hovedpunkter handler om blokkproduksjon, ikke om kontoer. Imellom brukte utviklerne, Vitalik Buterin inkludert, tid på et mer ubehagelig spørsmål. Vil native account abstraction faktisk fjerne fragmenteringen av lommeboken, eller bare flytte den et nytt sted?

For en norsk eier med ETH i MetaMask, Rabby eller OKX Wallet er dette ikke akademisk. Valgene som tas nå, avgjør om kontoen din følger deg rent på tvers av kjeder og apper, eller om du ender låst til én lommeboks versjon av «smart». ETH handles rundt 2 500 dollar, om lag 23 300 kroner med en dollarkurs nær 9,3 (CoinDesk), mens millioner av kontoer allerede bærer en 7702-delegering. Her er situasjonen, hva som endret seg i september, og hva det betyr for kontoen du faktisk kontrollerer.

Kort oppsummert: hva EIP-7702 er, og hvorfor det vant

Ethereum har lenge hatt to slags kontoer. På den ene siden den vanlige adressen din, en externally owned account (EOA), styrt av én privatnøkkel: den kan bare signere og sende, én transaksjon om gangen. På den andre siden smartkontrakt-kontoen, som kan bære regler, men som historisk krevde at du satte opp en helt ny konto med en ny adresse. EIP-7702 fjerner det valget. Med en enkelt fullmakt kan den eksisterende EOA-en din peke på en smartkontrakt og oppføre seg som en smartkonto, uten at adressen, saldoen eller historikken endrer seg.

Forslaget kom fra Vitalik Buterin, Sam Wilson, Ansgar Dietrichs og Matt Garnett (lightclient) i mai 2024, som et lettere alternativ til det eldre EIP-3074. Det innførte ingen nye opkoder og var laget for å være kompatibelt med den langsiktige planen om native account abstraction. Grunnen til at 7702 «vant» i praksis er enkel: den krevde ingen migrering. En bruker med tre års historikk på samme adresse fikk batching, gass-abstraksjon og økt-nøkler uten å flytte en eneste token. Det eldre ERC-4337-sporet, som fungerer via et eget lag av UserOperations og bundlere, krevde derimot at du opprettet en ny kontrakt-konto. 7702 møtte folk der de allerede var, og adopsjonen fulgte.

7702 erstatter ikke 4337; de utfyller hverandre. EntryPoint-kontrakten som styrer 4337 fikk i versjon 0.8 innebygd støtte for 7702, slik at en oppgradert EOA kan gå inn i det samme økosystemet av bundlere og paymastere. Men for den vanlige eieren er 7702 den synlige endringen: den dagen lommeboken din spurte om lov til å «oppgradere» kontoen, var det som regel en 7702-fullmakt du godkjente.

Mekanikken i korte trekk

Under panseret er 7702 en ny transaksjonstype, 0x04, kalt SET_CODE_TX_TYPE. Den bærer en liste kalt authorization_list, der hvert element er en tuppel: [chain_id, address, nonce, y_parity, r, s]. Adressen er kontrakten kontoen din skal delegere til. Når transaksjonen bekreftes, legges det en delegeringspeker på kontoen din on-chain: bytene 0xef0100 etterfulgt av den 20-byte lange kontraktadressen, til sammen 23 byte. Fra da av kjører kontoen din kontraktens kode.

Det er verdt å forstå at delegeringspekeren er offentlig og lesbar. Enhver kan slå opp adressen din i en blokkutforsker og se de 23 bytene som avslører hvilken kontrakt kontoen din låner kode fra. Det er både styrken og svakheten: styrken fordi du kan verifisere hva du faktisk har godkjent, svakheten fordi en angriper like enkelt kan se hvilke kontoer som er delegert til en sårbar kontrakt. På infrastruktursiden fikk EntryPoint-kontrakten i ERC-4337 innebygd støtte for 7702 i versjon 0.8, med en referanseimplementasjon kalt Simple7702Account, slik at en oppgradert EOA kan bruke det etablerte laget av bundlere og paymastere uten å være en 4337-konto fra bunnen av.

Selve fullmakten signeres med et prefiks, MAGIC 0x05, slik at den ikke kan forveksles med en vanlig melding: den signerte meldingen er keccak av 0x05 sammen med rlp av chain_id, adresse og nonce. Du nullstiller kontoen ved å signere en ny fullmakt som peker til nulladressen; da blir kontoen en ren EOA igjen. Ett detaljert varsel er verdt å merke seg: setter du chain_id til 0, gjelder fullmakten på alle kjeder samtidig, noe som er bekvemt, men åpner for replay på tvers av nettverk. Tabellen under viser hva du faktisk ser, og hva hvert felt betyr.

Adopsjonen: hundrevis av millioner autorisasjoner, med ett forbehold

På overflaten ser tallene enorme ut. Sporingstjenesten BundleBear viser nær 246 millioner kumulative autorisasjoner, over 57 millioner aktive delegeringer og mer enn 103 millioner set-code-transaksjoner i midten av september 2026. Ambire var først ute; MetaMask Smart Accounts, Rabby, Trust Wallet og Safe fulgte, og på børssiden var OKX Wallet og WhiteBIT tidlig ute.

Forbeholdet er viktig, og det gjentas hver gang noen presenterer et rått autorisasjonstall som «vekst». En stor andel av autorisasjonene stammer ikke fra brukere som frivillig oppgraderer, men fra automatiserte sweepere som tømmer allerede kompromitterte kontoer. Handelsfirmaet Wintermute fant kort etter Pectra at over 97 prosent av de tidlige delegeringene pekte på gjenbrukt bytekode, den såkalte CrimeEnjoyor-koden; om lag 2,88 ETH var brukt til å autorisere rundt 79 000 adresser, og én kontrakt håndterte mer enn 52 000 (CoinDesk). De aktive delegeringene, tallet på vel 57 millioner, sier mer om reell bruk enn det kumulative tallet gjør. Poenget er ikke at 7702 er utrygt, men at det høye tallet delvis er støy. Behandle autorisasjonstallet som et gulv for oppmerksomhet, ikke et mål på suksess.

MetaMask, med over 30 millioner månedlige brukere, gjorde 7702 til den primære oppgraderingsveien for vanlige kontoer, og det alene forklarer en stor del av de aktive delegeringene. På børssiden er bildet mer forsiktig. En handelsplass som tar imot innskudd på adresser som kan være 7702-delegerte, må vurdere hva delegeringen gjør før den krediterer en konto, og flere store aktører har derfor innført screening av delegeringspekeren i innskuddsflyten. Resultatet er et tydelig skille: lommebøkene omfavnet 7702 raskt fordi det gir bedre brukeropplevelse, mens børsene beveget seg langsommere fordi de bærer den operative risikoen.

Fragmenteringen 7702 skapte i det stille

Her begynner den delen av historien som fikk mindre oppmerksomhet i 2025, men som utviklerne nå diskuterer åpent. Da lommebøker begynte å delegere brukernes EOA-er, endret oppførselen seg på måter appene ikke var forberedt på. Enkelte interaksjoner begynte å gå gjennom bunter (batches) i stedet for enkelttransaksjoner, og det forstyrret hendelsessporing, poengprogrammer og tilskrivning av data. En app som telte «antall swapper per adresse» for å dele ut poeng, kunne plutselig se flere handlinger samlet i én transaksjon, eller utført av en delegat-kontrakt heller enn av adressen selv. Mange brukere skjønte rett og slett ikke hva som endret seg da lommeboken spurte om å «oppgradere».

Dette er fragmentering av et subtilt slag. Den handler ikke om at du har fem lommebøker på fem kjeder, men om at samme adresse begynner å oppføre seg forskjellig avhengig av hvilken lommebok som satte delegeringen, hvilken kontrakt den peker på, og om appen forstår 7702 eller ikke. En delegering du satte i MetaMask peker på MetaMasks reviderte kontrakt; en du satte i Rabby peker på noe annet. Adressen er den samme, men «kontoen» er det ikke helt. For en bransje som lovet at account abstraction skulle gjøre alt enklere, er dette et ubehagelig funn: den første effekten var at ting ble mer uensartet, ikke mindre.

Fragmenteringsdebatten: samler native konto kaoset, eller flytter det bare?

Det store spørsmålet, slik det ble formulert i en bredt referert debatt blant AA-utviklere denne måneden, er dette: kommer native account abstraction faktisk til å løse fragmenteringen, eller kommer den bare til å flytte den (Etherspot-oppsummering)? Argumentene er verdt å ta på alvor, for de peker på en strukturell, ikke bare teknisk, utfordring.

Det første stridspunktet er økt-nøkler og samspill. En app kan gi deg en scoped tillatelse, for eksempel en 15-minutters økt som får lov til å bytte, men ikke overføre. Spørsmålet er om en slik tillatelse kan gis gjennom ett felles grensesnitt som fungerer på tvers av alle lommebøker, eller om hver lommebok låser implementeringen til sin egen variant. Skjer det siste, gjenskaper man akkurat den fragmenteringen native konto skulle fjerne, bare ett lag lenger opp. Det andre stridspunktet er at tillatelser fortsatt lever på app-laget. Selv om Ethereum får en delt standardkonto for EOA-er, vil den delte delen sannsynligvis bare dekke batching og gass-abstraksjon, ikke fulle tillatelser. Resten forblir opp til hver enkelt app og lommebok å definere.

Et konkret eksempel gjør poenget tydelig. Tenk deg et blokkjedespill som ber om en to-timers økt-nøkkel, slik at du slipper å godkjenne hver eneste handling mens du spiller. I dag defineres den økten av spillets egen integrasjon mot lommeboken du bruker. Bytter du lommebok, eller prøver det samme spillet på en annen kjede, er det ingen garanti for at økt-nøkkelen oppfører seg likt, eller i det hele tatt støttes. Det er fragmentering i praksis: en funksjon som føles sømløs så lenge du blir i ett økosystem, men som sprekker opp i det øyeblikket du krysser en grense standarden ikke dekker.

For en bruker som lurer på hvilken lommebok som er «riktig» i en slik verden, er dette mer enn teori. Valget av lommebok begynner å bestemme hvordan kontoen din faktisk kan oppføre seg, og et bytte er ikke gratis. Vi har sett nærmere på hva som skiller de store aktørene i gjennomgangen av hvilken smartkonto-lommebok du bør velge, og fragmenteringsdebatten gjør det valget viktigere, ikke mindre.

Vitalik og «én hovednøkkel for hele livet på kjeden»

Vitalik Buterin tok en tydelig posisjon i debatten. Ifølge referatet mener han at hver bruker bør ha nøyaktig én master recovery root, altså én hovednøkkel for hele livet sitt på kjeden, på tvers av Ethereum og alle lag-2. Resonnementet er at én godt sikret rot kan bygge på seg sosial gjenoppretting, tidslåser, multisig og zk-e-post, mens flere separate røtter i praksis pleier å ende opp dårlig beskyttet hver for seg. Det passer med den bredere retningen han staket ut i januar 2026, da han erklærte at året skulle brukes til å ta tilbake tapt terreng for selvråderett og tillitsminimering, blant annet gjennom lommebøker med sosial gjenoppretting og tidslåser som ikke gjør at du mister alt om du roter bort seed-frasen (The Block).

Motargumentet kom raskt, og det ble ikke avklart: én enkelt gjenopprettingsrot er også ett enkelt angrepspunkt. Samler du hele livet ditt under én rot, blir konsekvensen av at akkurat den kompromitteres tilsvarende total. Debatten endte uavgjort, og det er nettopp poenget. Ideen om «én konto for alt» er elegant, men den løser ikke fragmenteringen med mindre nøkkelhåndteringen forankres i selve protokollen, slik tilhengerne av native account abstraction argumenterer for; ellers forblir kontoen din bundet til en bestemt lommebok eller app.

Det ligger en dypere ambisjon under debatten. Buterin har lenge argumentert for at gjenoppretting og nøkkelrotasjon bør følge identiteten din, ikke den enkelte kjeden eller lommeboken; taper du en enhet, skal du kunne gjenopprette tilgang uten å være prisgitt en sentral aktør. En felles rot på tvers av Ethereum og lag-2 er tenkt som limet som gjør det mulig. Kritikken er ikke at målet er feil, men at veien dit legger mye makt i ett punkt, og at overgangen fra dagens virkelighet, der de fleste fortsatt har én seed-frase per lommebok, er alt annet enn triviell.

Lommeboken som tapsleder: når dårlig UX er et forretningsvalg

Det skarpeste argumentet i debatten var økonomisk, ikke teknisk. Flere utviklere påpekte at lommebøker i praksis fungerer som tapsledere: selve lommeboken er gratis, og pengene tjenes inn på swapper i appen og på ordreflyt. Det gir lommebøkene lite grunn til å la apper abstrahere dem bort. Konsekvensen, ifølge dette synet, er at dårlig brukeropplevelse ikke bare er et teknisk problem, men delvis et forretningsvalg: en lommebok som gjør seg selv utbyttbar, mister inntektskanalen sin.

Det er en ubehagelig, men nyttig linse. Den forklarer hvorfor konvergensen mot én felles standard går tregere enn ingeniørene skulle ønske, og hvorfor «bruk hvilken som helst app med hvilken som helst konto» fortsatt er mer et løfte enn en realitet. Den forklarer også hvorfor tilhengerne av native account abstraction insisterer på at nøkkelhåndterings-primitiver må ligge på protokollnivå. Legges de der, kan ikke en enkelt lommebok holde brukeren fanget, fordi kontoen ikke lenger tilhører lommeboken. Ligger de på app-laget, vinner insentivene som holder fragmenteringen i live.

Native account abstraction glapp igjen: EIP-8130 flyttet til Zenith

Så til det konkrete som skjedde i september. Base hadde lenge signalisert at native account abstraction, i form av EIP-8130, skulle lande på hovednettet med Cobalt-oppgraderingen «denne september». EIP-8130 er Coinbase- og Base-leirens forslag: kontoer settes opp via en on-chain konfigurasjon med faste nøkkeltyper (secp256k1, P-256, WebAuthn, BLS), transaksjoner sendes som vanlige transaksjoner uten bundlere eller relay, og kjeden validerer hver transaksjon mot konfigurasjonen. Ytelsestallene Base oppgir er reelle: en USDC-overføring faller fra 125 000 til 46 000 gass, rundt 63 prosent lavere, og transaksjonsstørrelsen krymper over 83 prosent (Base-dokumentasjonen).

Men landingen kom ikke. 8. september 2026 ble en pull request slått sammen i Base sitt kodelager som flyttet aktiveringen av EIP-8130 ut av Cobalt og over i en ny oppgradering kalt Zenith, på tvers av batch-validering, transaksjonspool, RPC og EVM-kjøring (base/base PR #4924). Zenith er bevisst satt til «None» på hovednett og Sepolia, altså kun devnet inntil noen faktisk planlegger den. Med andre ord: den september-landingen som mange ventet, inkluderte ikke native konto likevel. Base kan fortsatt sende Cobalt med andre funksjoner, men native account abstraction ble skjøvet til en fork uten dato. En tidligere gjennomgang hadde allerede notert at EIP-8130 forble eksperimentell på devnet; Zenith-flyttingen bekrefter det.

Det er verdt å merke seg hva EIP-8130 ville endret sammenlignet med 7702. Der 7702 legger lånt kode på en eksisterende EOA og fortsatt lener seg på ECDSA-nøkkelen din, lar 8130 kontoen konfigureres direkte i protokollen, med flere nøkkeltyper og uten avhengighet av bundlere eller et eget mempool. For brukeren ville forskjellen først og fremst merkes på pris og robusthet, ikke i det daglige. Men nettopp fordi 8130 er en dypere endring, er den også vanskeligere å rulle ut trygt, og det er en rimelig tolkning av hvorfor Base valgte å skille den ut i en egen fork heller enn å presse den gjennom Cobalt.

Dette er tredje gang på et halvt år at native AA på Base skyves. Mønsteret er tydelig: 7702 skulle være broen, men broen får stadig lengre levetid fordi den andre bredden ikke er ferdig. Det er ikke et tegn på at 7702 svikter, snarere tvert imot. Det betyr at delegeringen du har i dag, sannsynligvis er infrastrukturen du skal leve med et godt stykke inn i 2027.

Platåberget, Glamsterdam og gasstaket som forsvinner

På Ethereum selv gikk oppmerksomheten i august og september til Glamsterdam, den neste store harde forken etter Fusaka (som ble aktivert 3. desember 2025 med PeerDAS). Ethereum-stiftelsen åpnet et tidlig, offentlig testnett kalt Platåberget rundt 17. august, og forken til Glamsterdam skjedde der 20. august 2026 (EtherWorld). Testnettet skal kjøre i flere måneder slik at utviklere kan lete etter feil før forken når Sepolia, Hoodi og til slutt hovednettet. Navnet er, i tråd med Ethereums vane, hentet fra geografien: Platåberget er fjellplatået som ruver over Longyearbyen på Svalbard.

Det avgjørende for denne artikkelen er hva Glamsterdam faktisk inneholder, og hva den ikke inneholder. Hovedpunktene er enshrined proposer-builder separation (EIP-7732) og block-level access lists (EIP-7928), som flytter blokkbygging inn i protokollen og åpner for parallell kjøring. I tillegg kommer større grenser for kontraktstørrelse (EIP-7954 hever taket fra 24 til 64 KiB, og initcode fra 48 til 128 KiB) og et rammeverk for gass-reprising rettet mot et gulv på rundt 200 millioner gass. Account abstraction er derimot ikke en headliner i Glamsterdam. EIP-8141, forslaget om «frame-transaksjoner» som skal gi full native AA, ble skjøvet til status «Considered for Inclusion» som ikke-headliner, og pekes nå mot den påfølgende forken Hegotá, der FOCIL (EIP-7805) er utvalgt som konsensus-headliner. Buterin bekreftet 1. mars 2026 at EIP-8141 ventes «innen et år» som en del av Hegotá.

Det er én ting i Glamsterdam som treffer lommeboken din direkte, uansett om du bryr deg om blokkbygging eller ikke: gass-reprisingen fjerner det hardkodede maksimale gasstaket. Ethereum-stiftelsen advarte eksplisitt om at «lommebøker, indeksere, gass-estimatorer eller andre verktøy som baserer seg på et hardkodet maksimalt gasstak kan brekke under Glamsterdam» og bør testes før hovednettet. En vanlig ETH-overføring vil ikke lenger koste flate 21 000 gass; sender du til en konto som ikke finnes fra før, påløper det ekstra state-gass ved kjøring. For en 7702-smartkonto, som ofte bunter flere handlinger og sponser gass, betyr det at estimatene lommeboken viser deg må oppdateres. Dette er den nærmeste, mest praktiske konsekvensen av hele roadmapen, og den kommer før native AA i det hele tatt lander.

Sikkerheten: fortsatt nøklene og signeringen, ikke protokollen

Fragmentering til side: det viktigste sikkerhetspoenget om 7702 har ikke endret seg. Angrepene skjer i signeringsøyeblikket og gjennom nøkkeltyveri, ikke gjennom en feil i protokollen. En 7702-fullmakt installerer kode og flytter ingen penger i seg selv, og derfor ser den harmløs ut på signeringsskjermen. Det er nettopp det angriperne utnytter. En fagfellevurdert studie presentert på USENIX Security 26 analyserte 3 664 166 autorisasjoner på tvers av sju kjeder frem til midten av juli 2025 og fant at over 63 prosent var knyttet til ondsinnede kontrakter, med 924 bekreftede ondsinnede kontrakt-kontoer og om lag 2,36 millioner dollar i realiserte tap pluss vel 10 millioner i eksponering (USENIX). Forbeholdet er igjen at 63 prosent teller transaksjoner, ikke brukere eller kroner; sweeper-kontrakter gjenbrukes uforholdsmessig mye.

De dyre enkelttilfellene handler om phishing. Det mest kjente offeret tapte 1,54 millioner dollar i én 7702-transaksjon i august 2025, lurt av et falskt DeFi-grensesnitt; to slike saker samme år summerte til 2,54 millioner. Samtidig falt de samlede phishing-tapene 83 prosent i 2025, til rundt 83,85 millioner dollar (Cointelegraph). At det er signeringen og ikke koden som svikter, er samme lærdom vi trakk av bro-hacket der 4 000 bitcoin forlot Liquid: en velskrevet kontrakt hjelper lite når en menneskelig godkjenning blir manipulert. Delegat-kontrakten du peker på bør være revidert; det er nettopp derfor et modent økosystem for revisjoner og bug bounties betyr noe også for account abstraction. Og i motsetning til en bank finnes det ingen angrefrist: godkjenner du en ondsinnet fullmakt, kan du ikke reversere den, like lite som du enkelt får pengene tilbake etter et rug pull.

Økonomien bak angrepene forklarer hvorfor de vedvarer. Dreneringsverktøy selges som en tjeneste, der utviklerne tar en andel av det som stjeles, og 7702 ga dem en ny, effektiv måte å tømme en konto på med én signatur i stedet for mange. Det svakeste leddet er som regel blindsignering: en maskinvarelommebok viser ofte bare en hash, ikke hva du faktisk godkjenner, og da hjelper det lite at nøkkelen ligger trygt på en brikke. Klarsignering, der lommeboken oversetter transaksjonen til lesbar tekst, og simulering før du signerer, er de to tiltakene som monner mest for en vanlig bruker.

Børsen, forvareren og den norske vinkelen

Fragmenteringen treffer også børsene og forvarerne, men på en annen måte enn den treffer deg. En børs som lar deg ta ut til en 7702-delegert adresse, eller som bruker per-bruker innskuddsadresser, må nå kunne lese delegeringspekeren 0xef0100 og vurdere hva kontoen faktisk peker på før den behandler et innskudd eller uttak. Institusjonelle forvarere løser dette gjerne med MPC-baserte oppsett og retningslinjer på tvers av kjeder, og det er en påminnelse om at spørsmålet «hvordan vet jeg at myntene finnes og er trygge?» ikke forsvinner med smartkontoer. Vi har gått grundig gjennom nettopp den problemstillingen i artikkelen om kryptoforvaring og bevis på reserver.

Én risiko fortjener en egen advarsel for den som bruker børs. Mange plattformer konsoliderer innskudd ved å feie midler fra tusenvis av innskuddsadresser til en samlekonto. Er en slik innskuddsadresse blitt 7702-delegert til en ondsinnet kontrakt, kan en feiing i verste fall utløse noe annet enn en enkel overføring. Det er en av grunnene til at forvarere og børser bygger egne kontroller rundt delegerte adresser, og at institusjonelle aktører foretrekker MPC-oppsett der ingen enkelt nøkkel alene kan flytte verdier.

For norske eiere er den regulatoriske rammen relativt avklart. MiCA er innlemmet i EØS-avtalen og gjennomført i norsk rett gjennom kryptoeiendelsloven, i kraft 1. juli 2025, og Finanstilsynet lisensierer tilbydere av kryptoeiendelstjenester (CASP-er). En selvforvaltet smartkonto, altså en 7702-oppgradert lommebok du selv kontrollerer nøklene til, faller utenfor CASP-regelverket; det er tjenesteleverandøren, ikke protokollen, som reguleres. Skattemessig gjør det ingen forskjell om kontoen din er en EOA eller en smartkonto: Skatteetaten behandler gevinst og tap likt, som realisasjon, og fra 2026 kommer systematisk rapportering fra kryptotilbydere under CARF-regelverket. Betaler du gass i en stablecoin gjennom en paymaster, kan hver slik betaling i prinsippet være en realisasjon; det er en detalj verdt å huske for den som bruker gassfrihet ofte.

Slik leser, tilbakestiller og velger du i en fragmentert verden

Det praktiske er heldigvis enkelt, så lenge du gjør det bevisst. Du kan lese hva kontoen din faktisk peker på, du kan nullstille den, og du bør tenke gjennom hvilken leverandør du binder deg til. Merk at revoke.cash kan vise en 7702-delegering, men ikke oppheve den; selve nullstillingen skjer via lommeboken din eller ved å signere en fullmakt til nulladressen (revoke.cash).

1. Åpne eip7702.app eller Etherscan og søk opp adressen din; se etter delegeringspekeren 0xef0100 og hvilken kontrakt den peker på.
2. Kjenner du ikke igjen kontrakten, behandle kontoen som kompromittert og flytt verdiene til en fersk lommebok du kontrollerer.
3. For å nullstille: signer en 7702-fullmakt som peker til nulladressen, så blir kontoen en ren EOA igjen.
4. Bytter du lommebok-leverandør, migrer bevisst etter ERC-7779 i stedet for å stable ny kode oppå gammel lagring.
5. Gjør dette per kjede: en fullmakt på Ethereum gjelder ikke automatisk på Base, Arbitrum eller Optimism.

Valget av lommebok er den nye, undervurderte beslutningen. Så lenge tillatelser og økt-nøkler lever på app- og lommebok-laget, bestemmer leverandøren du velger hvor godt kontoen din samspiller med apper og andre kjeder, og hvor lett du kan flytte deg senere. Det er ikke lenger nok å spørre «hvilken lommebok er penest?»; spørsmålet er «hvilken delegat-kontrakt stoler jeg på, og hvor låst blir jeg?». MetaMask hardkoder for eksempel sin egen reviderte delegat, slik at en oppgradert konto bare låner MetaMasks kontrakt. Det gir forutsigbarhet, men også en form for binding. Fragmenteringsdebatten handler til syvende og sist om nettopp denne avveiningen.

Bunnlinjen: broen består, fragmenteringen også

Hvis 2025 var året 7702 landet, er 2026 året vi innser at broen ikke er midlertidig likevel. Native account abstraction glapp igjen i september, denne gangen fordi EIP-8130 ble flyttet fra Cobalt til en Zenith-fork uten dato. Glamsterdam, som nå testes på Platåberget, handler om blokkproduksjon og gass, ikke om kontoer, og full native AA er skjøvet til Hegotá «innen et år». Marius van der Wijden, kjerneutvikler på Ethereum, advarte allerede da 7702 var nytt om at det var «a very early proposal» og at man måtte «evaluate all the rough edges» (DL News). De ru kantene viser seg nå å være like mye organisatoriske og økonomiske som tekniske.

Alex Jupiter, senior produktsjef i MetaMask, beskrev i sin tid 7702 som en del av «one unified Account Abstraction roadmap». Halvannet år senere er ordet «unified» det mest omstridte i setningen. Fragmenteringen 7702 skulle fjerne, sitter delvis i insentivene til aktørene som bygger lommebøkene, og de insentivene forsvinner ikke av seg selv når koden blir bedre. For deg som eier er konklusjonen praktisk og udramatisk: sjekk hva kontoen din peker på, velg en delegat du stoler på, forstå at et lommebok-bytte har en kostnad, og ikke vent på at native konto skal rydde opp med det første. Broen består. Det gjør fragmenteringen også, i hvert fall for denne runden.

Ofte stilte spørsmål

Hva er EIP-7702, kort forklart?

EIP-7702 er en Ethereum-endring fra Pectra-oppgraderingen (7. mai 2025) som lar en vanlig konto (en EOA) peke på en smartkontrakt og oppføre seg som en smartkonto, uten å bytte adresse eller flytte tokens. Det gir batching, gass-abstraksjon og økt-nøkler med én signatur, og delegeringen kan nullstilles ved å peke til nulladressen.

Hva betyr «fragmentering» av lommeboken?

Fragmentering betyr at samme adresse oppfører seg forskjellig avhengig av hvilken lommebok som satte 7702-delegeringen og hvilken kontrakt den peker på, og at tillatelser og økt-nøkler defineres ulikt fra app til app. Debatten i 2026 handler om at native account abstraction kanskje ikke fjerner dette, men bare flytter det ett lag opp, blant annet fordi lommebøker har økonomiske grunner til ikke å gjøre seg utbyttbare.

Kommer native account abstraction i 2026?

Neppe fullt ut. Base flyttet EIP-8130 fra Cobalt-oppgraderingen til en ny fork kalt Zenith uten dato (pull request slått sammen 8. september 2026), og EIP-8141 på Ethereum er skjøvet til den påfølgende forken Hegotá, som Buterin anslår kommer «innen et år». Glamsterdam, som testes på Platåberget, inneholder ikke account abstraction som hovedpunkt.

Er EIP-7702 trygt å bruke?

Selve protokollen regnes som trygg; risikoen ligger i signeringsøyeblikket og i nøkkeltyveri, ikke i en feil i koden. Angrepene skjer via phishing og ondsinnede fullmakter, der én signatur kan gi en drenerings-kontrakt kontroll. Signer bare fullmakter du forstår, bruk klarsignering og maskinvarelommebok, og peker delegeringen på en revidert kontrakt du stoler på.

Hvordan påvirker Glamsterdam lommeboken min?

Glamsterdam fjerner det hardkodede maksimale gasstaket, og Ethereum-stiftelsen advarer om at lommebøker, indeksere og gass-estimatorer som antar et fast tak kan brekke og må oppdateres. En vanlig ETH-overføring koster ikke lenger flate 21 000 gass, og å sende til en ny konto påfører ekstra state-gass. For 7702-smartkontoer som bunter handlinger og sponser gass, betyr det at estimatene lommeboken viser må justeres.

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