EIP-7702 och native konton: bron som dröjer kvar 2026

När EIP-7702 gick live i Pectra-uppgraderingen den 7 maj 2025 beskrevs den nästan alltid på samma sätt: som en bro. En smart genväg som lät vanliga Ethereum-konton låna de smarta kontonas superkrafter, i väntan på att protokollet självt skulle lära sig konsten på riktigt. Drygt ett år senare, i september 2026, börjar den där riktiga versionen faktiskt ta form. Base förbereder native account abstraction i sin Cobalt-uppgradering, och på Ethereums huvudkedja har kärnutvecklarna schemalagt så kallade frame-transaktioner för en kommande hardfork.

Så då kan bron rivas? Inte än. Det korta svaret är att native account abstraction landar långsammare, och i fler bitar, än rubrikerna antyder, samtidigt som 7702 redan sitter under drygt 53 miljoner aktiva konton. För dig som håller krypto i egen plånbok, och för börserna som tar emot dina insättningar, är 7702 fortfarande det som faktiskt körs. Och det kommer att vara så ett bra tag till.

Den här genomgången handlar om själva övergången. Vi repeterar snabbt vad 7702 är och varför den byggdes som en bro, ser var adoptionen står efter Pectra och Fusaka, går igenom de tre vägarna till native konton (Base med EIP-8130, Ethereum med EIP-8141 och Paradigm-lägrets Tempo) och svarar på den praktiska fråga som få guider tagit i: vad händer med din 7702-delegering den dag native konton väl är här? Priser anges i kronor, och vi tar upp vad Finansinspektionen och MiCA säger om självförvaring.

Kort sammanfattning

• EIP-7702 lät vanliga konton (EOA) peka på smart kontrakt-kod via en revokerbar delegering. Den gick live i Pectra och var uttryckligen tänkt som en brygga mot native account abstraction.
• Adoptionen är omfattande: BundleBear räknar över 235 miljoner kumulativa auktoriseringar och drygt 53 miljoner aktiva delegeringar.
• Native konton är på väg, men styckevis. Base siktar på EIP-8130 i Cobalt-uppgraderingen i september 2026 (ännu bara på ett testnät), och Ethereum har flyttat EIP-8141 till schemalagd för en kommande fork.
• ETH handlas runt 2 470 dollar, cirka 23 700 kronor, enligt CoinDesk.
• Din delegering försvinner inte av sig själv när native konton kommer. Standarderna kan samexistera, och du styr själv över nollställningen.
• I Sverige ligger självförvarade smarta konton utanför MiCA och Finansinspektionens tillståndsplikt, medan hybridtjänster (molnnycklar, gassponsring, återställning) hamnar i en gråzon.

Vad EIP-7702 faktiskt är

Ethereum har historiskt haft två sorters konton. Det ena är det vanliga plånbokskontot, EOA (externally owned account), som styrs av en privat nyckel och inte kan innehålla någon egen logik. Det andra är kontraktskontot, som består av kod men saknar nyckel och bara agerar när någon anropar det. EIP-7702 suddar ut gränsen: den låter ett EOA peka på kod i ett smart kontrakt, så att kontot beter sig som ett smart konto men behåller sin gamla adress och sin gamla nyckel.

Mekaniskt sker det via en ny transaktionstyp, 0x04, ibland kallad set code transaction. Kontoägaren signerar en post i en auktoriseringslista med fälten kedje-id, kontraktsadress och nonce. När transaktionen körs skrivs en liten pekare in vid kontot: bytesekvensen 0xef0100 följt av den 20 byte långa kontraktsadressen, tillsammans 23 byte. Efter det kör kontot kontraktets kod varje gång det anropas. Signaturen görs med en särskild prefixbyte (MAGIC 0x05), och delegeringen nollställs genom att peka om kontot till nulladressen. Ett varningens ord som gällt sedan start: om auktoriseringen signeras med kedje-id 0 blir den giltig på alla kedjor, vilket öppnar för replay mellan nät.

Det viktiga är att 7702 inte ersätter det äldre ramverket ERC-4337, utan kompletterar det. 4337 byggde smarta konton ovanpå Ethereum med en egen infrastruktur av bundlers och en EntryPoint-kontrakt, utan att röra själva protokollet. 7702 tar i stället vanliga konton och ger dem samma förmågor. De två har till och med börjat växa ihop: EntryPoint version 0.8 lade till stöd för 7702 och en enkel referensimplementation. Vi har gått igenom hela funktionsstacken (batchade transaktioner, gassponsring och sessionsnycklar) i en separat genomgång av 7702-stacken, och specifikationen finns hos Ethereum Improvement Proposals.

Bron som var tänkt att vara tillfällig

För att förstå varför 7702 kallas en bro måste man backa bandet. Redan 2020 fanns ett förslag, EIP-3074, som ville ge EOA:er smarta förmågor genom två nya opcodes (AUTH och AUTHCALL). Förslaget var kraftfullt men kontroversiellt, eftersom det byggde in en helt ny och svårgranskad behörighetsmodell i protokollet, och det skrotades till slut till förmån för något mer framåtkompatibelt.

Det något mer framåtkompatibla blev EIP-7702, framlagt i maj 2024 av bland andra Vitalik Buterin, Sam Wilson, Ansgar Dietrichs och utvecklaren lightclient. Poängen var uttrycklig: inga nya opcodes, ingen ny permanent behörighetsmodell, utan en enkel delegering som fungerar i dag men som inte står i vägen för den slutgiltiga, protokollnativa lösningen längre fram. Alex Jupiter, senior produktchef på MetaMask, beskrev enligt DL News hela poängen som att foga in 7702 i en enda enhetlig färdplan för account abstraction, snarare än att bygga en avstickare. Ethereum-utvecklaren Marius van der Wijden var, i samma rapportering, mer avvaktande: förslaget var enligt honom fortfarande mycket tidigt och alla skarpa kanter behövde utvärderas.

Med andra ord: 7702 var aldrig tänkt att vara slutmålet. Den skulle ge plånböcker och användare batchning, gassponsring och sessionsnycklar med en gång, medan protokollet i lugn och ro arbetade fram den riktiga native-versionen. Frågan som ingen riktigt kunde svara på 2024 var hur lång den där mellanperioden skulle bli. I september 2026 har vi ett bättre svar: längre än många trodde.

Var 7702 står i dag, efter Pectra och Fusaka

Adoptionssiffrorna är svindlande vid första anblick. Enligt BundleBear har nätverken tillsammans registrerat 235 918 988 kumulativa auktoriseringar, 53 579 308 aktiva delegeringar och 98 750 059 set-code-transaktioner. Det gör 7702 till en av de snabbast spridda kontostandarderna i Ethereums historia.

Men siffrorna behöver en nyans. Kumulativa auktoriseringar är inte samma sak som antal användare, eftersom en stor del av de tidiga delegeringarna kom från automatiserade sweeper-bottar som pekade tusentals redan komprometterade konton mot samma kod. Den mest ärliga mätaren är antalet aktiva delegeringar, alltså EOA:er som just nu bär en 7702-pekare, och även den ligger över 53 miljoner. På plånbokssidan stöds standarden i dag av bland andra Ambire (som var först ute), MetaMask Smart Accounts, Rabby, Trust Wallet, Safe och OKX Wallet.

Sedan Pectra har infrastrukturen runtom också mognat. Fusaka-uppgraderingen aktiverades den 3 december 2025 och förde med sig PeerDAS och ett höjt gastak, vilket gjorde data på lager två-kedjor billigare och därmed gjorde smarta konton mer praktiska att använda i vardagen. Timingen är inte oviktig: ju billigare det blir att köra logik på kedjan, desto mindre bråttom är det att flytta samma logik ner i protokollet. Tabellen nedan sammanfattar var vi befinner oss.

EOA, ERC-4337, EIP-7702 och native AA sida vid sida

Det enklaste sättet att förstå varför bron dröjer kvar är att lägga de fyra modellerna bredvid varandra. Ett rent EOA är billigt och enkelt men kan ingenting utöver att signera en transaktion i taget. ERC-4337 ger full flexibilitet men kräver en separat infrastruktur av bundlers och relän. EIP-7702 ger de flesta av samma förmågor till ett vanligt konto, utan att röra protokollet. Native account abstraction bygger till sist in allt i själva Ethereum, men det kräver just en protokolländring, och sådana tar tid.

Poängen med tabellen är inte att en kolumn vinner. Det är att kolumnen längst till höger, den som skulle göra alla andra överflödiga, fortfarande står med ena foten på ett testnät. Så länge det är fallet är 7702 den enda av de tre smarta modellerna som både är protokollnativ (till skillnad från 4337) och redan färdig och utrullad (till skillnad från native AA).

Native account abstraction landar: Base Cobalt och EIP-8130

Den nyhet som gör den här hösten intressant heter Cobalt. Base, Coinbases lager två-kedja, planerar att införa native account abstraction genom EIP-8130 i sin Cobalt-uppgradering, med sikte på september 2026. Men här behövs ett tydligt förbehåll, för det är lätt att läsa rubrikerna som att det redan är gjort. Enligt Bitcoinist körs EIP-8130 tills vidare bara på Bases testnät Vibenet, det är inte utrullat på huvudnätet, och något exakt aktiveringsdatum är ännu inte spikat. Standarden är med andra ord på väg, men experimentell.

Tekniskt är EIP-8130, som utvecklaren Chris Hunter på Coinbase och Base ritat upp, en ganska konservativ konstruktion. Den inför en egen transaktionstyp, 0x79, och ett så kallat Keystore-kontrakt på kedjan där kontot lagrar sina inställningar, ungefär som en universell inställningspanel. I stället för att tillåta godtycklig valideringslogik låser 8130 sig till en fast uppsättning autentiseringsmetoder: secp256k1, P-256, WebAuthn och delegering. Förslaget delas i två nivåer, en mer tillåtande Level 1 tänkt för Ethereums huvudkedja och en mer restriktiv Level 2 för höggenomströmningskedjor som Base, och det behåller en fallback till ERC-4337. Native-funktionerna som lyfts fram är tre: gassponsring, batchade anrop och sessionsnycklar.

Vinsterna som Base pekar på handlar mest om gas och storlek. Enligt Bases ingenjörsblogg sjunker en native USDC-överföring från 125 000 till 46 000 gas, en minskning med 63,2 procent, samtidigt som transaktionens storlek krymper med 83,4 procent. En djupare genomgång av det enhetliga kontostandardsförslaget finns hos Crypto Briefing, och de tekniska specifikationerna ligger i Bases dokumentation. Arbetet drivs tillsammans med Optimism och WalletConnect, och tanken är att OP Stack-kedjorna ska följa efter senare.

Att en tung aktör som WalletConnect är med spelar roll för momentum. Pedro Gomes, grundare av WalletConnect, skrev enligt sitt eget inlägg på X att han efter månader med det konkurrerande förslaget nu är övertygad om att EIP-8130 är den bättre vägen till native account abstraction, med motiveringen att det är enklare, mer portabelt och fokuserat på vad plånböcker faktiskt behöver. Vem som vinner berättelsen om native konton är delvis en fråga om rykte och uppmärksamhet, en handelsvara i sig, något vi skrivit om i genomgången av mindshare-maskinen.

Ethereums egen väg: EIP-8141 och frame-transaktioner

Base är inte ensam om att bygga native konton, och Ethereums huvudkedja går en annan väg. Där heter det ledande förslaget EIP-8141, framlagt i slutet av februari 2026 av Vitalik Buterin med flera, och det bygger på en idé som kallas frame-transaktioner. En sådan transaktion har den nya typen 0x06 och delas upp i separata steg, eller frames: en VERIFY-frame som kör kontots egen valideringslogik och en efterföljande frame som utför själva överföringen eller anropet. En ny opcode, APPROVE, flyttar behörighetslogiken ut ur protokollets stela regler och in i EVM:en, och noderna simulerar transaktionen innan den släpps in i mempoolen.

Skillnaden mot 8130 är filosofisk. Där 8130 låser sig till fasta nyckeltyper tillåter 8141 godtycklig validering, vilket i teorin räcker för allt från exotiska multisig-uppställningar till post-kvantsäkra signaturer. Buterin har enligt Cointelegraph beskrivit 8141 som en samlingslösning som knyter ihop och löser i stort sett alla kvarvarande problem som account abstraction var tänkt att lösa, och sagt att det ser möjligt ut att få på plats inom ett år, i den fork han kallar Hegota.

Men försiktighet är fortfarande temat. Enligt ETH Daily har kärnutvecklarna flyttat EIP-8141 till status schemalagd för inkludering i Hegota, samtidigt som de betonar att implementationen kan ändras och att förslaget inte är forkens rubrikfunktion. Klienter som Nethermind och Besu har flaggat för komplexiteten, och som Everstake påpekar tar validerare på sig nytt arbete när de måste förhandssimulera transaktioner. Marius van der Wijdens gamla varning, att kanterna behöver slipas, gäller alltså i högsta grad även den native versionen. Specifikationen i sin helhet finns hos Ethereum Improvement Proposals.

Tre vägar till native konton

Utöver Base och Ethereum finns ett tredje läger. Paradigm-utvecklare har lagt fram Tempo, en avskalad design med en egen transaktionstyp (0x76) som fokuserar på ett fåtal primitiver: atomisk batchning, giltighetsfönster och native passkeys via P-256 och WebAuthn. Tempo undviker medvetet både godtycklig valideringslogik och gasbetalning i token, vilket gör den enklare men mindre kraftfull än de andra två. En bra översikt över alla tre finns hos Biconomy. Tabellen nedan ställer dem mot varandra.

Tre förslag, tre transaktionstyper, tre tidslinjer. Det säger något viktigt: native account abstraction är inte en enda knapp som slås på ett bestämt datum, utan en utdragen och splittrad process. Just den splittringen är en av de starkaste anledningarna till att 7702, den gemensamma nämnare som redan fungerar överallt, kommer att vara relevant länge.

Vad händer med din 7702-delegering när native konton kommer?

Det här är frågan som få guider tar i, och den enda praktiska som de flesta läsare faktiskt bryr sig om. Svaret börjar i hur en delegering lagras. Din 7702-pekare (0xef0100 följt av en kontraktsadress) ligger vid ditt konto på kedjan. Den ligger kvar tills du aktivt gör något åt den. Ingen protokolluppgradering, varken Cobalt eller Hegota, kommer att gå in och radera den åt dig. Kontrollen ligger hos dig.

Det betyder att standarderna samexisterar snarare än ersätter varandra över en natt. När native konton väl är live har du i praktiken tre val. Du kan behålla din 7702-delegering och fortsätta som förut. Du kan nollställa den genom att delegera till nulladressen, vilket gör kontot till ett rent EOA igen. Eller så kan du gå över till ett native kontos konfiguration, till exempel genom att skriva in dina inställningar i Bases Keystore-kontrakt. Det avgörande att förstå är att din privata nyckel och din kontoadress förblir desamma i alla tre fallen. Det som ändras är hur valideringen uttrycks, inte vem du är på kedjan.

Just den samexistensen är också den nya risken. Under en övergångsperiod finns flera kontomodeller på samma gång, med olika transaktionstyper och olika sätt att visa vad du signerar. Det ökar ytan för förvirring och för blind signering, alltså att godkänna något vars faktiska innebörd du inte ser. Plånböckernas viktigaste jobb de närmaste åren blir därför att tydligt visa vilket läge ditt konto är i och exakt vad en signatur gör, oavsett om den kommer via 7702 eller en native konfiguration.

För vanliga användare betyder det här att man inte behöver stressa. Om din plånbok i dag kör 7702 fungerar den precis lika bra dagen efter att Cobalt aktiveras. Sessionsnycklar, till exempel, är särskilt praktiska i spel, där de låter en app signera drag åt dig under en begränsad tid; hur den logiken passar in i en vardag där man både äger och tjänar tog vi upp när vi skrev om hur Sky Mavis rör sig från play-to-earn. Den funktionen försvinner inte, den får bara fler sätt att implementeras på.

Vad övergången betyder för börser och förvaring

För börser och förvaringstjänster är övergången mindre en fråga om spänning och mer en fråga om drift. Redan i 7702-eran har börserna behövt lära sig att läsa av den 23 byte långa delegeringsdesignatorn på insättningsadresser, eftersom en insättning från ett delegerat EOA kan bete sig oväntat, till exempel genom att en sweeper automatiskt drar tillbaka medlen i samma block. Vissa aktörer, som OKX Wallet och WhiteBIT, var tidiga med att stödja delegeringar, medan andra har varit försiktigare och i praktiken behandlat delegerade konton med extra granskning.

Native account abstraction lägger till ytterligare ett lager. Nu handlar det inte bara om att känna igen en 7702-pekare, utan om att kunna hantera helt nya transaktionstyper (0x79 hos Base, 0x06 på Ethereum) för både insättningar och uttag. En börs som vill stödja native uttag måste bygga och testa mot varje sådan typ, och tills det är gjort blir vanliga transaktioner och 7702 den gemensamma nämnaren som allt måste falla tillbaka på. Det är ännu ett skäl till att bron bär längre än planerat: den fungerar överallt redan i dag, medan native-stödet måste rullas ut börs för börs.

För organisationer och DAO:er ser bilden lite annorlunda ut, eftersom kassan där oftast ligger i ett Safe-multisig snarare än ett enskilt EOA. För dem blir valet mellan 7702, 4337 och native konton också en styrningsfråga: vem får ändra kontots konfiguration, och hur? Att sådana beslut kan bli infekterade har vi sett tidigare, till exempel när styrningen blev ett lönearbete. Även här är den pragmatiska hållningen att inte byta bort en fungerande uppställning bara för att en nyare standard finns på ett testnät.

Säkerheten under övergången

7702:s första år gav en tydlig läxa: den svaga länken är sällan protokollet, utan signeringsögonblicket. De ökända sweepers som fyllde de tidiga siffrorna var till stor del samma kopierade kod. Handelsfirman Wintermute konstaterade enligt CoinDesk att över 97 procent av de tidiga delegeringarna använde exakt samma bytekod, spridd över omkring 79 000 adresser, och att verksamheten knappt var lönsam eftersom kontona redan var tömda. Det var alltså inte ett fel i 7702, utan opportunister som återanvände redan läckta nycklar.

Nätfisket är allvarligare. Enligt AMBCrypto och säkerhetsföretaget Scam Sniffer dränerades över 12 miljoner dollar från mer än 15 000 plånböcker i augusti 2025 i attacker kopplade till 7702, där ett enda offer i ett fall förlorade 1,54 miljoner dollar i en enda transaktion. En akademisk studie som lades fram vid USENIX Security kopplade i sitt urval 63 procent av 7702-auktoriseringarna till illasinnade kontrakt, med drygt 2,3 miljoner dollar i bekräftade stölder. Siffrorna ska läsas rätt: 63 procent gäller transaktioner, inte användare eller kronor, eftersom angriparnas kontrakt återanvänds oproportionerligt.

Slutsatsen för övergångsperioden är obekväm men enkel. Ju fler kontomodeller som lever parallellt, desto större blir ytan för blind signering, och desto viktigare blir tydlig signering (arbetet med standarden ERC-7730) och plånböcker som visar exakt vad du godkänner. Den som vill ha hela försvarshandboken mot drainers hittar den i vår genomgång av 7702-stacken; huvudpoängen här är att native konton inte i sig löser signeringsproblemet, de flyttar bara var det uppstår.

Finansinspektionen, MiCA och självförvaring

Regleringsläget i Sverige är i grunden oförändrat av allt det tekniska ovan, men värt att upprepa. Ett självförvarat smart konto, oavsett om det körs som 7702 eller som ett kommande native konto, ligger utanför MiCA och därmed utanför Finansinspektionens tillståndsplikt, så länge det bara är du som håller nyckeln. MiCA reglerar leverantörer av kryptotillgångstjänster (växlare, förvarare, handelsplatser), inte den kod du själv kör i din plånbok. Finansinspektionen sammanfattar sitt ansvar på sin sida om kryptotillgångar och kryptotillgångstjänster.

Gråzonen uppstår i hybridfallen. Så snart en tredje part sköter något åt dig, molnbaserade passkeys, återställning via bekanta eller gassponsring som en tjänst, kan den funktionen börja se ut som en tjänst i lagens mening, och då aktualiseras frågan om tillstånd. Det är en av de mer intressanta juridiska frågorna som native konton väcker, eftersom just gassponsring och återställning är sådant som byggs in i standarderna. Kom också ihåg tidslinjen: 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, och kryptoderivat (terminer, perpetualer) räknas som finansiella instrument under MiFID II, inte under MiCA.

På skattesidan gäller att Skatteverket beskattar vinster i inkomstslaget kapital oavsett om ditt konto är ett vanligt EOA eller ett smart konto. Värt att notera för den som experimenterar med gassponsring: att betala nätverksavgiften i ett stablecoin räknas i praktiken som en avyttring av den tillgången, alltså en skattepliktig händelse, även om beloppet är litet. Kontostandarden ändrar tekniken, inte skattereglerna.

Så förbereder du dig

Den goda nyheten är att du inte behöver göra något dramatiskt inför native konton. Men några rutiner är värda att ha på plats redan nu, medan bron bär.

1. Kontrollera om ditt konto redan har en aktiv delegering. En blockutforskare visar 0xef0100-koden vid adressen, och det finns dedikerade verktyg för att läsa av 7702-status.
2. Lär dig hur du nollställer. En delegering tas bort genom att peka om kontot till nulladressen, och du bör veta hur din plånbok gör det innan du behöver det.
3. Använd plånböcker som visar tydligt vad du signerar. Tydlig signering är ditt bästa skydd mot blind signering, och den blir viktigare, inte mindre viktig, när flera standarder samexisterar.
4. Var extra skeptisk mot länkar som lovar gasfria uttag, gratis anspråk eller batch-godkännanden. Det är den vanligaste ingången för 7702-nätfiske.
5. Om du använder börser: ta reda på hur din insättningsadress hanterar delegeringar och vilka transaktionstyper börsen stödjer för uttag.
6. Vänta inte på native konton för att skärpa rutinerna. Den standard du kör i dag bär ett bra tag till, och goda vanor är oberoende av vilken kontomodell som är på modet.

Slutsats: bron blev infrastruktur

EIP-7702 marknadsfördes som en tillfällig bro, och i teorin är den det fortfarande. I praktiken har den blivit infrastruktur. Med drygt 53 miljoner aktiva delegeringar, stöd i alla stora plånböcker och en färdig plats i protokollet är den den enda smarta kontomodell som både är native och redan fungerar överallt. Native account abstraction är på riktigt på väg, men den kommer i tre olika förslag, på tre olika kedjor, med tre olika tidslinjer, och det mesta av det ligger ännu på testnät.

För dig som håller egen krypto är budskapet lugnande: inget av det här kräver panik eller brådstörtade byten. Bron är stabil, din nyckel och din adress följer med oavsett vad som händer i protokollet, och din viktigaste uppgift är densamma i dag som i morgon, nämligen att se exakt vad du signerar. Den dag native konton väl står färdiga kommer du att korsa över på en bro som visade sig hålla betydligt längre än någon räknade med.

Vanliga frågor

Ersätter native account abstraction EIP-7702?

Inte på kort sikt. Native account abstraction (till exempel Base EIP-8130 och Ethereums EIP-8141) bygger in kontologiken i protokollet, men lösningarna landar gradvis och 7702 sitter redan under drygt 53 miljoner aktiva konton. Under lång tid framåt kommer standarderna att samexistera, och 7702 förblir det som de flesta plånböcker faktiskt kör.

När kommer native account abstraction?

Bit för bit. Base siktar på EIP-8130 i Cobalt-uppgraderingen i september 2026, men standarden körs ännu bara på ett testnät (Vibenet) och något exakt datum är inte spikat. På Ethereums huvudkedja har EIP-8141 flyttats till schemalagd för en kommande Hegota-fork i slutet av 2026, med reservationen att implementationen kan ändras.

Måste jag ta bort min 7702-delegering när native konton kommer?

Nej. En delegering är en pekare som lagras vid ditt konto och den försvinner inte av sig själv. Du kan behålla den, nollställa den genom att delegera till nulladressen, eller senare gå över till ett native kontos konfiguration. Nyckeln och adressen är desamma; det som ändras är hur valideringen uttrycks.

Är EIP-8130 och EIP-8141 samma sak?

Nej. EIP-8130 (Base, Coinbase, Optimism, WalletConnect) bygger på fasta nyckeltyper och en konfiguration på kedjan, medan EIP-8141 (Vitalik Buterin med flera) tillåter godtycklig validering via frame-transaktioner. 8130 rullas ut på Base först, medan 8141 riktar sig mot Ethereums huvudkedja.

Regleras smarta konton av Finansinspektionen?

Ett självförvarat smart konto, där bara du har nyckeln, ligger utanför MiCA och Finansinspektionens tillståndsplikt för kryptoleverantörer. Så snart en tredje part sköter nycklar, återställning eller gassponsring åt dig kan tjänsten däremot hamna i en gråzon. Vinster beskattas av Skatteverket oavsett kontotyp.

Yuki Tanaka bevakar plånböcker, självförvaring och Ethereums kontostandarder för HOGE Wire.