{"id":437,"date":"2026-09-20T13:09:30","date_gmt":"2026-09-20T13:09:30","guid":{"rendered":"https:\/\/hoge.gg\/no\/eip-7702-mev-smartkonto-frontrunning-2026\/"},"modified":"2026-09-20T13:09:30","modified_gmt":"2026-09-20T13:09:30","slug":"eip-7702-mev-smartkonto-frontrunning-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/eip-7702-mev-smartkonto-frontrunning-2026\/","title":{"rendered":"EIP-7702 og MEV: smartkontoen din som m\u00e5l og skjold i 2026"},"content":{"rendered":"

Ethereum omsettes for rundt 2.580 dollar, dr\u00f8yt 24.000 kroner med en dollarkurs i overkant av 9,40, denne helgen i september 2026, if\u00f8lge CoinDesk<\/a> og valuta-kurser.no<\/a>. EIP-7702 har v\u00e6rt aktiv p\u00e5 hovednettet siden Pectra-oppgraderingen 7. mai 2025, og adopsjonssporeren BundleBear<\/a> teller n\u00e5 n\u00e6rmere 59 millioner aktive delegeringer og godt over 100 millioner set-code-transaksjoner. Ti norske artikler her p\u00e5 HOGE Wire har allerede forklart hva en smartkonto er, hvordan den t\u00f8mmes av en drainer, hvem som betaler gassen, og hvorfor den kalles en bro til framtidens kontoer.<\/p>

Men ett sp\u00f8rsm\u00e5l har sluppet unna alle de ti: n\u00e5r smartkontoen din pakker en godkjenning og et token-bytte inn i \u00e9n og samme transaksjon og sender den ut p\u00e5 nettverket, hvem er det egentlig som bestemmer hvilken rekkef\u00f8lge den havner i, og hvem tjener p\u00e5 den rekkef\u00f8lgen? Svaret heter MEV.<\/p>

MEV, maximal extractable value, er verdien noen kan hente ut ene og alene ved \u00e5 velge hvilke transaksjoner som kommer med i en blokk og i hvilken rekkef\u00f8lge. Det er en stille industri som lever av \u00e5 kile seg foran, bak og rundt handlene til vanlige folk. EIP-7702 endrer dette spillet p\u00e5 begge sider av bordet: smartkontoen gir deg nye forsvarsverkt\u00f8y, men bryter samtidig et gammelt vern som mange kontrakter stolte p\u00e5. Og i bakgrunnen gj\u00f8r Ethereum seg klar for Glamsterdam, forken som er ventet i fjerde kvartal 2026, og som bygger om selve MEV-forsyningskjeden. Denne gjennomgangen ser p\u00e5 smartkontoen din som b\u00e5de bytte og skjold.<\/p>

Kort oppfriskning: hva EIP-7702 faktisk gj\u00f8r<\/h2>

For dem som ikke har lest de forrige ti: EIP-7702 innf\u00f8rer en ny transaksjonstype, 0x04, som lar en helt vanlig konto (en externally owned account, eller EOA) peke p\u00e5 kode i en smartkontrakt og kj\u00f8re den som sin egen. P\u00e5 kjeden ser du det som en delegeringsmark\u00f8r, bytene 0xef0100 etterfulgt av adressen til kontrakten kontoen din l\u00e5ner kode fra, til sammen 23 byte. Spesifikasjonen<\/a>, skrevet av blant andre Vitalik Buterin og Sam Wilson, beskriver en autorisasjonsliste med feltene chain_id, adresse, nonce og en signatur, og delegeringen kan n\u00e5r som helst nullstilles ved \u00e5 peke p\u00e5 nulladressen.<\/p>

Den ene evnen som betyr mest for denne artikkelen, er batching. En smartkonto kan samle flere handlinger, for eksempel en ERC-20-godkjenning og selve byttet p\u00e5 en desentralisert b\u00f8rs, i \u00e9n atomisk transaksjon som enten gjennomf\u00f8res i sin helhet eller ikke i det hele tatt. Der en vanlig konto m\u00e5tte sende to separate transaksjoner, gj\u00f8r 7702 det i ett steg, slik den offisielle Pectra-dokumentasjonen<\/a> beskriver. Den andre store endringen er mer subtil: en konto som f\u00f8r var garantert kodel\u00f8s, kan n\u00e5 b\u00e6re kode. Begge deler f\u00e5r konsekvenser for MEV, som vi skal se.<\/p>

Verdt \u00e5 ha med seg er at delegeringen ikke er en engangshendelse du ikke kan angre p\u00e5. Den ligger p\u00e5 kontoen til du selv peker p\u00e5 en ny kontrakt eller nullstiller den mot nulladressen, og den er i utgangspunktet bundet til \u00e9n kjede. Det gir fleksibilitet, men ogs\u00e5 en felle: en delegering du satte opp for lenge siden og glemte, kan fortsatt v\u00e6re aktiv og gi en kontrakt rett til \u00e5 handle p\u00e5 dine vegne. Nettopp derfor er det \u00e5 lese og rydde i egne delegeringer en del av MEV- og sikkerhetshygienen vi kommer tilbake til.<\/p>

MEV, kort forklart, og hvorfor lommeboken din er innblandet<\/h2>

N\u00e5r du sender en transaksjon p\u00e5 Ethereum, havner den som regel f\u00f8rst i den offentlige mempoolen, et venterom der alle uinnfridde transaksjoner ligger synlig f\u00f8r de kommer med i en blokk. I dette venterommet sitter det automatiserte akt\u00f8rer, kalt searchere, som leser hver eneste transaksjon og leter etter muligheter til \u00e5 tjene penger p\u00e5 rekkef\u00f8lgen. De pakker sine egne transaksjoner sammen med dine i bunter, byr p\u00e5 plass hos en builder som setter sammen blokken, og builderen leverer til slutt blokken til en validator (proposer). Denne kjeden, searcher til builder til proposer, er MEV-forsyningskjeden, og hvert ledd tar en bit av verdien underveis.<\/p>

For deg som handler er poenget enkelt: alt du kringkaster er synlig for noen som kan tjene p\u00e5 \u00e5 handle f\u00f8r eller etter deg. De vanligste formene er front-running (\u00e5 legge en handel rett foran din), back-running (\u00e5 handle rett bak deg, ofte arbitrasje) og det mest beryktede, sandwich-angrepet, der en bot kj\u00f8per foran deg, lar din handel presse prisen opp, og selger rett etterp\u00e5. Resultatet er at du f\u00e5r d\u00e5rligere pris, og boten stikker av med differansen. Vanlige folk som handler p\u00e5 desentraliserte b\u00f8rser er ikke tilskuere til dette; de er r\u00e5varen. Tabellen under oppsummerer de vanligste typene og hvordan EIP-7702 spiller inn.<\/p>

MEV-type<\/th>Hva skjer<\/th>Hvem rammes<\/th>EIP-7702-vinkel<\/th><\/tr><\/thead>
Front-running<\/td>En bot ser handelen din og legger sin egen rett foran<\/td>Kj\u00f8pere av tokens med tynn likviditet<\/td>Batching skjuler ikke handelen hvis den g\u00e5r via offentlig mempool<\/td><\/tr>
Sandwich<\/td>Bot kj\u00f8per foran, selger bak, klemmer handelen din<\/td>Alle som handler p\u00e5 DEX med slippage<\/td>7702 br\u00f8t tx.origin-vernet enkelte kontrakter brukte<\/td><\/tr>
Back-running \/ arbitrasje<\/td>Bot utnytter prisforskjellen din handel skaper<\/td>Indirekte alle; jevner ut priser mellom markeder<\/td>Atomiske batcher kan selv gj\u00f8re arbitrasje i ett steg<\/td><\/tr>
Likvidasjoner<\/td>Boter kappes om \u00e5 likvidere underdekte l\u00e5n<\/td>L\u00e5ntakere i DeFi<\/td>7702-batcher kan pakke tilbakebetaling og uttak sammen<\/td><\/tr>
Ordreflyt-fangst<\/td>Transaksjonen din selges videre som eksklusiv ordreflyt<\/td>Alle; verdien tilfaller mellomledd<\/td>7702 endrer ikke hvem som f\u00f8rst ser transaksjonen din<\/td><\/tr><\/tbody><\/table><\/figure>

tx.origin-vernet som EIP-7702 br\u00f8t<\/h2>

Her kommer den f\u00f8rste av 7702s to store MEV-konsekvenser, og den er beskrevet i klartekst i spesifikasjonens egen sikkerhetsdel. I mange \u00e5r har enkelte kontrakter, s\u00e6rlig launchpads og tokens som ville holde boter ute, brukt et enkelt triks: de krevde at tx.origin er lik msg.sender. Ideen var at en searcher som sandwicher deg, m\u00e5 rute angrepet gjennom en egen kontrakt, og da vil tx.origin (den opprinnelige avsenderen) v\u00e6re forskjellig fra msg.sender (den som kaller akkurat n\u00e5). Var de like, antok kontrakten at kallet kom rett fra et menneske med en kodel\u00f8s konto, ikke fra en bot.<\/p>

EIP-7702 river bort denne antakelsen. Spesifikasjonen<\/a> sier rett ut at den bryter invarianten om at tx.origin er lik msg.sender bare i det \u00f8verste kj\u00f8ringslaget, og lister sandwich-beskyttelse som en av bruksm\u00e5tene som blir rammet. Grunnen er at en 7702-delegert konto n\u00e5 kan kj\u00f8re full kontraktlogikk samtidig som den fortsatt er tx.origin. Vernet som skulle skille \u00abekte menneske\u00bb fra \u00abbot\u00bb, skiller ikke lenger noe som helst. Utviklere som lente seg p\u00e5 dette m\u00f8nsteret, m\u00e5 bygge nye forsvar, og brukere b\u00f8r vite at et vern de kanskje trodde beskyttet dem, kan v\u00e6re borte.<\/p>

Spesifikasjonen er n\u00f8ktern om nyansene: kontrakter som bare bruker tx.origin til \u00e5 bekrefte at avsenderen er en EOA, er up\u00e5virket, og reentrancy-vakter som lente seg p\u00e5 det samme, regnes uansett som en d\u00e5rlig praksis fra f\u00f8r. Men for anti-bot- og anti-sandwich-m\u00f8nstre er beskjeden entydig. Dette er ikke en teoretisk fotnote; det er en endring i hva utviklere trygt kan anta om hvem som kaller kontrakten deres, og den kom da knappen ble skrudd p\u00e5 for over 59 millioner delegerte kontoer.<\/p>

Atomiske batcher: b\u00e5de skjold og ny angrepsflate<\/h2>

Den andre store MEV-konsekvensen g\u00e5r andre veien, og her er 7702 faktisk et forsvar. En atomisk batch gjennomf\u00f8res helt eller ikke i det hele tatt. Pakker du godkjenning og bytte sammen, kan du ikke lenger havne i den klassiske fellen der godkjenningen g\u00e5r gjennom, men byttet feiler, slik at en bot rekker \u00e5 utnytte en dinglende godkjenning. Legger du i tillegg en slippage-sjekk inne i batchen, holder betingelsen ved den simulerte slutt-tilstanden, og en handel som ville gitt deg for d\u00e5rlig pris, ruller rett og slett tilbake. Ingen halvferdige tilstander, ingen etterlatte godkjenninger.<\/p>

Men atomisitet gj\u00f8r deg ikke usynlig. S\u00e5 lenge batchen g\u00e5r via den offentlige mempoolen, ser en searcher fortsatt at den inneholder et bytte, og kan bygge en sandwich rundt hele bunten. Forskjellen er at angriperen n\u00e5 m\u00e5 simulere den batchede logikken din for \u00e5 finne byttet og bekrefte at slippage-betingelsen fortsatt holder i sluttilstanden angrepet skaper. 7702-trafikk ser dessuten annerledes ut p\u00e5 ledningen enn gamle EOA-kall, s\u00e5 searchere som ignorerer den, g\u00e5r glipp av en voksende andel av handlene som er verdt \u00e5 angripe. Kort sagt: batching fjerner noen billige triks mot deg, men flytter kappl\u00f8pet, det avslutter det ikke.<\/p>

Mempoolen: n\u00e5r din batch gj\u00f8r andres transaksjon foreldet<\/h2>

Det finnes en tredje, mindre kjent effekt som lever helt nede i mempool-mekanikken. Fordi en 7702-delegert konto kan kj\u00f8re kode som flytter saldoer, advarer spesifikasjonen<\/a> om at det blir mulig \u00e5 f\u00e5 transaksjoner fra andre kontoer til \u00e5 bli foreldet: en delegert kontos handling kan endre en tilstand som andre ventende transaksjoner var avhengige av, slik at de plutselig feiler. For \u00e5 begrense dette anbefaler spesifikasjonen at noder ikke godtar mer enn \u00e9n ventende transaksjon for en EOA som har en delegeringsmark\u00f8r.<\/p>

Det h\u00f8res teknisk ut, men konsekvensen er praktisk. Regelen om \u00e9n ventende transaksjon p\u00e5virker hvor raskt du kan sende etterf\u00f8lgende handlinger fra samme smartkonto, og den gir searchere og builders et nytt hensyn \u00e5 ta n\u00e5r de setter sammen blokker. Muligheten til \u00e5 gj\u00f8re andres transaksjoner foreldet er ogs\u00e5 en form for gratis chikane (griefing): en akt\u00f8r kan i prinsippet fylle blokkplass med handlinger som stadig ugyldiggj\u00f8r andres ventende transaksjoner. Base-laget demper dette med mempool-regler, men det er nok et eksempel p\u00e5 at en tilsynelatende enkel \u00abgi kontoen kode\u00bb-funksjon r\u00f8rer ved antakelser dypt nede i systemet.<\/p>

Sandwich i tall: hva dataene faktisk sier<\/h2>

Hvor mye penger snakker vi om? Fersk data fra analyseselskapet EigenPhi, gjengitt av Cointelegraph<\/a>, viser at sandwich-angrep p\u00e5 Ethereum faktisk har avtatt: fra nesten 10 millioner dollar i m\u00e5nedlig verdiuttrekk mot slutten av 2024 (rundt 94 millioner kroner) til omtrent 2,5 millioner dollar i m\u00e5neden (dr\u00f8yt 23 millioner kroner) i oktober 2025. Over perioden november 2024 til oktober 2025 registrerte EigenPhi mer enn 95.000 sandwich-angrep, med et samlet tap for handlende p\u00e5 rundt 60 millioner dollar, alts\u00e5 godt over en halv milliard kroner.<\/p>

To detaljer er verdt \u00e5 merke seg. For det f\u00f8rste er snittfortjenesten per angrep sv\u00e6rt lav, i overkant av 3 dollar, rundt 28 kroner, noe som forteller at dette er et volumspill mot mange sm\u00e5 handler, ikke noen f\u00e5 store ran. For det andre g\u00e5r mesteparten av verdien ikke til angriperen i det hele tatt: byggerne fanger opp brorparten gjennom gassavgifter, og searcheren sitter igjen med en margin p\u00e5 rundt 5 prosent. Til sammenligning ble det p\u00e5 Solana i 2025 trukket ut rundt 13,4 millioner dollar (om lag 126 millioner kroner) gjennom hele 1,55 millioner sandwich-angrep, if\u00f8lge de samme dataene. MEV er med andre ord ikke et Ethereum-problem alene, men mekanikken og forsvaret er lengst utviklet nettopp der.<\/p>

Slik ser et enkelt sandwich-angrep ut i praksis. Du legger inn en ordre p\u00e5 en desentralisert b\u00f8rs om \u00e5 bytte ETH mot en mindre likvid token, og setter en slippage p\u00e5 for eksempel 2 prosent. En bot ser ordren i den offentlige mempoolen, kj\u00f8per den samme tokenen rett foran deg og presser prisen opp. Din handel g\u00e5r gjennom til den n\u00e5 h\u00f8yere prisen, helt inntil grensen din p\u00e5 2 prosent, f\u00f8r boten selger rett bak deg og tar differansen. Du fikk tokenen, men betalte toppen av det du sa deg villig til, og de to prosentene havnet i lomma til noen andre. Jo h\u00f8yere slippage du tillater, desto st\u00f8rre bit kan klemmes ut.<\/p>

At tallene faller er godt nytt, men det betyr ikke at trusselen er borte. Den forteller mest om at forsvaret virker: stadig mer ordreflyt sendes privat, utenom det \u00e5pne venterommet der boterne jakter. Det bringer oss til det viktigste avsnittet for lommebok- og b\u00f8rsbrukere.<\/p>

Privat ordreflyt: Flashbots Protect og MetaMask Smart Transactions<\/h2>

Det reelle vernet mot sandwich er \u00e5 aldri vise transaksjonen din i den offentlige mempoolen i det hele tatt. Flashbots Protect<\/a> er et gratis RPC-endepunkt, lansert i 2022, som ruter transaksjonen din gjennom en privat kanal rett til byggerne og forbi det offentlige venterommet. Transaksjonen er dermed skjult for sandwich-boter helt til den er bekreftet, den kommer bare med i en blokk hvis den ikke ruller tilbake, og skaper den MEV, kan du f\u00e5 deler av verdien tilbake som refusjon. Du legger den til som et vanlig RPC i lommeboken din; Flashbots<\/a> oppgir rpc.flashbots.net og kjede-ID 1 for Ethereum.<\/p>

Store lommeb\u00f8ker har begynt \u00e5 bygge dette inn som standard. MetaMask lanserte i mai 2024 Smart Transactions<\/a>, som sender handelen til en \u00abvirtuell mempool\u00bb der den holdes privat til den er bekreftet, mens validerte deltakere byr p\u00e5 retten til \u00e5 inkludere den. MetaMask<\/a> forh\u00e5ndssimulerer hver slik transaksjon, noe som b\u00e5de beskytter mot front-running og sandwich og kutter antallet feilede transaksjoner. Prinsippet, private mempooler og selektiv deling av \u00abhint\u00bb til searchere gjennom mekanismer som Flashbots MEV-Share, er blitt normen snarere enn et nisjetriks, og det er hovedgrunnen til at EigenPhis kurve peker nedover.<\/p>

Men gratis er det sjelden. Bak den private ordreflyten vokser det fram et marked der lommeb\u00f8ker og RPC-tjenester kan selge retten til \u00e5 se og bygge rundt transaksjonene dine, gjennom det som kalles ordreflyt-auksjoner. Ideen er at verdien som ellers ville g\u00e5tt til en tilfeldig sandwich-bot, i stedet auksjoneres bort og delvis f\u00f8res tilbake til deg som refusjon. Baksiden er sentralisering: hvis noen f\u00e5 akt\u00f8rer f\u00e5r eksklusiv tilgang til storparten av ordreflyten, flytter man makten fra en \u00e5pen mempool til noen lukkede rom. For deg som bruker er det verdt \u00e5 vite at \u00abMEV-beskyttelse\u00bb ikke betyr at ingen tjener p\u00e5 handelen din, bare at du forh\u00e5pentlig f\u00e5r en st\u00f8rre del av kaka og slipper den verste klemmen.<\/p>

Poenget for 7702-brukere er at privat ordreflyt og atomiske batcher utfyller hverandre. Batchen s\u00f8rger for at handelen din er alt-eller-ingenting; det private endepunktet s\u00f8rger for at ingen bot f\u00e5r se den f\u00f8r den er avgjort. Sammen er de langt sterkere enn hver for seg.<\/p>

Metode<\/th>Synlig for boter?<\/th>Sandwich-vern<\/th>MEV-refusjon<\/th>Merknad<\/th><\/tr><\/thead>
Offentlig mempool<\/td>Ja<\/td>Ingen<\/td>Nei<\/td>Standard; mest utsatt<\/td><\/tr>
Flashbots Protect (RPC)<\/td>Nei<\/td>Ja<\/td>Ja<\/td>Legges til manuelt i lommeboken<\/td><\/tr>
MetaMask Smart Transactions<\/td>Nei<\/td>Ja<\/td>Delvis<\/td>Innebygd, forh\u00e5ndssimulert<\/td><\/tr>
Atomisk 7702-batch<\/td>Ja (via offentlig mempool)<\/td>Delvis (alt-eller-ingenting)<\/td>Nei<\/td>Best kombinert med privat RPC<\/td><\/tr><\/tbody><\/table><\/figure>

B\u00f8rsene, searcherne og 7702-trafikken<\/h2>

MEV er ikke bare en sak mellom deg og en anonym bot; det er ogs\u00e5 blitt en driftssak for b\u00f8rser og forvaltere. En searcher som vil tjene penger i 2026, kan ikke lenger ignorere 7702-transaksjoner, for de utgj\u00f8r en voksende del av det som er verdt \u00e5 analysere, og de ser annerledes ut p\u00e5 ledningen. Samtidig m\u00e5 b\u00f8rser som tar imot innskudd, forholde seg til at en innskuddsadresse plutselig kan b\u00e6re kode. Vi har sett n\u00e6rmere p\u00e5 hvordan innskuddsapparatet h\u00e5ndterer dette i artikkelen om n\u00e5r innskuddsadresser kj\u00f8rer kode<\/a>, der 23-byte-mark\u00f8ren blir noe innskuddssystemet m\u00e5 screene f\u00f8r midler frigis.<\/p>

For en sentralisert b\u00f8rs er sammenhengen mellom MEV og 7702 mest en risiko p\u00e5 uttakssiden og i den interne konsolideringen av innskudd: en delegert konto kan oppf\u00f8re seg p\u00e5 m\u00e5ter et enkelt overf\u00f8ringsskript ikke forventer, og en sweeper som er koblet p\u00e5 en innskuddsadresse, kan kj\u00f8re samtidig med b\u00f8rsens egen konsolidering. For desentraliserte b\u00f8rser er MEV selve grunnst\u00f8yen: hver eneste handel er potensielt en sandwich-mulighet, og det er derfor DEX-aggregatorer i \u00f8kende grad ruter ordrer gjennom private kanaler og tilbyr MEV-beskyttelse som en funksjon, ikke et tilvalg. Enten du handler p\u00e5 en CEX eller en DEX, er sp\u00f8rsm\u00e5let det samme: hvem ser transaksjonen din f\u00f8r den avgj\u00f8res?<\/p>

Glamsterdam og ePBS: forsyningskjeden bygges om<\/h2>

Den store nyheten som gj\u00f8r denne artikkelen tidsaktuell, er at Ethereum er i ferd med \u00e5 bygge om selve MEV-forsyningskjeden. Neste hardfork etter Fusaka (som gikk live 3. desember 2025) heter Glamsterdam, og den er ventet p\u00e5 hovednettet i fjerde kvartal 2026, med en Sepolia-fork planlagt til 6. oktober 2026. Ethereum.org<\/a> oppgir to hovedforslag: EIP-7732, enshrined proposer-builder separation (ePBS), og EIP-7928, block-level access lists (BALs).<\/p>

ePBS er den som betyr mest for MEV. I dag hviler forholdet mellom proposere og byggere p\u00e5 mellomvare som MEV-Boost og p\u00e5 tredjeparts relayere. EIP-7732 forankrer skillet mellom den som foresl\u00e5r blokken og den som bygger den direkte i protokollen, fjerner behovet for den eksterne mellomvaren, og utvider propageringsvinduet fra rundt 2 til omtrent 9 sekunder slik at nettet trygt kan h\u00e5ndtere st\u00f8rre datamengder. BALs gir p\u00e5 sin side et kart over avhengighetene mellom transaksjoner p\u00e5 forh\u00e5nd, noe som muliggj\u00f8r mer parallell kj\u00f8ring. For brukeren betyr ikke dette at sandwich forsvinner, men at selve maskineriet som ordner transaksjonene, blir mindre avhengig av \u00e5 stole p\u00e5 private relayere.<\/p>

Hva betyr det konkret for deg som bruker? P\u00e5 kort sikt lite: selv med ePBS p\u00e5 plass vil en handel du kringkaster \u00e5pent, fortsatt kunne sandwiches, s\u00e5 det praktiske forsvaret ligger uansett i privat ordreflyt. Det ePBS gj\u00f8r, er \u00e5 gj\u00f8re selve fundamentet sunnere ved \u00e5 fjerne et lag av tillit til private relayere som i dag kan g\u00e5 ned eller sile bort transaksjoner. Datoen er heller ikke spikret; Ethereum.org oppgir fjerde kvartal 2026 uten bekreftet dato, og forker har en tendens til \u00e5 gli. Poenget er retningen: base-laget tar tilbake ansvaret for hvordan blokker settes sammen, i stedet for \u00e5 overlate det til frivillig mellomvare.<\/p>

Native account abstraction er derimot ikke med i Glamsterdam. Forslaget EIP-8141 (frame transactions) er, if\u00f8lge ETH Daily<\/a>, flyttet til \u00abScheduled for Inclusion\u00bb i den p\u00e5f\u00f8lgende forken, Hegot\u00e1, som er ventet en gang i 2027. Inntil da forblir EIP-7702 broen mange kontoer krysser, et tema vi har tatt for oss i gjennomgangen av fragmenteringen ingen fikser enn\u00e5<\/a>. Tidslinjen under viser hvordan bitene henger sammen.<\/p>

Oppgradering<\/th>N\u00e5r<\/th>N\u00f8kkel-EIP<\/th>Betydning for smartkontoer og MEV<\/th><\/tr><\/thead>
Pectra<\/td>7. mai 2025<\/td>EIP-7702<\/td>EOA-er kan b\u00e6re kode og batche; ny angreps- og forsvarsflate<\/td><\/tr>
Fusaka<\/td>3. desember 2025<\/td>PeerDAS<\/td>Billigere data for lag 2; ingen direkte AA-endring<\/td><\/tr>
Glamsterdam<\/td>Ventet Q4 2026<\/td>EIP-7732 (ePBS), EIP-7928 (BALs)<\/td>Forankrer proposer-builder-skillet; mindre relay-avhengighet<\/td><\/tr>
Hegot\u00e1<\/td>Ventet 2027<\/td>EIP-8141, EIP-7805 (FOCIL)<\/td>Native account abstraction og sensurmotstand p\u00e5 protokollniv\u00e5<\/td><\/tr><\/tbody><\/table><\/figure>

FOCIL og \u00abingen alternativ vei inn\u00bb<\/h2>

Det er en dypere MEV-relatert bekymring bak ePBS og native account abstraction, og Vitalik Buterin har v\u00e6rt tydelig p\u00e5 den. Smartkontoer og personvernprotokoller er i dag avhengige av tredjeparts mellomledd bare for \u00e5 f\u00e5 transaksjonene sine inkludert p\u00e5 kjeden. Buterin har beskrevet denne relay-avhengigheten som en kilde til s\u00e5rbarhet og skj\u00f8rhet: hvis en relay g\u00e5r ned, eller en relay-operat\u00f8r nekter \u00e5 behandle en bestemt transaksjon, har sluttbrukeren ingen alternativ vei inn i blokka, if\u00f8lge news.bitcoin.com<\/a>.<\/p>

Svaret utviklerne har landet p\u00e5, heter FOCIL, fork-choice enforced inclusion lists, f\u00f8rt inn som EIP-7805 og lagt til veikartet<\/a> i februar 2026. FOCIL lar tilfeldig utvalgte komiteer av validatorer tvinge gjennom at transaksjoner blir inkludert i blokker, slik at ingen enkelt akt\u00f8r kan sensurere en transaksjon bare ved \u00e5 nekte \u00e5 videresende den. Buterin sier mekanismen gir \u00abguaranteed rapid inclusion\u00bb, alts\u00e5 at n\u00e6r sagt enhver gyldig transaksjon kommer med innen ett til to slot, selv i et fiendtlig milj\u00f8. For 7702-brukere som ellers er prisgitt bundlere og relayere, er dette en langsiktig forsikring mot at nettopp mellomleddene i MEV-kjeden skal kunne holde deg ute.<\/p>

Sikkerhet: det er fortsatt n\u00f8klene, ikke koden<\/h2>

MEV er den mest oversette risikoen ved smartkontoer, men den er ikke den eneste, og det er verdt \u00e5 sette den i sammenheng. Ethereum-kjerneutvikleren Marius van der Wijden minnet tidlig om at 7702 fortsatt er ferskt, og at \u00abIt’s still a very early proposal, so we need to evaluate all the rough edges\u00bb, if\u00f8lge DL News<\/a>. I samme sak beskriver Alex Jupiter i MetaMask 7702 som det han kaller \u00abone unified Account Abstraction roadmap\u00bb, alts\u00e5 broen som samler et fragmentert felt. Begge poengene gjelder ogs\u00e5 MEV: de skarpe kantene inkluderer tx.origin-bruddet og mempool-effektene, mens det samlende veikartet er nettopp det ePBS og native AA skal levere.<\/p>

Den st\u00f8rste faren for de fleste er likevel gammel: \u00e5 signere noe man ikke forst\u00e5r. Da EIP-7702 ble skrudd p\u00e5, fant Wintermute at over 97 prosent av de tidligste delegeringene var gjenbrukt \u00abCrimeEnjoyor\u00bb-kode fra sweepere, men at det ikke var l\u00f8nnsomt fordi kontoene allerede var tomme, ikke et tegn p\u00e5 en feil i 7702, if\u00f8lge CoinDesk<\/a>. Den dyreste enkelthendelsen s\u00e5 langt, et phishing-tap p\u00e5 1,54 millioner dollar (rundt 14,5 millioner kroner) i \u00e9n batch-signatur forkledd som et Uniswap-bytte, er dokumentert av Cryptopolitan<\/a>. L\u00e6rdommen sikkerhetsmilj\u00f8et gjentar, er at problemet i bunn og grunn ikke er 7702, men at brukere sliter med \u00e5 sikre sine egne private n\u00f8kler. Blindsignering er fienden, og den samme bug bounty-\u00f8konomien som betaler rekordsummer<\/a>, klarer ikke \u00e5 stoppe tap som starter med en signatur brukeren selv godkjente.<\/p>

MEV-verdenen og DeFi-angrepene henger sammen: en sandwich er tross alt bare prismanipulasjon i det sm\u00e5, og de st\u00f8rre slektningene finner du i tre generasjoner orakel-manipulasjon<\/a> og i forsvaret vi har beskrevet i gjennomgangen av det som faktisk virker<\/a>. Tabellen under samler de viktigste risikovektorene rundt 7702, inkludert dem denne artikkelen har lagt til.<\/p>

Risikovektor<\/th>Hva det er<\/th>Tiltak<\/th><\/tr><\/thead>
Blindsignering<\/td>Godkjenne en batch uten \u00e5 se hva den gj\u00f8r<\/td>Les innholdet; bruk lommeb\u00f8ker med klarsignering<\/td><\/tr>
tx.origin-brudd<\/td>Anti-sandwich-vern som ikke lenger holder<\/td>Ikke stol p\u00e5 tx.origin; bruk privat ordreflyt<\/td><\/tr>
Foreldede transaksjoner<\/td>Delegert kode kan ugyldiggj\u00f8re andres ventende tx<\/td>Mempool-regel om \u00e9n ventende tx per delegert EOA<\/td><\/tr>
Lagringskollisjon<\/td>Delegatkode skriver over kontoens lagringsplasser<\/td>Bruk ERC-7201-navnerom i kontrakten<\/td><\/tr>
chain_id=0-replay<\/td>Signatur som kan gjenbrukes p\u00e5 andre kjeder<\/td>Bind delegeringen til \u00e9n kjede<\/td><\/tr>
Sponset transaksjon<\/td>Relayer risikerer at autorisasjonen trekkes<\/td>Bonding eller omd\u00f8mmesystem for relayere<\/td><\/tr><\/tbody><\/table><\/figure>

Finanstilsynet, MiCA og MEV-gr\u00e5sonen<\/h2>

Hvor st\u00e5r s\u00e5 det norske og europeiske regelverket i alt dette? Kort sagt: MEV i seg selv er ikke ulovlig. Det er en konsekvens av hvordan \u00e5pne blokkjeder ordner transaksjoner, ikke en tjeneste noen tilbyr under konsesjon. Finanstilsynet<\/a> f\u00f8rer tilsyn med tjenestetilbydere for kryptoeiendeler (CASP-er) etter MiCA, som ble innlemmet i norsk rett gjennom kryptoeiendelsloven i kraft 1. juli 2025 via E\u00d8S-avtalen. Tilsynet retter seg mot b\u00f8rser, forvaltere og utstedere, ikke mot protokollen selv eller din egen selvforvarte smartkonto.<\/p>

Det betyr at en 7702-delegert lommebok du styrer selv, faller utenfor CASP-regimet, mens en b\u00f8rs som ruter ordreflyten din, m\u00e5 forholde seg til hele MiCA-apparatet, inkludert reglene om h\u00e5ndtering av kundemidler og reisebestemmelsen (travel rule) ved overf\u00f8ringer. Handel med kryptoderivater som futures og evigvarende kontrakter er dessuten finansielle instrumenter under MiFID II, ikke MiCA, og h\u00f8rer inn under markedsregelverket. P\u00e5 skattesiden begynner systematisk rapportering fra kryptotjenestetilbydere til Skatteetaten under CARF-rammeverket i 2026, noe som gj\u00f8r at flere transaksjoner blir synlige for myndighetene. Poenget for en MEV-bevisst bruker er at ansvaret for \u00e5 beskytte egen ordreflyt i praksis ligger hos deg og lommeboken din, ikke hos et tilsyn.<\/p>

Et betimelig sp\u00f8rsm\u00e5l er om sandwich-angrep egentlig er en form for markedsmanipulasjon. P\u00e5 et regulert marked ville front-running av kundeordrer v\u00e6rt ulovlig, men en desentralisert b\u00f8rs er ikke en regulert markedsplass med en megler som skylder deg beste utf\u00f8relse. MEV oppst\u00e5r i en tillatelsesl\u00f8s protokoll der rekkef\u00f8lgen p\u00e5 transaksjoner er offentlig spill. Der kryptohandelen derimot skjer med derivater, futures eller evigvarende kontrakter, gjelder MiFID II og markedsmisbruksreglene fullt ut, og en akt\u00f8r som systematisk utnytter kundeordrer kan komme i myndighetenes s\u00f8kelys. Grensen g\u00e5r alts\u00e5 ikke ved teknikken, men ved hvilken innpakning handelen har og hvem som tilbyr den.<\/p>

Slik beskytter du smartkontoen din mot MEV<\/h2>

Det gode er at forsvaret er tilgjengelig og for det meste gratis. En praktisk sjekkliste for en 7702-bruker som vil unng\u00e5 \u00e5 bli sandwich-mat:<\/p>

  • Bruk et MEV-beskyttet RPC eller en lommebok med innebygd privat innsending (for eksempel Flashbots Protect eller MetaMask Smart Transactions), slik at handelen aldri vises i den offentlige mempoolen.<\/li>
  • Les hva batchen faktisk inneholder f\u00f8r du signerer; en godkjenning og et bytte i samme signatur skal du kunne kjenne igjen, ikke blindsignere.<\/li>
  • Sett fornuftig slippage p\u00e5 store handler, og del gjerne sv\u00e6rt store ordrer opp i mindre biter.<\/li>
  • Nullstill gamle eller ukjente delegeringer ved \u00e5 peke p\u00e5 nulladressen, og kontroller delegeringsmark\u00f8ren din p\u00e5 en blokkutforsker med jevne mellomrom.<\/li>
  • Foretrekk atomiske batcher framfor mange l\u00f8se godkjenninger som blir liggende og dingle.<\/li>
  • Hold deg til reviderte lommeb\u00f8ker og kjente delegatorer; en delegering til feil kontrakt gir bort full kontroll i \u00e9n signatur.<\/li><\/ul>

    Ingen av punktene krever at du forst\u00e5r detaljene i ePBS eller FOCIL. De krever bare at du behandler hver signatur som det den er, en instruks til en konto som n\u00e5 kan gj\u00f8re langt mer enn f\u00f8r.<\/p>

    Bunnlinjen<\/h2>

    EIP-7702 blir v\u00e6rende. Fram til native account abstraction lander i Hegot\u00e1 en gang i 2027, er set-code-transaksjonen broen de fleste kontoer krysser, og den broen b\u00e6rer n\u00e5 titalls millioner delegeringer. MEV er den delen av regnestykket de ti forrige norske forklaringene hoppet over, og den fortjener oppmerksomhet nettopp fordi den r\u00f8rer ved begge sider av smartkontoen: batching gir deg et skjold, mens den kodeb\u00e6rende kontoen br\u00f8t et gammelt vern og skapte nye hensyn helt nede i mempoolen.<\/p>

    Det oppmuntrende er at b\u00e5de base-laget og lommeb\u00f8kene angriper problemet fra hver sin kant. ePBS og FOCIL bygger om og sikrer forsyningskjeden p\u00e5 protokollniv\u00e5, mens privat ordreflyt fra Flashbots og MetaMask allerede har presset sandwich-tallene nedover. Men ingen av delene fritar deg fra \u00e5 v\u00e6re \u00e5rv\u00e5ken. Den samme l\u00e6rdommen som gjelder for drainere, gjelder for MEV: teknologien gir deg kraftige verkt\u00f8y, men den siste linjen med forsvar er fortsatt en bruker som leser f\u00f8r hen signerer.<\/p>

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

    Hva er MEV, og hvordan rammer det EIP-7702-lommeboken min?<\/h3>

    MEV (maximal extractable value) er verdien noen kan hente ut ved \u00e5 bestemme rekkef\u00f8lgen p\u00e5 transaksjoner i en blokk, for eksempel ved \u00e5 kile seg foran eller rundt handelen din. EIP-7702 gj\u00f8r lommeboken din til en smartkonto som kan pakke flere handlinger i \u00e9n transaksjon, noe som b\u00e5de gir nye forsvar (atomisk gjennomf\u00f8ring) og nye ting for searchere \u00e5 analysere.<\/p>

    Beskytter EIP-7702 meg mot sandwich-angrep?<\/h3>

    Delvis. En atomisk batch gjennomf\u00f8res helt eller ikke i det hele tatt, s\u00e5 du unng\u00e5r halvferdige tilstander, men selve handelen kan fortsatt bli utsatt for sandwich hvis den g\u00e5r gjennom den offentlige mempoolen. EIP-7702-spesifikasjonen sl\u00e5r dessuten fast at det gamle tx.origin-vernet mot sandwich ikke lenger holder. Reelt vern f\u00e5r du f\u00f8rst n\u00e5r transaksjonen sendes privat, utenom den offentlige mempoolen.<\/p>

    Hvordan sl\u00e5r jeg p\u00e5 MEV-beskyttelse i lommeboken?<\/h3>

    Bruk en lommebok eller et RPC-endepunkt som sender transaksjonen din privat til byggerne i stedet for den \u00e5pne mempoolen. MetaMask har innebygd Smart Transactions, og Flashbots Protect kan legges til som RPC. Da er transaksjonen skjult for sandwich-boter til den er bekreftet.<\/p>

    Endrer Glamsterdam-oppgraderingen hvordan MEV fungerer?<\/h3>

    Ikke direkte for deg som bruker, men den bygger om kjeden bak. Glamsterdam (ventet i fjerde kvartal 2026) forankrer proposer-builder-separasjon i protokollen med EIP-7732 og fjerner avhengigheten av tredjeparts relayere som MEV-Boost. Det endrer hvem som setter sammen blokkene, men du trenger fortsatt privat ordreflyt for \u00e5 slippe unna sandwich.<\/p>

    Er MEV ulovlig, og hva sier Finanstilsynet?<\/h3>

    MEV er i seg selv ikke ulovlig; det er en konsekvens av hvordan offentlige blokkjeder ordner transaksjoner. Finanstilsynet regulerer tjenestetilbydere (CASP-er) under MiCA, ikke selve protokollen eller din egen selvforvarte lommebok. Handel med kryptoderivater faller derimot under MiFID II.<\/p>