Selvforvart eller tjeneste? Smartkontoens juss i 2026
En smartkonto føles som ren selvforvaring, men MiCA bygger hele ansvaret rundt hvem som kontrollerer «tilgangsmiddelet». Vi tegner opp hvor grensen mot en regulert tjeneste faktisk går i 2026.
De siste par årene har account abstraction gjort kryptolommeboken merkbart lettere å bruke. Du kan betale gassavgift i en stablecoin, samle flere handlinger i én signatur, la en «guardian» hjelpe deg tilbake inn hvis telefonen forsvinner, og i praksis aldri se en tolv ords frase. Markedsføringen kaller det selvforvaring med menneskelig ansikt. Det tekniske er imponerende, men det viktigste skiftet er ikke teknisk. Det er juridisk.
Hele ansvarsarkitekturen i MiCA, EU-regelverket Norge har tatt inn via EØS, hviler på ett spørsmål: hvem kontrollerer «tilgangsmiddelet» til kryptoeiendelene. Så lenge svaret er «bare deg», er du utenfor regelverket for tjenesteytere. I det øyeblikket en paymaster, en gjenopprettingstjeneste eller en skylagret passkey tar på en bit av den tilgangen, begynner grensen mot en regulert tjeneste å bli uskarp. En smartkonto er bygget nettopp for å spre tilgangen utover, og det er derfor den er interessant for en jurist, ikke bare en utvikler.
Dette er ingen nisje. Ved inngangen til oktober 2026 viser BundleBear over 1,3 milliarder ERC-4337-operasjoner fordelt på rundt 68 millioner kontoer, og mer enn 63 millioner aktive EIP-7702-delegeringer. Titalls millioner kontoer lever allerede i denne gråsonen. Denne artikkelen tegner opp hvor grensen faktisk går i 2026: hva Finanstilsynet fører tilsyn med, hva MiCA artikkel 75 gjør noen ansvarlig for, hvordan reiseregelen når helt inn i den selvforvarte lommeboken, og hvorfor Skatteetaten ikke bryr seg om hvilken kontotype du bruker.
En viktig presisering først: dette er ingen juridisk rådgivning, og gråsonen vi beskriver er nettopp det, en gråsone. Mye av det som følger er faglige vurderinger av hvordan et regelverk skrevet for tjenesteytere møter en teknologi som med vilje sprer kontroll utover. Rettspraksisen er ung, og de endelige svarene vil komme fra tilsyn og domstoler, ikke fra markedsføringen til en lommebok-app.
Det korte svaret først
En smartkonto der du alene holder nøkkelen, og peker den mot kode du selv kontrollerer, er selvforvaring. Den faller utenfor definisjonen av en kryptoeiendelstjeneste, og Finanstilsynet fører ikke tilsyn med den, like lite som tilsynet fører tilsyn med en papirlommebok. I det øyeblikket en tredjepart kontrollerer eller medkontrollerer tilgangsmiddelet, altså holder en nøkkelandel, kan flytte midlene dine, eller sitter i en obligatorisk gjenopprettingsvei, begynner det å ligne oppbevaring og forvaltning på vegne av kunde. Det er en regulert tjeneste.
De fleste produktene i 2026 lever et sted mellom disse ytterpunktene. Det praktiske poenget er enkelt og litt ubehagelig: etiketten «selvforvaring» i appen er ikke det juridiske svaret. Arkitekturen er det. Resten av artikkelen handler om å lese den arkitekturen, komponent for komponent.
Hvorfor er dette verdt en hel artikkel? Fordi konsekvensene peker i hver sin retning. Er du reelt i selvforvaring, har du ingen å klage til når noe ryker, men du slipper også en mellommann som kan fryse, feile eller gå konkurs. Er du egentlig kunde hos en tjeneste, har du et lovfestet vern, men da gjelder også krav til identifikasjon, rapportering og tilsyn. Å vite hvilken side av streken du står på er derfor ikke akademisk; det avgjør hvem som bærer risikoen den dagen noe går galt.
Fire slags konto, én felles forvirring
For å se hvor tilgangen havner, må man skille fire slags konto. En vanlig konto (EOA, «externally owned account») er den klassiske: én privat nøkkel styrer alt, og mister du frasen, er alt borte. En ERC-4337-konto er en smartkontrakt som opptrer som konto, med et nytt lag av mellomledd under panseret: en «bundler» som pakker operasjonene dine, en «paymaster» som kan dekke gassen, og en felles «EntryPoint»-kontrakt. En EIP-7702-konto er en vanlig konto som etter Pectra-oppgraderingen kan delegere til kontraktskode, altså låne egenskapene til en smartkontrakt uten å bytte adresse. Og native account abstraction legger logikken rett inn i protokollen.
Juridisk er dette en trapp, ikke et sprang. En vanlig konto har ingen andre parter: taper du nøkkelen, finnes det ingen å ringe. En ERC-4337-konto legger til infrastruktur som i teorien kan la deg stå uten en vei inn hvis en bundler eller paymaster faller bort, men som i utgangspunktet ikke kan ta midlene dine. En 7702-konto beholder den vanlige nøkkelen, men peker den mot kode noen andre har skrevet og kan oppdatere. Og native-varianten flytter en del av denne logikken inn i protokollen og et keystore. For hvert trinn vokser listen over parter en tilsynsmyndighet kan komme til å interessere seg for.
Forskjellen er ikke bare teknisk fjas. Hvert steg mot mer programmerbarhet legger til parter som potensielt tar på tilgangsmiddelet. Vil du ha hele mekanikken bak 7702, har vi gått gjennom den i regnskapet halvannet år etter Pectra. Her holder det å se hvem som dukker opp ved siden av deg i hver modell.
| Kontotype | Hvem holder nøkkelen | Hvor bor logikken | Nye mellomledd |
|---|---|---|---|
| Vanlig konto (EOA) | Du, én privat nøkkel | I nøkkelen | Ingen |
| ERC-4337 | Du, men kontoen er en kontrakt | I smartkontrakten | Bundler, paymaster, EntryPoint |
| EIP-7702 | Du, samme nøkkel og adresse | I delegatkontrakten du peker på | Delegatkontrakt, eventuell paymaster |
| Native AA | Du, nøkkel eller passkey | I protokollen og et keystore | Keystore, validatorregler |
«Tilgangsmiddelet» er hele poenget
MiCA artikkel 75 regulerer oppbevaring og forvaltning av kryptoeiendeler på vegne av kunder. Teksten snakker gjennomgående om to ting som kan gå tapt: selve kryptoeiendelene, og «tilgangsmiddelet» til dem. Det er et bevisst valg. En tjenesteyter kan miste kundens bitcoin, men den kan også miste det som gir tilgang til dem, altså nøkler, seed-fraser eller signeringsrettigheter, og konsekvensen for kunden er den samme.
Derfor bygger artikkel 75 ansvaret rundt kontroll over tilgangen, ikke rundt hvem som «eier» en nøkkel i teknisk forstand. En tjenesteyter som oppbevarer på vegne av kunde er ansvarlig overfor kunden for tap av kryptoeiendeler eller tilgangsmiddel som skyldes en hendelse som kan tilskrives tjenesteyteren, og ansvaret er begrenset til markedsverdien av det tapte på tidspunktet tapet oppstod. Dette er et strengt ansvar: det forutsetter ikke skyld hos forvareren. Avtalen mellom partene avgjør om kunden beholder kontrollen, eller om kryptoeiendelene og tilgangsmiddelet overføres til tjenesteyterens fulle kontroll.
Det følger også konkrete plikter med å være forvarer. En CASP som oppbevarer på vegne av kunder må blant annet føre et register over posisjoner, holde kundenes kryptoeiendeler atskilt fra sine egne, og ha rutiner som gjør at kundenes midler ikke blandes med foretakets ved en konkurs. Dette er helt vanlig verdipapir-tankegang overført til krypto, og det er nettopp fraværet av slike plikter som kjennetegner ren selvforvaring: der finnes det ikke noe register å føre, ingen midler å skille ut, og ingen motpart som skal ha rutiner. Du er hele systemet.
Legg merke til hva MiCA ikke spør om. Regelverket spør ikke «finnes det en privat nøkkel?» Det spør «hvem kontrollerer tilgangsmiddelet?» I en vanlig lommebok er svaret trivielt: tilgangsmiddelet er seed-frasen, og den har du. I en smartkonto er tilgangsmiddelet ikke lenger ett objekt. Det kan være en nøkkel pluss en delegatkontrakt, pluss en gjenopprettingsgruppe, pluss en skykopi av en passkey. Spørsmålet som var trivielt, blir plutselig vanskelig, og det er her hele gråsonen oppstår.
Når selvforvaring stille blir en tjeneste
La oss gå gjennom komponentene en smartkonto typisk henter inn, og stille det samme spørsmålet for hver: rører denne parten tilgangsmiddelet, eller bidrar den bare?
En paymaster betaler gassavgiften for deg. Circle sin paymaster lar deg for eksempel betale gass i USDC mot et påslag på rundt ti prosent. En ren paymaster flytter ikke midlene dine og kan ikke signere på dine vegne; den betaler en regning. Det ligner ikke forvaring. Men en «paymaster-as-a-service» som også tar hånd om nøkler eller signeringspolicy er en annen sak.
En gjenopprettingstjeneste (recovery-as-a-service) er mer følsom. Hvis et selskap driver «guardians» som sammen kan gjenopprette kontoen din, og den gjenopprettingen er obligatorisk eller selskapet alene sitter på nok andeler til å flytte midlene, da medkontrollerer selskapet tilgangsmiddelet. En skylagret passkey er en mildere variant av samme problem: når iCloud eller Google holder en faktor som kreves for å signere, er en bit av tilgangen ute av dine hender. Vi har skrevet om nettopp telefonen og skyen som angrepsflate i stykket om Trail of Bits og mobiltrusselen.
Ta et konkret oppsett mange møter uten å tenke over det: en innebygd lommebok der du logger inn med e-post eller en sosial konto, nøkkelen lever i et sikkert maskinvaremiljø på telefonen, og en skytjeneste tar vare på en sikkerhetskopi slik at du kommer inn igjen på en ny enhet. Dette markedsføres som selvforvaring, og i de fleste hverdagssituasjoner oppfører det seg slik. Men hvis leverandørens infrastruktur er nødvendig for at du i det hele tatt skal kunne signere eller gjenopprette, da sitter leverandøren på en del av tilgangsmiddelet, selv om den aldri «ser» en privat nøkkel i klartekst. Det er dette MiCA ber deg vurdere, ikke markedsføringen.
En MPC-løsning der tilbyderen holder en nøkkelandel er det tydeligste tilfellet. Hvis to av tre andeler trengs for å signere, og selskapet holder én, kan ingen part flytte midlene alene, men selskapet er en nødvendig medunderskriver. Et modulregister leverer installerbar kode til kontoen din, og en bundler bestemmer rekkefølgen operasjonene havner i. Spørsmålet om hvem som faktisk driver disse lagene, har vi tatt opp i gjennomgangen av de nye mellomleddene bak kontoen. Tabellen under oppsummerer hvor hver komponent sannsynligvis lander, med det forbeholdet at dette er faglige vurderinger, ikke avklart rettspraksis.
| Komponent | Hvem rører tilgangsmiddelet | Sannsynlig MiCA-posisjon |
|---|---|---|
| Ren paymaster (betaler gass) | Ingen tilgang til nøkler | Normalt utenfor forvaring |
| Bundler | Rekkefølge, ikke kontroll | Normalt utenfor forvaring |
| Modulregister | Leverer kode, brukeren installerer | Gråsone, avhenger av tvang |
| Skylagret passkey | Holder én nødvendig faktor | Gråsone |
| Obligatorisk gjenoppretting | Medkontrollerer tilgangen | Lener mot tjeneste |
| MPC-andel hos tilbyder | Nødvendig medunderskriver | Lener mot forvaring |
| Full depotløsning (børs) | Full kontroll | Forvaring, klar CASP |
Hva Finanstilsynet faktisk fører tilsyn med
Norge tok MiCA inn i nasjonal rett gjennom kryptoeiendelsloven, som trådte i kraft 1. juli 2025 og gjennomfører forordning (EU) 2023/1114 via EØS-avtalen. Finanstilsynet gir tillatelse til, og fører tilsyn med, kryptoeiendelstjenesteytere (CASP). De regulerte tjenestene er blant annet oppbevaring og forvaltning av kryptoeiendeler, drift av en handelsplattform, veksling (krypto mot penger og krypto mot krypto), overføringstjenester, rådgivning og porteføljeforvaltning. Foretak som allerede har tillatelse til tilsvarende tjenester kan nøye seg med en melding etter artikkel 60; andre må søke full tillatelse etter artikkel 63.
En tillatelse er ingen formalitet. Søkeren må ha fysisk tilstedeværelse i EØS, egnede eiere og ledelse, kapital, og forsvarlige rutiner for alt fra oppbevaring til håndtering av interessekonflikter, og autorisasjonen føres inn i et felles register hos den europeiske verdipapir- og markedstilsynsmyndigheten (ESMA). Når et foretak først har tillatelse i ett EØS-land, kan det tilby tjenestene sine over landegrensene gjennom såkalt passporting. For brukeren er den praktiske lærdommen enkel: sjekk at en tjeneste faktisk står i ESMA-registeret før du lar den oppbevare noe for deg.
Tidslinjen har vært stram. Overgangsregelen i kryptoeiendelsloven skulle opprinnelig løpe ut 30. desember 2025, men Finanstilsynet foreslo å forlenge den til 30. juni 2026, fordi et betydelig antall søknader ikke ville rekke å bli ferdigbehandlet i tide. Resultatet er at registrerte veksle- og oppbevaringstilbydere fikk fortsette til sommeren 2026, eller til de hadde fått eller blitt nektet tillatelse etter artikkel 63.
De første norske tillatelsene kom våren 2026. AK Jensen Norway AS ble Norges første CASP-foretak, Týr Markets AS fikk den første fulle tillatelsen etter artikkel 63 (med virkning fra 18. mai 2026), og Firi AS fulgte like etter (fra 22. mai 2026). Felles for alle er at de er tjenesteytere. Poenget som ofte drukner i overskriftene er dette: Finanstilsynet fører tilsyn med CASP-ene, ikke med ren selvforvaringsprogramvare. En lommebok-app som bare lar deg styre dine egne nøkler er i utgangspunktet ikke en kryptoeiendelstjeneste. Det er først når produktet rundt smartkontoen begynner å ta hånd om tilgangen at tilsynet blir relevant.
Ansvaret når koden svikter
Her blir forskjellen mellom selvforvaring og tjeneste konkret, og dyr. Under artikkel 75 er en forvarer strengt ansvarlig overfor deg for tap som kan tilskrives den, opp til markedsverdien på tapstidspunktet. Mister en CASP én ETH på grunn av en hendelse den svarer for, er ansvaret begrenset til det ETH var verdt da tapet skjedde, i skrivende stund rundt 26 100 kroner per ETH (ETH i underkant av 2 720 dollar, med en dollarkurs rundt 9,62) ifølge Fortunes prisnotering. Du har altså en motpart med et lovfestet ansvar.
Ren selvforvaring snur dette helt. Kontrollerer du tilgangsmiddelet selv, finnes det ingen CASP å holde ansvarlig når noe går galt. Peker 7702-delegeringen din mot en ondsinnet kontrakt, godkjenner du en «permit» du ikke forsto, eller signerer du blindt en transaksjon som tømmer kontoen, er tapet ditt og bare ditt. Forskere hos Wintermute fant at de aller fleste tidlige 7702-delegeringene pekte mot identisk sweeper-kode som er bygget for å dra ut midler i det en nøkkel allerede er kompromittert. Ingen tilsynsmyndighet dekker det.
Forskjellen er ikke at den ene modellen er trygg og den andre farlig. En CASP kan hackes, og har historisk blitt det, men da finnes det en ansvarlig motpart, et krav om å holde midlene atskilt, og et tilsyn som kan gripe inn. Ved selvforvaring bytter du bort den motparten mot full kontroll. Det er et legitimt valg, men det bør være et bevisst et. Problemet oppstår når et produkt selger deg følelsen av selvforvaringens suverenitet og samtidig en tjenestes bekvemmelighet, uten å være tydelig på hvem som faktisk bærer tapet den dagen noe ryker.
Dette er byttehandelen i klartekst. Selvforvaring gir deg suverenitet og hele nedsiden; en regulert tjeneste gir deg et ansvarsvern, men du gir fra deg kontroll over tilgangen. Nedsiden ved selvforvaring er ikke bare teknisk: den er også fysisk, slik vi beskrev i saken om skiftenøkkel-angrep og fysisk tvang mot kryptoeiere. Og når feilen ligger i koden snarere enn i nøkkelen, blir ansvarskjeden fort uklar; vi gikk gjennom et slikt tilfelle i analysen av Halborn og angrepene som omgår revisjonen. En smartkonto gjør koden til en del av tilgangsmiddelet, og dermed gjør den også koden til en del av ansvarsspørsmålet.
Reiseregelen møter den selvforvarte lommeboken
Selv en lommebok du eier helt alene slipper ikke unna det regulerte systemet i det den snakker med en børs. Reiseregelen, forordning (EU) 2023/1113 (ofte omtalt som TFR), har vært i kraft siden 30. desember 2024 og pålegger CASP-er å samle inn og sende med informasjon om avsender og mottaker ved overføringer av kryptoeiendeler.
For overføringer på over 1 000 euro til eller fra en selvforvart lommebok går regelen lenger: børsen må verifisere at du faktisk eier eller kontrollerer adressen, typisk gjennom en «Satoshi-test» (en liten verifiserende transaksjon), en signert melding, eller videoidentifikasjon. Den europeiske banktilsynsmyndigheten (EBA) har gitt egne retningslinjer for hvordan denne kontrollen skal gjennomføres.
I praksis betyr dette at selv den mest prinsippfaste selvforvareren møter systemet i det verdiene skal inn eller ut via en børs. Børsen samler opplysninger om både avsender og mottaker, og over terskelen må den knytte den selvforvarte adressen til en identifisert person. Reiseregelen gjør altså ikke smartkontoen din til en regulert tjeneste, men den gjør den synlig for de regulerte partene den snakker med. For mange er nettopp denne kombinasjonen, full selvkontroll og samtidig full sporbarhet ved inn- og utgang, den mest overraskende delen av bildet i 2026.
Konsekvensen er verdt å dvele ved. Smartkontoen din kan være aldri så selvforvart, men idet den sender til eller mottar fra en norsk eller europeisk børs over terskelen, blir den trukket inn i perimeteret. Ikke som en regulert part i seg selv, men som et objekt den regulerte parten må dokumentere eierskapet til. Grensen mellom «deg» og «systemet» er altså ingen mur. Den er en membran.
Skatteetaten ser ingen forskjell
Der MiCA skiller skarpt mellom selvforvaring og tjeneste, bryr skatteretten seg ikke det minste om hvilken kontotype du bruker. Gevinst på kryptoeiendeler skattlegges som kapitalinntekt med 22 prosent i 2026, og hver realisasjon utløser et skattepliktig tidspunkt. «Realisasjon» er dessuten videre enn mange tror: et salg teller, en veksling fra én token til en annen teller, og et kjøp betalt med krypto teller. En gassfri smartkonto som betaler gass i en token, eller et kort som trekker fra en stablecoin i kontoen, produserer dermed en stille strøm av skattepliktige disposisjoner. Beholdningen inngår i tillegg i formuesskatten til markedsverdi ved årsskiftet.
Det tøffeste for brukeren er at ingenting av dette er forhåndsutfylt. «Kryptovaluta er ikke forhåndsutfylt på skattemeldingen», sier seniorrådgiver Marius Johansen i Skatteetaten, som understreker at ansvaret ligger hos den enkelte: «Du må selv ta ansvar for å føre opp beholdning som formue, gevinst som inntekt eller eventuelt tap til fradrag.»
Fra januar 2026 trådte CARF (Crypto-Asset Reporting Framework), OECDs internasjonale rapporteringsstandard, i kraft. Den pålegger veksle- og oppbevaringstjenester å rapportere opplysninger direkte til skattemyndighetene, med første rapportering i årene som følger. Men her dukker selvforvaringens bakside opp igjen: en ren selvforvart smartkonto har ingen tjenesteyter som rapporterer på dine vegne, så ansvaret for å dokumentere hver eneste disposisjon faller fullt og helt på deg.
Native account abstraction: hvem arver gråsonen
Løsningen mange i miljøet håper på, er native account abstraction: å legge kontologikken rett inn i protokollen og kvitte seg med de eksterne mellomleddene. Men selv her splittet veiene seg. Rundt midten av september 2026 ga Ethereum- og Base-leirene opp forsøket på å samle seg om ett felles forslag. Ethereum går videre med EIP-8141 («frame transactions»), der Vitalik Buterin er blant forfatterne, mens Base og Coinbase satser på EIP-8130, en keystore-basert tilnærming. Derek Chiang, som står bak ZeroDev og jobber i Ethlabs, oppsummerte bruddet med at de tekniske løsningene de fant, alle krevde at én av sidene måtte gi avkall på litt av sine kjernemål.
Drivkraften bak å gå native er det Buterin kaller «intermediary minimization». Han har formulert målet slik: «maximize what you can do even if all the world’s infrastructure except the Ethereum chain itself goes down». Spørsmålet for en jurist er om native AA faktisk krymper gråsonen. Svaret er delvis. Færre eksterne bundlere betyr færre parter som rører operasjonsflyten. Men et keystore er fortsatt et sted der tilgangskonfigurasjonen bor, gjenoppretting involverer fortsatt noen, og passkey-synkronisering lener seg fortsatt på en skyleverandør. Gråsonen forsvinner ikke. Den flytter seg, fra bundleren til keystoret.
Glamsterdam 6. oktober flytter ikke grensen
Det er lett å blande sammen kalenderen. Ethereums neste oppgradering, Glamsterdam, aktiveres på testnettet Sepolia 6. oktober 2026 klokken 13.53.36 UTC, ved epoke 353 024. Oppgraderingen kombinerer Amsterdam på utførelseslaget og Gloas på konsensuslaget, og hovedtrekkene er ePBS (innebygd skille mellom blokkforeslår og blokkbygger) og block-level access lists, altså ting som handler om kapasitet og blokkstruktur. En hovednettlansering ventes i løpet av fjerde kvartal 2026, men uten fastsatt dato, og klientene regnes ennå ikke som helt klare.
Her er poenget: Glamsterdam er en gjennomstrømningsoppgradering, ikke account abstraction. Den rører ikke ved hvem som kontrollerer tilgangsmiddelet, og den flytter derfor ikke en millimeter på grensen mellom selvforvaring og regulert tjeneste. Native AA ligger i en senere gaffel. Når noen i oktober sier at «Ethereum endrer lommebøkene denne uken», snakker de om ytelse, ikke om jus.
Sjekkliste: er «lommeboken» din egentlig en tjeneste?
Du trenger ingen advokat for å lese arkitekturen i grove trekk. Still produktet disse spørsmålene:
- Kan noen andre enn deg flytte midlene dine, alene eller sammen med et selskap?
- Avhenger gjenoppretting av én bestemt tilbyder som kan forsvinne?
- Holder tilbyderen en nøkkelandel (MPC) som trengs for å signere?
- Finnes det en obligatorisk skykopi av en faktor du ikke kan skru av?
- Kan du eksportere nøkkelen og forlate tjenesten uten å tape tilgang?
Jo flere «ja» på de fire første og «nei» på det siste, jo nærmere en regulert tjeneste er du, uansett hva appen kaller seg. Tabellen under viser hvordan de fire regelverkene treffer de to ytterpunktene.
| Dimensjon | Ren selvforvaring | Hybrid eller tjeneste |
|---|---|---|
| Kontroll over tilgang | Bare deg | Delt med, eller hos, tilbyder |
| Ansvar ved tap (MiCA art. 75) | Ditt eget | Tilbyder strengt ansvarlig, opp til markedsverdi |
| Tilsyn (Finanstilsynet) | Utenfor CASP-tilsyn | Kan være CASP |
| Reiseregelen (TFR) | Verifiseres av børs over 1 000 euro | Tilbyder er selv rapporteringspliktig |
| Skatt (Skatteetaten) | 22 % gevinst, du rapporterer selv | 22 % gevinst, CARF-rapportering fra tilbyder |
For utviklere og tilbydere: når trenger produktet ditt lisens?
For den som bygger, snur spørsmålet seg. Designvalget «skal produktet mitt ta på tilgangsmiddelet?» er samtidig et regulatorisk valg. Bygger du en paymaster som bare betaler gass, eller nøytral programvare brukeren selv kontrollerer, er du sannsynligvis utenfor. Lar du produktet holde en nøkkelandel, drive obligatorisk gjenoppretting, eller på annen måte kunne flytte kundens midler, nærmer du deg oppbevaring og forvaltning på vegne av kunde. Da snakker vi om full tillatelse etter artikkel 63, fysisk tilstedeværelse i EØS, og krav til kapital, styring og rapportering. Autoriserte CASP-er må i tillegg forholde seg til DORA, EUs regelverk for digital driftsstabilitet.
Gråsonen er ingen teoretisk kuriositet; den er et produktspørsmål med reelle konsekvenser. En MPC-arkitektur med to-av-tre der selskapet holder én andel «for brukervennlighetens skyld» kan være akkurat den detaljen som gjør et selvforvaringsprodukt til en tjeneste med konsesjonsplikt. Rådet til utviklere er kjedelig, men riktig: få en juridisk vurdering av hvem som faktisk kan bevege midlene, før du skriver «non-custodial» på forsiden.
Veien videre
Retningen er ganske tydelig. Da den EU-brede overgangsperioden tok slutt 1. juli 2026 (Finanstilsynet har uttalt seg om utløpet for Norges del), ba ESMA uregulerte tjenesteytere om å avvikle ordnet og ivareta kundenes interesser. Avviklingsplanene skulle la kundene overføre kryptoeiendelene sine enten «to an authorised CASP or to a self-hosted wallet», altså til en autorisert tjenesteyter eller til en selvforvart lommebok. Nettopp den todelingen er hele poenget i denne artikkelen: regelverket kjenner en autorisert tjeneste og en selvforvart lommebok, men en programmerbar smartkonto passer ikke rent inn i noen av boksene.
ESMA har, sammen med tilsyn som franske AMF, østerrikske FMA og italienske Consob, dessuten tatt til orde for mer enhetlig tilsyn, inkludert direkte ESMA-tilsyn med de største CASP-ene. Perimeteret vil med andre ord neppe bli mindre. Samtidig vil native AA, keystore-løsninger og de nye agentlommebøkene fortsette å teste akkurat det samme spørsmålet: hvem kontrollerer tilgangsmiddelet? For deg som bruker eller bygger betyr det én ting. Etiketten «selvforvaring» kommer til å bety mindre og mindre, og arkitekturen kommer til å bety mer og mer. Les den før du stoler på den.
Ofte stilte spørsmål
Er en smartkonto selvforvaring eller en regulert tjeneste?
Det kommer an på hvem som kontrollerer tilgangsmiddelet. Holder du nøkkelen alene og peker den mot kode du selv styrer, er det selvforvaring og utenfor MiCA. Så snart en tredjepart kan flytte midlene eller sitter i en obligatorisk gjenopprettingsvei, kan det regnes som oppbevaring på vegne av kunde, altså en regulert tjeneste.
Fører Finanstilsynet tilsyn med MetaMask eller en 7702-lommebok?
Nei, Finanstilsynet fører tilsyn med kryptoeiendelstjenesteytere (CASP) som driver oppbevaring, veksling eller handelsplattform, ikke med ren selvforvaringsprogramvare. En lommebok der du styrer dine egne nøkler er i utgangspunktet utenfor, men en tilbyder som holder en nøkkelandel eller driver obligatorisk gjenoppretting kan havne innenfor.
Hvem er ansvarlig hvis en paymaster eller delegatkontrakt tømmer smartkontoen min?
Ved ren selvforvaring er tapet ditt eget, fordi det ikke finnes noen tjenesteyter å holde ansvarlig. En CASP er etter MiCA artikkel 75 strengt ansvarlig, men bare for tap som kan tilskrives den, og ansvaret er begrenset til markedsverdien av det tapte på tapstidspunktet.
Hvordan beskattes en smartkonto i Norge?
På nøyaktig samme måte som annen krypto. Gevinst skattlegges som kapitalinntekt med 22 prosent ved hver realisasjon, beholdningen inngår i formuesskatten til markedsverdi ved årsskiftet, og ingenting er forhåndsutfylt. Fra 2026 rapporterer veksle- og oppbevaringstjenester under CARF, men en selvforvart konto må du dokumentere selv.
Endrer Glamsterdam (6. oktober) noe for smartkontoens juridiske status?
Nei. Glamsterdam er en gjennomstrømningsoppgradering med ePBS og block-level access lists, ikke account abstraction, og den rører ikke ved hvem som kontrollerer tilgangsmiddelet. Grensen mellom selvforvaring og regulert tjeneste er den samme før og etter oppgraderingen.
Av Yuki Tanaka, journalist i HOGE Wire med lommebøker, børser og kryptoregulering som fast beat.