EIP-7702 möter börsen: så hanteras ditt smarta konto 2026
Sexton månader efter Pectra möter ditt smarta konto börsen och förvararen. Så läser handelsplatser av en delegerad adress, och så skyddar du dig i insättnings- och uttagsflödet.
Den 7 maj 2025 aktiverades EIP-7702 i Ethereums Pectra-uppgradering. Sedan dess kan en helt vanlig Ethereum-adress bära programkod utan att byta adress och utan att bli ett separat kontrakt. Sexton månader senare har antalet så kallade set-code-transaktioner passerat 100 miljoner, och antalet aktiva delegeringar ligger kring 55 miljoner enligt BundleBear. ETH handlas den här veckan kring 2 455 dollar, ungefär 23 500 kronor, enligt CoinDesk. De flesta av de uppgraderingarna skedde tyst inuti plånböcker, utan att användaren fattade ett aktivt beslut.
Den del av historien som fått minst uppmärksamhet handlar inte om hur din plånbok förändrades, utan om vad som händer i kanten: när ett smart konto möter en börs eller en förvarare i insättnings- och uttagsflödet. Det är där självförvar och reglerad verksamhet tar i varandra, och det är där de nya riskerna blir en praktisk fråga för både handelsplatsen och dig som flyttar pengar. Den här genomgången utgår från förvararens och börsens perspektiv snarare än plånboksanvändarens, eftersom det är den vinkeln som saknats i den svenska bevakningen hittills.
Snabbrepetition: vad EIP-7702 gör med ditt konto
EIP-7702 inför en ny transaktionstyp, 0x04, som brukar kallas set code. Med den kan innehavaren av en vanlig plånbok (en externally owned account, EOA) signera en auktorisering som pekar kontot mot ett smart kontrakt. På kedjan syns det som att kontots kodfält fylls med en designator: bytesekvensen 0xef0100 följd av en 20 bytes lång kontraktsadress, tillsammans 23 bytes. Adressen och den privata nyckeln är oförändrade; kontot lånar bara logik från kontraktet det pekar på. Detaljerna finns i den ursprungliga EIP-7702-specifikationen.
Två egenskaper är centrala för resten av den här texten. Den första är att en delegering återställs genom att peka kontot mot nulladressen; då försvinner koden och kontot blir en vanlig EOA igen. Den andra är att en auktorisering signerad med chain_id satt till noll gäller på alla EVM-kedjor samtidigt, vilket är bekvämt men också en replay-risk. Ethereums egen vägledning för Pectra understryker dessutom att det inte längre går att anta att tx.origin är en enkel plånbok, en detalj som får konsekvenser långt utanför utvecklarnas kod.
Själva auktoriseringen är en liten datastruktur: en lista med tupler som var och en innehåller kedjans id, adressen till koden som ska lånas, ett nonce och en signatur. Meddelandet som signeras inleds med ett magiskt byte, 0x05, vilket gör att en delegeringssignatur aldrig kan förväxlas med en vanlig transaktion. EIP-7702 ersätter inte ERC-4337, standarden som infört paketerade transaktioner via ett EntryPoint-kontrakt sedan 2023, utan kompletterar den, och den senaste EntryPoint-versionen känner till 7702 och kan använda samma konton. För en börs är det värt att förstå att de två teknikerna ofta uppträder tillsammans, och att ett och samma konto kan vara både 7702-delegerat och del av ett 4337-flöde.
Varför ett smart konto är en börs- och förvararfråga
Nästan all infrastruktur för handelsplatser och förvarare byggdes på ett antagande: en inkommande adress är antingen en enkel EOA eller ett känt kontrakt, och de två beter sig olika. EIP-7702 river den gränsen. En uttagsadress som ser ut som en helt vanlig plånbok kan i själva verket köra kod i samma ögonblick som den tar emot pengar. För en börs betyder det att både insättnings- och uttagssidan behöver ett nytt kontrollsteg som inte fanns före maj 2025.
Det här är baksidan av samma konvergens som gör att en börs numera kan kännas som en plånbok, ett tema vi tog upp i analysen av när börsen blir din plånbok. När plånbok och handelsplats smälter ihop på användarsidan uppstår en spegelbild på operatörssidan: förvararen måste nu tolka kod där den tidigare bara såg en mottagare. Ingen protokolländring krävde det, men verkligheten gjorde det oundvikligt.
Tre kontotyper sett från förvararens stol
Det enklaste sättet att förstå den operativa skillnaden är att ställa de tre kontotyperna bredvid varandra och fråga hur en börs faktiskt behandlar var och en av dem.
| Egenskap | Vanlig EOA | ERC-4337-konto | EIP-7702-konto |
|---|---|---|---|
| Adress | 0x-adress | ny kontraktsadress | samma EOA-adress |
| Vem styr | privat nyckel | kontraktslogik plus nyckel eller passkey | privat nyckel plus delegerad kod |
| Hur börsen ser den | enkel mottagare | kontrakt (kan avvisas av äldre system) | ser ut som EOA men bär kod (0xef0100) |
| Kan tömmas vid insättning | nej | beror på koden | ja, om den delegerats till en sweeper |
| Återkallelse | ej relevant | byt kontrakt eller nyckel | delegera till nulladressen |
Den fjärde raden är den som håller riskchefer vakna. En vanlig EOA kan aldrig dränera sig själv i det ögonblick den tar emot en insättning. Ett EIP-7702-konto kan det, om den delegerade koden är skriven för att vidarebefordra allt som kommer in. Det gör insättnings- och uttagsadresser till något som måste granskas, inte bara registreras.
Så läser en börs av en delegerad insättningsadress
Rent tekniskt är kontrollen enkel: en börs eller förvarare frågar noden efter kontots kod och tittar efter prefixet 0xef0100. Finns det där är adressen delegerad, och de följande 20 byten avslöjar vilket kontrakt den pekar på. Ethereums vägledning noterar att kompletterande verktyg kan meddela en användare att en delegering är på plats genom att läsa av kontots kod, och samma logik gäller på operatörssidan. Vem som helst kan göra kontrollen manuellt via eip7702.app, som byggts av Curvegrid och visar delegeringar över flera kedjor.
Det operativa problemet uppstår i två riktningar. På insättningssidan vill börsen veta om avsändaradressen bär kod som kan bråka med interna redovisningssystem, till exempel genom att skicka tillbaka eller vidarebefordra medel automatiskt. På uttagssidan är frågan allvarligare: om en kund begär ett uttag till en adress som redan delegerats till en dränerande sweeper, hamnar utbetalningen i praktiken direkt i angriparens händer. Just den varianten, där en delegering och en gassponsrad transaktion samverkar, hänger ihop med hela ekonomin kring betalda transaktioner som vi kartlade i genomgången av 7702-stacken. En börs som inte läser av designatorn kan alltså betala ut pengar rakt in i en fälla utan att något ser fel ut i gränssnittet.
Till det kommer en mer vardaglig komplikation. Börser genererar ofta en unik insättningsadress per kund och sveper sedan ihop saldona till en gemensam varm plånbok med automatiska konsolideringstransaktioner. Om en sådan insättningsadress eller mellanplånbok av misstag blir delegerad kan konsolideringen bete sig oväntat, eftersom kontot nu kör kod i stället för att bara vidarebefordra värde. Det tvingar operatörer att övervaka sina egna adresser lika noga som kundernas, och att lägga avläsningen av designatorn till de rutinkontroller som körs före varje utbetalning. En tidigare trivial bokföringsoperation blir därmed något som kräver aktiv bevakning.
Fireblocks, MPC och den institutionella förvaringens svar
Förvaringsbranschen har tänkt igenom det här mer noggrant än de flesta plånboksleverantörer, eftersom deras kunder rör sig med större belopp. Arik Galansky, teknikchef på förvaringsjätten Fireblocks, formulerade i mars 2025 en säkerhetsförst-hållning till EIP-7702: en enda skadlig delegering räcker för att ett konto ska kunna tömmas, så delegera bara till kontrakt som är fullständigt granskade och betrodda, och håll dessutom delegeringen till konton med begränsat värde. Resten av kapitalet bör ligga i plånböcker utan smart kontrakt-risk. Poängen, enligt Fireblocks genomgång, är att 7702 främst ger UX-fördelar och passar heta plånböcker, inte kalla förvar.
I praktiken betyder det en arkitektur i lager. En liten, aktiv summa ligger i ett hett, 7702-delegerat konto för smidiga vardagsuttag, medan huvuddelen av kapitalet vilar i kallare förvar utan smart kontrakt-risk. Fireblocks framhåller också att man bör välja kontrakt med så liten kodyta som möjligt och undvika äldre plånbokskontrakt, som kan vara sårbara för front-running och storage-kollisioner. Logiken är att varje extra funktion i den lånade koden är en extra möjlig svaghet, och att en förvarare som rör sig med kundmedel inte har råd att gissa. Det är en försiktighetsprincip snarare än teknisk optimism.
Fireblocks driver också en mer konstruktiv linje: att kombinera MPC-förvaring med EIP-7702. I MPC-modellen delas den privata nyckeln upp mellan flera parter så att det inte finns någon enskild punkt som kan läcka, och säkerhetspolicyn kan hållas utanför kedjan i stället för att exponeras för angripare. Galansky beskriver kombinationen som ett slags ömsesidighet, där MPC täpper till 7702-risker medan 7702 ger MPC-konton batchning, gassponsring och sessionsnycklar. En enda MPC-grund kan då styra aktivitet över många kedjor samtidigt, vilket enligt Fireblocks resonemang ger både institutionell säkerhet och de smarta kontonas smidighet. Det är i praktiken den mall som stora börser och förvarare lutar sig mot när de tar in tekniken.
Sweeperekonomin: varför de flesta angrepp går back
Det finns en anledning till att de tidiga skräckrubrikerna om EIP-7702 inte följdes av en våg av tömda börskonton. Handelsfirman Wintermute granskade delegeringarna kort efter Pectra och fann att över 97 procent av dem pekade mot exakt samma återanvända kod, ett sweeper-kontrakt som fått smeknamnet CrimeEnjoyor. Ungefär 2,88 ETH hade auktoriserat runt 79 000 adresser, och ett enda kontrakt hanterade över 52 000 av dem. Trots skalan var det knappt lönsamt, eftersom de flesta av adresserna redan var tomma eller sedan tidigare komprometterade, enligt Wintermutes genomgång via CoinDesk. Sweepern var alltså inte ett fel i 7702, utan ett verktyg för att automatiskt dammsuga konton vars nycklar redan var stulna.
Bilden är ändå inte harmlös. En empirisk genomgång som presenterades vid USENIX Security 2026 fann att en stor majoritet av auktoriseringarna i urvalet var kopplade till skadliga kontrakt, en siffra som ofta återges som drygt 63 procent, med bekräftade förluster i miljonklassen; vi gick igenom den datan i detalj i artikeln om 7702:s mörka sida. Det viktiga för en börs är nyansen: den höga andelen räknar transaktioner, inte kronor, eftersom angriparnas kontrakt återanvänds oproportionerligt. Hotet är verkligt, men det är koncentrerat till redan komprometterade nycklar snarare än till en svaghet i själva standarden.
När det smäller: 1,54 miljoner dollar i en signatur
Det tydligaste exemplet på hur illa det kan gå kom i augusti 2025. En enskild användare förlorade totalt cirka 1,54 miljoner dollar, ungefär 14,8 miljoner kronor, efter att ha signerat en enda batch-transaktion enligt EIP-7702. Signaturen godkände flera token-överföringar och NFT-godkännanden på en gång, och pengarna slussades vidare till mainnet via Relay Protocol, enligt Cryptopolitan. Ingen nyckel behövde stjälas; offret lurades att skriva under en enda auktorisering som gav angriparen allt på en gång. Det är precis den batchande kraften som gör 7702 bekvämt som också gör ett felaktigt klick så dyrt.
Fallet var inte isolerat. Under augusti 2025 dränerades över 12 miljoner dollar från fler än 15 000 plånböcker i en nätfiskevåg där 7702-signaturer var ett av huvudverktygen, enligt data sammanställd av Scam Sniffer. Samtidigt pekar helårssiffrorna åt rätt håll: de totala nätfiskeförlusterna föll med 83 procent under 2025 till omkring 83,85 miljoner dollar, motsvarande cirka 800 miljoner kronor, med ungefär 106 000 drabbade, enligt Cointelegraph. Slutsatsen för en börs är dubbel: de stora talen sjunker, men den enskilda katastrofen har blivit snabbare och mer koncentrerad.
Att pengarna slussades vidare via en bro har också en praktisk poäng för handelsplatser. När stulna medel flyttas snabbt mellan kedjor blir de svårare att frysa, och fönstret för att en börs ska hinna stoppa en insättning krymper till minuter. Det är en av anledningarna till att avläsning av delegeringar och snabb kommunikation mellan börser och analysföretag har blivit viktigare än förr. En enda signatur kan tömma ett konto, men det är kedjan av efterföljande transaktioner, ofta via broar och blandare, som avgör om något alls går att återfå.
Riskvektorer vid gränsen mellan plånbok och börs
Om man samlar de operativa hoten på ett ställe blir det tydligt att de flesta bor i gränssnittet, inte i protokollet. Tabellen nedan sorterar dem efter vem som faktiskt bär risken och vilket motmedel som fungerar.
| Vektor | Så fungerar den | Vem bär risken | Motmedel |
|---|---|---|---|
| Sweeper-delegering | adressen pekar på kopierad kod som vidarebefordrar inkommande medel | mottagaren och den som sätter in | läs av 0xef0100 före uttag, nolldelegera |
| Batch-signatur i nätfiske | en signatur godkänner flera överföringar och godkännanden | plånboksanvändaren | klarsignering, läs varje anrop |
| chain_id=0-replay | samma signatur gäller på alla EVM-kedjor | användaren | undvik kedjeoberoende delegeringar |
| Blind signering på hårdvara | enheten visar en hash, inte handlingen | signeraren | whitelist av granskade kontrakt |
| Storage-kollision vid byte | rester från förra kontraktet feltolkas | användaren och utvecklaren | ERC-7201-namespacing, nolldelegera mellan byten |
Notera att fyra av fem rader kräver mänsklig eller programmatisk kontroll utanför själva kedjan. Det är därför bra rutiner vid insättning och uttag ofta betyder mer än någon enskild teknisk finess.
Blind signering och hårdvaruplånbokens gräns
Många tror att en hårdvaruplånbok gör dem immuna, men EIP-7702 exponerar just den svaga punkten. En hårdvaruenhet visar ofta bara en hash av det som ska signeras, inte den faktiska handling som en delegering eller en batch innebär. Om användaren godkänner en hash utan att förstå den, spelar det ingen roll att nyckeln aldrig lämnat enheten. Ethereums vägledning rekommenderar därför att hårdvaruplånböcker för en whitelist över granskade delegeringskontrakt och bara stödjer dem, snarare än att låta vad som helst signeras.
Svaret på branschnivå heter klarsignering, alltså att enheten visar vad transaktionen faktiskt gör i klartext. Ethereum Foundation har tagit över förvaltningen av standarden ERC-7730 för just detta, med målet att en signerare ska se handlingen och inte bara en sträng, enligt stiftelsens meddelande. Marius van der Wijden, kärnutvecklare på Ethereum, har genomgående beskrivit 7702 som ett tidigt förslag där alla skarpa kanter måste utvärderas noggrant, ett omdöme han upprepade i DL News. Den koden som ett konto lånar är dessutom i praktiken en installerbar modul, och hela ekosystemet av sådana byggstenar och deras säkerhet gick vi igenom i artikeln om hur smarta konton blev moduler. Ju mer funktionsrikt kontraktet är, desto större är enligt Fireblocks sannolikheten att det döljer en exploaterbar svaghet.
Att blind signering är en verklig fara och inte en teoretisk oro visade Bybit-stölden i februari 2025, då angripare lurade signerare att godkänna en transaktion som såg ofarlig ut men i själva verket bytte ut logiken bakom en förvaringsplånbok, enligt experter som The Block talat med. Det var inte ett 7702-fall utan ett Safe-baserat konto, men lärdomen är densamma: kan den som signerar inte se vad som faktiskt händer, spelar det ingen roll hur säker nyckeln i sig är. EIP-7702 breddar den ytan till vanliga användare, eftersom en enda delegeringssignatur kan ge bort lika mycket kontroll som en felaktigt godkänd företagstransaktion.
Så kontrollerar och nollställer du en delegering innan du flyttar pengar
Innan du sätter in på en börs eller tar ut till en adress som kan vara delegerad lönar det sig att göra en snabb kontroll. Följande steg fungerar för de flesta plånböcker.
- Klistra in adressen på eip7702.app eller läs av kontots kod i en blockutforskare och leta efter prefixet 0xef0100.
- Ser du designatorn, kontrollera vilket kontrakt de följande 20 byten pekar på och om det är en känd, granskad implementation.
- Vill du ta bort delegeringen gör du det inifrån din egen plånbok, till exempel i MetaMask under kontodetaljer där funktionen för smart kontrakt-konto kan stängas av per kedja.
- Tekniskt innebär det att kontot delegeras till nulladressen, varefter det åter blir en vanlig EOA.
- Kom ihåg att externa tjänster som revoke.cash kan visa dina delegeringar men inte återkalla dem, vilket bekräftas i Revoke.cash egen förklaring.
En viktig varning: om nyckeln redan är komprometterad ger en återkallelse en falsk trygghet. Relays supportmaterial om skadliga 7702-delegeringar är tydligt med att den enda pålitliga lösningen då är att sluta använda den drabbade plånboken och flytta allt till en ny. Att bara nollställa delegeringen räcker inte om angriparen fortfarande har din nyckel.
Finansinspektionen, MiCA och gränsen mot CASP
För en svensk läsare är den regulatoriska gränsdragningen förvånansvärt ren. Ett självförvarat smart konto, oavsett om det är en vanlig EOA eller en 7702-delegering, ligger utanför MiCA:s tillståndsplikt, eftersom du håller nycklarna själv och ingen mellanhand utför en tjänst åt dig. Det är först när du interagerar med en börs eller förvarare som reglerna slår till, för då är motparten en leverantör av kryptotillgångstjänster (CASP) under Finansinspektionens tillsyn, enligt myndighetens genomgång av de tio tjänstekategorierna.
Det praktiska är att ansvaret för att läsa av en delegerad adress hamnar hos CASP:en, inte hos protokollet. Sedan den 1 oktober 2025 måste varje kryptoföretag som betjänar svenska kunder ha ansökt om tillstånd hos FI eller upphöra med verksamheten, och företag som redan var registrerade fick fram till den 30 september 2025 att lämna in sin ansökan. ESMA klargjorde dessutom redan den 19 mars 2025 var gränsen går mot finansiella instrument för nytto- och speltokens. Notera samtidigt att kryptoderivat som terminer och eviga kontrakt inte faller under MiCA utan under MiFID II, och alltså övervakas som finansiella instrument. Din delegering ändrar ingenting i den bilden; det som ändras är att CASP:en nu måste kunna se skillnad på ett vanligt konto och ett som bär kod.
Till det kommer två regelverk som redan gäller. EU:s förordning om överföring av medel, ofta kallad travel rule, kräver att en CASP samlar in och skickar med uppgifter om avsändare och mottagare vid överföringar, vilket blir mer komplext när mottagaren är en självförvarad adress som dessutom bär kod. DORA, regelverket för digital operativ motståndskraft, ställer krav på att finansiella aktörer klarar it-störningar och angrepp, vilket i praktiken innebär att avläsning av delegeringar och incidenthantering behöver vara inbyggt i systemen snarare än improviserat. För en svensk användare betyder det att en seriös börs numera ställer fler frågor vid uttag, inte av nyfikenhet utan för att reglerna kräver det.
Vägen framåt: Fusaka, native konton och din delegering
EIP-7702 var alltid tänkt som en bro, inte en slutstation. Fusaka-uppgraderingen aktiverades den 3 december 2025 och förde med sig PeerDAS, som sänker kostnaderna för lager 2 och därmed indirekt gör smarta konton billigare att använda, enligt CoinDesk. Nästa steg är riktiga native konton på protokollnivå. Base förbereder EIP-8130 i sin Cobalt-uppgradering, men lanseringsdatumet är fortfarande inte satt och standarden ligger kvar på en devnet, vilket Crypto Briefing bekräftar. På lager 1 diskuteras EIP-8141 för en möjlig framtida Hegota-hård fork.
| Uppgradering | När | Vad den betyder för ditt konto |
|---|---|---|
| Pectra (EIP-7702) | 7 maj 2025 | EOA kan bära kod, delegering införs |
| Fusaka (PeerDAS) | 3 december 2025 | billigare lager 2, ingen direkt 7702-ändring |
| Base Cobalt (EIP-8130) | datum ej satt | native konton på lager 2, 7702 blir en bro |
| Hegota (EIP-8141) | tidigast sent 2026 | native abstraktion på lager 1 |
Frågan de flesta glömmer är vad som händer med din befintliga delegering när native konton väl landar. Svaret är lugnande: din adress och din nyckel förblir desamma, och du kan välja att antingen behålla 7702-delegeringen eller nollställa den och gå över till den nya modellen. Vi gick igenom den övergången och varför bron sannolikt blir kvar länge i artikeln om native konton och bron som dröjer. För en börs betyder det att avläsningen av delegerade adresser inte är ett övergående problem, utan en permanent del av verktygslådan.
Depå, MPC-plånbok eller smart konto: tre vägar för en svensk användare
Var landar då en vanlig svensk användare i allt det här? Det beror på hur mycket ansvar man vill ta för sina egna nycklar, och de tre vanligaste modellerna hanterar EIP-7702 på olika sätt.
| Modell | Vem håller nyckeln | 7702-relevans | Passar för |
|---|---|---|---|
| Börsdepå | börsen | börsen hanterar delegeringar internt | nybörjare, aktiv handel |
| MPC-plånbok | delad mellan parter | 7702 ger UX, MPC täcker nyckelrisken | företag, större belopp |
| Självförvarat smart konto | du själv | du styr och ansvarar för delegeringen | van användare, DeFi |
Ingen av modellerna är rätt för alla. En börsdepå flyttar hela delegeringsfrågan till operatören, men då är det också operatören, inte du, som kontrollerar tillgångarna. En MPC-lösning är tänkt för den som rör sig med större belopp och vill ha institutionella kontroller. Ett självförvarat smart konto ger mest frihet men lägger också hela ansvaret för avläsning och återkallelse på dig. Det viktiga är att veta vilken modell man faktiskt använder, eftersom det avgör vem som bär risken när en adress bär kod.
Checklista för dig som rör dig mellan plånbok och börs
Sammanfattningsvis är EIP-7702 varken den katastrof som de första rubrikerna antydde eller en risk du kan ignorera. Det praktiska försvaret är enkelt och handlar mest om rutiner.
- Kontrollera om en adress är delegerad innan du sätter in eller tar ut större belopp; leta efter 0xef0100.
- Delegera bara till kontrakt som är granskade, och håll stora belopp i ett konto utan smart kontrakt-risk, i linje med Fireblocks hållning.
- Slå på klarsignering där det går och godkänn aldrig en batch-signatur du inte förstår.
- Undvik kedjeoberoende delegeringar med chain_id noll om du inte har ett specifikt behov.
- Vid misstanke om komprometterad nyckel: flytta till en ny plånbok i stället för att lita på en återkallelse.
- Kom ihåg att självförvar ligger utanför FI:s tillsyn, men att börsen du handlar på är en CASP med egna skyldigheter.
Vanliga frågor
Hur ser jag om min plånboksadress har blivit ett smart konto via EIP-7702?
Klistra in adressen på eip7702.app eller titta på kontots kod i en blockutforskare. Om koden inleds med 0xef0100 är kontot delegerat, och de följande 20 byten visar vilket kontrakt det pekar på. Många plånböcker, som MetaMask, visar också statusen direkt i kontodetaljerna.
Är det säkert att ta emot en börsutbetalning till ett delegerat konto?
Ja, om du själv kontrollerar delegeringen och den pekar på ett granskat kontrakt. Risken uppstår om adressen delegerats till en sweeper, för då kan inkommande medel vidarebefordras automatiskt i samma ögonblick de landar. Kontrollera alltid delegeringen innan du tar ut till en adress du är osäker på.
Kan en börs vägra insättningar från eller uttag till ett delegerat konto?
Börser och förvarare kan läsa av 0xef0100-designatorn och behandla delegerade adresser annorlunda, till exempel genom att flagga, fördröja eller i vissa fall begränsa dem. Det finns ingen gemensam standard, så policyn skiljer sig mellan handelsplatser, men avläsningen har blivit en normal del av deras riskkontroll.
Hur återkallar jag en EIP-7702-delegering?
Du gör det inifrån din egen plånbok, vilket tekniskt innebär att kontot delegeras till nulladressen och blir en vanlig EOA igen. Externa tjänster som revoke.cash kan visa dina delegeringar men inte ta bort dem. Är nyckeln redan stulen räcker en återkallelse inte, utan du bör flytta till en ny plånbok.
Gäller Finansinspektionens regler mitt självförvarade smarta konto?
Nej, ett självförvarat konto ligger utanför MiCA:s tillståndsplikt eftersom du håller nycklarna själv. Reglerna gäller den börs eller förvarare du interagerar med, som är en leverantör av kryptotillgångstjänster under FI:s tillsyn. Din delegering ändrar inte den gränsdragningen.
Yuki Tanaka bevakar plånböcker, självförvar och kontoabstraktion för HOGE Wire.