{"id":329,"date":"2026-08-31T13:04:05","date_gmt":"2026-08-31T13:04:05","guid":{"rendered":"https:\/\/hoge.gg\/no\/native-account-abstraction-base-cobalt-eip-8130-2026\/"},"modified":"2026-08-31T13:04:05","modified_gmt":"2026-08-31T13:04:05","slug":"native-account-abstraction-base-cobalt-eip-8130-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/native-account-abstraction-base-cobalt-eip-8130-2026\/","title":{"rendered":"Native account abstraction lander: Base, Cobalt og EIP-8130 i 2026"},"content":{"rendered":"

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

Timingen er talende. ETH omsettes rundt 2 450 dollar, i underkant av 23 000 kroner, etter en oppgang p\u00e5 omtrent 31 prosent siden begynnelsen av august (MetaMask<\/a>), og oppmerksomheten rundt lommeb\u00f8ker har sjelden v\u00e6rt h\u00f8yere. Da vi skrev om kappl\u00f8pet om native account abstraction<\/a> tidligere i sommer, sto tre leire mot hverandre. N\u00e5 er kampen i ferd med \u00e5 avgj\u00f8res, ikke i et hvitt dokument, men p\u00e5 et hovednett: en L2 sender protokollnativ account abstraction m\u00e5neder f\u00f8r Ethereum selv har l\u00e5st sin versjon inn i en oppgradering. Og grunnleggeren av WalletConnect har nettopp skiftet leir.<\/p>

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\u00f8rser og for norske brukere som holder n\u00f8klene selv.<\/p>

Hva native account abstraction egentlig betyr<\/h2>

Ethereum har fra f\u00f8rste stund hatt to kontotyper: eksternt eide kontoer (EOA-er), som styres av en privatn\u00f8kkel 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 \u00e5 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 \u00e9n.<\/p>

Frem til n\u00e5 har dette skjedd som et tillegg. ERC-4337 bygger et eget \u00f8kosystem av UserOperations, bundlere og en singleton EntryPoint-kontrakt opp\u00e5 kjeden, uten \u00e5 endre selve protokollen. EIP-7702 lar en EOA peke p\u00e5 kode i en kontrakt gjennom en delegeringsmark\u00f8r, slik at den vanlige kontoen din midlertidig oppf\u00f8rer 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<\/a>), og over 53 millioner Ethereum-kontoer har f\u00e5tt en aktiv delegering via EIP-7702 (BundleBear<\/a>).<\/p>

Native account abstraction snur dette p\u00e5 hodet. I stedet for \u00e5 legge logikk opp\u00e5 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<\/a>, 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\u00f8rleggingen forsvinner.<\/p>

Veien hit: fra ERC-4337 via EIP-7702 til native<\/h2>

Det er verdt \u00e5 forst\u00e5 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\u00f8tte for EIP-7702, slik at de to standardene spiller p\u00e5 lag i stedet for \u00e5 konkurrere.<\/p>

EIP-7702 kom med Pectra 7. mai 2025 og innf\u00f8rte en ny transaksjonstype, 0x04, som skriver en delegeringsmark\u00f8r (0xef0100 etterfulgt av en kontraktsadresse) inn i en vanlig konto. Delegeringen er reverserbar og knyttet til \u00e9n kjede. Adopsjonen har v\u00e6rt rask, men ogs\u00e5 en p\u00e5minnelse om baksiden: Wintermute fant at over 97 prosent av de tidlige delegeringene var gjenbrukt sveiper-kode kalt CrimeEnjoyor, kode som fors\u00f8kte \u00e5 t\u00f8mme kontoer, men som stort sett var ul\u00f8nnsom fordi den traff allerede kompromitterte, tomme lommeb\u00f8ker (CoinDesk<\/a>).<\/p>

B\u00e5de 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\u00e5 faktisk sender p\u00e5 et hovednett. Poenget med \u00e5 g\u00e5 native er ikke bare eleganse; det er \u00e5 kutte avhengigheten av mellomledd. Buterin har gjentatte ganger pekt p\u00e5 at smartkontoer i dag lener seg p\u00e5 bundlere og relayere som utgj\u00f8r en kilde til skj\u00f8rhet, og har foresl\u00e5tt mekanismer som FOCIL (EIP-7805) for \u00e5 garantere at transaksjoner kommer med i blokker uten \u00e5 m\u00e5tte g\u00e5 gjennom slike akt\u00f8rer (news.bitcoin.com<\/a>). N\u00e5r valideringen ligger i protokollen, trengs ingen ekstern bundler i det hele tatt.<\/p>

EIP-8130: kontoen som et oppsett<\/h2>

EIP-8130 b\u00e6rer tittelen \u00abAccount Abstraction by Account Configuration\u00bb, 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\u00e5 distribuere. I stedet for at hver bruker deployerer sin egen smartkontraktlommebok, lagrer en Keystore-kontrakt p\u00e5 en fast adresse kontoens preferanser p\u00e5 kjeden, en slags universell innstillingspanel for kontoen din (Crypto Briefing<\/a>).<\/p>

Teknisk innf\u00f8rer EIP-8130 \u00e9n ny transaksjonstype, AA_TX_TYPE 0x79, som valideres av protokollen selv. Det avgj\u00f8rende designvalget er at kontoen ikke kan bruke vilk\u00e5rlig 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\u00e5 tvers av kontoer. Denne innstrammingen er hele ideen: ved \u00e5 begrense mulighetene blir valideringen forutsigbar, billig og lett \u00e5 implementere likt overalt.<\/p>

Standarden opererer i to niv\u00e5er. Niv\u00e5 1 er ment for Ethereum-hovednettet og lignende kjeder, med en normativ gass-plan og mer tillatende aksept for fleksibilitet. Niv\u00e5 2 er ment for kjeder med h\u00f8y 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.<\/p>

Element<\/th>Beskrivelse<\/th><\/tr><\/thead>
Bak forslaget<\/td>Chris Hunter (Coinbase \/ Base), utkast oktober 2025<\/td><\/tr>
Transaksjonstype<\/td>AA_TX_TYPE 0x79, validert av protokollen selv<\/td><\/tr>
Kontooppsett<\/td>Keystore-kontrakt p\u00e5 fast adresse lagrer kontoens preferanser p\u00e5 kjeden<\/td><\/tr>
Signeringsmetoder<\/td>secp256k1, P-256, WebAuthn (passkeys), delegat<\/td><\/tr>
To niv\u00e5er<\/td>Niv\u00e5 1 (Ethereum-hovednettet, fleksibelt) og Niv\u00e5 2 (Base og andre L2-er, forutsigbart)<\/td><\/tr>
Innebygde funksjoner<\/td>Gass-sponsing, batch-kall, session keys, portabilitet p\u00e5 tvers av kjeder<\/td><\/tr>
Lander f\u00f8rst<\/td>Base, i Cobalt-oppgraderingen september 2026<\/td><\/tr><\/tbody><\/table>
EIP-8130 i korte trekk. Kilder: Crypto Briefing, Base-dokumentasjonen.<\/figcaption><\/figure>

Cobalt: dette sender Base i september<\/h2>

Cobalt er neste milep\u00e6l i Base sitt veikart, og f\u00f8lger 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\u00e5 Base Vibenet, et midlertidig utviklernett (kjede-ID 84538453), f\u00f8r den aktiveres p\u00e5 hovednettet i Cobalt i september 2026. En eksakt dato var ikke kunngjort da denne artikkelen ble skrevet.<\/p>

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 \u00e9n transaksjon) og session keys (native akt\u00f8rer med avgrenset fullmakt, slik at en app kan signere innenfor en definert ramme uten \u00e5 be om bekreftelse hele tiden). I tillegg kommer portabilitet p\u00e5 tvers av kjeder, parallelle nonces, underkontoer og n\u00f8kkelrotasjon som gir en vei ut hvis kvantedatamaskiner en dag truer dagens signaturer (Bitget News<\/a>).<\/p>

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

Operasjon<\/th>Native AA (EIP-8130)<\/th>ERC-4337<\/th>Endring<\/th><\/tr><\/thead>
USDC-overf\u00f8ring, gass<\/td>46 000<\/td>125 000<\/td>-63,2 %<\/td><\/tr>
USDC-overf\u00f8ring, datamengde<\/td>180 byte<\/td>1 090 byte<\/td>-83,4 %<\/td><\/tr>
Med passkey og sponsing, gass<\/td>68 700<\/td>173 000<\/td>-60,3 %<\/td><\/tr>
Med passkey og sponsing, datamengde<\/td>890 byte<\/td>1 940 byte<\/td>-56,1 %<\/td><\/tr><\/tbody><\/table>
Gass og datamengde: native account abstraction mot ERC-4337 p\u00e5 Base. Kilde: Base Engineering.<\/figcaption><\/figure>

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\u00e5 inn andre endringer under panseret, blant annet en samlet node-programvare som sl\u00e5r sammen konsensus- og eksekveringsklienten, men det er den native account abstraction-delen som endrer hverdagen for lommeboker og brukere.<\/p>

EIP-8130 mot EIP-8141: to veier til samme m\u00e5l<\/h2>

EIP-8130 er ikke det eneste forslaget om native account abstraction, og det er ikke engang det mest kjente. Den andre veien g\u00e5r gjennom EIP-8141, foresl\u00e5tt av Vitalik Buterin og flere 28. februar 2026. Der 8130 l\u00e5ser kontoen til et fast oppsett, g\u00e5r 8141 motsatt vei og tillater vilk\u00e5rlig validering. Mekanismen kalles frame transactions, en ny transaksjonstype 0x06 som deler en transaksjon i en VERIFY-ramme (signatursjekk og betaling av gebyr) og \u00e9n eller flere EXECUTE-rammer. Noder m\u00e5 simulere valideringen innenfor et gassbudsjett f\u00f8r transaksjonen slipper inn i mempoolen (Everstake<\/a>).<\/p>

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

Prisen er kompleksitet. EIP-8141 fikk \u00abConsidered for Inclusion\u00bb-status p\u00e5 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 \u00e5 bli oppgraderingens hovedoppslag (CCN<\/a>). Kontrasten til 8130 er sl\u00e5ende: der 8141 fortsatt er en kandidat for et fremtidig L1-vindu, sendes 8130 p\u00e5 et L2-hovednett i september. Tabellen under stiller de to opp mot hverandre.<\/p>

 <\/th>EIP-8130<\/th>EIP-8141<\/th><\/tr><\/thead>
Bak forslaget<\/td>Coinbase \/ Base (Chris Hunter)<\/td>Vitalik Buterin m.fl.<\/td><\/tr>
Transaksjonstype<\/td>0x79<\/td>0x06 (frame transactions)<\/td><\/tr>
Valideringsmodell<\/td>Fast oppsett, begrenset sett metoder<\/td>Vilk\u00e5rlig validering (VERIFY- og EXECUTE-rammer)<\/td><\/tr>
N\u00f8kkeltyper<\/td>secp256k1, P-256, WebAuthn, delegat<\/td>\u00c5pent, inkludert kvantesikre signaturer<\/td><\/tr>
Gass i token<\/td>Ja, innebygd<\/td>Ja, innebygd<\/td><\/tr>
Status<\/td>Sendes p\u00e5 Base i 2026<\/td>Kandidat for Hegota, sent 2026<\/td><\/tr>
Lander<\/td>L2 f\u00f8rst (ogs\u00e5 L1 via Niv\u00e5 1)<\/td>Ethereum L1<\/td><\/tr><\/tbody><\/table>
To veier til native account abstraction. Kilder: Crypto Briefing, Everstake, CCN.<\/figcaption><\/figure>

Momentumskiftet: da WalletConnect skiftet leir<\/h2>

Det tydeligste tegnet p\u00e5 hvilken vei vinden bl\u00e5ser, kom fra en som hadde brukt m\u00e5neder p\u00e5 den andre siden. Pedro Gomes, grunnlegger av WalletConnect, skrev at han etter lang tid med EIP-8141 n\u00e5 er \u00abconvinced EIP-8130 is the better path for native account abstraction\u00bb, og at standarden er \u00absimpler, more portable, and focused on what wallets actually need\u00bb (@pedrouid<\/a>). At WalletConnect, som kobler tusenvis av apper og lommeboker sammen, offentlig lener seg mot den konfigurasjonsbaserte tiln\u00e6rmingen, er ikke et teknisk detaljsp\u00f8rsm\u00e5l. Det er infrastrukturen brukere faktisk m\u00f8ter n\u00e5r de logger inn i en desentralisert app.<\/p>

Det er samtidig verdt \u00e5 holde hodet kaldt. De to forslagene er ikke n\u00f8dvendigvis et enten-eller. \u00c9n lesning er at 8130 er det pragmatiske L2-steget som kan tas n\u00e5, mens 8141 er L1-endgame som tar lengre tid fordi det gj\u00f8r mer. En annen er at et fragmentert felt med to konkurrerende transaksjonstyper kan gi lommebokutviklere doble integrasjonsjobber i \u00e5revis. Det som er sikkert, er at 8130 har f\u00e5tt fart, en dato og en kjede \u00e5 lande p\u00e5, mens 8141 fortsatt diskuteres i klientteamene.<\/p>

Hvem betaler gassen n\u00e5?<\/h2>

Gassfrihet har v\u00e6rt selve salgsargumentet for account abstraction, men noen m\u00e5 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\u00e5 Base og Arbitrum, mot et p\u00e5slag p\u00e5 rundt 10 prosent for \u00e5 dekke prissvingninger og veksling (Circle<\/a>). Det fungerer, men det legger til et mellomledd, og hvert mellomledd er b\u00e5de en kostnad og en avhengighet. Vi har g\u00e5tt dypere inn i denne \u00f8konomien i artikkelen om hvem som betaler gassen under EIP-7702 og paymasters<\/a>.<\/p>

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\u00e5klistret 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\u00e6rre mellomledd betyr lavere kostnad og f\u00e6rre steder ting kan g\u00e5 galt, og det er nettopp derfor tallene fra Base viser en s\u00e5 kraftig reduksjon i gass og datamengde.<\/p>

For en norsk bruker er det verdt \u00e5 merke seg en hake: \u00e5 betale gass i en stablecoin er ikke gratis i skattemessig forstand, men det kommer vi tilbake til.<\/p>

Passkeys, P-256 og slutten p\u00e5 seed-frasen<\/h2>

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

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\u00e5r den. For en hel generasjon brukere som aldri har l\u00e6rt \u00e5 skrive ned tolv ord p\u00e5 et papir, er dette forskjellen mellom \u00e5 pr\u00f8ve krypto og \u00e5 gi opp.<\/p>

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 \u00f8kosystemer er fortsatt umoden, selv om standarder for \u00e5 flytte passkeys mellom leverand\u00f8rer er under arbeid. Delegat-metoden i 8130 gir en vei til gjenoppretting og backup-n\u00f8kler, men den som setter opp en passkey-kontoen b\u00f8r forst\u00e5 hvor den egentlig ligger, og hva som skjer hvis telefonen mistes.<\/p>

N\u00f8kler, gjenoppretting og det som kan g\u00e5 galt<\/h2>

Keystore-kontrakten er b\u00e5de den store nyvinningen og et nytt ansvarsomr\u00e5de. Fordi kontoens oppsett ligger p\u00e5 kjeden, kan du rotere n\u00f8kler, legge til en delegat for gjenoppretting, opprette underkontoer med avgrensede fullmakter og bytte signeringsmetode uten \u00e5 flytte midlene dine. Spesifikasjonen sl\u00e5r fast at bare kontoen selv kan endre sitt eget oppsett, noe som lukker den mest \u00e5penbare angrepsd\u00f8ren. Men et oppsett p\u00e5 kjeden er ogs\u00e5 offentlig og programmerbart, og programmerbarhet er alltid en ny flate \u00e5 angripe.<\/p>

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\u00f8kkelgenerering er fortsatt reelt. Vi har sammenlignet de to tiln\u00e6rmingene i gjennomgangen MPC eller multisig: hvordan proffene deler n\u00f8kkelen<\/a>. Poenget er at native account abstraction gir bedre byggeklosser, ikke automatisk bedre rutiner. En smartkonto med d\u00e5rlig n\u00f8kkelh\u00e5ndtering er fortsatt en d\u00e5rlig sikret konto.<\/p>

Den nye angrepsflaten<\/h2>

N\u00e5r 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\u00e5 ikke i Safe-kontrakten, men i at angriperne (tilskrevet Lazarus-gruppen) kompromitterte en utviklermaskin, injiserte skadelig kode i signeringsgrensesnittet, og fikk signererne til \u00e5 godkjenne en transaksjon som byttet ut kontoens implementasjon via delegatecall. Signererne s\u00e5 en normal overf\u00f8ring; det de faktisk signerte, var noe annet (NCC Group<\/a>). Maskinvarelommeboker hjalp ikke, fordi de bare viste en hash, ikke handlingen.<\/p>

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

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

Hva det betyr for b\u00f8rser og lommeb\u00f8ker<\/h2>

For lommeb\u00f8kene er dette b\u00e5de 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 \u00e5 tilby gassfrihet, batching og passkey-innlogging uten \u00e5 drive egen bundler-infrastruktur. De som ikke f\u00f8lger med, risikerer \u00e5 tilby en kl\u00f8nete opplevelse mot konkurrenter der onboarding f\u00f8les som en vanlig app.<\/p>

For b\u00f8rsene handler det om h\u00e5ndtering. Innskudd fra og uttak til smartkontoer m\u00e5 gjenkjennes og behandles riktig, og en konto som styres av en passkey eller en delegat oppf\u00f8rer seg ikke som en klassisk EOA. Coinbase sin strategi er verdt \u00e5 legge merke til her, for selskapet bygger hele stabelen: en egen L2 i Base, en egen kontostandard i EIP-8130, innebygde lommeboker og oppkj\u00f8p som styrker distribusjonen. Vi s\u00e5 et eksempel p\u00e5 den appetitten da Coinbase kj\u00f8pte Vector<\/a>. N\u00e5r den som eier b\u00f8rsen ogs\u00e5 skriver kontostandarden og driver kjeden den lander p\u00e5, flyttes mye makt til ett sted i stabelen.<\/p>

Norge: Finanstilsynet, Skatteetaten og selvforvaring<\/h2>

MiCA gjelder i Norge gjennom kryptoeiendelsloven, som tr\u00e5dte i kraft 1. juli 2025 via E\u00d8S-avtalen. Finanstilsynet gir tillatelser til tjenestetilbydere (CASP-er), enten full autorisasjon etter artikkel 63 eller melding etter artikkel 60, og krever fysisk tilstedev\u00e6relse i E\u00d8S (Finanstilsynet<\/a>). De f\u00f8rste norske akt\u00f8rene med MiCA-tillatelse er p\u00e5 plass, blant dem AK Jensen Norway AS og T\u00fdr Markets AS, i tillegg til etablerte Firi.<\/p>

Det viktige for denne artikkelen er hva som faller utenfor. En ren selvforvart smartkonto, der du selv holder n\u00f8kkelen eller passkeyen, er ikke en tjeneste og reguleres ikke som en CASP. Men native account abstraction gj\u00f8r grensene gr\u00e5ere. 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\u00e6rme seg noe Finanstilsynet ser p\u00e5 som en tjeneste. Skillet mellom verkt\u00f8y og tjeneste blir et vurderingssp\u00f8rsm\u00e5l, ikke en teknisk selvf\u00f8lge.<\/p>

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<\/a>). Her ligger en praktisk felle i gassfriheten. \u00c5 betale gass i en stablecoin regnes som en realisasjon av den stablecoinen, alts\u00e5 en skattepliktig hendelse, selv om bel\u00f8pet er lite. Med native account abstraction som gj\u00f8r slike mikrobetalinger vanlige, kan du ende opp med hundrevis av sm\u00e5 disposisjoner som i prinsippet skal f\u00f8res. Fra 1. januar 2026 gjelder ogs\u00e5 CARF-rapportering, som p\u00e5legger kryptotilbydere systematisk \u00e5 rapportere opplysninger, s\u00e5 gapet mellom hva som skjer p\u00e5 kjeden og hva Skatteetaten kan se, krymper.<\/p>

Veien videre etter Cobalt<\/h2>

Det umiddelbare \u00e5 f\u00f8lge med p\u00e5 er selve Cobalt-aktiveringen p\u00e5 Base i september, og deretter hvor raskt OP Stack-kjedene tar i bruk EIP-8130. Blir standarden delt p\u00e5 tvers av mange L2-er, er portabiliteten reell; blir den v\u00e6rende Base-spesifikk, er den mest en Coinbase-fordel. P\u00e5 L1-siden er sp\u00f8rsm\u00e5let om EIP-8141 faktisk kommer med i Hegota, og om FOCIL leverer p\u00e5 l\u00f8ftet om at smartkontoer ikke lenger skal v\u00e6re prisgitt bundlere og relayere for \u00e5 komme med i en blokk.<\/p>

Det store \u00e5pne sp\u00f8rsm\u00e5let er om de to standardene konvergerer eller splitter feltet. Buterin har argumentert for at intermediary minimization er et kjerneprinsipp, at m\u00e5let er \u00e5 kunne gj\u00f8re 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 \u00e5 lande raskt. Begge kan ha rett samtidig: L2-ene f\u00e5r en enkel, portabel standard n\u00e5, mens L1 tar seg tid til den mer fleksible endgame-versjonen. For norske brukere er den praktiske testen enkel. Blir det \u00e5 bruke krypto til slutt like lett som \u00e5 \u00e5pne en bankapp, uten seed-fraser, uten gasskj\u00f8p i forkant og uten frykt for \u00e5 signere feil? Cobalt er det f\u00f8rste hovednettet der vi f\u00e5r se om svaret er ja.<\/p>

Frequently Asked Questions<\/h2>

Hva er native account abstraction, og hvordan skiller det seg fra ERC-4337 og EIP-7702?<\/h3>

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\u00e5 kjeden som en parallell infrastruktur, og EIP-7702 lar en vanlig konto midlertidig l\u00e5ne kode fra en kontrakt. Native AA, slik EIP-8130 definerer det, bygger evnene inn i kjeden selv, slik at hver konto oppf\u00f8rer seg som en smartkonto som standard.<\/p>

N\u00e5r lanserer Base native account abstraction?<\/h3>

Base sender native account abstraction gjennom EIP-8130 i Cobalt-oppgraderingen i september 2026. Standarden testes allerede p\u00e5 utviklernettet Vibenet, og OP Stack-kjeder ventes \u00e5 f\u00f8lge senere samme \u00e5r. En eksakt dato for hovednettet var ikke kunngjort da denne artikkelen ble skrevet.<\/p>

Hva er forskjellen p\u00e5 EIP-8130 og EIP-8141?<\/h3>

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\u00e5 Base allerede i 2026. EIP-8141 fra Vitalik Buterin og flere bruker frame transactions og tillater vilk\u00e5rlig validering, inkludert fremtidige kvantesikre signaturer, men er forel\u00f8pig en kandidat for Ethereums Hegota-oppgradering sent i 2026. Kort sagt: 8130 er enklere og lander f\u00f8rst p\u00e5 en L2, 8141 er mer fleksibel og sikter mot selve L1.<\/p>

Blir smartkontoer p\u00e5 Base billigere med native account abstraction?<\/h3>

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

Hvordan beskattes en smartkonto i Norge, og gjelder MiCA for selvforvaring?<\/h3>

Skatteetaten behandler gevinst og tap likt enten du bruker en vanlig konto eller en smartkonto, med 22 prosent skatt p\u00e5 realisert gevinst, og \u00e5 betale gass i en stablecoin regnes som en realisasjon. MiCA, innf\u00f8rt 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\u00e5sone.<\/p>