EIP-7702: delegeringen du glömde att återkalla
Hundratals miljoner EIP-7702-auktoriseringar har signerats, men bara runt 61 miljoner delegeringar är levande. Så kontrollerar och städar du ditt smarta konto innan någon annan gör det.
Det finns ett tal som borde oroa fler ägare av smarta konton än det gör. På BundleBears instrumentpanel har EIP-7702 samlat på sig över en kvarts miljard auktoriseringar sedan uppgraderingen Pectra gick live i maj 2025, men bara runt 61 miljoner delegeringar är i själva verket levande just nu. Skillnaden är inte ett mätfel. Den är summan av allt som signerats och sedan lämnats kvar: sweeper-bottar som auktoriserar om sig i det oändliga, kontrakt som bytts ut, och, viktigast för dig som läser detta, delegeringar som människor satte upp en gång och aldrig kom att tänka på igen.
EIP-7702 gjorde din vanliga plånboksadress programmerbar utan att du behövde flytta en enda krona till ett nytt konto. Det var poängen, och det är också fällan. En delegering är inte en session som löper ut när du stänger fliken. Den är ett tillstånd som ligger kvar på kedjan tills du aktivt ändrar det. Med ether kring 2 690 dollar (drygt 26 600 kronor per ether i slutet av september 2026, med dollarn kring 9,90 kronor, enligt MetaMask) är ett konto med en glömd delegering inte en abstrakt risk. Det är en dörr som du lämnat på glänt mot kod du kanske inte ens minns att du pekade på.
Den här artikeln handlar inte i första hand om vad EIP-7702 är, det har vi skrivit om förr, utan om det som nästan ingen guide tar upp: hur du kontrollerar vad ditt konto faktiskt pekar på, hur du återkallar en delegering på riktigt, varför en återkallelse inte städar bort allt, och varför hela jobbet måste göras om på varje kedja. Kort sagt: delegeringshygien.
Vad EIP-7702 egentligen gör med din adress
EIP-7702 kom med Pectra-uppgraderingen den 7 maj 2025 och införde en ny transaktionstyp, 0x04, en så kallad set-code-transaktion. Den låter en vanlig plånboksadress (en EOA, externally owned account) peka på koden i ett smart kontrakt. Adressen och den privata nyckeln är oförändrade; det som ändras är att kontot nu kör ett kontrakts logik när det anropas. I praktiken får du de funktioner som annars kräver ett kontraktskonto: du kan bunta ihop flera steg i en enda transaktion, låta någon annan betala gasavgiften, och sätta upp begränsade sessionsnycklar för appar och spel.
Mekaniken är enkel, och det är just därför den är lätt att glömma. När du godkänner en delegering signerar din plånbok en auktorisering (ett tupel av kedje-id, kontraktsadress och nonce). Kedjan skriver sedan in en pekare i ditt konto: tre byte, 0xef0100, följt av den 20 byte långa adressen till kontraktet. Den pekaren ligger kvar. Den försvinner inte när transaktionen är klar, den försvinner inte nästa vecka, och den bryr sig inte om att du bytte plånboksapp för ett halvår sedan. För en fördjupning i vem som faktiskt äger och styr koden du pekar på, se vår genomgång av det dolda beroendet i delegatkontraktet.
| Egenskap | Vanlig EOA | ERC-4337-konto | EIP-7702-konto |
|---|---|---|---|
| Adress | Din nyckeladress | Ny kontraktsadress | Din nyckeladress (oförändrad) |
| Privat nyckel styr | Ja | Nej (kontraktslogik) | Ja, men delegerad kod kör med |
| Buntade transaktioner | Nej | Ja | Ja |
| Gassponsring | Nej | Ja (paymaster) | Ja |
| Migrering krävs | Ingen | Ja, flytta tillgångar | Nej, samma konto uppgraderas |
| Delegeringen ligger kvar | Ej relevant | Ej relevant | Ja, tills du återkallar |
Delegeringen är ett tillstånd, inte en session
Om du har använt krypto ett tag känner du igen mönstret från token-godkännanden. Du gav en gång en DEX rätten att spendera dina USDC, glömde bort det, och år senare påminde en tjänst som Revoke.cash dig om att godkännandet fortfarande gällde. En EIP-7702-delegering är samma sorts kvardröjande beslut, fast ett steg djupare. Ett token-godkännande ger ett kontrakt rätt att röra en viss tillgång. En delegering gör ett kontrakts kod till ditt kontos kod. Det är inte en behörighet du gett bort, det är hela beteendet hos ditt konto som pekats om.
Det finns ingen inbyggd förfallotid. Specifikationen har ingen mekanism som säger att en delegering upphör efter en vecka eller när du loggar ut. Den som satte pekaren måste ta bort den. Det betyder att en delegering du godkände i en plånboksapp du sedan slutade använda fortfarande gäller, och att koden den pekar på fortfarande kör varje gång kontot anropas. Om det kontraktet dessutom är en uppgraderbar proxy kan logiken bakom din pekare ha ändrats sedan du godkände den, utan att din pekare rörts.
Det är den mentala modellen hela artikeln vilar på: inte att du en gång använde ett smart konto, utan att ditt konto pekar just nu på ett visst kontrakt och kommer att göra det tills du ändrar det. Frågan är inte om du någon gång testade en 7702-funktion. Frågan är vad ditt konto pekar på i det här ögonblicket, och om du vet det.
Gapet: en kvarts miljard signaturer, 61 miljoner levande konton
Siffrorna hjälper till att se problemets form. BundleBears 7702-instrumentpanel visade i slutet av september 2026 runt 257 miljoner kumulativa auktoriseringar, cirka 61,5 miljoner levande delegeringar och drygt 108 miljoner set-code-transaktioner. Det första talet, de kumulativa auktoriseringarna, är kraftigt uppblåst och ska läsas med försiktighet: en enda sweeper-bot kan auktorisera om tusentals adresser om och om igen, så det talet mäter aktivitet, inte antal människor. Det meningsfulla talet är de levande delegeringarna, alltså konton som just nu har en aktiv pekare.
Gapet mellan de två talen är inte 196 miljoner bortglömda plånböcker; det vore en missläsning. Gapet är summan av churn: auktoriseringar som ersatts av nyare, delegeringar som återkallats, och sweeper-mönster som räknas många gånger. Men inne i de 61,5 miljoner levande delegeringarna finns en delmängd som ingen instrumentpanel kan storleksbestämma exakt, nämligen de konton vars ägare satte en pekare och sedan gick vidare. Det är den delmängden den här artikeln vill hjälpa dig ur.
Ett sätt att tänka på det är att varje delegering befinner sig i ett av fyra tillstånd. Tre av dem är oproblematiska. Det fjärde är det du vill undvika, eftersom det är osynligt just för att du slutat titta på det.
| Tillstånd | Vad det betyder | Risknivå |
|---|---|---|
| Aktiv och avsedd | Du använder plånboken; pekaren går till ett kontrakt du valt | Låg, så länge du litar på kontraktet |
| Återställd till noll | Du har återkallat; kontot är en vanlig EOA igen | Ingen delegeringsrisk |
| Sweeper-ockuperad | Pekaren sattes av en angripare efter en nyckelläcka | Kritisk; nyckeln är redan komprometterad |
| Aktiv och bortglömd | Du satte pekaren en gång och tänker inte längre på den | Latent; beror på vad koden gör och kan göra |
Så ser en delegering ut på kedjan: 0xef0100
Den goda nyheten är att en delegering inte är gömd. Den ligger öppet i kontots kod, och du kan läsa den utan specialverktyg. När ett konto är delegerat sätts dess kod till en delegeringsindikator: tre byte, 0xef0100, följt av den 20 byte långa adressen till kontraktet, totalt 23 byte. Formatet står i EIP-7702-specifikationen, och det är också därför opkoder som EXTCODESIZE returnerar exakt 23 för ett delegerat konto: det är storleken på indikatorn, inte på kontraktets faktiska kod.
Praktiskt innebär det att du kan slå upp din egen adress på en blockutforskare som Etherscan och titta på fältet för kontraktskod. Börjar bytekoden med 0xef0100 har kontot en aktiv delegering, och de 20 byte som följer är adressen till kontraktet det pekar på. Kopiera den adressen och slå upp den i sin tur: är den verifierad, känd, granskad? Är det din plånbokstillverkares kontrakt, eller något du inte känner igen? Det här är grundsanningen. Instrumentpaneler och plånboksmenyer är bekvämare, men blockutforskaren visar vad som faktiskt står skrivet i ditt konto, utan mellanhänder som tolkar åt dig.
Varför en bortglömd delegering är en risk
En delegering till ett kontrakt du valt och litar på är i grunden trygg. Risken uppstår när tre saker glider isär: vad du trodde du godkände, vad kontraktet faktiskt kan göra, och vad det kan göra i framtiden. Om kontraktet bakom din pekare är en icke uppgraderbar singleton är den sista frågan avförd; koden kan inte ändras. Men många ramverk använder proxymönster, och då kan logiken bakom samma adress bytas ut efter att du godkänt den. Din pekare rörs inte, men det den pekar på gör det, och du får ingen ny signaturruta som varnar dig.
Den andra risken är blindsignering. Ett delegerat konto kan köra en buntad transaktion med flera steg, och om din plånbok bara visar en ogenomtränglig hash i stället för läsbara detaljer godkänner du något du inte kan granska. Det var precis den mekaniken som låg bakom flera av de dyraste 7702-relaterade stölderna: offret signerade en batch som innehöll token-överföringar och NFT-godkännanden på en gång. Vi har gått igenom den attackytan mer i detalj i artikeln om smarta konton som mål och sköld.
Den tredje risken är den mest banala och den vanligaste: du minns helt enkelt inte vad du gjorde. En pekare du satte för att testa en spelplånbok eller hämta en airdrop ser likadan ut på kedjan som en pekare du satte medvetet till din huvudplånbok. Utan hygien blir de omöjliga att skilja åt, och den du inte tittar på är den som blir farlig.
Konkret ser attackvägen ofta likadan ut. En angripare som redan kommit över din nyckel, via nätfiske, en läckt seed eller skadlig kod, behöver inte tömma kontot direkt. Med en delegering kan de sätta upp ett kontrakt som automatiskt vidarebefordrar allt som landar på adressen, så att varje framtida insättning försvinner i samma ögonblick den kommer in. En bortglömd men legitim delegering gör inte det, men den utökar ytan av kod som kan anropas mot ditt konto, och ju mindre du minns om den, desto svårare blir det att bedöma om en signaturbegäran är rimlig eller en fälla.
Poängen är inte att EIP-7702 är trasigt. Säkerhetsforskare är påfallande eniga om att protokollet i sig inte är buggigt. Taylor Monahan, säkerhetsforskare på MetaMask, sammanfattade det efter en uppmärksammad stöld på 1,54 miljoner dollar: ”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” (via Cryptopolitan). En bortglömd delegering är inte ett protokollfel. Den är ett stående beroende som du slutat hålla koll på, och beroenden du inte tittar på är precis de som blir farliga.
CrimeEnjoyor och kyrkogården av övergivna konton
Den mest synliga delen av 7702-landskapet är också den mörkaste. Kort efter Pectra upptäckte handelsfirman Wintermute att en förkrossande majoritet av de tidiga delegeringarna, över 97 procent, pekade på kontrakt med identisk bytekod. Det var inte plånbokstillverkare, utan sweepers: enkla kontrakt vars enda uppgift är att automatiskt tömma inkommande ether från redan komprometterade adresser. Familjen fick namnet CrimeEnjoyor, och en viktig nyansering följde direkt: det här är inte ett protokollfel. Kontrakten sätts upp efter att en privat nyckel redan läckt, och Wintermute konstaterade att de knappt är lönsamma; enligt rapporten spenderade de omkring 2,88 ether på att auktorisera runt 79 000 adresser.
Att sweepers är olönsamma gör dem inte harmlösa för dig. De skapar en kyrkogård av delegerade adresser, och när nya varianter dyker upp har Wintermute fortsatt att flagga dem så att plånböcker och utforskare kan varna användare (Cointelegraph). Bilden bekräftas av forskning: en studie som presenterades vid USENIX Security 2026 analyserade drygt 3,6 miljoner 7702-auktoriseringar över sju kedjor fram till mitten av juli 2025 och fann att över 63 procent var knutna till skadliga kontrakt, med 924 distinkta bekräftade skadliga kontraktskonton. Läs talet rätt: det räknar auktoriseringar, inte drabbade användare eller förlorade kronor, eftersom angriparnas kontrakt återanvänds oproportionerligt ofta.
Den bredare trenden är faktiskt uppmuntrande. Enligt Scam Sniffer föll de totala förlusterna från plånbokstömmare med 83 procent under 2025, till omkring 84 miljoner dollar. Men trenden döljer en förskjutning: batch-signeringsbedrägerier som utnyttjar just 7702 blev en större andel av de största enskilda stölderna. Med andra ord blir ekosystemet säkrare i genomsnitt samtidigt som den specifika 7702-vektorn mognar. Att systematiskt lära av haverier i efterhand, snarare än att skylla ifrån sig, är en kultur kryptovärlden fortfarande importerar från spelbranschen, något vi utvecklat i genomgången av vad som gick fel. Det är ännu ett skäl att inte lämna en delegering obevakad.
Så kontrollerar du dina delegeringar
Att kontrollera är enklare än de flesta tror, och det finns tre kompletterande sätt. Inget av dem kräver att du flyttar tillgångar eller signerar något riskabelt; att läsa är gratis och ofarligt.
- Blockutforskaren (grundsanningen): slå upp din adress på Etherscan och titta på kontraktskoden. Börjar den med 0xef0100 har du en aktiv delegering, och de följande 20 byte är kontraktet.
- Revoke.cash (överblick): tjänstens delegerings-flik visar dina 7702-delegeringar samlat. Notera dock en viktig begränsning: du kan se dem där, men du kan inte återkalla dem därifrån, eftersom de flesta plånböcker inte låter externa appar röra 7702-delegeringar.
- Plånboksappen: i MetaMask hittar du det under kontomenyn (de tre prickarna) och Kontouppgifter, där smarta konton listas per kedja enligt MetaMasks egen guide.
Gör det här för varje adress du bryr dig om, inte bara din huvudplånbok. Testkonton, gamla spelplånböcker och adresser du använde för en enda airdrop är precis de som mest sannolikt bär en bortglömd pekare, eftersom de är de du minst sannolikt tittar på.
Så återkallar du: nolladressen och en högre nonce
Att återkalla en delegering innebär att skriva över pekaren med ingenting. Tekniskt signerar du en ny set-code-auktorisering som pekar på nolladressen, 0x0000000000000000000000000000000000000000, med en högre nonce än den förra. Kedjan verifierar att auktoriseringen kommer från din EOA, rensar kontots kod och återställer kod-hashen till den tomma hashen. Kontot är därmed en vanlig EOA igen, och exploateringsfönstret stängs.
I praktiken behöver du sällan konstruera den transaktionen för hand. De vanligaste vägarna är dessa:
- Via plånboken: i MetaMask öppnar du Kontouppgifter, går till smarta konton och stänger av funktionen för varje kedja där den är aktiv. Det utfärdar återkallelsetransaktionen åt dig.
- Via ett verktyg: öppen kod som codeesura/eip7702-clean-delegation automatiserar återkallelsen från kommandoraden.
- Via en sponsor: samma verktyg har ett sponsrat läge där ett annat konto betalar gasavgiften, vilket är avgörande för en komprometterad adress som redan tömts på ether men fortfarande behöver återkalla en sweeper-pekare.
Det sponsrade läget är värt att stanna vid. En klassisk återvändsgränd är att en drabbad adress inte har någon ether kvar att betala gas med, och därför inte kan städa efter sig. Att en tredje part kan betala för återkallelsen bryter den låsningen, och det är också den mekanik som whitehat-räddare använder när de hjälper offer att stänga en pekare innan mer hinner tömmas. Ett viktigt förbehåll: en återkallelse tar bort pekaren, men om nyckeln redan läckt är kontot fortfarande komprometterat, och då ska du sluta använda adressen helt, inte återanvända den.
Ett vanligt scenario gör det konkret. Säg att du för ett år sedan testade en gaslös funktion i en plånboksapp du sedan bytte bort. Din huvudplånbok kan inte visa pekaren, eftersom en annan app satte den, och Revoke.cash kan visa den men inte ta bort den. Vägen framåt blir då antingen att öppna den gamla appen igen och stänga av funktionen där, eller att använda ett fristående verktyg som signerar återställningen mot nolladressen åt dig. Det är krångligare än det borde vara, och det är just därför en tidig kontroll lönar sig: ju färre bortglömda pekare du samlar på dig, desto mindre av det här detektivarbetet behöver du göra.
| Verktyg | Kan visa | Kan återkalla | Att tänka på |
|---|---|---|---|
| Etherscan | Ja (0xef0100) | Nej | Grundsanning; kräver ingen inloggning |
| Revoke.cash | Ja (delegerings-flik) | Nej | Endast inspektion; återkalla i plånboken |
| MetaMask | Ja (per kedja) | Ja (per kedja) | Stänger av smart konto en kedja i taget |
| codeesura CLI | Nej | Ja | Öppen kod; har ett sponsrat läge |
Fällan: återkallelse rensar koden, inte lagringen
Här kommer den del som nästan alla guider hoppar över, och som kan ställa till mer skada än den glömda delegeringen själv. Att återkalla rensar kontots kod och nollställer kod-hashen, men det rensar inte kontots lagring. OpenZeppelins dokumentation är tydlig: en återställning tar bort koden men rör inte de lagringsvariabler som det tidigare delegatkontraktet skrev.
För en ren återkallelse till en vanlig EOA spelar den kvarvarande lagringen sällan någon roll i praktiken. Problemet uppstår när du inte återkallar utan i stället pekar om till ett nytt kontrakt. Då kan det nya kontraktets variabler krocka med det gamlas kvarvarande lagring, och OpenZeppelin varnar uttryckligen för att en sådan krock kan göra din EOA oanvändbar. Rekommendationen är att behandla ombytet som en uppgradering av ett smart kontrakt, med samma disciplin kring lagringslayout som gäller för uppgraderbara kontrakt.
Den praktiska slutsatsen är enkel. Om ditt mål är att bli av med en delegering, återkalla till nolladressen i stället för att peka om till ett annat kontrakt på måfå. Om du byter plånbokstillverkare, lita på att appens egen migreringsväg hanterar lagringen korrekt hellre än att peka om manuellt. Städning ska förenkla ditt konto, inte förvandla det till ett minfält av gammal lagring.
En kedja i taget, och när kontot inte är ditt att återkalla
En delegering gäller per kedja. Pekaren du satte på Ethereum finns inte på Arbitrum eller Base om du inte auktoriserat den där också, och omvänt: att återkalla på en kedja rör inte de andra. Det betyder att hygienarbetet måste upprepas överallt du varit aktiv. En adress kan vara ren på huvudnätet och samtidigt bära en bortglömd pekare på en L2 där du en gång gjorde ett enda test. Vi har skrivit mer om varför ditt smarta konto inte följer med mellan kedjorna i genomgången av portabilitet.
Det finns ytterligare en hake, och den är obekväm. Stödet för att återkalla godtyckliga delegeringar är ojämnt mellan plånböcker. Många appar kan sätta och ta bort de delegeringar de själva skapat, men saknar den transaktionstyp som krävs för att ta bort en delegering som en annan app, eller en angripare, satte. Om din adress bär en pekare som din nuvarande plånbok inte kan röra kan du behöva den ursprungliga appen, ett fristående verktyg, eller det sponsrade läget ovan. Ekosystemet känner till luckan; rådet från flera håll är att aktivt be sin plånbokstillverkare att lägga till stöd för att återkalla godtyckliga delegeringar.
För den som förvaltar flera konton, till exempel spelplånböcker eller en kassa, blir det här en rutinfråga snarare än en engångsstädning. Samma logik som gäller för att välja rätt konto från början, vilket vi tog upp i artikeln om spelkontot och nästa miljard spelare, gäller för att stänga det snyggt: gör det per kedja, dokumentera vad varje adress pekar på, och gå igenom listan med jämna mellanrum.
Börser läser din delegering
Delegeringshygien är inte bara en självförvarsfråga, den påverkar hur du möter börserna. Centraliserade plattformar måste förhålla sig till att en insättningsadress kan vara en delegerad EOA, och flera screenar numera inkommande adresser för just den 23 byte långa indikatorn. En adress som pekar på ett känt sweeper-kontrakt kan behandlas annorlunda än en ren EOA: flaggas, fördröjas, eller kräva extra kontroll innan medel krediteras.
För dig som användare betyder det två saker. För det första: en ren, odelegerad adress, eller en som pekar på ett känt och legitimt kontrakt, ger minst friktion när du för medel till och från en börs. För det andra: om du någon gång tar emot medel på en adress som bär en sweeper-pekare bör du utgå från att nyckeln är komprometterad och sluta använda adressen helt, i stället för att försöka rädda den. En ren delegeringsstatus är, kort sagt, en del av att vara en välskött motpart, inte bara en privat säkerhetsdetalj.
Finansinspektionen, MiCA och självförvarets ansvar
För svenska läsare är regelbilden viktig att få rätt. MiCA gäller direkt i Sverige, och Finansinspektionen är den behöriga myndigheten. Sedan den 1 oktober 2025 måste varje kryptoföretag som riktar sig till svenska kunder ha ansökt om tillstånd hos Finansinspektionen eller upphöra med verksamheten; företag som redan var registrerade hade fram till den 30 september 2025 på sig att ansöka. Regleringen träffar leverantörer av kryptotjänster (CASP), alltså börser, förvarare och växlare, inte själva protokollet eller din privata plånbok.
Det är just därför delegeringshygien landar hos dig. Ett självförvarat konto, inklusive ett EIP-7702-konto du styr med din egen nyckel, faller utanför CASP-ramverket. Ingen tillståndspliktig mellanhand ansvarar för att din pekare är ren, för att du återkallat en gammal delegering eller för att du gjort det på varje kedja. ESMA klargjorde i mars 2025 gränsen mellan finansiella instrument och rena verktygs- eller speltokens, men den gränsdragningen ändrar inte grundprincipen: förvarar du själv, ansvarar du själv. Kryptoderivat, till exempel perpetuals, är för övrigt finansiella instrument under MiFID II och övervakas som sådana, inte under MiCA.
Glamsterdam och varför hygienen inte försvinner
Det ligger nära till hands att hoppas att nästa uppgradering gör hela frågan inaktuell. Det gör den inte, åtminstone inte snart. Ethereums nästa hårdgaffel, Glamsterdam, testkörs på Sepolia den 6 oktober 2026 (preliminärt 13:53 UTC, enligt beslutet från utvecklarsamtalet den 17 september), men dess tyngdpunkt ligger på genomströmning och blockproduktion, inte på kontomodellen. Huvudnumret är ePBS (EIP-7732), som flyttar in separationen mellan blockförslagsställare och byggare i själva protokollet.
Uppgraderingen är dessutom fortfarande en generalrepetition. Ett datum för huvudnätet är inte fastställt (färdplanen anger tentativt fjärde kvartalet 2026), och utvecklare har flaggat att värdelös test-ether kan låta illasinnade byggare vinna blockauktioner och hålla inne data på testnätet (Crypto Briefing). Det verkligt inbyggda kontostödet, i form av frame-transaktioner för en framtida fork, ligger längre bort och är dessutom föremål för en pågående designsplittring mellan Ethereum och Base.
Slutsatsen är enkel. Så länge delegeringsmodellen är det som faktiskt körs, och den kommer att vara det under överskådlig framtid, är delegeringshygien en del av vanligt självförvar, ungefär som att återkalla token-godkännanden blev det. Marius van der Wijden, kärnutvecklare på Ethereum, har beskrivit 7702 som ett sätt för befintliga plånböcker att efterlikna smarta konton, men påpekat att kanterna fortfarande behöver slipas (via DL News). En av de kanterna är precis den här: det är enkelt att slå på, och det är på dig att stänga av.
En enkel hygienrutin, steg för steg
Det mesta i den här artikeln kokar ner till en rutin du kan göra på en kvart, ett par gånger om året eller varje gång du slutar använda en plånbok. Poängen är inte att bli paranoid, utan att göra pekarna till något du faktiskt ser i stället för något du glömt. Så här ser en enkel genomgång ut.
- Lista dina adresser: huvudplånbok, spelkonton, kassor och de engångsadresser du använt för airdrops eller tester. Det är de sista som oftast bär en bortglömd pekare.
- Läs varje adress på kedjan: kontrollera på en blockutforskare om koden börjar med 0xef0100, och notera vilket kontrakt den pekar på.
- Bedöm kontraktet: känner du igen det, är det din plånbokstillverkares, och är det verifierat? Ett okänt kontrakt är en signal att agera.
- Återkalla det du inte använder: återställ pekaren till nolladressen via plånboken eller ett verktyg, hellre än att peka om på måfå.
- Upprepa per kedja: gör om samma sak på varje nätverk där adressen varit aktiv, eftersom en delegering gäller per kedja.
Den som förvaltar värden åt andra, till exempel en DAO-kassör eller en spelstudio med många plånböcker, bör dessutom skriva ner rutinen och lägga in den i kalendern. En delegering som ingen äger ansvaret för är precis den sortens tysta beroende som en obduktion i efterhand brukar peka ut som orsak. Bättre att stänga dörren i förväg än att förklara den efteråt.
Frequently Asked Questions
Hur vet jag om min plånbok har en aktiv EIP-7702-delegering?
Slå upp adressen på Etherscan och titta på kontraktskoden; börjar den med 0xef0100 finns en aktiv delegering, och de följande 20 byte är kontraktet. Revoke.cash och MetaMasks kontouppgifter visar samma sak i mer läsbar form.
Hur återkallar jag en EIP-7702-delegering?
Genom att signera en ny set-code-auktorisering mot nolladressen med en högre nonce. I MetaMask görs det via Kontouppgifter genom att stänga av smart konto per kedja, och öppna verktyg som codeesura eip7702-clean-delegation kan göra det från kommandoraden, även med en sponsor som betalar gasen.
Försvinner delegeringen av sig själv om jag slutar använda plånboken?
Nej. En delegering har ingen förfallotid och ligger kvar som ett tillstånd på kedjan tills du aktivt återkallar den. Att byta app eller vara inaktiv tar inte bort pekaren.
Rensar en återkallelse allt i mitt konto?
Nej. Att återkalla rensar kontots kod och kod-hash men inte dess lagring. För en ren återgång till en vanlig EOA spelar det sällan roll, men om du pekar om till ett nytt kontrakt kan kvarvarande lagring krocka och i värsta fall göra kontot oanvändbart, så behandla ombytet som en kontraktsuppgradering.
Måste jag återkalla på varje kedja separat?
Ja. Delegeringar gäller per kedja, så en pekare på Ethereum påverkar inte Arbitrum eller Base, och att städa på en kedja rör inte de andra. Gå igenom varje kedja där adressen varit aktiv.
Av Yuki Tanaka, senior redaktör på HOGE Wire med fokus på plånböcker, självförvar och kontosäkerhet.