Native account abstraction lander: Base, Cobalt og EIP-8130 i 2026

I femten måneder har account abstraction på Ethereum betydd én av to omveier. Enten ERC-4337, som legger en hel parallell infrastruktur av bundlere og EntryPoint-kontrakter oppå kjeden, eller EIP-7702, som lot en helt vanlig konto låne kode fra en kontrakt etter Pectra-oppgraderingen i mai 2025. Begge to hektet smartkonto-egenskaper på en kjede som i kjernen fortsatt bare forstår én slags konto. Nå er det i ferd med å endre seg på den største L2-en: Base sender native account abstraction gjennom EIP-8130 i Cobalt-oppgraderingen i september 2026, og gjør smartkontoen til noe kjeden gjør selv, ikke noe apper limer på i etterkant.

Timingen er talende. ETH omsettes rundt 2 450 dollar, i underkant av 23 000 kroner, etter en oppgang på omtrent 31 prosent siden begynnelsen av august (MetaMask), og oppmerksomheten rundt lommebøker har sjelden vært høyere. Da vi skrev om kappløpet om native account abstraction tidligere i sommer, sto tre leire mot hverandre. Nå er kampen i ferd med å avgjøres, ikke i et hvitt dokument, men på et hovednett: en L2 sender protokollnativ account abstraction måneder før Ethereum selv har låst sin versjon inn i en oppgradering. Og grunnleggeren av WalletConnect har nettopp skiftet leir.

Denne gjennomgangen tar for seg hva som faktisk skjer under panseret i EIP-8130, hvordan det skiller seg fra Vitalik Buterins konkurrerende EIP-8141, hva Base sender i Cobalt, og hva det hele betyr for gass, sikkerhet, børser og for norske brukere som holder nøklene selv.

Hva native account abstraction egentlig betyr

Ethereum har fra første stund hatt to kontotyper: eksternt eide kontoer (EOA-er), som styres av en privatnøkkel og en fast signeringsmetode kalt secp256k1, og kontraktskontoer, som styres av kode men ikke kan starte en transaksjon selv. Hele poenget med account abstraction er å viske ut det skillet, slik at en konto kan bestemme sine egne regler for hva som teller som en gyldig signatur, hvem som betaler for gassen, og hvordan flere handlinger samles i én.

Frem til nå har dette skjedd som et tillegg. ERC-4337 bygger et eget økosystem av UserOperations, bundlere og en singleton EntryPoint-kontrakt oppå kjeden, uten å endre selve protokollen. EIP-7702 lar en EOA peke på kode i en kontrakt gjennom en delegeringsmarkør, slik at den vanlige kontoen din midlertidig oppfører seg som en smartkonto. Begge fungerer, og skalaen er reell: BundleBear teller over 1,26 milliarder UserOps og mer enn 65 millioner aktive kontoer under ERC-4337 (BundleBear), og over 53 millioner Ethereum-kontoer har fått en aktiv delegering via EIP-7702 (BundleBear).

Native account abstraction snur dette på hodet. I stedet for å legge logikk oppå kjeden, flytter den valideringen inn i protokollen selv. Kjeden validerer hver transaksjon mot kontoens eget oppsett, uten bundlere, uten EntryPoint, uten en egen mempool ved siden av. Slik Base beskriver det, betyr det at smartkontoer virker uten den ekstra infrastrukturen som ERC-4337 krever. Hver konto blir en smartkonto som standard, og prisen for den ekstra rørleggingen forsvinner.

Veien hit: fra ERC-4337 via EIP-7702 til native

Det er verdt å forstå de tre lagene, for de eksisterer fortsatt side om side. ERC-4337 ble ferdigstilt i mars 2023 og ga oss bundlere som pakker brukerhandlinger, paymasters som kan dekke gass, og en EntryPoint-kontrakt som binder det sammen. Nyere versjoner av EntryPoint, som v0.8 fra 2025, la til støtte for EIP-7702, slik at de to standardene spiller på lag i stedet for å konkurrere.

EIP-7702 kom med Pectra 7. mai 2025 og innførte en ny transaksjonstype, 0x04, som skriver en delegeringsmarkør (0xef0100 etterfulgt av en kontraktsadresse) inn i en vanlig konto. Delegeringen er reverserbar og knyttet til én kjede. Adopsjonen har vært rask, men også en påminnelse om baksiden: Wintermute fant at over 97 prosent av de tidlige delegeringene var gjenbrukt sveiper-kode kalt CrimeEnjoyor, kode som forsøkte å tømme kontoer, men som stort sett var ulønnsom fordi den traff allerede kompromitterte, tomme lommebøker (CoinDesk).

Både 4337 og 7702 er i praksis stillaser rundt en begrensning. De etterligner en smartkonto uten at kjeden vet hva en smartkonto er. Native account abstraction fjerner stillaset. Det er dette Vitalik Buterin har kalt endgame for account abstraction, og det er dette Base nå faktisk sender på et hovednett. Poenget med å gå native er ikke bare eleganse; det er å kutte avhengigheten av mellomledd. Buterin har gjentatte ganger pekt på at smartkontoer i dag lener seg på bundlere og relayere som utgjør en kilde til skjørhet, og har foreslått mekanismer som FOCIL (EIP-7805) for å garantere at transaksjoner kommer med i blokker uten å måtte gå gjennom slike aktører (news.bitcoin.com). Når valideringen ligger i protokollen, trengs ingen ekstern bundler i det hele tatt.

EIP-8130: kontoen som et oppsett

EIP-8130 bærer tittelen «Account Abstraction by Account Configuration», og navnet forteller mye. Forslaget er skrevet av Chris Hunter i Coinbase og Base, med utkast fra oktober 2025, og behandler kontoen som et oppsett kjeden kan lese, ikke som en kontrakt du må distribuere. I stedet for at hver bruker deployerer sin egen smartkontraktlommebok, lagrer en Keystore-kontrakt på en fast adresse kontoens preferanser på kjeden, en slags universell innstillingspanel for kontoen din (Crypto Briefing).

Teknisk innfører EIP-8130 én ny transaksjonstype, AA_TX_TYPE 0x79, som valideres av protokollen selv. Det avgjørende designvalget er at kontoen ikke kan bruke vilkårlig valideringslogikk. I stedet velger den fra et fast sett kanoniske signeringsmetoder: secp256k1 (Ethereums eksisterende ordning), P-256 (kurven i Apples og Googles sikre brikker), WebAuthn (passkey-standarden) og en delegat-metode for autorisasjon på tvers av kontoer. Denne innstrammingen er hele ideen: ved å begrense mulighetene blir valideringen forutsigbar, billig og lett å implementere likt overalt.

Standarden opererer i to nivåer. Nivå 1 er ment for Ethereum-hovednettet og lignende kjeder, med en normativ gass-plan og mer tillatende aksept for fleksibilitet. Nivå 2 er ment for kjeder med høy kapasitet som Base og andre L2-rollups, med validering kun av de kanoniske metodene for forutsigbar ytelse. For kontoer som trenger noe utenom, finnes ERC-4337 fortsatt som fallback. Tabellen under oppsummerer forslaget.

Cobalt: dette sender Base i september

Cobalt er neste milepæl i Base sitt veikart, og følger Beryl-oppgraderingen som traff hovednettet 25. juni 2026 med den native token-standarden B20. Der Beryl handlet om tokens, handler Cobalt om kontoer. Standarden testes allerede av utviklere på Base Vibenet, et midlertidig utviklernett (kjede-ID 84538453), før den aktiveres på hovednettet i Cobalt i september 2026. En eksakt dato var ikke kunngjort da denne artikkelen ble skrevet.

Base fremhever tre native funksjoner: gass-sponsing (apper kan dekke brukerens gass eller la brukeren betale i hvilken som helst token, via utkastet ERC-8168), batch-kall (flere handlinger samlet atomisk i én transaksjon) og session keys (native aktører med avgrenset fullmakt, slik at en app kan signere innenfor en definert ramme uten å be om bekreftelse hele tiden). I tillegg kommer portabilitet på tvers av kjeder, parallelle nonces, underkontoer og nøkkelrotasjon som gir en vei ut hvis kvantedatamaskiner en dag truer dagens signaturer (Bitget News).

Gevinsten Base oppgir er konkret. En vanlig USDC-overføring med native account abstraction bruker 46 000 gass mot 125 000 med ERC-4337, en reduksjon på 63,2 prosent, og datamengden faller fra 1 090 til 180 byte. En overføring signert med passkey og med gassen sponset bruker 68 700 gass mot 173 000. Base beskriver det samlet som mer enn dobbelt så billig per transaksjon (Base Engineering).

Base bygger dette sammen med Optimism, Coinbase og WalletConnect, og planen er at OP Stack-kjeder skal ta i bruk standarden senere i 2026. Cobalt pakker også inn andre endringer under panseret, blant annet en samlet node-programvare som slår sammen konsensus- og eksekveringsklienten, men det er den native account abstraction-delen som endrer hverdagen for lommeboker og brukere.

EIP-8130 mot EIP-8141: to veier til samme mål

EIP-8130 er ikke det eneste forslaget om native account abstraction, og det er ikke engang det mest kjente. Den andre veien går gjennom EIP-8141, foreslått av Vitalik Buterin og flere 28. februar 2026. Der 8130 låser kontoen til et fast oppsett, går 8141 motsatt vei og tillater vilkårlig validering. Mekanismen kalles frame transactions, en ny transaksjonstype 0x06 som deler en transaksjon i en VERIFY-ramme (signatursjekk og betaling av gebyr) og én eller flere EXECUTE-rammer. Noder må simulere valideringen innenfor et gassbudsjett før transaksjonen slipper inn i mempoolen (Everstake).

Buterin har beskrevet 8141 som en samlepakke. Han kalte forslaget «an omnibus that wraps up and solves every remaining problem that AA was intended to address», og sa at native smartkontoer kunne lande «within a year» gjennom det han omtaler som Hegota-forken (Cointelegraph). Fordelen er fleksibilitet: multisig, sosial gjenoppretting, nøkkelrotasjon og til og med fremtidige kvantesikre signaturer kan bli native deler av kontomodellen, ikke bare tilleggsfunksjoner i lommeboka.

Prisen er kompleksitet. EIP-8141 fikk «Considered for Inclusion»-status på All Core Devs-samtalen 27. mars 2026 og er rettet mot Hegota-oppgraderingen (arbeidsnavn) sent i 2026, men klientteam som Nethermind og Besu har flagget implementeringskompleksitet, og nyere dekning omtaler forslaget som noe som har rykket videre mot planlagt inkludering uten å bli oppgraderingens hovedoppslag (CCN). Kontrasten til 8130 er slående: der 8141 fortsatt er en kandidat for et fremtidig L1-vindu, sendes 8130 på et L2-hovednett i september. Tabellen under stiller de to opp mot hverandre.

Momentumskiftet: da WalletConnect skiftet leir

Det tydeligste tegnet på hvilken vei vinden blåser, kom fra en som hadde brukt måneder på den andre siden. Pedro Gomes, grunnlegger av WalletConnect, skrev at han etter lang tid med EIP-8141 nå er «convinced EIP-8130 is the better path for native account abstraction», og at standarden er «simpler, more portable, and focused on what wallets actually need» (@pedrouid). At WalletConnect, som kobler tusenvis av apper og lommeboker sammen, offentlig lener seg mot den konfigurasjonsbaserte tilnærmingen, er ikke et teknisk detaljspørsmål. Det er infrastrukturen brukere faktisk møter når de logger inn i en desentralisert app.

Det er samtidig verdt å holde hodet kaldt. De to forslagene er ikke nødvendigvis et enten-eller. Én lesning er at 8130 er det pragmatiske L2-steget som kan tas nå, mens 8141 er L1-endgame som tar lengre tid fordi det gjør mer. En annen er at et fragmentert felt med to konkurrerende transaksjonstyper kan gi lommebokutviklere doble integrasjonsjobber i årevis. Det som er sikkert, er at 8130 har fått fart, en dato og en kjede å lande på, mens 8141 fortsatt diskuteres i klientteamene.

Hvem betaler gassen nå?

Gassfrihet har vært selve salgsargumentet for account abstraction, men noen må alltid betale. Under ERC-4337 skjer det gjennom en paymaster-kontrakt koblet til EntryPoint. Circle Paymaster lar deg for eksempel betale gass i USDC på Base og Arbitrum, mot et påslag på rundt 10 prosent for å dekke prissvingninger og veksling (Circle). Det fungerer, men det legger til et mellomledd, og hvert mellomledd er både en kostnad og en avhengighet. Vi har gått dypere inn i denne økonomien i artikkelen om hvem som betaler gassen under EIP-7702 og paymasters.

Native account abstraction flytter denne mekanikken inn i protokollen. I EIP-8130 er gass-sponsing en innebygd egenskap, beskrevet gjennom utkastet ERC-8168, og betaling i token er en del av standarden i stedet for et påklistret lag. En app kan dekke brukerens gass, eller brukeren kan betale i en stablecoin, uten en egen paymaster-kontrakt som tar sitt kutt og krever tillit. Færre mellomledd betyr lavere kostnad og færre steder ting kan gå galt, og det er nettopp derfor tallene fra Base viser en så kraftig reduksjon i gass og datamengde.

For en norsk bruker er det verdt å merke seg en hake: å betale gass i en stablecoin er ikke gratis i skattemessig forstand, men det kommer vi tilbake til.

Passkeys, P-256 og slutten på seed-frasen

En av de mest merkbare endringene for vanlige brukere handler om hvordan du signerer. P-256, også kalt secp256r1, er kurven som ligger bak passkeys, Apples Secure Enclave, Androids nøkkellager og WebAuthn-standarden. Problemet har vært at Ethereum ikke forstår denne kurven native, så å verifisere en passkey-signatur på kjeden har vært dyrt. RIP-7212 løste dette med en precompile kalt P256VERIFY på adresse 0x100, som kutter kostnaden fra rundt 300 000 gass til om lag 3 450, altså rundt hundre ganger billigere, og ble tatt i bruk tidlig av blant andre Arbitrum og Polygon (Alchemy).

EIP-8130 bygger P-256 og WebAuthn rett inn i settet av kanoniske signeringsmetoder. Resultatet er kontoer som kan styres av en passkey lagret i telefonens sikre brikke, uten den dyre omveien. I praksis betyr det at seed-frasen kan bli valgfri: du logger inn med Face ID eller fingeravtrykk, og kontoen godtar signaturen fordi protokollen forstår den. For en hel generasjon brukere som aldri har lært å skrive ned tolv ord på et papir, er dette forskjellen mellom å prøve krypto og å gi opp.

Det er ikke uten forbehold. Passkeys synkroniseres ofte gjennom iCloud eller Google, og den synkroniseringsveven blir da et enkeltpunkt som kan svikte eller angripes. Portabiliteten mellom økosystemer er fortsatt umoden, selv om standarder for å flytte passkeys mellom leverandører er under arbeid. Delegat-metoden i 8130 gir en vei til gjenoppretting og backup-nøkler, men den som setter opp en passkey-kontoen bør forstå hvor den egentlig ligger, og hva som skjer hvis telefonen mistes.

Nøkler, gjenoppretting og det som kan gå galt

Keystore-kontrakten er både den store nyvinningen og et nytt ansvarsområde. Fordi kontoens oppsett ligger på kjeden, kan du rotere nøkler, legge til en delegat for gjenoppretting, opprette underkontoer med avgrensede fullmakter og bytte signeringsmetode uten å flytte midlene dine. Spesifikasjonen slår fast at bare kontoen selv kan endre sitt eget oppsett, noe som lukker den mest åpenbare angrepsdøren. Men et oppsett på kjeden er også offentlig og programmerbart, og programmerbarhet er alltid en ny flate å angripe.

For organisasjoner og forvaltning av felleskassen forsvinner ikke behovet for multisig og delt kontroll fordi kontoen ble smartere. Safe forblir standarden for lag som forvalter store verdier, og valget mellom terskelsignatur og distribuert nøkkelgenerering er fortsatt reelt. Vi har sammenlignet de to tilnærmingene i gjennomgangen MPC eller multisig: hvordan proffene deler nøkkelen. Poenget er at native account abstraction gir bedre byggeklosser, ikke automatisk bedre rutiner. En smartkonto med dårlig nøkkelhåndtering er fortsatt en dårlig sikret konto.

Den nye angrepsflaten

Når validering flyttes inn i kode, blir koden angrepsflaten. Det tydeligste eksempelet er fortsatt Bybit-tyveriet 21. februar 2025, der rundt 1,5 milliarder dollar forsvant fra det som var en Safe-smartkonto. Feilen lå ikke i Safe-kontrakten, men i at angriperne (tilskrevet Lazarus-gruppen) kompromitterte en utviklermaskin, injiserte skadelig kode i signeringsgrensesnittet, og fikk signererne til å godkjenne en transaksjon som byttet ut kontoens implementasjon via delegatecall. Signererne så en normal overføring; det de faktisk signerte, var noe annet (NCC Group). Maskinvarelommeboker hjalp ikke, fordi de bare viste en hash, ikke handlingen.

Native account abstraction fjerner ikke dette problemet av seg selv. Blindsignering, altså å godkjenne data du ikke kan lese, er like farlig på en smartkonto som på en EOA. Løsningen er clear signing, der lommeboka viser hva du faktisk signerer i klartekst, en innsats standarden ERC-7730 forsøker å systematisere. Samtidig er det ny kode som må granskes: Keystore-kontrakten, de nye precompile-ene og valideringslogikken må revideres nøye før milliarder flyter gjennom dem. Sikkerhetsselskaper som gransker smartkontrakter for institusjonelle verdier får en større jobb, ikke en mindre, slik vi beskrev i Halborn på Wall Street.

Det finnes også en styrings- og fullmaktsdimensjon. Session keys og delegater gir apper rett til å handle på dine vegne innenfor en ramme, og en for vid ramme er en for stor sprengladning hvis nøkkelen lekker. Erfaringene fra angrep mot fullmakter og styringsmekanismer er relevante her, og vi har samlet forsvaret i gjennomgangen av hvordan du stopper et styringsangrep. Den gode nyheten er at det samlede trusselbildet faktisk har blitt bedre på ett punkt: phishing- og drenerings-tapene falt 83 prosent i 2025, til rundt 83,85 millioner dollar, ifølge Scam Sniffer (Cointelegraph). Marius van der Wijden, kjerneutvikler i Ethereum, oppsummerte holdningen som trengs: dette er «still a very early proposal, so we need to evaluate all the rough edges» (DL News).

Hva det betyr for børser og lommebøker

For lommebøkene er dette både en mulighet og en tvang. MetaMask, Ambire, Rabby, Safe og Coinbase sin egen Base Account har alle beveget seg mot smartkonto-modeller, og en protokollnativ standard senker terskelen for å tilby gassfrihet, batching og passkey-innlogging uten å drive egen bundler-infrastruktur. De som ikke følger med, risikerer å tilby en klønete opplevelse mot konkurrenter der onboarding føles som en vanlig app.

For børsene handler det om håndtering. Innskudd fra og uttak til smartkontoer må gjenkjennes og behandles riktig, og en konto som styres av en passkey eller en delegat oppfører seg ikke som en klassisk EOA. Coinbase sin strategi er verdt å legge merke til her, for selskapet bygger hele stabelen: en egen L2 i Base, en egen kontostandard i EIP-8130, innebygde lommeboker og oppkjøp som styrker distribusjonen. Vi så et eksempel på den appetitten da Coinbase kjøpte Vector. Når den som eier børsen også skriver kontostandarden og driver kjeden den lander på, flyttes mye makt til ett sted i stabelen.

Norge: Finanstilsynet, Skatteetaten og selvforvaring

MiCA gjelder i Norge gjennom kryptoeiendelsloven, som trådte i kraft 1. juli 2025 via EØS-avtalen. Finanstilsynet gir tillatelser til tjenestetilbydere (CASP-er), enten full autorisasjon etter artikkel 63 eller melding etter artikkel 60, og krever fysisk tilstedeværelse i EØS (Finanstilsynet). De første norske aktørene med MiCA-tillatelse er på plass, blant dem AK Jensen Norway AS og Týr Markets AS, i tillegg til etablerte Firi.

Det viktige for denne artikkelen er hva som faller utenfor. En ren selvforvart smartkonto, der du selv holder nøkkelen eller passkeyen, er ikke en tjeneste og reguleres ikke som en CASP. Men native account abstraction gjør grensene gråere. Hvis gjenoppretting skjer via en skytjeneste, hvis en tredjepart tilbyr paymaster-tjenester som en betalt tjeneste, eller hvis en delegat holdes av et selskap, kan tilbudet nærme seg noe Finanstilsynet ser på som en tjeneste. Skillet mellom verktøy og tjeneste blir et vurderingsspørsmål, ikke en teknisk selvfølge.

Skattemessig behandler Skatteetaten gevinst og tap likt uansett om du bruker en vanlig konto eller en smartkonto: realisert gevinst skattlegges som kapitalinntekt med 22 prosent (Skatteetaten). Her ligger en praktisk felle i gassfriheten. Å betale gass i en stablecoin regnes som en realisasjon av den stablecoinen, altså en skattepliktig hendelse, selv om beløpet er lite. Med native account abstraction som gjør slike mikrobetalinger vanlige, kan du ende opp med hundrevis av små disposisjoner som i prinsippet skal føres. Fra 1. januar 2026 gjelder også CARF-rapportering, som pålegger kryptotilbydere systematisk å rapportere opplysninger, så gapet mellom hva som skjer på kjeden og hva Skatteetaten kan se, krymper.

Veien videre etter Cobalt

Det umiddelbare å følge med på er selve Cobalt-aktiveringen på Base i september, og deretter hvor raskt OP Stack-kjedene tar i bruk EIP-8130. Blir standarden delt på tvers av mange L2-er, er portabiliteten reell; blir den værende Base-spesifikk, er den mest en Coinbase-fordel. På L1-siden er spørsmålet om EIP-8141 faktisk kommer med i Hegota, og om FOCIL leverer på løftet om at smartkontoer ikke lenger skal være prisgitt bundlere og relayere for å komme med i en blokk.

Det store åpne spørsmålet er om de to standardene konvergerer eller splitter feltet. Buterin har argumentert for at intermediary minimization er et kjerneprinsipp, at målet er å kunne gjøre mest mulig selv om alt av infrastruktur utenom Ethereum-kjeden skulle falle bort. EIP-8130 tar en mer pragmatisk vei og aksepterer et begrenset sett metoder for å lande raskt. Begge kan ha rett samtidig: L2-ene får en enkel, portabel standard nå, mens L1 tar seg tid til den mer fleksible endgame-versjonen. For norske brukere er den praktiske testen enkel. Blir det å bruke krypto til slutt like lett som å åpne en bankapp, uten seed-fraser, uten gasskjøp i forkant og uten frykt for å signere feil? Cobalt er det første hovednettet der vi får se om svaret er ja.

Frequently Asked Questions

Hva er native account abstraction, og hvordan skiller det seg fra ERC-4337 og EIP-7702?

Native account abstraction betyr at selve Ethereum-protokollen validerer transaksjoner mot kontoens eget oppsett, uten bundlere, EntryPoint-kontrakter eller en egen mempool. ERC-4337 legger smartkonto-logikk oppå kjeden som en parallell infrastruktur, og EIP-7702 lar en vanlig konto midlertidig låne kode fra en kontrakt. Native AA, slik EIP-8130 definerer det, bygger evnene inn i kjeden selv, slik at hver konto oppfører seg som en smartkonto som standard.

Når lanserer Base native account abstraction?

Base sender native account abstraction gjennom EIP-8130 i Cobalt-oppgraderingen i september 2026. Standarden testes allerede på utviklernettet Vibenet, og OP Stack-kjeder ventes å følge senere samme år. En eksakt dato for hovednettet var ikke kunngjort da denne artikkelen ble skrevet.

Hva er forskjellen på EIP-8130 og EIP-8141?

EIP-8130 fra Coinbase og Base beskriver kontoen som et fast oppsett med et begrenset sett signeringsmetoder (secp256k1, P-256, WebAuthn og delegat) og lander på Base allerede i 2026. EIP-8141 fra Vitalik Buterin og flere bruker frame transactions og tillater vilkårlig validering, inkludert fremtidige kvantesikre signaturer, men er foreløpig en kandidat for Ethereums Hegota-oppgradering sent i 2026. Kort sagt: 8130 er enklere og lander først på en L2, 8141 er mer fleksibel og sikter mot selve L1.

Blir smartkontoer på Base billigere med native account abstraction?

Ja. Base oppgir at en USDC-overføring med native AA bruker 46 000 gass mot 125 000 med ERC-4337, en reduksjon på 63,2 prosent, og at datamengden faller 83,4 prosent. En overføring med passkey og gass-sponsing bruker 68 700 gass mot 173 000. Base beskriver det samlet som mer enn dobbelt så billig per transaksjon.

Hvordan beskattes en smartkonto i Norge, og gjelder MiCA for selvforvaring?

Skatteetaten behandler gevinst og tap likt enten du bruker en vanlig konto eller en smartkonto, med 22 prosent skatt på realisert gevinst, og å betale gass i en stablecoin regnes som en realisasjon. MiCA, innført i Norge gjennom kryptoeiendelsloven fra 1. juli 2025, regulerer tjenestetilbydere (CASP-er) under tilsyn av Finanstilsynet, ikke selvforvaring; en ren selvforvart smartkonto faller utenfor, mens skytjenester for gjenoppretting eller gass kan havne i en gråsone.

Skrevet av Jonas Ellingsen, seniorredaktør for lommebøker og børser i HOGE Wire.