{"id":523,"date":"2026-10-05T13:10:27","date_gmt":"2026-10-05T13:10:27","guid":{"rendered":"https:\/\/hoge.gg\/no\/smartkonto-selvforvart-tjeneste-mica-grensen-2026\/"},"modified":"2026-10-05T13:10:27","modified_gmt":"2026-10-05T13:10:27","slug":"smartkonto-selvforvart-tjeneste-mica-grensen-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/smartkonto-selvforvart-tjeneste-mica-grensen-2026\/","title":{"rendered":"Selvforvart eller tjeneste? Smartkontoens juss i 2026"},"content":{"rendered":"

De siste par \u00e5rene har account abstraction gjort kryptolommeboken merkbart lettere \u00e5 bruke. Du kan betale gassavgift i en stablecoin, samle flere handlinger i \u00e9n signatur, la en \u00abguardian\u00bb hjelpe deg tilbake inn hvis telefonen forsvinner, og i praksis aldri se en tolv ords frase. Markedsf\u00f8ringen kaller det selvforvaring med menneskelig ansikt. Det tekniske er imponerende, men det viktigste skiftet er ikke teknisk. Det er juridisk.<\/p>

Hele ansvarsarkitekturen i MiCA, EU-regelverket Norge har tatt inn via E\u00d8S, hviler p\u00e5 ett sp\u00f8rsm\u00e5l: hvem kontrollerer \u00abtilgangsmiddelet\u00bb til kryptoeiendelene. S\u00e5 lenge svaret er \u00abbare deg\u00bb, er du utenfor regelverket for tjenesteytere. I det \u00f8yeblikket en paymaster, en gjenopprettingstjeneste eller en skylagret passkey tar p\u00e5 en bit av den tilgangen, begynner grensen mot en regulert tjeneste \u00e5 bli uskarp. En smartkonto er bygget nettopp for \u00e5 spre tilgangen utover, og det er derfor den er interessant for en jurist, ikke bare en utvikler.<\/p>

Dette er ingen nisje. Ved inngangen til oktober 2026 viser BundleBear<\/a> over 1,3 milliarder ERC-4337-operasjoner fordelt p\u00e5 rundt 68 millioner kontoer, og mer enn 63 millioner aktive EIP-7702-delegeringer<\/a>. Titalls millioner kontoer lever allerede i denne gr\u00e5sonen. Denne artikkelen tegner opp hvor grensen faktisk g\u00e5r i 2026: hva Finanstilsynet f\u00f8rer tilsyn med, hva MiCA artikkel 75 gj\u00f8r noen ansvarlig for, hvordan reiseregelen n\u00e5r helt inn i den selvforvarte lommeboken, og hvorfor Skatteetaten ikke bryr seg om hvilken kontotype du bruker.<\/p>

En viktig presisering f\u00f8rst: dette er ingen juridisk r\u00e5dgivning, og gr\u00e5sonen vi beskriver er nettopp det, en gr\u00e5sone. Mye av det som f\u00f8lger er faglige vurderinger av hvordan et regelverk skrevet for tjenesteytere m\u00f8ter en teknologi som med vilje sprer kontroll utover. Rettspraksisen er ung, og de endelige svarene vil komme fra tilsyn og domstoler, ikke fra markedsf\u00f8ringen til en lommebok-app.<\/p>

Det korte svaret f\u00f8rst<\/h2>

En smartkonto der du alene holder n\u00f8kkelen, og peker den mot kode du selv kontrollerer, er selvforvaring. Den faller utenfor definisjonen av en kryptoeiendelstjeneste, og Finanstilsynet f\u00f8rer ikke tilsyn med den, like lite som tilsynet f\u00f8rer tilsyn med en papirlommebok. I det \u00f8yeblikket en tredjepart kontrollerer eller medkontrollerer tilgangsmiddelet, alts\u00e5 holder en n\u00f8kkelandel, kan flytte midlene dine, eller sitter i en obligatorisk gjenopprettingsvei, begynner det \u00e5 ligne oppbevaring og forvaltning p\u00e5 vegne av kunde. Det er en regulert tjeneste.<\/p>

De fleste produktene i 2026 lever et sted mellom disse ytterpunktene. Det praktiske poenget er enkelt og litt ubehagelig: etiketten \u00abselvforvaring\u00bb i appen er ikke det juridiske svaret. Arkitekturen er det. Resten av artikkelen handler om \u00e5 lese den arkitekturen, komponent for komponent.<\/p>

Hvorfor er dette verdt en hel artikkel? Fordi konsekvensene peker i hver sin retning. Er du reelt i selvforvaring, har du ingen \u00e5 klage til n\u00e5r noe ryker, men du slipper ogs\u00e5 en mellommann som kan fryse, feile eller g\u00e5 konkurs. Er du egentlig kunde hos en tjeneste, har du et lovfestet vern, men da gjelder ogs\u00e5 krav til identifikasjon, rapportering og tilsyn. \u00c5 vite hvilken side av streken du st\u00e5r p\u00e5 er derfor ikke akademisk; det avgj\u00f8r hvem som b\u00e6rer risikoen den dagen noe g\u00e5r galt.<\/p>

Fire slags konto, \u00e9n felles forvirring<\/h2>

For \u00e5 se hvor tilgangen havner, m\u00e5 man skille fire slags konto. En vanlig konto (EOA, \u00abexternally owned account\u00bb) er den klassiske: \u00e9n privat n\u00f8kkel 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 \u00abbundler\u00bb som pakker operasjonene dine, en \u00abpaymaster\u00bb som kan dekke gassen, og en felles \u00abEntryPoint\u00bb-kontrakt. En EIP-7702-konto er en vanlig konto som etter Pectra-oppgraderingen kan delegere til kontraktskode, alts\u00e5 l\u00e5ne egenskapene til en smartkontrakt uten \u00e5 bytte adresse. Og native account abstraction legger logikken rett inn i protokollen.<\/p>

Juridisk er dette en trapp, ikke et sprang. En vanlig konto har ingen andre parter: taper du n\u00f8kkelen, finnes det ingen \u00e5 ringe. En ERC-4337-konto legger til infrastruktur som i teorien kan la deg st\u00e5 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\u00f8kkelen, 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 \u00e5 interessere seg for.<\/p>

Forskjellen er ikke bare teknisk fjas. Hvert steg mot mer programmerbarhet legger til parter som potensielt tar p\u00e5 tilgangsmiddelet. Vil du ha hele mekanikken bak 7702, har vi g\u00e5tt gjennom den i regnskapet halvannet \u00e5r etter Pectra<\/a>. Her holder det \u00e5 se hvem som dukker opp ved siden av deg i hver modell.<\/p>

Kontotype<\/th>Hvem holder n\u00f8kkelen<\/th>Hvor bor logikken<\/th>Nye mellomledd<\/th><\/tr><\/thead>
Vanlig konto (EOA)<\/td>Du, \u00e9n privat n\u00f8kkel<\/td>I n\u00f8kkelen<\/td>Ingen<\/td><\/tr>
ERC-4337<\/td>Du, men kontoen er en kontrakt<\/td>I smartkontrakten<\/td>Bundler, paymaster, EntryPoint<\/td><\/tr>
EIP-7702<\/td>Du, samme n\u00f8kkel og adresse<\/td>I delegatkontrakten du peker p\u00e5<\/td>Delegatkontrakt, eventuell paymaster<\/td><\/tr>
Native AA<\/td>Du, n\u00f8kkel eller passkey<\/td>I protokollen og et keystore<\/td>Keystore, validatorregler<\/td><\/tr><\/tbody><\/table><\/figure>

\u00abTilgangsmiddelet\u00bb er hele poenget<\/h2>

MiCA artikkel 75<\/a> regulerer oppbevaring og forvaltning av kryptoeiendeler p\u00e5 vegne av kunder. Teksten snakker gjennomg\u00e5ende om to ting som kan g\u00e5 tapt: selve kryptoeiendelene, og \u00abtilgangsmiddelet\u00bb til dem. Det er et bevisst valg. En tjenesteyter kan miste kundens bitcoin, men den kan ogs\u00e5 miste det som gir tilgang til dem, alts\u00e5 n\u00f8kler, seed-fraser eller signeringsrettigheter, og konsekvensen for kunden er den samme.<\/p>

Derfor bygger artikkel 75 ansvaret rundt kontroll over tilgangen, ikke rundt hvem som \u00abeier\u00bb en n\u00f8kkel i teknisk forstand. En tjenesteyter som oppbevarer p\u00e5 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\u00e5 tidspunktet tapet oppstod. Dette er et strengt ansvar: det forutsetter ikke skyld hos forvareren. Avtalen mellom partene avgj\u00f8r om kunden beholder kontrollen, eller om kryptoeiendelene og tilgangsmiddelet overf\u00f8res til tjenesteyterens fulle kontroll.<\/p>

Det f\u00f8lger ogs\u00e5 konkrete plikter med \u00e5 v\u00e6re forvarer. En CASP som oppbevarer p\u00e5 vegne av kunder m\u00e5 blant annet f\u00f8re et register over posisjoner, holde kundenes kryptoeiendeler atskilt fra sine egne, og ha rutiner som gj\u00f8r at kundenes midler ikke blandes med foretakets ved en konkurs. Dette er helt vanlig verdipapir-tankegang overf\u00f8rt til krypto, og det er nettopp frav\u00e6ret av slike plikter som kjennetegner ren selvforvaring: der finnes det ikke noe register \u00e5 f\u00f8re, ingen midler \u00e5 skille ut, og ingen motpart som skal ha rutiner. Du er hele systemet.<\/p>

Legg merke til hva MiCA ikke sp\u00f8r om. Regelverket sp\u00f8r ikke \u00abfinnes det en privat n\u00f8kkel?\u00bb Det sp\u00f8r \u00abhvem kontrollerer tilgangsmiddelet?\u00bb 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\u00e6re en n\u00f8kkel pluss en delegatkontrakt, pluss en gjenopprettingsgruppe, pluss en skykopi av en passkey. Sp\u00f8rsm\u00e5let som var trivielt, blir plutselig vanskelig, og det er her hele gr\u00e5sonen oppst\u00e5r.<\/p>

N\u00e5r selvforvaring stille blir en tjeneste<\/h2>

La oss g\u00e5 gjennom komponentene en smartkonto typisk henter inn, og stille det samme sp\u00f8rsm\u00e5let for hver: r\u00f8rer denne parten tilgangsmiddelet, eller bidrar den bare?<\/p>

En paymaster betaler gassavgiften for deg. Circle sin paymaster<\/a> lar deg for eksempel betale gass i USDC mot et p\u00e5slag p\u00e5 rundt ti prosent. En ren paymaster flytter ikke midlene dine og kan ikke signere p\u00e5 dine vegne; den betaler en regning. Det ligner ikke forvaring. Men en \u00abpaymaster-as-a-service\u00bb som ogs\u00e5 tar h\u00e5nd om n\u00f8kler eller signeringspolicy er en annen sak.<\/p>

En gjenopprettingstjeneste (recovery-as-a-service) er mer f\u00f8lsom. Hvis et selskap driver \u00abguardians\u00bb som sammen kan gjenopprette kontoen din, og den gjenopprettingen er obligatorisk eller selskapet alene sitter p\u00e5 nok andeler til \u00e5 flytte midlene, da medkontrollerer selskapet tilgangsmiddelet. En skylagret passkey er en mildere variant av samme problem: n\u00e5r iCloud eller Google holder en faktor som kreves for \u00e5 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<\/a>.<\/p>

Ta et konkret oppsett mange m\u00f8ter uten \u00e5 tenke over det: en innebygd lommebok der du logger inn med e-post eller en sosial konto, n\u00f8kkelen lever i et sikkert maskinvaremilj\u00f8 p\u00e5 telefonen, og en skytjeneste tar vare p\u00e5 en sikkerhetskopi slik at du kommer inn igjen p\u00e5 en ny enhet. Dette markedsf\u00f8res som selvforvaring, og i de fleste hverdagssituasjoner oppf\u00f8rer det seg slik. Men hvis leverand\u00f8rens infrastruktur er n\u00f8dvendig for at du i det hele tatt skal kunne signere eller gjenopprette, da sitter leverand\u00f8ren p\u00e5 en del av tilgangsmiddelet, selv om den aldri \u00abser\u00bb en privat n\u00f8kkel i klartekst. Det er dette MiCA ber deg vurdere, ikke markedsf\u00f8ringen.<\/p>

En MPC-l\u00f8sning der tilbyderen holder en n\u00f8kkelandel er det tydeligste tilfellet. Hvis to av tre andeler trengs for \u00e5 signere, og selskapet holder \u00e9n, kan ingen part flytte midlene alene, men selskapet er en n\u00f8dvendig medunderskriver. Et modulregister leverer installerbar kode til kontoen din, og en bundler bestemmer rekkef\u00f8lgen operasjonene havner i. Sp\u00f8rsm\u00e5let om hvem som faktisk driver disse lagene, har vi tatt opp i gjennomgangen av de nye mellomleddene bak kontoen<\/a>. Tabellen under oppsummerer hvor hver komponent sannsynligvis lander, med det forbeholdet at dette er faglige vurderinger, ikke avklart rettspraksis.<\/p>

Komponent<\/th>Hvem r\u00f8rer tilgangsmiddelet<\/th>Sannsynlig MiCA-posisjon<\/th><\/tr><\/thead>
Ren paymaster (betaler gass)<\/td>Ingen tilgang til n\u00f8kler<\/td>Normalt utenfor forvaring<\/td><\/tr>
Bundler<\/td>Rekkef\u00f8lge, ikke kontroll<\/td>Normalt utenfor forvaring<\/td><\/tr>
Modulregister<\/td>Leverer kode, brukeren installerer<\/td>Gr\u00e5sone, avhenger av tvang<\/td><\/tr>
Skylagret passkey<\/td>Holder \u00e9n n\u00f8dvendig faktor<\/td>Gr\u00e5sone<\/td><\/tr>
Obligatorisk gjenoppretting<\/td>Medkontrollerer tilgangen<\/td>Lener mot tjeneste<\/td><\/tr>
MPC-andel hos tilbyder<\/td>N\u00f8dvendig medunderskriver<\/td>Lener mot forvaring<\/td><\/tr>
Full depotl\u00f8sning (b\u00f8rs)<\/td>Full kontroll<\/td>Forvaring, klar CASP<\/td><\/tr><\/tbody><\/table><\/figure>

Hva Finanstilsynet faktisk f\u00f8rer tilsyn med<\/h2>

Norge tok MiCA inn i nasjonal rett gjennom kryptoeiendelsloven<\/a>, som tr\u00e5dte i kraft 1. juli 2025 og gjennomf\u00f8rer forordning (EU) 2023\/1114 via E\u00d8S-avtalen. Finanstilsynet gir tillatelse til, og f\u00f8rer tilsyn med, kryptoeiendelstjenesteytere (CASP)<\/a>. De regulerte tjenestene er blant annet oppbevaring og forvaltning av kryptoeiendeler, drift av en handelsplattform, veksling (krypto mot penger og krypto mot krypto), overf\u00f8ringstjenester, r\u00e5dgivning og portef\u00f8ljeforvaltning. Foretak som allerede har tillatelse til tilsvarende tjenester kan n\u00f8ye seg med en melding etter artikkel 60; andre m\u00e5 s\u00f8ke full tillatelse etter artikkel 63.<\/p>

En tillatelse er ingen formalitet. S\u00f8keren m\u00e5 ha fysisk tilstedev\u00e6relse i E\u00d8S, egnede eiere og ledelse, kapital, og forsvarlige rutiner for alt fra oppbevaring til h\u00e5ndtering av interessekonflikter, og autorisasjonen f\u00f8res inn i et felles register hos den europeiske verdipapir- og markedstilsynsmyndigheten (ESMA). N\u00e5r et foretak f\u00f8rst har tillatelse i ett E\u00d8S-land, kan det tilby tjenestene sine over landegrensene gjennom s\u00e5kalt passporting. For brukeren er den praktiske l\u00e6rdommen enkel: sjekk at en tjeneste faktisk st\u00e5r i ESMA-registeret f\u00f8r du lar den oppbevare noe for deg.<\/p>

Tidslinjen har v\u00e6rt stram. Overgangsregelen i kryptoeiendelsloven skulle opprinnelig l\u00f8pe ut 30. desember 2025, men Finanstilsynet foreslo \u00e5 forlenge den til 30. juni 2026<\/a>, fordi et betydelig antall s\u00f8knader ikke ville rekke \u00e5 bli ferdigbehandlet i tide. Resultatet er at registrerte veksle- og oppbevaringstilbydere fikk fortsette til sommeren 2026, eller til de hadde f\u00e5tt eller blitt nektet tillatelse etter artikkel 63.<\/p>

De f\u00f8rste norske tillatelsene kom v\u00e5ren 2026. AK Jensen Norway AS<\/a> ble Norges f\u00f8rste CASP-foretak, T\u00fdr Markets AS<\/a> fikk den f\u00f8rste fulle tillatelsen etter artikkel 63 (med virkning fra 18. mai 2026), og Firi AS<\/a> 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\u00f8rer tilsyn med CASP-ene, ikke med ren selvforvaringsprogramvare. En lommebok-app som bare lar deg styre dine egne n\u00f8kler er i utgangspunktet ikke en kryptoeiendelstjeneste. Det er f\u00f8rst n\u00e5r produktet rundt smartkontoen begynner \u00e5 ta h\u00e5nd om tilgangen at tilsynet blir relevant.<\/p>

Ansvaret n\u00e5r koden svikter<\/h2>

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\u00e5 tapstidspunktet. Mister en CASP \u00e9n ETH p\u00e5 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\u00f8lge Fortunes prisnotering<\/a>. Du har alts\u00e5 en motpart med et lovfestet ansvar.<\/p>

Ren selvforvaring snur dette helt. Kontrollerer du tilgangsmiddelet selv, finnes det ingen CASP \u00e5 holde ansvarlig n\u00e5r noe g\u00e5r galt. Peker 7702-delegeringen din mot en ondsinnet kontrakt, godkjenner du en \u00abpermit\u00bb du ikke forsto, eller signerer du blindt en transaksjon som t\u00f8mmer kontoen, er tapet ditt og bare ditt. Forskere hos Wintermute fant at de aller fleste tidlige 7702-delegeringene pekte mot identisk sweeper-kode<\/a> som er bygget for \u00e5 dra ut midler i det en n\u00f8kkel allerede er kompromittert. Ingen tilsynsmyndighet dekker det.<\/p>

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 \u00e5 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\u00f8r v\u00e6re et bevisst et. Problemet oppst\u00e5r n\u00e5r et produkt selger deg f\u00f8lelsen av selvforvaringens suverenitet og samtidig en tjenestes bekvemmelighet, uten \u00e5 v\u00e6re tydelig p\u00e5 hvem som faktisk b\u00e6rer tapet den dagen noe ryker.<\/p>

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\u00e5 fysisk, slik vi beskrev i saken om skiften\u00f8kkel-angrep og fysisk tvang mot kryptoeiere<\/a>. Og n\u00e5r feilen ligger i koden snarere enn i n\u00f8kkelen, blir ansvarskjeden fort uklar; vi gikk gjennom et slikt tilfelle i analysen av Halborn og angrepene som omg\u00e5r revisjonen<\/a>. En smartkonto gj\u00f8r koden til en del av tilgangsmiddelet, og dermed gj\u00f8r den ogs\u00e5 koden til en del av ansvarssp\u00f8rsm\u00e5let.<\/p>

Reiseregelen m\u00f8ter den selvforvarte lommeboken<\/h2>

Selv en lommebok du eier helt alene slipper ikke unna det regulerte systemet i det den snakker med en b\u00f8rs. Reiseregelen, forordning (EU) 2023\/1113 (ofte omtalt som TFR), har v\u00e6rt i kraft siden 30. desember 2024<\/a> og p\u00e5legger CASP-er \u00e5 samle inn og sende med informasjon om avsender og mottaker ved overf\u00f8ringer av kryptoeiendeler.<\/p>

For overf\u00f8ringer p\u00e5 over 1 000 euro til eller fra en selvforvart lommebok g\u00e5r regelen lenger: b\u00f8rsen m\u00e5 verifisere at du faktisk eier eller kontrollerer adressen, typisk gjennom en \u00abSatoshi-test\u00bb (en liten verifiserende transaksjon), en signert melding, eller videoidentifikasjon. Den europeiske banktilsynsmyndigheten (EBA) har gitt egne retningslinjer for hvordan denne kontrollen skal gjennomf\u00f8res.<\/p>

I praksis betyr dette at selv den mest prinsippfaste selvforvareren m\u00f8ter systemet i det verdiene skal inn eller ut via en b\u00f8rs. B\u00f8rsen samler opplysninger om b\u00e5de avsender og mottaker, og over terskelen m\u00e5 den knytte den selvforvarte adressen til en identifisert person. Reiseregelen gj\u00f8r alts\u00e5 ikke smartkontoen din til en regulert tjeneste, men den gj\u00f8r 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.<\/p>

Konsekvensen er verdt \u00e5 dvele ved. Smartkontoen din kan v\u00e6re aldri s\u00e5 selvforvart, men idet den sender til eller mottar fra en norsk eller europeisk b\u00f8rs over terskelen, blir den trukket inn i perimeteret. Ikke som en regulert part i seg selv, men som et objekt den regulerte parten m\u00e5 dokumentere eierskapet til. Grensen mellom \u00abdeg\u00bb og \u00absystemet\u00bb er alts\u00e5 ingen mur. Den er en membran.<\/p>

Skatteetaten ser ingen forskjell<\/h2>

Der MiCA skiller skarpt mellom selvforvaring og tjeneste, bryr skatteretten seg ikke det minste om hvilken kontotype du bruker. Gevinst p\u00e5 kryptoeiendeler skattlegges som kapitalinntekt med 22 prosent i 2026, og hver realisasjon<\/a> utl\u00f8ser et skattepliktig tidspunkt. \u00abRealisasjon\u00bb er dessuten videre enn mange tror: et salg teller, en veksling fra \u00e9n token til en annen teller, og et kj\u00f8p 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\u00f8m av skattepliktige disposisjoner. Beholdningen inng\u00e5r i tillegg i formuesskatten til markedsverdi ved \u00e5rsskiftet.<\/p>

Det t\u00f8ffeste for brukeren er at ingenting av dette er forh\u00e5ndsutfylt. \u00abKryptovaluta er ikke forh\u00e5ndsutfylt p\u00e5 skattemeldingen\u00bb, sier seniorr\u00e5dgiver Marius Johansen i Skatteetaten, som understreker at ansvaret ligger hos den enkelte: \u00abDu m\u00e5 selv ta ansvar for \u00e5 f\u00f8re opp beholdning som formue, gevinst som inntekt eller eventuelt tap til fradrag.\u00bb<\/a><\/p>

Fra januar 2026 tr\u00e5dte CARF (Crypto-Asset Reporting Framework), OECDs internasjonale rapporteringsstandard, i kraft. Den p\u00e5legger veksle- og oppbevaringstjenester \u00e5 rapportere opplysninger direkte til skattemyndighetene, med f\u00f8rste rapportering i \u00e5rene som f\u00f8lger. Men her dukker selvforvaringens bakside opp igjen: en ren selvforvart smartkonto har ingen tjenesteyter som rapporterer p\u00e5 dine vegne, s\u00e5 ansvaret for \u00e5 dokumentere hver eneste disposisjon faller fullt og helt p\u00e5 deg.<\/p>

Native account abstraction: hvem arver gr\u00e5sonen<\/h2>

L\u00f8sningen mange i milj\u00f8et h\u00e5per p\u00e5, er native account abstraction: \u00e5 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\u00f8ket p\u00e5 \u00e5 samle seg om ett felles forslag. Ethereum g\u00e5r videre med EIP-8141<\/a> (\u00abframe transactions\u00bb), der Vitalik Buterin er blant forfatterne, mens Base og Coinbase satser p\u00e5 EIP-8130, en keystore-basert tiln\u00e6rming. Derek Chiang, som st\u00e5r bak ZeroDev og jobber i Ethlabs, oppsummerte bruddet<\/a> med at de tekniske l\u00f8sningene de fant, alle krevde at \u00e9n av sidene m\u00e5tte gi avkall p\u00e5 litt av sine kjernem\u00e5l.<\/p>

Drivkraften bak \u00e5 g\u00e5 native er det Buterin kaller \u00abintermediary minimization\u00bb. Han har formulert m\u00e5let slik: \u00abmaximize what you can do even if all the world’s infrastructure except the Ethereum chain itself goes down\u00bb<\/a>. Sp\u00f8rsm\u00e5let for en jurist er om native AA faktisk krymper gr\u00e5sonen. Svaret er delvis. F\u00e6rre eksterne bundlere betyr f\u00e6rre parter som r\u00f8rer operasjonsflyten. Men et keystore er fortsatt et sted der tilgangskonfigurasjonen bor, gjenoppretting involverer fortsatt noen, og passkey-synkronisering lener seg fortsatt p\u00e5 en skyleverand\u00f8r. Gr\u00e5sonen forsvinner ikke. Den flytter seg, fra bundleren til keystoret.<\/p>

Glamsterdam 6. oktober flytter ikke grensen<\/h2>

Det er lett \u00e5 blande sammen kalenderen. Ethereums neste oppgradering, Glamsterdam, aktiveres p\u00e5 testnettet Sepolia 6. oktober 2026<\/a> klokken 13.53.36 UTC, ved epoke 353 024. Oppgraderingen kombinerer Amsterdam p\u00e5 utf\u00f8relseslaget og Gloas p\u00e5 konsensuslaget, og hovedtrekkene<\/a> er ePBS (innebygd skille mellom blokkforesl\u00e5r og blokkbygger) og block-level access lists, alts\u00e5 ting som handler om kapasitet og blokkstruktur. En hovednettlansering ventes i l\u00f8pet av fjerde kvartal 2026, men uten fastsatt dato, og klientene regnes enn\u00e5 ikke som helt klare.<\/p>

Her er poenget: Glamsterdam er en gjennomstr\u00f8mningsoppgradering, ikke account abstraction. Den r\u00f8rer ikke ved hvem som kontrollerer tilgangsmiddelet, og den flytter derfor ikke en millimeter p\u00e5 grensen mellom selvforvaring og regulert tjeneste. Native AA ligger i en senere gaffel. N\u00e5r noen i oktober sier at \u00abEthereum endrer lommeb\u00f8kene denne uken\u00bb, snakker de om ytelse, ikke om jus.<\/p>

Sjekkliste: er \u00ablommeboken\u00bb din egentlig en tjeneste?<\/h2>

Du trenger ingen advokat for \u00e5 lese arkitekturen i grove trekk. Still produktet disse sp\u00f8rsm\u00e5lene:<\/p>