EIP-7702 og MEV: smartkontoen din som mål og skjold i 2026

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

Men ett spørsmål har sluppet unna alle de ti: når smartkontoen din pakker en godkjenning og et token-bytte inn i én og samme transaksjon og sender den ut på nettverket, hvem er det egentlig som bestemmer hvilken rekkefølge den havner i, og hvem tjener på den rekkefølgen? Svaret heter MEV.

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

Kort oppfriskning: hva EIP-7702 faktisk gjør

For dem som ikke har lest de forrige ti: EIP-7702 innfører en ny transaksjonstype, 0x04, som lar en helt vanlig konto (en externally owned account, eller EOA) peke på kode i en smartkontrakt og kjøre den som sin egen. På kjeden ser du det som en delegeringsmarkør, bytene 0xef0100 etterfulgt av adressen til kontrakten kontoen din låner kode fra, til sammen 23 byte. Spesifikasjonen, 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år som helst nullstilles ved å peke på nulladressen.

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å en desentralisert børs, i én atomisk transaksjon som enten gjennomføres i sin helhet eller ikke i det hele tatt. Der en vanlig konto måtte sende to separate transaksjoner, gjør 7702 det i ett steg, slik den offisielle Pectra-dokumentasjonen beskriver. Den andre store endringen er mer subtil: en konto som før var garantert kodeløs, kan nå bære kode. Begge deler får konsekvenser for MEV, som vi skal se.

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

MEV, kort forklart, og hvorfor lommeboken din er innblandet

Når du sender en transaksjon på Ethereum, havner den som regel først i den offentlige mempoolen, et venterom der alle uinnfridde transaksjoner ligger synlig før de kommer med i en blokk. I dette venterommet sitter det automatiserte aktører, kalt searchere, som leser hver eneste transaksjon og leter etter muligheter til å tjene penger på rekkefølgen. De pakker sine egne transaksjoner sammen med dine i bunter, byr på 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.

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

tx.origin-vernet som EIP-7702 brøt

Her kommer den første av 7702s to store MEV-konsekvenser, og den er beskrevet i klartekst i spesifikasjonens egen sikkerhetsdel. I mange år har enkelte kontrakter, særlig 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å rute angrepet gjennom en egen kontrakt, og da vil tx.origin (den opprinnelige avsenderen) være forskjellig fra msg.sender (den som kaller akkurat nå). Var de like, antok kontrakten at kallet kom rett fra et menneske med en kodeløs konto, ikke fra en bot.

EIP-7702 river bort denne antakelsen. Spesifikasjonen sier rett ut at den bryter invarianten om at tx.origin er lik msg.sender bare i det øverste kjøringslaget, og lister sandwich-beskyttelse som en av bruksmåtene som blir rammet. Grunnen er at en 7702-delegert konto nå kan kjøre full kontraktlogikk samtidig som den fortsatt er tx.origin. Vernet som skulle skille «ekte menneske» fra «bot», skiller ikke lenger noe som helst. Utviklere som lente seg på dette mønsteret, må bygge nye forsvar, og brukere bør vite at et vern de kanskje trodde beskyttet dem, kan være borte.

Spesifikasjonen er nøktern om nyansene: kontrakter som bare bruker tx.origin til å bekrefte at avsenderen er en EOA, er upåvirket, og reentrancy-vakter som lente seg på det samme, regnes uansett som en dårlig praksis fra før. Men for anti-bot- og anti-sandwich-mønstre 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å for over 59 millioner delegerte kontoer.

Atomiske batcher: både skjold og ny angrepsflate

Den andre store MEV-konsekvensen går andre veien, og her er 7702 faktisk et forsvar. En atomisk batch gjennomføres 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år gjennom, men byttet feiler, slik at en bot rekker å 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årlig pris, ruller rett og slett tilbake. Ingen halvferdige tilstander, ingen etterlatte godkjenninger.

Men atomisitet gjør deg ikke usynlig. Så lenge batchen går 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å må simulere den batchede logikken din for å finne byttet og bekrefte at slippage-betingelsen fortsatt holder i sluttilstanden angrepet skaper. 7702-trafikk ser dessuten annerledes ut på ledningen enn gamle EOA-kall, så searchere som ignorerer den, går glipp av en voksende andel av handlene som er verdt å angripe. Kort sagt: batching fjerner noen billige triks mot deg, men flytter kappløpet, det avslutter det ikke.

Mempoolen: når din batch gjør andres transaksjon foreldet

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

Det høres teknisk ut, men konsekvensen er praktisk. Regelen om én ventende transaksjon påvirker hvor raskt du kan sende etterfølgende handlinger fra samme smartkonto, og den gir searchere og builders et nytt hensyn å ta når de setter sammen blokker. Muligheten til å gjøre andres transaksjoner foreldet er også en form for gratis chikane (griefing): en aktør kan i prinsippet fylle blokkplass med handlinger som stadig ugyldiggjør andres ventende transaksjoner. Base-laget demper dette med mempool-regler, men det er nok et eksempel på at en tilsynelatende enkel «gi kontoen kode»-funksjon rører ved antakelser dypt nede i systemet.

Sandwich i tall: hva dataene faktisk sier

Hvor mye penger snakker vi om? Fersk data fra analyseselskapet EigenPhi, gjengitt av Cointelegraph, viser at sandwich-angrep på Ethereum faktisk har avtatt: fra nesten 10 millioner dollar i månedlig verdiuttrekk mot slutten av 2024 (rundt 94 millioner kroner) til omtrent 2,5 millioner dollar i måneden (drøyt 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å rundt 60 millioner dollar, altså godt over en halv milliard kroner.

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

Slik ser et enkelt sandwich-angrep ut i praksis. Du legger inn en ordre på en desentralisert børs om å bytte ETH mot en mindre likvid token, og setter en slippage på for eksempel 2 prosent. En bot ser ordren i den offentlige mempoolen, kjøper den samme tokenen rett foran deg og presser prisen opp. Din handel går gjennom til den nå høyere prisen, helt inntil grensen din på 2 prosent, før 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øyere slippage du tillater, desto større bit kan klemmes ut.

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 åpne venterommet der boterne jakter. Det bringer oss til det viktigste avsnittet for lommebok- og børsbrukere.

Privat ordreflyt: Flashbots Protect og MetaMask Smart Transactions

Det reelle vernet mot sandwich er å aldri vise transaksjonen din i den offentlige mempoolen i det hele tatt. Flashbots Protect 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å deler av verdien tilbake som refusjon. Du legger den til som et vanlig RPC i lommeboken din; Flashbots oppgir rpc.flashbots.net og kjede-ID 1 for Ethereum.

Store lommebøker har begynt å bygge dette inn som standard. MetaMask lanserte i mai 2024 Smart Transactions, som sender handelen til en «virtuell mempool» der den holdes privat til den er bekreftet, mens validerte deltakere byr på retten til å inkludere den. MetaMask forhåndssimulerer hver slik transaksjon, noe som både beskytter mot front-running og sandwich og kutter antallet feilede transaksjoner. Prinsippet, private mempooler og selektiv deling av «hint» 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.

Men gratis er det sjelden. Bak den private ordreflyten vokser det fram et marked der lommebøker og RPC-tjenester kan selge retten til å se og bygge rundt transaksjonene dine, gjennom det som kalles ordreflyt-auksjoner. Ideen er at verdien som ellers ville gått til en tilfeldig sandwich-bot, i stedet auksjoneres bort og delvis føres tilbake til deg som refusjon. Baksiden er sentralisering: hvis noen få aktører får eksklusiv tilgang til storparten av ordreflyten, flytter man makten fra en åpen mempool til noen lukkede rom. For deg som bruker er det verdt å vite at «MEV-beskyttelse» ikke betyr at ingen tjener på handelen din, bare at du forhåpentlig får en større del av kaka og slipper den verste klemmen.

Poenget for 7702-brukere er at privat ordreflyt og atomiske batcher utfyller hverandre. Batchen sørger for at handelen din er alt-eller-ingenting; det private endepunktet sørger for at ingen bot får se den før den er avgjort. Sammen er de langt sterkere enn hver for seg.

Børsene, searcherne og 7702-trafikken

MEV er ikke bare en sak mellom deg og en anonym bot; det er også blitt en driftssak for børser og forvaltere. En searcher som vil tjene penger i 2026, kan ikke lenger ignorere 7702-transaksjoner, for de utgjør en voksende del av det som er verdt å analysere, og de ser annerledes ut på ledningen. Samtidig må børser som tar imot innskudd, forholde seg til at en innskuddsadresse plutselig kan bære kode. Vi har sett nærmere på hvordan innskuddsapparatet håndterer dette i artikkelen om når innskuddsadresser kjører kode, der 23-byte-markøren blir noe innskuddssystemet må screene før midler frigis.

For en sentralisert børs er sammenhengen mellom MEV og 7702 mest en risiko på uttakssiden og i den interne konsolideringen av innskudd: en delegert konto kan oppføre seg på måter et enkelt overføringsskript ikke forventer, og en sweeper som er koblet på en innskuddsadresse, kan kjøre samtidig med børsens egen konsolidering. For desentraliserte børser er MEV selve grunnstøyen: hver eneste handel er potensielt en sandwich-mulighet, og det er derfor DEX-aggregatorer i økende grad ruter ordrer gjennom private kanaler og tilbyr MEV-beskyttelse som en funksjon, ikke et tilvalg. Enten du handler på en CEX eller en DEX, er spørsmålet det samme: hvem ser transaksjonen din før den avgjøres?

Glamsterdam og ePBS: forsyningskjeden bygges om

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

ePBS er den som betyr mest for MEV. I dag hviler forholdet mellom proposere og byggere på mellomvare som MEV-Boost og på tredjeparts relayere. EIP-7732 forankrer skillet mellom den som foreslår 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åndtere større datamengder. BALs gir på sin side et kart over avhengighetene mellom transaksjoner på forhånd, noe som muliggjør mer parallell kjøring. For brukeren betyr ikke dette at sandwich forsvinner, men at selve maskineriet som ordner transaksjonene, blir mindre avhengig av å stole på private relayere.

Hva betyr det konkret for deg som bruker? På kort sikt lite: selv med ePBS på plass vil en handel du kringkaster åpent, fortsatt kunne sandwiches, så det praktiske forsvaret ligger uansett i privat ordreflyt. Det ePBS gjør, er å gjøre selve fundamentet sunnere ved å fjerne et lag av tillit til private relayere som i dag kan gå 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 å gli. Poenget er retningen: base-laget tar tilbake ansvaret for hvordan blokker settes sammen, i stedet for å overlate det til frivillig mellomvare.

Native account abstraction er derimot ikke med i Glamsterdam. Forslaget EIP-8141 (frame transactions) er, ifølge ETH Daily, flyttet til «Scheduled for Inclusion» i den påfølgende forken, Hegotá, 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å. Tidslinjen under viser hvordan bitene henger sammen.

FOCIL og «ingen alternativ vei inn»

Det er en dypere MEV-relatert bekymring bak ePBS og native account abstraction, og Vitalik Buterin har vært tydelig på den. Smartkontoer og personvernprotokoller er i dag avhengige av tredjeparts mellomledd bare for å få transaksjonene sine inkludert på kjeden. Buterin har beskrevet denne relay-avhengigheten som en kilde til sårbarhet og skjørhet: hvis en relay går ned, eller en relay-operatør nekter å behandle en bestemt transaksjon, har sluttbrukeren ingen alternativ vei inn i blokka, ifølge news.bitcoin.com.

Svaret utviklerne har landet på, heter FOCIL, fork-choice enforced inclusion lists, ført inn som EIP-7805 og lagt til veikartet i februar 2026. FOCIL lar tilfeldig utvalgte komiteer av validatorer tvinge gjennom at transaksjoner blir inkludert i blokker, slik at ingen enkelt aktør kan sensurere en transaksjon bare ved å nekte å videresende den. Buterin sier mekanismen gir «guaranteed rapid inclusion», altså at nær sagt enhver gyldig transaksjon kommer med innen ett til to slot, selv i et fiendtlig miljø. 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.

Sikkerhet: det er fortsatt nøklene, ikke koden

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

Den største faren for de fleste er likevel gammel: å signere noe man ikke forstår. Da EIP-7702 ble skrudd på, fant Wintermute at over 97 prosent av de tidligste delegeringene var gjenbrukt «CrimeEnjoyor»-kode fra sweepere, men at det ikke var lønnsomt fordi kontoene allerede var tomme, ikke et tegn på en feil i 7702, ifølge CoinDesk. Den dyreste enkelthendelsen så langt, et phishing-tap på 1,54 millioner dollar (rundt 14,5 millioner kroner) i én batch-signatur forkledd som et Uniswap-bytte, er dokumentert av Cryptopolitan. Lærdommen sikkerhetsmiljøet gjentar, er at problemet i bunn og grunn ikke er 7702, men at brukere sliter med å sikre sine egne private nøkler. Blindsignering er fienden, og den samme bug bounty-økonomien som betaler rekordsummer, klarer ikke å stoppe tap som starter med en signatur brukeren selv godkjente.

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

Finanstilsynet, MiCA og MEV-gråsonen

Hvor står så det norske og europeiske regelverket i alt dette? Kort sagt: MEV i seg selv er ikke ulovlig. Det er en konsekvens av hvordan åpne blokkjeder ordner transaksjoner, ikke en tjeneste noen tilbyr under konsesjon. Finanstilsynet fører tilsyn med tjenestetilbydere for kryptoeiendeler (CASP-er) etter MiCA, som ble innlemmet i norsk rett gjennom kryptoeiendelsloven i kraft 1. juli 2025 via EØS-avtalen. Tilsynet retter seg mot børser, forvaltere og utstedere, ikke mot protokollen selv eller din egen selvforvarte smartkonto.

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

Et betimelig spørsmål er om sandwich-angrep egentlig er en form for markedsmanipulasjon. På et regulert marked ville front-running av kundeordrer vært ulovlig, men en desentralisert børs er ikke en regulert markedsplass med en megler som skylder deg beste utførelse. MEV oppstår i en tillatelsesløs protokoll der rekkefølgen på transaksjoner er offentlig spill. Der kryptohandelen derimot skjer med derivater, futures eller evigvarende kontrakter, gjelder MiFID II og markedsmisbruksreglene fullt ut, og en aktør som systematisk utnytter kundeordrer kan komme i myndighetenes søkelys. Grensen går altså ikke ved teknikken, men ved hvilken innpakning handelen har og hvem som tilbyr den.

Slik beskytter du smartkontoen din mot MEV

Det gode er at forsvaret er tilgjengelig og for det meste gratis. En praktisk sjekkliste for en 7702-bruker som vil unngå å bli sandwich-mat:

• 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.
• Les hva batchen faktisk inneholder før du signerer; en godkjenning og et bytte i samme signatur skal du kunne kjenne igjen, ikke blindsignere.
• Sett fornuftig slippage på store handler, og del gjerne svært store ordrer opp i mindre biter.
• Nullstill gamle eller ukjente delegeringer ved å peke på nulladressen, og kontroller delegeringsmarkøren din på en blokkutforsker med jevne mellomrom.
• Foretrekk atomiske batcher framfor mange løse godkjenninger som blir liggende og dingle.
• Hold deg til reviderte lommebøker og kjente delegatorer; en delegering til feil kontrakt gir bort full kontroll i én signatur.

Ingen av punktene krever at du forstår detaljene i ePBS eller FOCIL. De krever bare at du behandler hver signatur som det den er, en instruks til en konto som nå kan gjøre langt mer enn før.

Bunnlinjen

EIP-7702 blir værende. Fram til native account abstraction lander i Hegotá en gang i 2027, er set-code-transaksjonen broen de fleste kontoer krysser, og den broen bærer nå titalls millioner delegeringer. MEV er den delen av regnestykket de ti forrige norske forklaringene hoppet over, og den fortjener oppmerksomhet nettopp fordi den rører ved begge sider av smartkontoen: batching gir deg et skjold, mens den kodebærende kontoen brøt et gammelt vern og skapte nye hensyn helt nede i mempoolen.

Det oppmuntrende er at både base-laget og lommebøkene angriper problemet fra hver sin kant. ePBS og FOCIL bygger om og sikrer forsyningskjeden på protokollnivå, mens privat ordreflyt fra Flashbots og MetaMask allerede har presset sandwich-tallene nedover. Men ingen av delene fritar deg fra å være årvåken. Den samme lærdommen som gjelder for drainere, gjelder for MEV: teknologien gir deg kraftige verktøy, men den siste linjen med forsvar er fortsatt en bruker som leser før hen signerer.

Ofte stilte spørsmål

Hva er MEV, og hvordan rammer det EIP-7702-lommeboken min?

MEV (maximal extractable value) er verdien noen kan hente ut ved å bestemme rekkefølgen på transaksjoner i en blokk, for eksempel ved å kile seg foran eller rundt handelen din. EIP-7702 gjør lommeboken din til en smartkonto som kan pakke flere handlinger i én transaksjon, noe som både gir nye forsvar (atomisk gjennomføring) og nye ting for searchere å analysere.

Beskytter EIP-7702 meg mot sandwich-angrep?

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

Hvordan slår jeg på MEV-beskyttelse i lommeboken?

Bruk en lommebok eller et RPC-endepunkt som sender transaksjonen din privat til byggerne i stedet for den åpne 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.

Endrer Glamsterdam-oppgraderingen hvordan MEV fungerer?

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 å slippe unna sandwich.

Er MEV ulovlig, og hva sier Finanstilsynet?

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.

Av Jonas Ellingsen, redaktør i HOGE Wire. Ingenting i denne artikkelen er investeringsråd.