Femtio signaturer, ett svep: EIP-7702 efter Binance-rånet

Den 29 oktober 2026 räckte det med en enda transaktion. I den låg femtio signerade auktoriseringar, var och en knuten till ett eget löpnummer, var och en pekande på ett kontrakt som bara lydde angriparen. När en av dem träffade rätt löpnummer började Binances heta plånbok köra kod den aldrig själv hade skrivit. Minuter senare var 167 464 ETH och drygt 1,6 miljarder USDT borta, och innan dygnet var slut hade motsvarande omkring 6,36 miljarder dollar (ungefär 64 miljarder kronor) lämnat börsen över tio blockkedjor. Det blev den största kryptostölden som någonsin dokumenterats, enligt TRM Labs.

Mekanismen som gjorde det möjligt heter EIP-7702. Den aktiverades på Ethereum i maj 2025 och var tänkt som en present till vanliga användare: ett sätt att låta ett vanligt konto bete sig som ett smart kontrakt utan att byta adress eller nyckel. Ett och ett halvt år senare är samma funktion både den mest använda plånboksnyheten på åratal och den tekniska ryggraden i ett miljardrån. Den här texten tar isär hur det hänger ihop: vad EIP-7702 faktiskt gör, varför rånet inte var protokollets fel men ändå inte hade sett likadant ut utan det, och vad slutsatsen blir för dig, för kryptobörserna och för Finansinspektionen.

Vad EIP-7702 faktiskt gör

Ett vanligt Ethereum-konto, en så kallad externally owned account eller EOA, är i grunden bara en privat nyckel. Det kan skicka pengar och signera transaktioner, men det kan inte köra egen logik; det finns ingen kod bakom adressen. Ett smart kontrakt kan köra logik, men styrs inte av en nyckel. I tio år har den gränsen varit skarp, och hela idén om det smarta kontot har handlat om att sudda ut den.

EIP-7702 löser det med en ny transaktionstyp (0x04), kallad set code transaction, som kom in i Ethereum genom Pectra-uppgraderingen. Den låter dig signera en auktorisering som säger: lägg en pekare i mitt konto till den här delegatens kod. Tekniskt skrivs en liten markör in i kontots kodfält, 0xef0100 följt av en 20 bytes lång adress, sammanlagt 23 bytes, enligt specifikationen. Så länge markören ligger där kör ditt konto delegatens kod när någon anropar det, men det behåller sin adress, sitt saldo och sin nyckel. Du är fortfarande en EOA; du har bara lånat ett kontrakts beteende.

Det är värt att hålla isär de olika vägarna till ett smart konto, för de ser olika ut i vem som håller nyckeln och vad du kan stänga av.

Anatomin bakom Binance-rånet

Det som gör Binance-fallet lärorikt är inte att EIP-7702 hade en bugg. Det hade det inte. Det lärorika är hur rent funktionen lät sig vändas till vapen när något annat redan hade gått sönder, nämligen börsens system för att signera transaktioner. Enligt TRM Labs byggde angriparen en enda transaktion som innehöll femtio auktoriseringar, alla signerade av Binances heta plånbok. Varje auktorisering pekade på ett sweeper-kontrakt som bara tog order från operatören, alltså angriparen.

Varför femtio? En auktorisering är bunden till kontots löpnummer, dess nonce, och angriparen kände inte till det exakta aktuella värdet. Lösningen var att signera femtio stycken i rad, en för varje tänkbart löpnummer, så att minst en skulle vara giltig när transaktionen kördes. Det är en detalj som säger allt om attackens karaktär: den var inte ett intrång i Ethereum, utan en välförberedd användning av en helt legitim funktion, utförd av någon som redan kunde få börsens signeringssystem att skriva under vad som helst.

När en giltig auktorisering väl låg på kedjan pekade Binance 14, en av börsens primära heta plånböcker, mot angriparens kod. Inom minuter tömdes 167 464 ETH och 63 olika tokens, däribland cirka 1,615 miljarder USDT. Därefter drogs ytterligare omkring 780 miljoner USDC från sekundära plånböcker knutna till Binance 14, och adressen Binance 16 angreps på samma sätt, enligt teknisk analys från Fireblocks som refereras av Blockchain.News. Det var dock inte en Ethereum-händelse. Giltiga signaturer dök upp samtidigt på tio kedjor med, som TRM uttrycker det, ”different chains, key types and signing schemes”. Slutsatsen blev att angriparen hade fått förmågan ”to make Binance’s hot wallet signing system sign transactions of its choosing across chains”.

Hur pengarna fördelade sig över kedjorna säger en del om varför totalsumman blev så svindlande. Den här fördelningen bygger på TRM Labs sammanställning.

TRM tillskriver attacken ”TraderTraitor, North Korea’s elite hacking unit” med hög säkerhet, och pekar på samma mönster som vid Bybit-rånet på 1,5 miljarder dollar: små uttag via Tornado Cash som finansierade en operatörsplånbok, en iscensättning som började långt före stölden, och signaturer som hämtades in i förväg och sedan verkställdes i en enda skur. Ungefär 2,7 miljarder dollar har frysts av stablecoin-utgivare och Arbitrums Security Council, medan runt 2,4 miljarder dollar i tillgångar fortfarande är i rörelse. För den som vill följa hur en börsobduktion växer fram i realtid har vi tidigare beskrivit hur obduktionen av stora hack återvänder till börsen.

Att pengarna till stor del kunde spåras och delvis frysas pekar på rånets paradox. Återhämtningen kom inte från någon egenskap i självförvaringen, utan från dess motsats: centraliserade nödbromsar. Stablecoin-utgivare kunde frysa USDT och USDC, Arbitrums Security Council kunde ingripa, och Binance kunde fylla igen hålet ur sin egen balansräkning så att kunderna gjordes hela. Det är värt att hålla i minnet när man väger ett smart självförvarat konto mot en börs: 7702 ger dig kontrollen, men ingen balansräkning står bakom dig om en signatur går fel.

Var det EIP-7702:s fel?

Det korta svaret är nej, och det är viktigt att säga det tydligt, eftersom rubrikerna lätt ger intrycket att en ny Ethereum-funktion visade sig vara osäker. Det som gick sönder var Binances interna signeringsinfrastruktur. När ett företags system för att skriva under transaktioner är komprometterat spelar det mindre roll vilken mekanism som används därefter; angriparen kan redan få kontot att göra i stort sett vad som helst. Chainalysis beskriver kärnan nyktert: ”the attacker used an operational wallet funded through Tornado Cash to submit valid signed authorizations that allowed a Binance hot wallet to run attacker-deployed code”, enligt deras genomgång av händelsen.

Säkerhetsforskaren Taylor Monahan sa samma sak redan när de första 7702-dränerarna dök upp 2025, och formuleringen har åldrats väl: ”It’s not actually a 7702 issue, its the same issue crypto has had since day one: end users struggle to secure their private keys”, enligt The Block. I samma sammanhang tillade hon att ”7702 just unlocks a bunch of cool abilities that make sweeping addresses more cost efficient and less tedious”. Det är precis det som hände i Binance-fallet, fast uppskalat till institutionell nivå: funktionen gjorde inte intrånget möjligt, men den gjorde själva tömningen billigare, renare och snabbare när intrånget väl var ett faktum.

Ändå går det inte att vifta bort rollen helt. EIP-7702 koncentrerar makt till en enda signatur på ett sätt som äldre konton inte gjorde. Förr krävdes separata transaktioner för att godkänna, flytta och svepa; nu kan en signerad auktorisering knyta ett helt program till kontot. Den egenskapen är poängen för en vanlig användare, och den är också exakt det en angripare vill ha. Rånet är därför inte ett argument mot 7702, men det är ett mycket dyrt argument för att den som signerar måste förstå vad en auktorisering egentligen delar ut.

Det är här sättet att tänka på säkerhet förskjuts. I den gamla världen var hemligheten din privata nyckel, och allt handlade om att skydda den. Med 7702 blir också dina signaturer tillgångar: en signerad auktorisering är i praktiken en nyckel till ett visst beteende, och den kan samlas in i förväg, lagras och utlösas senare, precis som i Binance-fallet där signaturerna hämtades in innan de verkställdes i en skur. Det betyder att det inte räcker att fråga om någon har din nyckel; du måste också fråga vad du har signerat, till vem, och om de signaturerna fortfarande kan användas mot dig.

Samma funktion, andra sidan av myntet

För att se varför 7702 blev så snabbt antaget måste man titta på vardagen, inte på rånet. Den egenskap angriparen missbrukade, att en signatur kan få kontot att köra ett program, är densamma som ger en helt vanlig plånbok förmågor den aldrig hade förut. Du kan bunta ihop ett godkännande och ett byte i en enda transaktion i stället för två. Du kan låta en paymaster betala gasen åt dig, så att du kan handla utan att först äga ETH. Du kan sätta upp en sessionsnyckel som får göra små, avgränsade saker under en begränsad tid. Och du kan koppla på social återhämtning, så att en förlorad nyckel inte längre betyder att allt är förlorat.

Jamie Elkaleh, marknadschef på Bitget Wallet, satte ord på varför branschen tryckte på: det här ”brings self-custody closer to the ease of centralized exchanges”, sa han till The Block. Det är en talande ambition. I åratal har självförvaring betytt sämre användarupplevelse än att låta en börs sköta allt; 7702 var försöket att ta tillbaka bekvämligheten utan att ge upp kontrollen. För den som vill ha en praktisk genomgång av hur man väljer mellan de olika plånbokstyperna har vi gått igenom hur du väljer och säkrar rätt smart plånbok.

Spänningen i hela historien ligger just här. Det finns inte en bra version av 7702 för användare och en dålig version för angripare. Det är samma mekanism. Att en signatur kan betyda så mycket är både det som gör ett smart konto smidigt och det som gör ett komprometterat signeringssystem katastrofalt. Resten av den här genomgången handlar om hur man lever med den dubbelheten.

Siffrorna, och varför de ljuger lite

På ytan ser antagandet enormt ut. Analystjänsten BundleBear räknar in över 280 miljoner auktoriseringar sedan starten, runt 73 miljoner levande delegeringar och drygt 119 miljoner set code-transaktioner. Men den första siffran ljuger lite, och det är värt att veta varför. En stor del av alla auktoriseringar har aldrig handlat om bekvämlighet, utan om tömning.

Den mest delegerade koden på Ethereum är nämligen inte en plånbokstillverkares kontrakt, utan en liten sweeper som branschen döpt till CrimeEnjoyor. Den används för att automatiskt vittja konton vars nyckel redan läckt. Wintermute beskrev fenomenet så här: ”The CrimeEnjoyor contract is short, simple, and widely reused”, och ”this one copy-pasted bytecode now accounts for the majority of all EIP-7702 delegations”, enligt The Block. Med andra ord: en betydande andel av det som ser ut som 7702-användning är i själva verket brottsplatser, inte nöjda användare.

Bilden blir ännu tydligare i forskningen. En studie presenterad vid USENIX Security 2026, ”Revealing the Dark Side of Smart Accounts” av Mingyuan Huang med kollegor, gick igenom 3,66 miljoner 7702-auktoriseringar på sju kedjor och fann att omkring 63 procent av dem var knutna till kontrakt kontrollerade av angripare. Forskarna bekräftade manuellt 924 skadliga kontraktskonton, flera av dem tidigare orapporterade, och beräknade realiserade förluster på runt 2,36 miljoner dollar plus ytterligare exponering på drygt 10 miljoner. Det är små summor jämfört med Binance, men poängen är mönstret: den tidiga användningen av 7702 drevs i hög grad av dem som ville komma åt andras pengar. De meningsfulla talen att följa är därför de levande delegeringarna, inte de kumulativa auktoriseringarna.

Det finns en annan siffra värd att lägga märke till. ERC-4337, den äldre vägen till smarta konton via separata kontraktskonton, har efter flera år nått ungefär lika många aktiva konton som 7702 har levande delegeringar, båda i storleksordningen drygt sjuttio miljoner enligt samma BundleBear-dashboard. Det säger något om var branschen landat: de två modellerna konkurrerar inte längre om att vinna, de smälter samman. En vanlig plånbok kan använda en 7702-delegering för att peka på logik av 4337-snitt, och för användaren suddas skillnaden ut. Det är en tyst men viktig förskjutning, för den innebär att det smarta kontot inte längre är ett experiment utan den normala formen för ett Ethereum-konto.

Priset i kronor

Något av det mest obehagliga med rånet är kontrasten i kostnad. Att signera en auktorisering kostar nästan ingenting i gas; själva de femtio signaturer som vände Binances plånbok var i sammanhanget en försumbar utgift jämfört med vad de låste upp. Samma billighet gäller förstås den vanliga användaren, och det är en av de verkliga vinsterna med 7702. Nedan ett räkneexempel på vad olika åtgärder kostar vid ett gaspris på ungefär 5 gwei och ETH runt 19 300 kronor, enligt CoinGecko (priset föll cirka 6 procent på ett dygn, så exakta kronor varierar).

Siffrorna är just ett räkneexempel; faktisk kostnad rör sig med gaspriset, som kan vara både lägre och mångdubbelt högre när kedjan är belastad. Poängen är storleksordningen. Att slå på ett smart konto kostar ungefär vad en enkel överföring kostar, och en paymaster kan dessutom ta betalt i stablecoin i stället för ETH, vilket Bitget redan gör på flera kedjor. För en vanlig användare är tröskeln alltså praktiskt taget noll, och det är exakt därför funktionen spridit sig så fort.

Börsens blinda fläck: att läsa ett konto med kod

Om rånet har en tydlig adressat utöver Binance självt, så är det resten av börsbranschen. I åratal byggde börser och förvarare på ett tyst antagande: ett vanligt konto, en EOA, har ingen kod, och därför kan det inte bete sig som ett kontrakt. På den regeln vilade bland annat det gamla skyddet i EIP-3607, tanken att en adress med kod inte får vara avsändare. EIP-7702 river den regeln. Nu kan en helt vanlig insättningsadress bära en 0xef0100-markör och köra logik som börsen inte har granskat.

Det tvingar fram två sorters hemläxa. Den första handlar om insättningar. En börs måste numera läsa varje inkommande adress och kontrollera om den är delegerad, alltså om kodfältet börjar med 0xef0100 och är exakt 23 bytes. Är den det behöver börsen veta vilken delegat adressen pekar på innan den behandlar en insättning eller ett uttag, annars kan den luras av ett konto vars beteende ändras mitt i ett flöde. Den andra läxan är den Binance just fick: att skydda sin egen signeringsinfrastruktur. Det var där allt brast. En het plånbok som kan fås att signera godtyckliga auktoriseringar är i praktiken redan förlorad, oavsett om verktyget heter 7702 eller något annat.

Svaret stavas i allt högre grad MPC och policymotorer: signeringsnycklar splittras över flera parter så att ingen enskild komprometterad server kan skriva under ensam, och regler avgör vilka kontrakt en utbetalning över huvud taget får röra. Men policymotorer hjälper bara om de faktiskt granskar innehållet i det som signeras. Rånet visade att hastigheten i ett 7702-svep lämnar nästan ingen tid att reagera; Binance 14 var tömd på minuter. Hur den operativa upplevelsen kring ett plånbokssvep förändras efter oktober har vi tecknat i genomgången av plånbokens UX efter Binance-rånet.

I praktiken landar mycket i vitlistor. En börs kan välja att bara acceptera insättningar från odelegerade konton, eller att enbart tillåta delegeringar till en kort lista av granskade delegatkontrakt och flagga allt annat för manuell kontroll. Det låter strängt, men alternativet är att i blindo lita på kod man aldrig sett. Samma logik gäller uttag: en utbetalning till en delegerad adress kan betyda att mottagaren är en helt vanlig användare med ett smart konto, eller att adressen i tysthet dirigerar om pengarna. Skillnaden syns bara om man läser delegaten, och det är den sortens kontroll som skiljer en börs som lärt sig av oktober från en som inte gjort det.

Har du redan ett smart konto?

Många som läser det här har redan en delegering de aldrig aktivt valde. Under 2026 gick flera plånböcker, bland dem MetaMask, över till att slå på smarta konton som standard för nya användare. Det betyder att du kan ha en 0xef0100-markör på ditt konto utan att minnas att du bett om den. Att kontrollera saken är enkelt och tar en minut.

Slå upp din adress på en blockutforskare som Etherscan och titta om kontot visas som delegerat; en EOA med en delegering har ett kodfält på exakt 23 bytes som inleds med 0xef0100, följt av delegatens adress. Tjänster som Revoke.cash har en särskild flik för 7702-delegeringar, men var medveten om att den i regel bara låter dig inspektera, inte återkalla, enligt deras förklaring. I MetaMask kan du se och slå av det smarta kontot per kedja under kontoinställningarna. Det viktiga är att göra kontrollen på varje kedja du använder, eftersom en delegering gäller en adress på en bestämd kedja, inte nyckeln som sådan; samma adress kan vara delegerad på Ethereum men orörd på Arbitrum, eller tvärtom.

Att delegeringen ofta sker tyst är en poäng i sig. När en plånbok slår på smarta konton som standard flyttas ett aktivt val till att bli ett förval, och de flesta klickar sig förbi utan att läsa. Det är inte nödvändigtvis fel; förvalen pekar i regel på granskad kod. Men det betyder att ansvaret för att veta vad man har tyst har flyttats till användaren. Den som aldrig kontrollerat sitt konto kan alltså vara delegerad utan att veta det, och första gången man upptäcker det borde inte vara efter en incident.

Av-knappen: återkalla eller stänga dörren för gott

Det finns två sätt att bli av med en delegering, och de är inte samma sak. Det första är att återkalla den: du signerar en ny auktorisering som pekar kontot mot nolladressen, vilket nollställer kodfältet och gör dig till en vanlig EOA igen. Det är reversibelt; du kan delegera på nytt i morgon. En viktig hake är att en återkallelse rensar koden och kodhashen men inte nödvändigtvis lagringen som en tidigare delegat kan ha skrivit, vilket OpenZeppelin varnar för; behandla ett konto som haft en okänd delegat med samma försiktighet som ett uppgraderbart kontrakt.

Det andra sättet är nytt och kom som ett direkt svar på hösten. Dagen efter Binance-rånet lämnade utvecklaren nicolashw in ett utkast, numrerat EIP-8476, som beskriver en permanent avregistrering. I stället för markören 0xef0100 skrivs en 0xef0200 in, som för all framtid blockerar kontot från att delegeras, medan EVM rapporterar kodfältet som tomt. Förslaget ligger som öppet utkast och är inte antaget. Det är också värt att läsa det finstilta: en permanent avregistrering stoppar inte en läckt nyckel från att flytta pengar, den återkallar inte befintliga godkännanden, och den kan bryta återhämtningslösningar som själva bygger på delegering.

Skillnaden mellan att återkalla och att stänga dörren för gott är i grunden en fråga om vem du är. En aktiv användare som vill ha batchning och gaslösa transaktioner vill kunna slå av och på. En långsiktig förvarare som aldrig tänker använda ett smart konto kan föredra en permanent spärr, just för att eliminera hela klassen av delegeringsrisker. Vi har resonerat mer om den valfriheten i texten om rätten att förbli en dum plånbok.

Hårdvara och konsten att läsa det du signerar

Hela Binance-rånet vilade på signaturer, och det pekar på den kanske mest underskattade försvarslinjen: förmågan att faktiskt förstå vad man skriver under. En 7702-auktorisering är inte en vanlig överföring. På en hårdvaruplånbok som inte kan visa innebörden blir den lätt en obegriplig hexsträng, och då signerar man blint. Blindsignering har legat bakom en lång rad stölder, och det är i den miljön en delegering kan smyga sig in.

Branschens svar heter clear signing: att enheten översätter transaktionen till något begripligt innan du godkänner, så att en auktorisering visas som just en delegering till en namngiven delegat och inte som brus. Standarden ERC-7730, som samlar strukturerade beskrivningar av vad en transaktion gör, togs över av Ethereum Foundation som förvaltare under 2026 och är en del av den rörelsen. För en hårdvaruplånbok är stödet för 7702 och clear signing i praktiken skillnaden mellan att se att du är på väg att delegera ditt konto och att inte ana det. Det är ingen slump att de säkraste rutinerna numera börjar med att aldrig godkänna en signatur man inte kan läsa i klartext.

Sessionsnycklar, spel och agenter

Dubbelheten i 7702 blir som tydligast när man tittar framåt, mot det funktionen egentligen är byggd för. En sessionsnyckel är en avgränsad fullmakt: ett spel eller en app får göra vissa små saker åt dig under en begränsad tid, utan att du behöver skriva under varje enskild handling. För blockkedjespel är det en förutsättning för att spelandet över huvud taget ska kännas som ett spel och inte som en ändlös rad av signeringsdialoger. När kontot kan köra logik kan det också säga ja till tusen små speldrag men nej till att tömmas. Vi har tittat närmare på hur den sortens kontomodell förändrar ägandet i genomgången av Aptos, spelen och frågan om vem som äger spelaren.

Samma logik driver den framväxande vågen av AI-agenter som ska kunna betala för tjänster på egen hand, ofta i stablecoin och ofta i väldigt många små transaktioner. Ett smart konto med spenderingstak och tidsbegränsade fullmakter är det naturliga hemmet för en sådan agent. Men poängen tål att upprepas: en sessionsnyckel är en delegering, och en delegering är en fullmakt. Binance-rånet var i grunden en fullmakt som hamnade i fel händer, bara på institutionell skala. Varje gång du ger ett spel eller en agent rätt att agera i ditt namn ger du bort en bit kontroll, och värdet av funktionen står och faller med hur snävt den fullmakten är skriven.

Glamsterdam, native AA och vägen framåt

En vanlig missuppfattning är att Ethereums nästa stora uppgradering ska städa upp i allt det här. Det stämmer inte. Glamsterdam handlar om genomströmning, inte om konton. Dess tyngsta delar är ePBS (EIP-7732) och block-access lists (EIP-7928), alltså sätt att göra blocken effektivare, inte att förändra hur ett smart konto fungerar. Uppgraderingen har dessutom glidit på tidtabellen: aktiveringen på testnätet Hoodi sköts upp i slutet av oktober sedan säkerhetsutvecklare flaggat för att föreslagna gasändringar kunde störa redan utplacerade kontrakt, enligt Ethereum Foundation och CoinDesk. Något fast datum för huvudnätet finns inte; utvecklarna siktar löst på början av december, men den officiella listan står tom.

Det som på riktigt skulle jämna ut 7702:s skarpa kanter är native account abstraction, alltså att konton och kod förenas på protokollnivå i stället för via en lånad pekare. Där pågår en designstrid mellan två läger: Ethereums eget spår kring frame-transaktioner (EIP-8141) och Bases nyckelregister (EIP-8130). Derek Chiang, som leder ZeroDev, sammanfattade varför det tar tid: en gemensam lösning ”required one side or the other to compromise at least a little bit on their core goals”, sa han till The Block. Oavsett vilket läger som vinner är tidslinjen 2027 i bästa fall. Till dess är EIP-7702 inte en övergångslösning på väg bort, utan den modell vi faktiskt lever med.

FI, MiCA och skatten

Var hamnar ett delegerat självförvarat konto i det svenska regelverket? Kort svar: mestadels utanför det. MiCA, EU:s kryptoförordning som gäller direkt i Sverige, reglerar utgivare och leverantörer av kryptotjänster, så kallade CASP, inte själva protokollet och inte din privata plånbok. Finansinspektionen är den behöriga myndigheten under MiCA, och sedan den 1 oktober 2025 måste varje kryptoföretag som riktar sig till svenska kunder ha ansökt om tillstånd hos FI eller upphöra; företag som redan var registrerade hade på sig till den 30 september 2025 att lämna in ansökan. Det är börsen eller förvararen som träffas av reglerna, inte du som signerar en auktorisering i din egen plånbok.

Det betyder också att ansvaret ser olika ut beroende på var du förvarar. Använder du en förvarare omfattas den av MiCA:s ansvarsregler för förvaring; håller du nycklarna själv bär du själv risken, precis som Binance-rånet illustrerade på sitt eget plan. En sak MiCA inte rör är kryptoderivat; terminer och eviga kontrakt är finansiella instrument under MiFID II och övervakas som sådana, inte under MiCA. Och för Skatteverket ändrar ett smart konto ingenting i sak: en försäljning eller ett byte är fortfarande en avyttring som ska redovisas på blankett K4, och ett gaslöst eller batchat byte är lika skattepliktigt som ett vanligt. Att en paymaster betalade gasen ändrar inte att en avyttring skett.

Checklista: så hanterar du ditt delegerade konto

Rånet var en institutionell händelse, men lärdomarna skalar ned till den enskilda plånboken. Det här är de praktiska stegen.

• Kontrollera om ditt konto redan är delegerat: titta efter ett kodfält på 23 bytes som börjar med 0xef0100 på varje kedja du använder, inte bara på Ethereum.
• Ta reda på vilken delegat du pekar på. En delegering är ett beroende, inte en funktion; vet vems kod som kör ditt konto.
• Återkalla delegeringar du inte känner igen genom att sätta kontot till nolladressen, och kom ihåg att lagring kan ligga kvar efteråt.
• Överväg en permanent spärr (EIP-8476, när den finns) för konton med stora saldon som du ändå aldrig tänker använda som smarta konton.
• Signera aldrig en auktorisering du inte kan läsa i klartext; prioritera en hårdvaruplånbok med stöd för clear signing.
• Håll stora långsiktiga innehav på en separat, odelegerad kall adress, skild från det konto du använder till vardags.
• Kom ihåg att en sessionsnyckel är en fullmakt: ge bara spel och agenter så smala rättigheter som uppgiften kräver, och återkalla dem när du är klar.

Ett och ett halvt år efter att EIP-7702 aktiverades är domen varken att funktionen var ett misstag eller att den är ofarlig. Den gjorde självförvaring smidigare än någonsin, och den gav det största kryptorånet i historien dess sista, eleganta steg. Båda sakerna är sanna samtidigt, och de följer av exakt samma egenskap: att en signatur kan betyda ett program. Det bästa försvaret är därför inte att undvika smarta konton, utan att behandla varje auktorisering som den fullmakt den faktiskt är.

Vanliga frågor

Vad är EIP-7702?

EIP-7702 är en Ethereum-funktion som kom med Pectra-uppgraderingen i maj 2025. Den låter ett vanligt konto (en EOA) peka på ett smart kontrakts kod via en markör, 0xef0100, och därmed köra program som batchade transaktioner, gaslösa betalningar och sessionsnycklar, utan att byta adress eller nyckel.

Orsakade EIP-7702 Binance-hacket 2026?

Nej. Grundorsaken var att Binances interna signeringssystem komprometterades. När angriparen väl kunde få systemet att signera använde de EIP-7702 för att låta en het plånbok köra deras kod, med femtio auktoriseringar i en enda transaktion. Funktionen gjorde tömningen effektivare, men intrånget skedde i signeringsinfrastrukturen, inte i protokollet.

Hur vet jag om mitt konto är delegerat?

Slå upp din adress på en blockutforskare som Etherscan och titta om kodfältet är 23 bytes och börjar med 0xef0100; då är kontot delegerat. Kontrollera varje kedja för sig, eftersom en delegering gäller en adress på en bestämd kedja och inte nyckeln. Verktyg som Revoke.cash kan också visa delegeringen.

Hur återkallar jag en EIP-7702-delegering?

Du signerar en ny auktorisering som pekar kontot mot nolladressen, vilket nollställer koden och gör dig till en vanlig EOA igen. Det är reversibelt. Observera att lagring som en tidigare delegat skrivit kan ligga kvar, så behandla ett konto med okänd delegat försiktigt. För ett permanent stopp finns utkastet EIP-8476.

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

Funktionen i sig har inte haft någon känd bugg, men den koncentrerar makt till en signatur, så risken ligger i vad du signerar och vem du delegerar till. Använd en hårdvaruplånbok med clear signing, delegera bara till granskad kod, håll stora innehav på en separat odelegerad adress, och återkalla delegeringar du inte känner igen.

Av Yuki Tanaka, senior redaktör på HOGE Wire med fokus på plånböcker, kryptobörser och Ethereums kontoinfrastruktur.