Delegaten du aldrig läste: EIP-7702:s dolda beroende 2026

Under de första veckorna efter att Ethereums Pectra-uppgradering aktiverades på mainnet den 7 maj 2025 lade analytiker på marknadsgaranten Wintermute märke till något besynnerligt. Mer än 97 procent av alla nya EIP-7702-delegationer pekade mot i praktiken identisk kod: korta, kopierade kontrakt som fått öknamnet «CrimeEnjoyor» och vars enda syfte var att automatiskt dränera inkommande ETH från redan komprometterade adresser.

Rubrikerna lät som en katastrof, men berättelsen bakom siffran är mer avslöjande än paniken. Den säger något grundläggande om vad EIP-7702 gör med ditt konto. Din adress slutar vara enbart en nyckel och blir en pekare till kod som någon annan har skrivit, distribuerat och kontrollerar. Frågan som nästan ingen ställer när de trycker på knappen «uppgradera till smart konto» är kort men obekväm: vems kod pekar mitt konto på, och vad får den göra med mina pengar?

Det här är inte ännu en förklaring av hur account abstraction fungerar. Det är en granskning av delegaten, alltså det kontrakt som numera sitter mellan din privata nyckel och ditt saldo. Vi går igenom varför nästan alla delegationer klumpar ihop sig hos en handfull kontrakt, vad det innebär för systemrisk och leverantörslåsning, vad specifikationen själv varnar för, och hur Finansinspektionens och MiCA:s syn på förvaring gör bilden grumligare för svenska användare. ETH handlades kring 2 690 dollar (runt 26 500 kronor) i slutet av september 2026, enligt CoinDesk, men det som står på spel när du delegerar är inte priset på en token. Det är kontrollen över hela kontot.

Vad EIP-7702 faktiskt gör med ditt konto

EIP-7702 kom med Pectra och införde en ny transaktionstyp, 0x04. Med den kan ett vanligt konto, en externally owned account eller EOA, signera en auktorisation som sätter kontots kod. Auktorisationen är en liten datastruktur på formen [chain_id, address, nonce, y_parity, r, s]. När den bakas in i en transaktion skrivs kontots kod om till en så kallad delegeringsindikator: byte-sekvensen 0xef0100 följd av en 20 byte lång kontraktsadress, totalt 23 byte, enligt själva specifikationen.

Effekten är att ditt konto beter sig som kontraktet på den adressen, samtidigt som du behåller samma privata nyckel och samma adress. Plötsligt kan kontot bunta ihop flera åtgärder i en transaktion, låta någon annan betala gasen, och dela ut tidsbegränsade nycklar till appar. Ethereums egen dokumentation beskriver detta som steget som gör EOA:er programmerbara utan att de byter identitet.

Två egenskaper är viktiga för resten av den här artikeln. För det första är delegeringen beständig. Den ligger kvar tvärs över transaktioner tills du aktivt tar bort den. Du återkallar genom att signera en ny auktorisation mot nolladressen 0x0000…0000, vilket nollställer kontots kod. För det andra kan en auktorisation göras kedjeoberoende: sätter du chain_id till 0 gäller den på alla kedjor samtidigt, annars bara på den kedja du anger. Den lilla detaljen får stora konsekvenser, vilket vi återkommer till.

Ett konkret exempel gör skillnaden tydlig. Utan delegering måste du först godkänna en token och sedan i en separat transaktion byta den, betala gas två gånger och signera två gånger. Med en delegat kan plånboken bunta ihop godkännande och byte till en enda signerad åtgärd, och en relayer kan skjuta till gasen så att du slipper hålla ETH för avgifter. Det är den upplevelsen som gör 7702 attraktivt, och det är samma mekanism som gör en skadlig delegat så farlig: kraften att göra flera saker på en gång tillhör kontraktet, inte dig.

Delegaten är inte din kod

När du «uppgraderar» distribuerar du normalt inte ditt eget kontrakt. Din plånbok pekar dig mot en färdig implementation som leverantören har valt. OpenZeppelin beskriver mönstret i sin dokumentation för EOA-delegering: du lånar logik från ett delat kontrakt. MetaMask använder till exempel en variant som kallas EIP7702StatelessDeleGator, som delar adress med din EOA och medvetet inte lagrar någon signerardata i själva kontraktet, och som bygger på gränssnittet ERC-7710, vilket framgår av deras öppna delegation framework. Ambire, som lanserade stöd redan när Pectra gick live och beskriver sig som den första förlängningsplånboken med 7702-stöd, har sin egen delegat.

Konsekvensen är enkel att missa men svår att överskatta. Tusentals, i förlängningen miljoner, konton pekar mot exakt samma bytecode. Ditt smarta konto är i praktiken en tunn pekare; logiken bor i ett kontrakt du inte skrev och inte ensam kan ändra. Om leverantören uppgraderar eller distribuerar en ny version är det den koden som avgör vad ditt konto kan göra.

Förtroendet flyttar därmed. Tidigare gällde regeln «skydda din nyckel, så är du säker». Efter en delegering måste du lita på tre saker samtidigt: din nyckel, författarna bakom delegaten, och den som har rätt att byta ut delegaten. Det är en helt annan riskmodell än den de flesta trodde att självförvaring innebar.

Siffrorna som chockade: när 97 procent pekade åt samma håll

Wintermutes genomgång av den första månaden efter Pectra gav den tydligaste illustrationen. Mer än 97 procent av alla delegationer pekade mot identisk sweeper-kod, och vid ett tillfälle använde över 80 procent återanvänd, kopierad kod. Angriparna hade lagt cirka 2,88 ETH på att auktorisera ungefär 79 000 adresser, och en enda adress stod för över 52 000 av dem.

Det fascinerande är att kampanjen inte var lönsam. De stulna medlen flödade till adresser utan några inkommande ETH-överföringar, alltså tomma kassor. Wintermute beskrev kontraktet som kort, enkelt och återanvänt i stor skala, och kallade situationen både mörk och märklig. Firman var samtidigt noga med att påpeka att EIP-7702 inte är trasigt och är säkert att använda.

Nyansen är avgörande, för den skiljer FUD från fakta. En sweeper fungerar bara efter att en privat nyckel redan har läckt. EIP-7702 orsakade inte stölderna; det industrialiserade städningen av redan kapade plånböcker, eftersom en delegering gör det trivialt att tömma varje krona som råkar landa på adressen. Men datan blottlägger ett strukturellt faktum som gäller även de laglydiga: delegationer koncentreras massivt till ett fåtal kontrakt. Den skadliga varianten är bara det mest synliga uttrycket för mönstret. Analytiker på DefiHackLabs visade till och med att den enskilt mest använda delegaten under en period var ett rent phishing-kontrakt.

Koncentrationsrisken: en bugg, miljoner konton

Vänd nu på resonemanget. Om miljoner konton pekar mot en och samma legitima implementation blir den koden en enda gemensam felkälla. En allvarlig bugg i ett brett använt delegatkontrakt skulle inte drabba en användare, utan alla som pekar mot det, samtidigt. Sprängradien är hela användarbasen, inte ett enskilt konto.

Historien ger perspektiv. Kryptobranschens största förluster har sällan berott på trasig kryptografi, utan på delad kod och nycklar som brustit på ett ställe och drabbat många på en gång. Delegatmodellen lägger till ännu en sådan gemensam nämnare, den här gången direkt kopplad till vanliga plånböcker snarare än till broar eller stora protokoll. Skillnaden är att en delegat kan bytas ut och återkallas, vilket ger en utväg som en hårdkodad bugg i ett broprotokoll sällan gör. Men utvägen förutsätter att användaren vet att den finns.

Det här är inte en hypotetisk oro som journalister hittat på. Specifikationen själv, författad av bland andra Vitalik Buterin och Sam Wilson, varnar i sina egna säkerhetsöverväganden för att en dåligt implementerad delegat kan «ge en illasinnad aktör nära fullständig kontroll över en signerares EOA», enligt EIP-texten. Samma dokument pekar på risken för lagringskollisioner när ett konto flyttas mellan delegater, ett problem som standarden ERC-7201 försöker mildra, och på att den vanliga initieringsfasen saknas, vilket tvingar fram signaturbaserad verifiering.

Att en handfull kontrakt bär upp nästan all aktivitet är alltså en tveeggad egenskap. Å ena sidan innebär det att välgranskad kod återanvänds i stället för att var och en snickrar ihop sin egen buggiga variant. Å andra sidan koncentreras risken till just de kontrakten. När ett protokoll väl har brustit är frågan inte bara hur mycket som gick förlorat, utan vilka som överlever granskningen efteråt, ett tema vi har behandlat i vår genomgång av livet efter hacket.

De vanligaste delegaterna och vad de gör

Bilden nedan förenklar, men fångar spännvidden mellan seriös infrastruktur och rent illvillig kod. Gemensamt för alla är att de samlar upp många konton bakom samma bytecode.

Leverantörslåsning: ditt smarta konto följer inte med

Koncentrationen skapar ett andra problem som sällan diskuteras: inlåsning. MetaMask:s delegat är inte densamma som Ambires, som inte är densamma som Safes. Sätter du din delegering i en plånbok och öppnar en annan i morgon, säg Rabby eller Ambire, följer inte kontots «smarthet» med. Sessionsnycklar, behörigheter och eventuell återställningskonfiguration hör till det kontrakt du valde, och den nya plånboken kanske varken förstår det eller vill annat än att be dig delegera om.

Det här är en annan sorts portabilitetsproblem än det vi tidigare beskrivit när ett smart konto inte följer med mellan olika kedjor. Där handlar det om att en auktorisation ofta är knuten till en specifik chain_id. Här handlar det om inlåsning mellan plånböcker på samma kedja. Gränssnitt som ERC-7710 och ERC-7715 syftar till interoperabilitet, men i praktiken binder valet av delegat dig till ett ekosystem.

För en användare som trott att självförvaring betyder full rörlighet är det en obehaglig insikt. Din on-chain-identitet blir en pekare mot en leverantörs kontrakt, och att byta leverantör innebär att nollställa och börja om från noll.

Vad specifikationen själv varnar för

Det är värt att stanna vid specifikationens säkerhetsavsnitt, eftersom det är författarna själva som ritar upp farorna. Utöver delegatens makt över kontot nämns front-running vid initiering: eftersom ett 7702-konto saknar den vanliga initieringskoden måste uppsättningen ske via signaturkontroll med ecrecover, annars kan någon hinna före. Lagringskollisioner tas upp som en reell risk vid migrering mellan delegater. Och noder rekommenderas att inte acceptera mer än en väntande transaktion för en EOA med aktiv delegering, just för att delegerad kod kan tömma kontot oväntat, enligt specifikationens säkerhetsöverväganden.

Ett övervägande sticker ut för den som följer MEV. EIP-7702 bryter delvis antagandet att tx.origin är lika med msg.sender enbart i den översta anropsramen, ett antagande som en del skydd mot sandwich-attacker lutar sig mot. Vi har tidigare beskrivit hur ett smart konto både kan bli ett mål och en sköld i MEV-spelet. Poängen här är enklare: även de som konstruerade 7702 pekar ut delegaten som den farliga ytan.

Vem granskar koden du litar på?

Om delegaten är den farliga ytan blir granskning avgörande. Seriösa delegatkontrakt bör revideras av oberoende part. Säkerhetsfirman Halborn har publicerat en genomgång av vad som måste kontrolleras specifikt i 7702-delegater, och forskarvärlden har börjat ta itu med problemet på allvar: arbetet DelegProof presenterar en maskinkontrollerad, formell säkerhetsanalys av EIP-7702-delegering.

Vad letar en granskare efter i en delegat? De klassiska frågorna handlar om vem som får anropa vad, om signaturer kan spelas upp igen på en annan kedja, om lagringen krockar med en framtida version, och om det finns någon dold uppgraderingsnyckel som ger utvecklaren tyst kontroll. Just uppgraderingsrätten är central: kan koden bakom din delegat bytas ut utan att du märker det spelar det mindre roll hur säker den var den dag du delegerade. En läsbar delegat talar om detta i klartext.

Problemet är att nästan ingen användare läser koden. Ett minimikrav är att kontraktet är verifierat och märkt hos en blockutforskare, så att du åtminstone ser vem det utger sig för att vara. Men märkning är inte granskning, och en verifierad källkod kan fortfarande vara farlig.

Här möter tekniken en förtroendefråga som liknar den vi ställt om byggare i stort: hur vet du att den som skrev och underhåller delegaten är att lita på? När rykte och meritlista blir verifierbara on-chain blir det åtminstone möjligt att skilja seriösa team från anonyma. Skillnaden mot ett vanligt token-godkännande är dessutom viktig: en delegat kan styra hela kontot, inte bara en enskild tillgång du gett tillstånd till.

Phishing-vektorn: «uppgradera ditt konto»

Den mest akuta risken för vanliga användare är inte en abstrakt bugg, utan ett bedrägeri. Mönstret är rakt: en angripare lurar dig att signera en 7702-auktorisation mot en skadlig delegat, ofta utanför plånboken via en webbplats eller ett mejl. I samma stund kan delegaten tömma allt. Att du kan förlora alla dina tokens om du delegerar till ett skadligt kontrakt är inte en överdrift, utan en beskrivning av hur mekanismen fungerar.

MetaMask har därför byggt in en varning som är värd att upprepa: en uppgradering till smart konto sker bara inne i plånboken. Ber en webbplats eller ett mejl dig signera något utanför plånboken för att «uppgradera» eller «aktivera» smarta funktioner är det med säkerhet ett bedrägeriförsök, enligt plånbokens egen information till användare. Rådet låter banalt men träffar rätt, eftersom hela attacken bygger på att en enda signatur kan lämna över kontot.

Så kontrollerar och återkallar du din delegation

Det praktiska är enklare än det låter, och alla som använder ett delegerat konto bör kunna det. En kort checklista:

• Slå upp din adress hos en blockutforskare. Visar kontots kod byte-sekvensen 0xef0100 följd av en adress har du en aktiv delegering, och du ser vilket kontrakt den pekar mot.
• Kontrollera att målet är känt och märkt, till exempel MetaMask, Ambire eller Safe. Ett omärkt, nyskapat kontrakt är ett varningstecken.
• Återkalla genom att signera en ny auktorisation mot nolladressen, vilket nollställer koden. Tänk på att detta kräver en transaktion; om nyckeln redan är komprometterad kan en sweeper hinna före.
• Föredra delegater som delar adress med din EOA och inte lagrar egen signerardata, eftersom de ger kontraktet mindre självständig kontroll.

Checklista innan du delegerar

Självförvaring eller inte? Finansinspektionen och MiCA

Var landar allt detta juridiskt? MiCA reglerar leverantörer av kryptotillgångstjänster, CASP:er, och en av de reglerade tjänsterna är just tillhandahållande av förvaring och administration av kryptotillgångar för kunders räkning. Sådan verksamhet kräver tillstånd, i Sverige från Finansinspektionen, enligt artikel 62 i MiCA och kommissionens delegerade förordning (EU) 2025/305. Företag som drev sådan verksamhet före årsskiftet 2024/2025 fick en övergångsperiod men skulle ansöka senast den 30 september 2025.

En vanlig, icke-depåförvarande plånbok är inte en CASP. Du håller nyckeln, och du kan återkalla. Att peka ditt konto mot ett delegatkontrakt överför i sig inte förvaringen så länge du behåller nyckeln och rätten att nollställa. Så långt är självförvaring fortfarande självförvaring.

Gråzonen uppstår när delegaten låter någon annan flytta pengar åt dig. Sessionsnycklar med utgiftsrätt, gaslösa relayers eller en social återställning som i praktiken kontrolleras av leverantören börjar närma sig administration för kunders räkning. Var gränsen går är ännu inte prövat specifikt för 7702-delegater, och varken Finansinspektionen eller ESMA har dragit en skarp linje. Slutsatsen för svenska användare är att «icke-depåförvarande» blivit en glidande skala i samma stund du delegerar. Läs vad delegaten faktiskt får göra.

Ekonomin bakom delegaten: vem betalar för koden

Någon distribuerar, granskar och underhåller delegaten, och någon betalar gasen när transaktioner sponsras. De kostnaderna försvinner inte för att användaren slipper se dem. Vi har tidigare grävt i vem som egentligen betalar för det gaslösa, och delegaten är en central del av den ekonomin, eftersom det är den och den tillhörande relayern eller paymastern som avgör vem som kan sponsra och styra ordningen på transaktioner.

Det finns dessutom en incitamentsfråga. En «gratis» delegat kan tjäna pengar på andra sätt, genom transaktionsordning och MEV, genom data, eller helt enkelt genom den inlåsning den skapar. Och koncentrationen har en ekonomisk drivkraft: det är billigare och tryggare att återanvända en välgranskad implementation än att bygga sin egen. Just den rationella impulsen är det som klumpar ihop alla hos ett fåtal kontrakt, vilket i sin tur ökar systemrisken. Paradoxen är inbyggd.

Underhållsbördan är inte trivial. Ett kontrakt som miljoner konton lutar sig mot måste följa med när nya EIP:er landar, när kedjor ändrar regler och när nya attacker upptäcks. Den som bär det ansvaret behöver intäkter, och saknas de riskerar delegaten att bli övergiven kod som ingen vågar röra men alla är beroende av. Frågan om vem som betalar är därför inte bara en fråga om gas, utan om vem som håller själva infrastrukturen vid liv över tid.

Vad detta betyder för svenska användare och börser

För en privatperson är slutsatsen konkret: delegaten är den nya sak du måste granska, precis som du bör granska ett smart kontrakt innan du godkänner det. Fråga vem som skrev koden, om den är reviderad, om du kan återkalla, och om du låser in dig hos en leverantör. En signatur räcker för att lämna över kontot, så behandla varje uppmaning att «uppgradera» med samma misstänksamhet som en okänd transaktion.

För börser och förvarare är det en driftsfråga. En insättningsadress som är en delegerad EOA beter sig annorlunda, och en börs bör kunna upptäcka delegeringsindikatorn 0xef0100 och besluta om policy: acceptera, flagga, eller hantera uttag med särskild försiktighet. Frågan har blivit skarpare i takt med att allt fler konton uppgraderas, och den kopplar direkt till hur förvarare läser och hanterar smarta konton i sina system.

För svenska sparare som möter krypto via reglerade aktörer efter MiCA blir det här en fråga om information lika mycket som teknik. En plattform som förklarar vad en delegat är, vilka den litar på och hur du återkallar gör mer för säkerheten än den som gömmer allt bakom en knapp märkt «uppgradera». Läsbarhet är i praktiken den nya formen av konsumentskydd.

Kvar står en avvägning. EIP-7702:s löfte, bättre UX, gaslösa transaktioner, buntning och återställning, är verkligt och redan i bruk. Men mekanismen flyttar förtroendet in i ett kontrakt som nästan ingen läser. Vinnarna blir de plånböcker som gör delegaten läsbar: märkt, granskad, återkallbar, och ärlig om inlåsningen. Tills dess är det bästa försvaret den enklaste frågan. Vems kod pekar mitt konto på?

Frequently Asked Questions

Vad är en delegat i EIP-7702?

En delegat är det smarta kontrakt som ditt konto pekar mot efter en 7702-uppgradering. Din adress och nyckel är oförändrade, men kontots kod sätts till en delegeringsindikator (0xef0100 följt av kontraktets adress), och det är kontraktets logik som körs när kontot anropas.

Är EIP-7702 säkert att använda?

Själva mekanismen anses säker, och marknadsgaranten Wintermute har uttryckligen sagt att EIP-7702 inte är trasigt. Risken ligger i vad du delegerar till. En skadlig delegat kan tömma kontot, och de så kallade sweepers som dominerade statistiken fungerar bara på konton vars nyckel redan läckt.

Hur ser jag vilket kontrakt mitt konto pekar på?

Slå upp din adress hos en blockutforskare och titta på kontots kod. Börjar den med 0xef0100 har du en aktiv delegering, och de följande 20 byten anger kontraktsadressen. Kontrollera sedan att målet är verifierat och märkt.

Hur återkallar jag en delegation?

Du signerar en ny auktorisation som pekar mot nolladressen 0x0000…0000, vilket nollställer kontots kod. Det kräver en transaktion, så gör det från en säker nyckel; är nyckeln redan komprometterad kan en sweeper hinna före.

Räknas det som förvaring enligt MiCA om jag delegerar?

I regel nej, så länge du behåller nyckeln och kan återkalla; då är du fortfarande självförvarande. Gråzonen uppstår om delegaten låter en leverantör flytta dina medel, vilket kan närma sig sådan förvaring för kunders räkning som kräver tillstånd från Finansinspektionen.

Av redaktionen på HOGE Wire. Denna text är journalistik, inte finansiell eller juridisk rådgivning.