Självförvar eller tjänst? Smarta konton, MiCA och FI 2026
Ett smart konto är bara kod, men MiCA och FI byggde regelboken för en värld med tydliga mellanhänder. Vi reder ut när självförvar blir en reglerad tjänst och vem som bär ansvaret.
Ett konto som är kod, och en regelbok som inte räknade med det
Det smarta kontot är inte längre ett experiment. Enligt data från BundleBear har ERC-4337 passerat 1,3 miljarder UserOperations, med drygt 68 miljoner konton som gjort minst en transaktion och över 14,5 miljoner dollar i gas som betalats av någon annan än kontoinnehavaren själv. Lägg till EIP-7702, som sedan Pectra-uppgraderingen låter en helt vanlig plånboksadress bete sig som ett smart konto: BundleBear räknar till över 260 miljoner auktoriseringar och fler än 63 miljoner levande delegationer. Ethereum självt handlas runt 2 685 dollar, ungefär 26 900 kronor, med ett börsvärde kring 328 miljarder dollar (CoinDesk).
Bakom funktionerna gömmer sig en fråga som sällan ställs i de svenska plånboksguiderna: var hamnar ett smart konto i regelboken? MiCA och Finansinspektionen byggde sitt ramverk kring en enkel skiljelinje. Antingen håller du dina egna nycklar, vilket är självförvar och ligger utanför reglerna, eller så håller en leverantör dem åt dig, vilket är förvar och en tillståndspliktig tjänst. Account abstraction är konstruerad för att sudda ut just den gränsen. Den här texten handlar inte om hur du slipper seed-frasen, utan om var den juridiska gränsen går när kontot blir programmerbart, vem som bär ansvaret när något går fel, och vad Finansinspektionen faktiskt granskar.
Det är en fråga som blivit akut just nu, av två skäl. Dels har den svenska tillståndsprövningen under MiCA gått från teori till verklighet, med bolag som fått nej. Dels drar tekniken åt ett håll där allt färre mellanhänder rör vid din transaktion, vilket paradoxalt nog flyttar själva gränsen för vad som räknas som en tjänst.
Vad ett smart konto faktiskt är, och de tre vägarna dit
En vanlig Ethereum-adress är ett externally owned account, en EOA: en privat nyckel styr allt, och tappar du nyckeln är pengarna borta. Ett smart konto flyttar in logiken i kod, så att regler för vem som får signera, hur mycket och när kan skrivas in i själva kontot. Tre vägar leder dit, och skillnaden mellan dem är inte bara teknisk utan avgör var kontot landar juridiskt.
ERC-4337 bygger ett kontrakt som ditt konto, utan att ändra Ethereums konsensus. Transaktioner paketeras som UserOperations i en egen mempool, samlas ihop av bundlers och skickas via ett gemensamt EntryPoint-kontrakt; en paymaster kan betala gasen. EIP-7702 tar en annan väg: sedan Pectra (7 maj 2025) kan en EOA via en transaktion av typ 0x04 peka på kontraktskod och tillfälligt bete sig som ett smart konto, en delegation som är återkallelig och gäller per kedja. Den tredje vägen, native account abstraction, bygger in hela mekaniken i själva protokollet.
Skillnaden är inte akademisk. Ett ERC-4337-konto lever vid sidan av protokollet och är beroende av en infrastruktur av bundlers och ett gemensamt EntryPoint-kontrakt, medan en EIP-7702-delegation låter en befintlig adress låna ett kontrakts beteende men behålla sin egen nyckel. Native account abstraction skulle i stället göra kontot till en förstklassig medborgare i protokollet. Var och en av modellerna placerar olika parter i transaktionskedjan, och det är just den placeringen som regelboken bryr sig om.
Marius van der Wijden, kärnutvecklare på Ethereum, har beskrivit 7702 som något som «adds a new transaction type that allows existing wallets to emulate the functions of Account Abstraction wallets», och samtidigt manat branschen att «evaluate all the rough edges» (DL News). Flera av de kantigheterna är inte tekniska utan juridiska, och de syns tydligast när man ställer varje kontotyp mot regelbokens utgångspunkt.
| Kontotyp | Vem eller vad styr nyckeln | Mellanhand i transaktionskedjan | MiCA:s utgångspunkt |
|---|---|---|---|
| EOA (vanlig plånbok) | Du, en privat nyckel | Ingen (validatorer utför) | Självförvar, utanför MiCA |
| ERC-4337 smart konto | Kontraktskod plus din signeringsnyckel | Bundler, EntryPoint, ofta paymaster | Självförvar om bara du kan signera, annars gråzon |
| EIP-7702 (uppgraderad EOA) | Din nyckel, delegerad till kod | Delegatkontraktets författare, ev. relayer | Självförvar, men delegaten kan ändra spelreglerna |
| Native AA (EIP-8141 eller 8130) | Protokollet validerar direkt | Färre externa mellanhänder | Beror på nyckelmodellen, inte på bundlers |
MiCA:s skiljelinje: förvar «för kundens räkning»
MiCA reglerar inte protokoll, utan tjänsteleverantörer. En av de tillståndspliktiga tjänsterna är förvaring och administration av kryptotillgångar för kunders räkning. Definitionen är precis: det handlar om att förvara eller kontrollera, för kundens räkning, kryptotillgångar eller medlen för att komma åt dem, i praktiken de privata nycklarna.
MiCA räknar upp en rad kryptotillgångstjänster, från drift av en handelsplattform och växling till utförande av order och rådgivning. Förvaring och administration för kunders räkning är en av dem, och den är särskilt känslig eftersom den handlar om vem som faktiskt rår över tillgångarna. Det är därför lagstiftaren valde ordet kontroll, inte ägande: det spelar ingen roll vems pengarna är, utan vem som kan flytta dem.
Två ord bär hela gränsdragningen: «kontrollera» och «för kundens räkning». Den som kontrollerar åtkomstmedlen åt någon annan driver förvar, och förvar kräver tillstånd under MiCA:s avdelning V. Artikel 75 lägger till en hel kravkatalog för den som gör det: ett avtal med kunden, ett register över positioner, en förvaringspolicy, besked till kunden, strikt åtskillnad mellan kundens och företagets tillgångar, och ett uttryckligt ansvar för förluster (MiCA artikel 75).
Poängen för ett smart konto är att «kontroll» inte längre är ett rent ja eller nej. Koden kan ge en part rätt att signera, en annan rätt att byta nyckel, en tredje rätt att betala gasen. Varje sådan rättighet är en liten bit kontroll, utdelad till olika aktörer, och det är där regelboken börjar skava. En EOA var binär; ett smart konto är en gradskala.
När bara du har nyckeln: utanför reglerna
Den renaste varianten är enkel. Om bara du kan signera, och ingen annan kan flytta dina tillgångar eller byta din nyckel, är ditt smarta konto självförvar. Då driver plånboksutvecklaren ingen kryptotillgångstjänst enligt MiCA, och faller utanför hela CASP-ramverket. Koden du kör är ett verktyg, inte en tjänst som någon tillhandahåller åt dig.
I praktiken betyder «bara du» ganska mycket. Det betyder en signeringsnyckel som du ensam kontrollerar, ingen förmyndare som kan ta över, ingen molntjänst som i tysthet håller en kopia, och ingen återställningsmekanism som låter en tredje part skriva om kontot. Så snart något av detta läggs till blir bilden gråare, och det är där de flesta konsumentvänliga plånböcker faktiskt befinner sig i dag.
Att ESMA ser det på det sättet framgår indirekt men tydligt av myndighetens eget språk. När ESMA i ett uttalande i juni 2026 uppmanade oauktoriserade leverantörer att avveckla ordnat, bad man kunderna att föra över sina tillgångar «to an authorised CASP, where one is identified, or to a self-hosted wallet» (ESMA). Den självförvarade plånboken framställs alltså som det uttryckligen oreglerade alternativet till en auktoriserad aktör. Det är ingen eftergift, det är en gränsmarkering.
Baksidan står i samma uttalande. ESMA varnar för att kunder hos oauktoriserade leverantörer «do not benefit from MiCA safeguards, including protections for client assets». Självförvar betyder att du slipper mellanhanden, men också att du står utan skyddsnät. Finansinspektionen granskar tjänsteleverantörer, inte din kod, och den som väljer bort tjänsten väljer samtidigt bort det konsumentskydd som följer med tillståndet.
Gråzonen: paymasters, moln-passkeys och förmyndare
Mellan rent självförvar och renodlad depå ligger ett brett fält där account abstraction faktiskt lever, och där MiCA-statusen avgörs av detaljer. Så fort en tredje part rör vid åtkomstmedlen glider kontot mot förvarsdefinitionen, även om användaren fortfarande kallar det för sin egen plånbok.
En paymaster-tjänst som betalar din gas rör inte din nyckel, men tar betalt och tar en roll i transaktionen. En moln-synkad passkey innebär att Apples eller Googles infrastruktur håller kopior av din signeringsnyckel. En social återställningstjänst där ett företag kan rotera din nyckel ser i praktiken ut som kontroll över åtkomstmedlen. En inbäddad plånbok där leverantören håller en nyckeldel i en TEE, ett MPC-upplägg, landar i exakt den gråzon där «kontroll» blir en bedömningsfråga. Att dessa operatörer dessutom tenderar att koncentreras till ett fåtal aktörer gör frågan skarpare, något vi granskat i genomgången av vem som styr maskineriet bakom kontot.
| Funktion | Vem rör åtkomstmedlen | Sannolik MiCA-position |
|---|---|---|
| Paymaster som sponsrar gas | Betalar gas, rör inte nyckeln | Oftast ej förvar, men kan vara en annan tjänst |
| Gas betald i token (ERC-20-paymaster) | Tredje part växlar din token | Ej förvar, men själva växlingen kan vara en egen tjänst |
| Moln-synkad passkey | Plattformen håller en nyckelkopia | Gråzon, beror på vem som kan återskapa nyckeln |
| Social återställning via företag | Kan rotera din nyckel | Nära kontroll av åtkomstmedel |
| Inbäddad plånbok med nyckeldel (MPC eller TEE) | Leverantören håller en del | Gråzon, ofta förvar om parten kan flytta |
| Keystore på en annan kedja | Styr konton tvärs över kedjor | Beror på vem som äger och kan ändra keystoren |
Ingen av raderna är ett självklart ja eller nej, och det är själva problemet. Account abstraction är designad för att kombinera de här funktionerna sömlöst, men varje kombination kan flytta kontot över en gräns som varken användaren eller leverantören märker förrän en tillsynsmyndighet ställer frågan. En plånbok som marknadsförs som självförvar kan, när man läser finstilta villkor om återställning och synk, visa sig ha byggt in precis den kontroll som utlöser tillståndsplikt.
Ta ett vardagligt exempel. En användare slår på molnbaserad återställning för att slippa oron att tappa sin nyckel, och godkänner att leverantören får hjälpa till att återskapa åtkomst. Tekniskt är det en bekvämlighet; juridiskt kan samma val ha flyttat kontot från självförvar till något som börjar likna en förvaringstjänst, beroende på exakt hur återställningen är byggd. Varken användaren eller supportavdelningen tänkte på saken som ett tillståndsärende.
Vem bär ansvaret när koden sviker?
Skillnaden mellan förvar och självförvar blir konkret i det ögonblick pengarna försvinner. Artikel 75.8 i MiCA är ordagrant tydlig: en förvarande leverantör «shall be liable to their clients for the loss of any crypto-assets or of the means of access to the crypto-assets as a result of an incident that is attributable to them», och ansvaret är «capped at the market value of the crypto-asset that was lost, at the time the loss occurred». Använder förvararen en underförvarare måste den enligt artikel 75.9 vara en leverantör med tillstånd enligt artikel 59 (MiCA artikel 75).
I självförvar finns ingen sådan rad. Töms ditt smarta konto genom en blind signering, en drainer eller ett läckt delegat, är förlusten din, utan tak och utan motpart att vända sig till. Det är samma obekväma räkning vi gått igenom i frågan om vem som betalar när krypto töms: ju mer du äger själv, desto mer av risken bär du själv.
Skillnaden i praktisk upprättelse är stor. Hos en auktoriserad förvarare finns ett avtal, en tillsynsmyndighet att vända sig till och i vissa fall försäkringslösningar. I rent självförvar finns ingen motpart, ingen reklamationsväg och ingen ersättning, bara kedjan som genomförde transaktionen och som inte ångrar sig. Det är den verkliga innebörden av «not your keys, not your coins», fast läst baklänges: inte din risk, inte din förlust, så länge någon annan bär nyckeln.
Här blir account abstraction ett tveeggat argument. Programmerbarheten kan bygga in skyddsräcken, som utgiftstak, tidslås och krav på flera signaturer, som en EOA aldrig hade. Men samma programmerbarhet är en ny attackyta, och ansvaret för att läsa koden rätt stannar hos dig så länge du är i självförvar. Väljer du i stället en förvarare för att slippa den risken, köper du ett ansvarsåtagande, men betalar med att återinföra just den mellanhand som account abstraction skulle ta bort.
Reseregeln följer med in
Så länge du håller dig till ditt eget konto lämnar reglerna dig i fred. Men få stannar där. Förr eller senare rör kontot en börs, och då slår EU:s reseregel till. Förordning (EU) 2023/1113 gäller fullt ut sedan 30 december 2024 och tvingar varje CASP att samla in, verifiera, överföra och spara uppgifter om avsändare och mottagare för varje kryptoöverföring, utan något beloppsgolv (reglerna sammanfattas här).
Självförvarade plånböcker är inte förbjudna, men de får ett tillägg. När en kund för över mer än 1 000 euro till eller från sin egen självförvarsplånbok måste börsen verifiera att kunden faktiskt kontrollerar adressen, med en kryptografisk signatur, en mikrotransaktion (det så kallade «Satoshi-testet») eller ett likvärdigt tekniskt bevis.
Konsekvensen för smarta konton är underskattad. Ett smart konto i rent självförvar ligger utanför reseregeln, men i samma sekund det skickar till eller tar emot från en svensk börs måste börsen kunna knyta kontot till dig. Den programmerbara pseudonymiteten tar slut vid börsens dörr, och ju fler automatiska flöden ett smart konto har mot en reglerad plattform, desto fler kontrollpunkter uppstår.
Till det kommer att rapporteringen snart blir automatisk. Genom OECD:s ramverk CARF och EU:s DAC8 ska plattformar börja rapportera användares kryptoinnehav och transaktioner till skattemyndigheterna, vilket betyder att Skatteverket får allt bättre insyn i flöden som tidigare var osynliga. Ett smart konto som ofta rör en reglerad börs lämnar med andra ord spår på fler ställen än användaren kanske tror.
Börsen som blir din plånbok
Gränsen blir ännu suddigare när börsen bygger in plånboken i sin egen app. Inbäddade smarta konton, där inloggning sker med ansikte eller e-post och nycklar skapas osynligt, marknadsförs gärna som självförvar men ligger ofta mittemellan. Frågan är enkel att ställa och svår att svara på: kan leverantören flytta dina pengar utan din signatur, och kan den återskapa din nyckel? Om svaret är ja lutar det mot förvar, och då gäller hela CASP-regelverket med allt vad det innebär av tillstånd, åtskillnad av tillgångar och ansvar.
Det delegerade kontot gör saken knivigare, eftersom en EIP-7702-delegation kan ge ett börskopplat kontrakt rätt att agera i ditt ställe. Vi har nystat i just den spänningen i genomgången av det delegerade kontots dilemma. För en svensk användare är tumregeln densamma oavsett vad produkten heter: läs vem som kan signera i ditt ställe, inte vad appen kallar sig. Marknadsföringsordet «självförvar» har ingen juridisk tyngd, det har kontrollen över nyckeln.
Det finns en mellanväg som växer fram, där börsen håller en nyckeldel men inte kan agera ensam. Då blir frågan hur tröskeln är satt: krävs din signatur för varje uttag, eller kan leverantören under vissa villkor flytta pengar på egen hand? Svaret avgör om produkten är självförvar med extra bekvämlighet eller en förvaringstjänst i ny förpackning, och det framgår sällan av marknadsföringen.
Är din token ens «krypto»? MiFID II-gränsen
Ett smart konto kan hålla vad som helst, och allt är inte «kryptotillgångar» i MiCA:s mening. ESMA:s riktlinjer av den 19 mars 2025 (ESMA75453128700-1323) sätter kriterierna för när en kryptotillgång i stället är ett finansiellt instrument enligt artikel 2.4 i MiCA (ESMA). Ger en token innehavaren rättigheter som liknar aktier eller obligationer är den ett överlåtbart värdepapper, och då gäller MiFID II i stället för MiCA, enligt principen om teknikneutralitet.
Det är inte en akademisk gränsdragning. Kryptoderivat, som terminer och perpetuals, är finansiella instrument under MiFID II och övervakas av Finansinspektionen i rollen som marknadsmyndighet, inte under MiCA. Ett smart konto som med ett enda tryck paketerar en swap in i en tokeniserad aktie eller en derivatposition drar in en annan regelbok, med andra krav på både dig och motparten. Programmerbarheten gör det lätt att råka passera den gränsen utan att inse det, eftersom kontot inte märker skillnad på att byta en stablecoin och att ta en hävstångsposition.
Förenklat finns fyra fack. Betalnings- och verktygstokens samt de flesta renodlade kryptotillgångar faller under MiCA. Stablecoins delas upp i e-pengatokens och tillgångsanknutna tokens med egna regler. Tokens med aktie- eller obligationsliknande rättigheter är finansiella instrument under MiFID II. Och vissa saker, som rena samlarobjekt, kan hamna utanför alltihop. Ett smart konto bryr sig inte om facken, men det gör regelverket, och ansvaret för att veta vilket fack en position landar i ligger på innehavaren.
Skatteverket ser varje steg
Juridiken slutar inte vid tillsynen. Skatteverket behandlar kryptotillgångar som andra tillgångar, och varje avyttring, att sälja, byta eller betala med en kryptotillgång, utlöser en kapitalvinst eller kapitalförlust som ska redovisas på bilaga K4 avsnitt D. Skattesatsen är 30 procent på vinst, förluster är avdragsgilla till 70 procent, och omkostnadsbeloppet beräknas enligt genomsnittsmetoden (Skatteverket).
Account abstraction gör det här lättare att missa än någonsin. En batchad transaktion som gör fem byten i ett svep är fem avyttringar. Betalar du gasen i en token är själva betalningen en avyttring. En sessionsnyckel som automatiskt balanserar om en position skapar en ström av skattehändelser som användaren aldrig ser på skärmen. Bekvämligheten döljer deklarationsjobbet, men inte skatteplikten.
För en svensk användare betyder det att det smarta i kontot också borde omfatta bokföringen. Den som förlitar sig på att allt bara fungerar riskerar en K4 som inte går ihop när Skatteverket, med data från allt fler rapporterande plattformar, ställer frågan. Här är ironin tydlig: samma programmerbarhet som kan automatisera skatteloggning är den som, obevakad, skapar flest oredovisade händelser.
Native account abstraction flyttar gränsen
Den tekniska utvecklingen rör sig åt ett håll som faktiskt påverkar juridiken. Den 15 september 2026 övergav Ethereum- och Base-lägren försöket att ena sina förslag för inbyggd account abstraction (The Block). Derek Chiang, som ledde arbetet, sammanfattade brottet så här: «While we identified a number of technical solutions, they all required one side or the other to compromise at least a little bit on their core goals.»
Kvar står två spår. Ethereums EIP-8141, kallat frame transactions, siktar på den kommande Hegotá-uppgraderingen och delar en transaktion i ramar som var för sig validerar avsändaren, godkänner vem som betalar och utför själva handlingen. Base kör sitt eget EIP-8130 med en keystore på kedjan och planerar att leverera det i en kommande uppgradering senare i år. Vem som egentligen bestämmer standarden är en fråga om styrning snarare än omröstning, en dynamik vi beskrivit i genomgången av vem som styr Bitcoin och Ethereum.
Varför spelar det roll för regelboken? För att native account abstraction tar bort de externa bundlers och relayer som ett 4337-konto lutar sig mot. Färre mellanhänder i transaktionskedjan ger en renare självförvarsberättelse, och färre parter som kan sägas kontrollera åtkomstmedlen. Vitalik Buterin har gjort just mellanhandsminimering till en princip och beskrivit målet som att «maximize what you can do even if all the world’s infrastructure except the Ethereum chain itself goes down» (Cointelegraph). Ju mindre infrastruktur du är beroende av, desto tydligare är det att du, och ingen annan, kontrollerar kontot. Vi har kartlagt hela det vägvalet i vägskälet mellan Ethereum och Base.
En varning mot att blanda ihop kalendern: nästa stora Ethereum-händelse, Glamsterdam, aktiveras på testnätet Sepolia den 6 oktober 2026 (crypto.news), men den handlar om genomströmning, med ePBS via EIP-7732 och block-access-lists via EIP-7928, inte om native account abstraction. Det senare hör till Hegotá, och något skarpt datum för huvudnätet finns ännu inte.
För regelboken är den avgörande effekten subtil men verklig. När valideringen flyttar in i protokollet behöver kontot inte längre lita på en extern bundler eller relayer för att få med sin transaktion i ett block. Färre beroenden betyder färre parter som kan sägas kontrollera åtkomsten åt dig, och därmed en renare självförvarsstatus. Tekniken och juridiken pekar här åt samma håll, vilket är ovanligt nog att vara värt att notera.
| Dimension | Ethereum EIP-8141 | Base EIP-8130 |
|---|---|---|
| Grundidé | Frame transactions, en ny transaktionstyp | Ny transaktionstyp plus en keystore på kedjan |
| Validering | Godtycklig, inklusive kvantsäker | Fasta, kurerade nyckeltyper |
| Styrande mål | Censurmotstånd och säkerhet | Skala och kompatibilitet |
| Måluppgradering | Hegotá (datum ej låst) | Kommande Base-uppgradering i år |
| Gas i token | Ja, utan mellanhand | Ja, i flera lägen |
DORA: även driftsäkerheten blir ett krav
Tillstånd är inte slutpunkten. En auktoriserad CASP, inklusive den som erbjuder förvar av smarta konton eller inbäddade plånböcker, omfattas också av DORA, EU:s förordning om digital operativ motståndskraft. Den ställer krav på IT-riskhantering, incidentrapportering, regelbundna tester och kontroll av tredjepartsleverantörer, och den gäller finansiella aktörer brett, inte bara banker.
För smarta konton är kopplingen konkret. En leverantör som kör bundler-, paymaster- eller keystore-infrastruktur åt kunder bygger just den sortens kritiska IT-beroende som DORA vill göra motståndskraftigt. Ju mer av account abstractions maskineri en aktör driver åt sina användare, desto mer ser den ut som en reglerad finansiell infrastruktur, med allt vad det innebär av krav, och desto längre bort är den från den fria kod som ett rent självförvarskonto består av. Regelbördan följer med kontrollen, inte med etiketten.
Poängen är att regleringen inte straffar tekniken utan rollen. DORA, MiCA och reseregeln träffar den som tar på sig att driva något åt andra. En utvecklare som släpper öppen kod som du själv kör träffas inte på samma sätt som ett bolag som håller dina nycklar och lovar drift dygnet runt. Account abstraction gör den skillnaden svårare att se, men den försvinner inte.
Sverige just nu: FI, tidsfristen och vad som granskas
Hur ser det då ut på hemmaplan? Från den 1 oktober 2025 måste alla kryptobolag som vill fortsätta erbjuda kryptotjänster i Sverige ha skickat in en ansökan till Finansinspektionen, annars ska verksamheten läggas ned (FI). Bolag som redan var registrerade hos FI får fortsätta medan ansökan prövas. Bland dem som lämnat in ansökningar finns välkända svenska namn som Safello och Goobit, och FI har redan nekat minst ett bolag, QB Europe, som i sin tur överklagat beslutet. Prövningen är med andra ord inte en formalitet.
MiCA:s övergångsperiod löpte ut i slutet av juni 2026, vilket betyder att endast bolag med tillstånd får erbjuda kryptotjänster i Sverige framöver. Det viktiga för dig som använder ett smart konto är var gränsen för mandatet går: Finansinspektionen granskar tjänsteleverantörerna, alltså börser, förvarare och handelsplattformar, inte den kod du själv kör i självförvar (FI om MiCA).
Det gör gränsdragningen i den här texten praktisk, inte teoretisk. Så länge bara du håller nyckeln är du utanför FI:s mandat. I samma sekund du, eller en leverantör du använder, bygger in en operatör som kan flytta eller återskapa nyckeln, kan en tjänst ha uppstått som egentligen borde ha tillstånd, utan att någon satt sig för att bygga en börs.
För en svensk användare blir råden konkreta. Kontrollera om en tjänst du använder finns i FI:s företagsregister, läs villkoren för vad leverantören kan göra med din nyckel, och var extra uppmärksam på funktioner som återställning och synk som i tysthet kan flytta kontrollen. Det betyder inte att självförvar är det enda rätta svaret, bara att du bör veta vilken sida av gränsen du står på innan något går fel.
Checklista: läser du reglerna rätt för ditt konto?
Sex frågor avgör var ditt smarta konto landar, juridiskt och skattemässigt.
- Är du den enda som kan signera, utan att någon annan kan flytta pengarna? Då är det självförvar, utanför MiCA.
- Finns en operatör i återställnings-, paymaster-, keystore- eller synkkedjan som kan agera åt dig? Då glider du mot förvar.
- Rör kontot en börs? Räkna med KYC och reseregeln, inklusive bevis på att du kontrollerar adressen vid belopp över 1 000 euro.
- Kan din token vara ett finansiellt instrument, med aktieliknande rättigheter eller derivatexponering? Då gäller MiFID II och FI som marknadsmyndighet, inte MiCA.
- Har du loggat varje byte, varje gasbetalning i token och varje automatisk ombalansering för K4 avsnitt D?
- Vet du vem som bär förlusten om kontot töms? I självförvar är svaret du, utan tak.
Account abstraction är på väg att göra självförvar både säkrare och bekvämare än det var med seed-frasen. Men bekvämligheten får inte dölja att varje funktion som lägger till en mellanhand också kan flytta ditt konto över en juridisk gräns. Den som förstår var den gränsen går behåller det account abstraction egentligen lovar: kontroll, med ansvaret som följer med den.
Vanliga frågor
Är ett smart konto självförvar enligt MiCA?
Ja, om bara du kan signera och ingen annan kan flytta dina tillgångar eller byta din nyckel. Då driver plånboksleverantören ingen förvaringstjänst och faller utanför MiCA:s CASP-regler. Så fort en tredje part kan kontrollera åtkomstmedlen, alltså nyckeln eller medlen för att komma åt den, närmar sig kontot i stället förvarsdefinitionen i artikel 75.
När blir mitt smarta konto en reglerad tjänst?
Gränsen går vid kontroll för kundens räkning. En paymaster som bara betalar gas är sällan förvar, men en tjänst som kan rotera din nyckel, en inbäddad plånbok där leverantören håller en nyckeldel, eller en keystore som någon annan äger kan innebära att en tillståndspliktig förvaringstjänst har uppstått, ofta utan att vare sig du eller leverantören tänkt på det.
Gäller EU:s reseregel min självförvarsplånbok?
Inte så länge du bara flyttar mellan egna konton utan en börs inblandad. Men när du skickar till eller tar emot från en börs måste börsen följa förordning (EU) 2023/1113, och vid belopp över 1 000 euro verifiera att du kontrollerar din självförvarsadress, till exempel med en kryptografisk signatur eller ett Satoshi-test.
Hur beskattar Skatteverket smarta konton och gaslösa transaktioner?
Precis som andra kryptotillgångar. Varje avyttring, att sälja, byta eller betala, är en skattehändelse som redovisas på K4 avsnitt D, med 30 procent skatt på vinst och genomsnittsmetoden för omkostnadsbeloppet. Batchade byten, gas betald i token och automatiska sessionsnyckeltransaktioner är var och en avyttringar, även om appen bara visar ett tryck.
Vad är skillnaden mellan EIP-8141 och EIP-8130, och påverkar det mig?
EIP-8141 är Ethereums förslag till inbyggd account abstraction med frame transactions och godtycklig validering, medan Base:s EIP-8130 bygger på en keystore på kedjan med fasta nyckeltyper. För dig som användare är den viktigaste effekten att inbyggd account abstraction tar bort externa bundlers och relayer, vilket ger en renare och tydligare självförvarsberättelse.
Yuki Tanaka bevakar plånböcker, börser och regelverk för HOGE Wire.