{"id":337,"date":"2026-09-02T13:10:26","date_gmt":"2026-09-02T13:10:26","guid":{"rendered":"https:\/\/hoge.gg\/no\/smartkontoen-ble-moduler-erc-7579-erc-6900-2026\/"},"modified":"2026-09-02T13:10:26","modified_gmt":"2026-09-02T13:10:26","slug":"smartkontoen-ble-moduler-erc-7579-erc-6900-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/smartkontoen-ble-moduler-erc-7579-erc-6900-2026\/","title":{"rendered":"Smartkontoen ble moduler: ERC-7579 mot ERC-6900 i 2026"},"content":{"rendered":"

For fem \u00e5r siden var en smartkonto p\u00e5 Ethereum i praksis ett enkelt program. \u00c9n smartkontrakt gjorde alt: sjekket signaturen din, h\u00e5ndhevet reglene og utf\u00f8rte transaksjonen. Skulle du endre noe, m\u00e5tte hele kontrakten byttes ut eller oppgraderes gjennom kompliserte proxy-triks. I 2026 ser bildet helt annerledes ut. Lommeboken din er i ferd med \u00e5 bli en samling moduler du kan installere, skru av og bytte ut, omtrent som apper p\u00e5 en telefon.<\/p>

Skiftet har et navn og et nummer: ERC-7579, den minimale standarden for modul\u00e6re smarte kontoer. Den har en rival i ERC-6900, en tyngre standard fra Alchemy, og rundt dem har det vokst opp en hel infrastruktur av registre, attesteringer og utviklerverkt\u00f8y. Resultatet er en stille standardkrig om hvordan lommeboken din skal bygges, og en ny app-\u00f8konomi for funksjoner de fleste brukere aldri kommer til \u00e5 se navnet p\u00e5.<\/p>

Denne gjennomgangen forklarer hva modul\u00e6re smarte kontoer er, hvordan ERC-7579 og ERC-6900 skiller seg fra hverandre, hvem som faktisk bygger dem (Safe, ZeroDev, Biconomy, Rhinestone og flere), hvordan portabilitet og innl\u00e5sing henger sammen med ERC-7779, og hva installerbar kode betyr for sikkerheten din. Til slutt tar vi med hva Finanstilsynet og Skatteetaten sier for norske brukere.<\/p>

Fra ett program til mange moduler<\/h2>

En tradisjonell kontrakt-lommebok, som de tidlige versjonene av Argent eller Safe, bakte reglene sine inn i \u00e9n kontrakt. Ville du legge til sosial gjenoppretting eller en bruksgrense, m\u00e5tte funksjonen kodes inn, revideres og rulles ut p\u00e5 nytt. Det fungerte, men det gjorde hver lommebok til en \u00f8y: kode kunne ikke enkelt deles, og en bruker kunne ikke plukke og velge funksjoner uten \u00e5 bytte hele produktet.<\/p>

Modul\u00e6re konti snur dette p\u00e5 hodet. Kontoen deles i to lag: en slank kjerne som bare vet hvordan den installerer, fjerner og kaller moduler, og et sett moduler som holder den faktiske logikken. Sammenligningen som g\u00e5r igjen er et operativsystem: kjernen er som en OS-kjerne, mens modulene er drivere og apper du legger til etter behov. ERC-7579-spesifikasjonen<\/a> formaliserer nettopp dette grensesnittet, slik at en modul skrevet for \u00e9n konto kan kj\u00f8re p\u00e5 en annen.<\/p>

Hvorfor n\u00e5? Fordi account abstraction ikke lenger er et nisjeeksperiment. Gjennom ERC-4337 er det registrert over 1,26 milliarder UserOperations og dr\u00f8yt 65 millioner konti med aktivitet, if\u00f8lge BundleBear<\/a>. EIP-7702, som kom med Pectra-oppgraderingen i mai 2025, har i tillegg gjort vanlige adressekonti om til smarte kontoer, med over 53 millioner aktive delegeringer og n\u00e6r 100 millioner set-code-transaksjoner (BundleBear<\/a>). Med den skalaen blir det upraktisk \u00e5 bygge hver lommebok fra bunnen. Moduler lar utviklere gjenbruke og dele funksjoner, og lar brukere sette sammen sin egen konto. Ether, som betaler gassen for det hele, omsettes for rundt 2 420 dollar, snaut 22 500 kroner (CoinDesk<\/a>).<\/p>

Kort oppfriskning: EOA, smartkonto og de to veiene inn<\/h2>

En vanlig Ethereum-adresse (en EOA, \u00abexternally owned account\u00bb) styres av \u00e9n privat n\u00f8kkel. Har du n\u00f8kkelen, har du full kontroll; mister du den, er alt tapt. En smartkonto er derimot en kontrakt: reglene for hvem som f\u00e5r lov til \u00e5 gj\u00f8re hva, kan programmeres. Det er dette som gj\u00f8r batching (flere handlinger i \u00e9n transaksjon), gassabstraksjon, sosial gjenoppretting og session keys mulig i det hele tatt.<\/p>

Det finnes to veier inn. Den f\u00f8rste er ERC-4337<\/a>, som ble ferdigstilt i mars 2023 og legger et eget lag opp\u00e5 Ethereum med bundlere, en felles EntryPoint-kontrakt og paymastere, uten \u00e5 endre selve protokollen; EntryPoint v0.8 fra 2025 la til st\u00f8tte for EIP-7702. Den andre er EIP-7702, som lar en eksisterende EOA peke til en kontrakt via en delegeringspeker (0xef0100 etterfulgt av en 20-byte adresse) og dermed l\u00e5ne smartkontoens egenskaper uten \u00e5 flytte midler til en ny adresse. Modulene vi skal se p\u00e5, sitter opp\u00e5 begge veiene. Poenget med hele oppfriskningen er at modularene ikke er en tredje konkurrent til ERC-4337 og EIP-7702, men et lag som gj\u00f8r begge mer nyttige.<\/p>

For en vanlig bruker er det de praktiske f\u00f8lgene som teller. En smartkonto kan samle en godkjenning og et bytte i \u00e9n signatur i stedet for to, la deg gjenopprette tilgang med hjelp fra betrodde kontakter i stedet for en tapt frase, og sette et tak p\u00e5 hvor mye som kan forsvinne p\u00e5 en d\u00e5rlig dag. Modulene er byggeklossene som gj\u00f8r hver av disse egenskapene til noe du kan sl\u00e5 p\u00e5 uten \u00e5 bytte lommebok.<\/p>

ERC-7579: den minimale modulstandarden<\/h2>

ERC-7579<\/a>, \u00abMinimal Modular Smart Accounts\u00bb, n\u00e5dde ferdig status p\u00e5 EIP-sporet i 2024. Forfatterne kommer fra tvers av bransjen: Konrad Kopp (Rhinestone), Taek Lee (ZeroDev), utvikleren kjent som zeroknots, Filipp Makarov (Biconomy) og Elim Poon. At konkurrenter skrev standarden sammen, er hele poenget. M\u00e5let er det minste felles grensesnittet, slik at en modul skrevet \u00e9n gang virker p\u00e5 tvers av mange kontoimplementasjoner.<\/p>

Standarden definerer noen f\u00e5 funksjoner en konto m\u00e5 ha: installModule, uninstallModule, isModuleInstalled og isModuleType. Den sier bevisst lite om hvordan lagringen skal se ut eller hvordan tillatelser skal h\u00e5ndteres; det overlates til modulene og til implementasjonen. \u00abMinimal\u00bb er ikke en unnskyldning, det er designfilosofien. Jo mindre standarden dikterer, jo lettere er det for Safe, Kernel og Nexus \u00e5 v\u00e6re enige om det samme grensesnittet, og jo lavere er terskelen for en uavhengig utvikler til \u00e5 skrive en modul som virker overalt.<\/p>

Bakgrunnen er verdt \u00e5 ta med. ERC-4337 ga oss selve kontomodellen, men hver 4337-lommebok var fortsatt et monolittisk stykke kode. \u00d8nsket om \u00e5 gjenbruke validatorer og utf\u00f8rere p\u00e5 tvers av lommeb\u00f8ker er det som drev fram modultanken. ERC-7579 er svaret som fikk bredest oppslutning, blant annet fordi den ikke tvinger et helt rammeverk p\u00e5 deg, men bare blir enig om hvordan en modul kobles inn og ut.<\/p>

De fire modultypene, forklart<\/h2>

ERC-7579 deler moduler i fire typer etter n\u00e5r og hvordan de griper inn i en transaksjon. Det er denne firedelingen som gj\u00f8r at en utvikler kan skrive en enkelt, avgrenset bit funksjonalitet uten \u00e5 m\u00e5tte forst\u00e5 resten av kontoen.<\/p>

Modultype<\/th>Rolle<\/th>Eksempler<\/th><\/tr><\/thead>
Validator (type 1)<\/td>Avgj\u00f8r om en transaksjon er gyldig: signatur, nonce og autorisasjon<\/td>ECDSA, multisig, passkey (P-256), session keys<\/td><\/tr>
Executor (type 2)<\/td>Utf\u00f8rer handlinger p\u00e5 vegne av kontoen etter at valideringen er godkjent<\/td>Planlagte betalinger, auto-sparing, n\u00f8dflytt av midler<\/td><\/tr>
Fallback-handler (type 3)<\/td>Svarer p\u00e5 kall kontoen ellers ikke forst\u00e5r<\/td>ERC-1271-signaturer, mottak av ERC-721 og ERC-1155<\/td><\/tr>
Hook (type 4)<\/td>Kj\u00f8rer f\u00f8r og\/eller etter en handling og kan blokkere den<\/td>Bruksgrenser, hvitelister, ratebegrensning<\/td><\/tr><\/tbody><\/table><\/figure>

Valideringsmodulene er de mest interessante for b\u00e5de sikkerhet og brukervennlighet, for det er her alternative signeringsmetoder bor. En passkey-validator bruker P-256-kurven som ligger i Apples Secure Enclave og Androids n\u00f8kkellager; takket v\u00e6re RIP-7212<\/a>, en precompile som kutter kostnaden for P-256-verifisering fra rundt 300 000 til cirka 3 450 gass, er dette blitt praktisk p\u00e5 flere L2-er. En annen validator kan implementere en multisig der flere n\u00f8kler m\u00e5 signere, en modell vi har sett n\u00e6rmere p\u00e5 i gjennomgangen av MPC eller multisig<\/a>. Poenget er at samme konto kan ha flere validatorer installert samtidig, for eksempel en passkey til hverdags og en multisig til de store bel\u00f8pene.<\/p>

Hook-modulene er den andre siden av mynten. En hook kj\u00f8rer rundt hver handling og kan si nei. Vil du at kontoen aldri skal sende mer enn et gitt bel\u00f8p per dag, eller bare til adresser p\u00e5 en hviteliste, er det en hook som h\u00e5ndhever regelen. Executor-moduler, derimot, handler proaktivt: de kan sette opp en fast overf\u00f8ring den f\u00f8rste i m\u00e5neden eller flytte alt til en n\u00f8dadresse hvis noe utl\u00f8ses. Fire typer, \u00e9n konto, og du bestemmer hvilke som er installert.<\/p>

Slik henger det sammen i \u00e9n transaksjon: en valideringsmodul sjekker f\u00f8rst at signaturen er ekte og at du har lov til \u00e5 handle, en hook kan s\u00e5 gripe inn og avvise hvis bel\u00f8pet bryter en grense, kontoen utf\u00f8rer handlingen, og en ny hook kan kj\u00f8re etterp\u00e5 for \u00e5 logge eller sperre. Fordi hvert steg er en egen modul, kan du bytte ut signeringen uten \u00e5 r\u00f8re bruksgrensene, eller stramme inn grensene uten \u00e5 r\u00f8re signeringen.<\/p>

ERC-6900: den andre leiren<\/h2>

ERC-7579 er ikke den eneste m\u00e5ten \u00e5 gj\u00f8re en konto modul\u00e6r p\u00e5. ERC-6900<\/a>, som Alchemy foreslo i 2023, sikter mot det samme m\u00e5let, men med en langt mer omfattende spesifikasjon. Der 7579 er minimal, er 6900 preskriptiv: den p\u00e5byr navngitt lagring etter ERC-7201<\/a>, definerer en rikere plugin-modell med tillatelsesgrafer og avhengigheter mellom plugins, og bygger flere garantier inn i selve standarden. Den driver Alchemys Account Kit og Modular Account.<\/p>

De to er ikke kompatible. En modul skrevet for ERC-7579 kj\u00f8rer ikke p\u00e5 en ERC-6900-konto, og omvendt. Det er dette som er standardkrigen: to leirer med ulik filosofi om hvor mye en standard b\u00f8r diktere. Alchemys argument er at n\u00e5r standarden selv h\u00e5ndhever lagring og tillatelser, blir det vanskeligere \u00e5 skyte seg selv i foten. Motargumentet er at mer regler betyr mer kompleksitet, tregere iterasjon og en h\u00f8yere inngangsterskel. I praksis har ERC-7579 f\u00e5tt bredest oppslutning (Safe, ZeroDev, Biconomy, Rhinestone og OpenZeppelin bygger alle rundt den), mens ERC-6900 tilbyr sterkere innebygde garantier til gjengjeld for mer tyngde.<\/p>

Dimensjon<\/th>ERC-7579<\/th>ERC-6900<\/th><\/tr><\/thead>
Filosofi<\/td>Minimal; overlater mest mulig til moduler<\/td>Omfattende; bygger garantier inn i standarden<\/td><\/tr>
Lagring<\/td>Uforeskrevet (opp til modul og implementasjon)<\/td>Navngitt lagring etter ERC-7201 p\u00e5budt<\/td><\/tr>
Tillatelser<\/td>H\u00e5ndteres av hooks og moduler<\/td>Innebygd tillatelsesgraf mellom plugins<\/td><\/tr>
Hovedakt\u00f8rer<\/td>Safe, ZeroDev, Biconomy, Rhinestone, OpenZeppelin<\/td>Alchemy (Account Kit, Modular Account)<\/td><\/tr>
Avveining<\/td>Fleksibel og lett \u00e5 integrere<\/td>Tryggere som standard, men tyngre<\/td><\/tr><\/tbody><\/table><\/figure>

Rhinestone og modulregisteret<\/h2>

En standard alene lager ikke et \u00f8kosystem. Det er her Rhinestone<\/a> kommer inn, et infrastrukturselskap som har gjort ERC-7579 til noe utviklere faktisk kan bygge p\u00e5. Rhinestone st\u00e5r bak tre ting som henger sammen: et modulregister, standarden ERC-7484 og utviklerverkt\u00f8yet ModuleKit.<\/p>

Modulregisteret l\u00f8ser oppdagelsesproblemet. Skal du installere en modul, hvordan vet du at den er trygg? Registeret lister moduler i to lag: et \u00e5pent fellesskapslag og et revidert lag der modulen har v\u00e6rt gjennom en definert revisjonsprosess, med attestering p\u00e5 kjeden om at koden p\u00e5 en gitt adresse faktisk ble revidert f\u00f8r den ble listet. Per f\u00f8rste kvartal 2026 snakker vi om flere titalls moduler, med kjente revisorer som Spearbit, ChainSecurity, OpenZeppelin og Trail of Bits involvert. ERC-7484<\/a> standardiserer hvordan en konto sp\u00f8r registeret om slike attesteringer f\u00f8r<\/em> en modul installeres, en mekanisme Rhinestone kaller registerh\u00e5ndhevet sikkerhet.<\/p>

ModuleKit er Foundry-basert og lar en utvikler teste den samme modulen mot Safe, Kernel, Nexus og Alchemys Modular Account i \u00e9n testsuite. Det senker kostnaden ved \u00e5 skrive en modul som virker overalt, og det er nettopp den kostnaden som avgj\u00f8r om app-\u00f8konomien tar av. Attesteringer og revisjoner har med dette blitt en egen \u00f8konomi, med egne insentiver; vi har sett p\u00e5 hvordan slike utbetalinger avgj\u00f8res i bug bounty-maskineriet<\/a>. En modul uten attestering er ikke ulovlig \u00e5 bruke, men den b\u00f8r behandles som ukjent kode fra en fremmed.<\/p>

Verdt \u00e5 forst\u00e5 er hva en attestering faktisk sier. Den er ikke en garanti for at en modul er feilfri, men en signert p\u00e5stand fra en navngitt part om at koden p\u00e5 en bestemt adresse er den som ble gjennomg\u00e5tt, og at den besto en definert prosess. To-lagsmodellen betyr at du selv velger risikoprofil: holder du deg til det reviderte laget, f\u00e5r du f\u00e6rre valg men mer trygghet; \u00e5pner du for fellesskapslaget, f\u00e5r du flere moduler men m\u00e5 stole mer p\u00e5 din egen vurdering.<\/p>

Safe7579: broen mellom Safe og modulene<\/h2>

Ingen enkelt akt\u00f8r har mer p\u00e5 spill i modulverdenen enn Safe. I andre kvartal 2026 behandlet Safe-konti rundt 130 millioner transaksjoner og oppbevarte eiendeler verdt 27,24 milliarder dollar fordelt p\u00e5 over 63 millioner konti, if\u00f8lge The Block<\/a>. Safe var opprinnelig bygget rundt sin egen multisig-modell, ikke rundt ERC-7579, s\u00e5 sp\u00f8rsm\u00e5let ble hvordan man kobler en s\u00e5 stor installert base til det nye modulgrensesnittet.<\/p>

Broen heter Safe7579, en adapter utviklet av Rhinestone og Safe som gj\u00f8r Safe-konti kompatible med ERC-7579. Med den kan eksisterende Safe-brukere installere 7579-moduler, og det f\u00f8lger med 14 reviderte moduler (blant dem en \u00abdead man’s switch\u00bb, flash-l\u00e5n og sosial gjenoppretting), etter en revisjon av Ackee (Safe-dokumentasjonen<\/a>). For DAO-er og bedriftskasser blir moduler ogs\u00e5 et styringsverkt\u00f8y: en hook kan tvinge fram flertallsgodkjenning, en executor kan sette opp planlagte utbetalinger eller en tidsforsinkelse. Baksiden er at slik makt kan misbrukes fra innsiden, og forsvaret mot det er tema i slik stopper du et styringsangrep<\/a>.<\/p>

For organisasjoner er dette mer enn teknikk. En Safe med de rette modulene kan kreve at tre av fem signerer store utbetalinger, forsinke uttak med en innebygd venteperiode s\u00e5 mistenkelige transaksjoner kan stanses i tide, og gi avgrensede roller til ansatte uten \u00e5 gi dem n\u00f8klene til hele kassen. Det er slike moduler som gj\u00f8r en multisig til et faktisk styringssystem, ikke bare en delt n\u00f8kkel.<\/p>

Hvem bygger modul\u00e6re konti<\/h2>

Bak standardene st\u00e5r et knippe implementasjoner som konkurrerer om utviklere og brukere. De fleste har landet p\u00e5 ERC-7579, men de skiller seg p\u00e5 modenhet, utbredelse og filosofi.<\/p>

Akt\u00f8r<\/th>Konto eller produkt<\/th>Standard og merknad<\/th><\/tr><\/thead>
ZeroDev<\/td>Kernel (V3)<\/td>F\u00f8rste native ERC-7579-konto; blant de mest utbredte m\u00e5lt i unike adresser<\/td><\/tr>
Biconomy<\/td>Nexus<\/td>ERC-7579; erstattet den eldre Biconomy Smart Account og driver en modulbutikk<\/td><\/tr>
Safe<\/td>Safe med Safe7579<\/td>ERC-7579 via adapter; st\u00f8rst forvaltet verdi<\/td><\/tr>
OpenZeppelin<\/td>AccountERC7579<\/td>Ferdig ERC-7579-mal i kontraktsbiblioteket<\/td><\/tr>
Trust Wallet<\/td>Smart Accounts<\/td>ERC-7579-basert<\/td><\/tr>
Coinbase<\/td>Base Account<\/td>F\u00f8lger standardretningen, men er ikke en ren ERC-7579-konto; satser p\u00e5 egen native-modell<\/td><\/tr><\/tbody><\/table><\/figure>

Merk den siste raden. Coinbase og Base beveger seg mot native account abstraction via en egen konfigurasjonsbasert modell (mer om det under), snarere enn \u00e5 bygge p\u00e5 ERC-7579-moduler. Det er en p\u00e5minnelse om at \u00abmodul\u00e6r\u00bb og \u00abnative\u00bb er to ulike svar p\u00e5 samme problem, og at de st\u00f8rste akt\u00f8rene ikke n\u00f8dvendigvis velger likt. For en vanlig bruker betyr det at valget av lommebok ogs\u00e5 er et valg av \u00f8kosystem: hvilke moduler du f\u00e5r tilgang til, henger sammen med hvilken standard produktet har satset p\u00e5.<\/p>

App-\u00f8konomien: en butikk for lommebokfunksjoner<\/h2>

N\u00e5r moduler blir standardiserte og reviderte, oppst\u00e5r noe som ligner p\u00e5 en appbutikk for lommeboken. Biconomy driver for eksempel en modulbutikk som g\u00e5r p\u00e5 Rhinestones infrastruktur (Rhinestone<\/a>). I stedet for \u00e5 bytte lommebok for \u00e5 f\u00e5 en ny funksjon, installerer du en modul, omtrent som du laster ned en app i stedet for \u00e5 kj\u00f8pe en ny telefon.<\/p>

Hva slags apper snakker vi om? Session keys som lar deg signere \u00e9n gang og s\u00e5 spille i en time uten \u00e5 godkjenne hvert trekk, en funksjon som har gjort account abstraction popul\u00e6r i blokkjedespill og hos AI-agenter som handler p\u00e5 dine vegne. Bruksgrenser som stopper en t\u00f8mming f\u00f8r den skjer. Auto-sparing som flytter en andel til en spareplass ved hver inntekt. Planlagte og gjentakende betalinger. Gjenoppretting via venner eller en ekstra enhet. Alt dette er moduler, ikke egenskaper st\u00f8pt inn i \u00e9n bestemt lommebok.<\/p>

Session keys er kanskje det klareste eksempelet p\u00e5 hvorfor moduler betyr noe. I et blokkjedespill vil du ikke godkjenne hvert sverdslag i lommeboken; en session key installert som en modul lar spillet handle innenfor snevre rammer (bare dette spillet, bare en time, bare sm\u00e5 bel\u00f8p) uten \u00e5 be om signatur hver gang. Den samme mekanikken driver AI-agenter som handler eller betaler p\u00e5 dine vegne, der hooks setter grensene for hvor langt agenten f\u00e5r g\u00e5. Fjern modulen, og fullmakten forsvinner.<\/p>

Den store gevinsten er at funksjonene blir b\u00e6rbare p\u00e5 tvers av kontoer som deler standard, og at en god modul kan skrives \u00e9n gang og brukes av mange. En liten utvikler kan lage en spesialisert bruksgrense-hook og n\u00e5 alle 7579-kontoer, uten \u00e5 bygge en hel lommebok. Baksiden, som vi kommer til n\u00e5, er at kontoen din bare er s\u00e5 trygg som modulene du velger \u00e5 slippe inn.<\/p>

Portabilitet og innl\u00e5sing: ERC-7779<\/h2>

Moduler gj\u00f8r funksjoner b\u00e6rbare inne i en konto. Men hva med selve kontoen? Her lurer en innl\u00e5singsfelle. Med EIP-7702 delegerer EOA-en din til en bestemt implementasjon, og hver implementasjon bruker sitt eget lagringsoppsett bundet til seg. Bytter du lommebokleverand\u00f8r, kan lagringen kollidere, eller kontoen kan i verste fall bli ubrukelig fordi den nye koden tolker de gamle lagringsplassene feil.<\/p>

ERC-7779<\/a>, \u00abInteroperable Delegated Accounts\u00bb, er svaret. Den definerer et grensesnitt (IInteroperableDelegatedAccount) med to sentrale metoder: accountId(), som gir kontoen en lesbar identitet, og accountStorageBases(), som lister alle lagringsbasene kontoen har brukt. Til sammen lar det en ny lommebok redelegere trygt og rydde opp i gammel lagring, slik at du kan flytte mellom leverand\u00f8rer uten \u00e5 miste midler. Standarden er et samarbeid mellom Ethereum Foundation, Trust Wallet, Safe, Alchemy og Rhinestone, if\u00f8lge en gjennomgang hos Cointelegraph<\/a>. Der moduler gj\u00f8r funksjoner b\u00e6rbare, gj\u00f8r ERC-7779 kontoen din b\u00e6rbar, og det er nettopp portabilitet som avgj\u00f8r om en standard forblir en \u00e5pen allmenning eller blir en innel\u00e5st hage.<\/p>

Et konkret scenario gj\u00f8r faren tydelig. Si at du delegerte EOA-en din til lommebok A i fjor, installerte et par moduler, og n\u00e5 vil over til lommebok B som har bedre gjenoppretting. Uten en felles forst\u00e5else av hvor de gamle dataene ligger, kan B skrive over noe A la igjen, og resultatet kan bli en konto som oppf\u00f8rer seg uforutsigbart. Det er akkurat denne overgangen ERC-7779 gj\u00f8r trygg, ved \u00e5 la B lese hvilke lagringsbaser A brukte, og rydde opp f\u00f8r den tar over.<\/p>

Sikkerheten i installerbar kode<\/h2>

Alt dette har en pris. \u00c5 installere en modul er \u00e5 gi en bit kode retten til \u00e5 validere eller utf\u00f8re p\u00e5 kontoen din. En ondsinnet eller feilbeheftet modul er dermed en direkte vei til tap. En falsk validator kan godkjenne hva som helst; en r\u00e5 executor kan flytte midler. En ondsinnet modul er i praksis en rug pull p\u00e5 kontoniv\u00e5, og de samme forsvarsvanene gjelder, se slik oppdager du en rug pull<\/a>.<\/p>

En mer subtil fare er lagringskollisjon: to moduler som skriver til samme lagringsplass og overskriver hverandre, med uforutsigbare f\u00f8lger. Det er derfor navngitt lagring etter ERC-7201 er viktig, og hvorfor ERC-6900 gj\u00f8r det obligatorisk mens ERC-7579 overlater ansvaret til modulforfatteren. Registeret og attesteringene (ERC-7484) demper risikoen ved \u00e5 luke ut de verste modulene f\u00f8r de listes, men de fjerner den ikke; en revidert modul kan fortsatt ha en feil som ikke ble fanget opp.<\/p>

Det finnes et forsvar innebygd i selve modeltanken: minste privilegium. En godt designet modul ber bare om det den trenger, og en hook kan begrense hva en annen modul f\u00e5r lov til. En session key b\u00f8r for eksempel v\u00e6re bundet til ett spill, ett tidsvindu og et lite bel\u00f8p, ikke til hele kontoen. Problemet er at brukeren sjelden ser omfanget av det hun godkjenner, og en modul som ber om for mye, ser lik ut som en som ber om akkurat nok.<\/p>

Den st\u00f8rste faren er likevel den enkleste: at brukeren godkjenner noe hun ikke forst\u00e5r. Det er den samme svakheten som blind signering. Det dyreste eksempelet er fortsatt Bybit-tyveriet 21. februar 2025, der rundt 1,5 milliarder dollar forsvant. Det var ikke en feil i Safe-kontrakten, men i det signererne s\u00e5: angriperne (tilskrevet Lazarus-gruppen) hadde manipulert Safe-grensesnittet slik at signererne godkjente en delegatecall som byttet ut kontoimplementasjonen, mens skjermen viste en vanlig overf\u00f8ring (NCC Group<\/a>). Ledgers teknologidirekt\u00f8r Charles Guillemet har beskrevet blind signering som den avgj\u00f8rende svakheten: brukeren vet ikke om hun godkjenner et airdrop eller gir en ondsinnet kontrakt lov til \u00e5 t\u00f8mme lommeboken (NFT Plazas<\/a>). N\u00f8yaktig det samme sp\u00f8rsm\u00e5let gjelder n\u00e5r du installerer en modul.<\/p>

Motmidlet er \u00e5 gj\u00f8re det synlig hva du godkjenner. Clear signing, standardisert som ERC-7730, ble overf\u00f8rt til Ethereum Foundation som n\u00f8ytral forvalter i mai 2026, under prinsippet om at du skal se det du signerer (Ethereum Foundation<\/a>). Tallene gir grunn til forsiktig optimisme: phishing- og drainer-tap falt 83 prosent i 2025, til 83,85 millioner dollar, if\u00f8lge Scam Sniffer (Cointelegraph<\/a>), selv om nye vektorer knyttet til batch-signaturer og ondsinnede godkjenninger vokser. L\u00e6rdommen er at programmerbare konti flytter risikoen fra hvem som holder n\u00f8kkelen, til hva slags kode du slipper til.<\/p>

Standardkrigen m\u00f8ter native account abstraction<\/h2>

Det store, uavklarte sp\u00f8rsm\u00e5let er om protokollen selv kommer til \u00e5 sluke modulene. Flere forslag vil bygge account abstraction inn i Ethereum, uten et eget lag av bundlere og adaptere. To skiller seg ut.<\/p>

EIP-8130<\/a>, drevet av Coinbase og Base, tar en konfigurasjonsbasert vei: faste autentiseringstyper (secp256k1, P-256, WebAuthn og delegat), native gasssponsing, batching og session keys, en ny transaksjonstype (0x79) og en Keystore-kontrakt som lagrer innstillingene dine. En native USDC-overf\u00f8ring blir rundt 63 prosent billigere i gass. Forslaget var ventet i Base sin Cobalt-oppgradering, men per tidlig september 2026 st\u00e5r aktiveringen p\u00e5 hovednettet oppf\u00f8rt som uavklart, og EIP-8130 kj\u00f8rer forel\u00f8pig bare p\u00e5 testnettet Vibenet (Bitcoinist<\/a>). WalletConnect-grunnlegger Pedro Gomes har argumentert for at nettopp EIP-8130 er den beste veien til native account abstraction, fordi den er enklere og mer portabel og fokuserer p\u00e5 det lommeb\u00f8ker faktisk trenger (@pedrouid<\/a>).<\/p>

Det andre forslaget, EIP-8141 fra Vitalik Buterin med flere, er mer ambisi\u00f8st. Buterin har beskrevet det som et samleforslag som l\u00f8ser alle gjenst\u00e5ende problemer account abstraction var ment \u00e5 adressere, og sikter mot en fremtidig \u00abHegota\u00bb-fork \u00abinnen et \u00e5r\u00bb (Cointelegraph<\/a>). Det bruker s\u00e5kalte frame-transaksjoner og er planlagt for inkludering, men er ikke hovedsaken i forken, og klientteam som Nethermind og Besu har flagget kompleksitet. Ethereum-kjerneutvikler Marius van der Wijden har mant til edruelighet: dette er tidlige forslag, og alle de skarpe kantene m\u00e5 vurderes f\u00f8r de kan tas i bruk (DL News<\/a>).<\/p>

Det finnes ogs\u00e5 en tredje, mer minimalistisk retning fra Paradigm-milj\u00f8et, kalt Tempo, som holder seg til de enkleste primitivene og bevisst dropper vilk\u00e5rlig logikk og gassbetaling i token. Uansett hvem som vinner, peker sporene mot sameksistens: native konti tar seg av det protokollen kan standardisere billig og trygt, mens moduler fyller inn spesialfunksjonene et marked ettersp\u00f8r. En bruker vil neppe merke grensen; hun installerer en funksjon, og under panseret avgj\u00f8r leverand\u00f8ren om den bor i protokollen eller i en modul.<\/p>

Betyr native account abstraction at modulene blir overfl\u00f8dige? Neppe. Native forslag standardiserer noen funksjoner (signeringsmetoder, gass, batching) i protokollen, men den modul\u00e6re app-\u00f8konomien lever trolig videre opp\u00e5 native konti, og ERC-7779 forbereder allerede migrasjon mellom modeller. De to lagene konvergerer snarere enn \u00e5 utrydde hverandre. For en dypere titt p\u00e5 selve native-kappl\u00f8pet, se native account abstraction lander: Base, Cobalt og EIP-8130<\/a>.<\/p>

Regler for norske brukere: Finanstilsynet, MiCA og skatt<\/h2>

MiCA gjelder i Norge gjennom E\u00d8S-avtalen, og kryptoeiendelsloven tr\u00e5dte i kraft 1. juli 2025. Finanstilsynet<\/a> gir tillatelser til tilbydere av kryptoeiendelstjenester (CASP) etter MiCA, enten som full tillatelse (artikkel 63) eller notifikasjon (artikkel 60), med krav om fysisk tilstedev\u00e6relse i E\u00d8S. Blant de f\u00f8rste norske akt\u00f8rene er AK Jensen Norway AS, T\u00fdr Markets AS, Firi AS og NBX.<\/p>

Det avgj\u00f8rende skillet for denne artikkelen: ren selvforvaring faller utenfor CASP-reglene. En smartkonto du selv kontrollerer, med eller uten moduler, er ikke en tjeneste Finanstilsynet regulerer; tilsynet regulerer tilbydere, ikke protokollen eller din egen lommebok. Gr\u00e5sonene dukker opp n\u00e5r tredjeparter kommer inn i bildet: et modulregister som drives som en betalt tjeneste, en paymaster som betaler gassen din mot vederlag, eller en gjenopprettingstjeneste som holder en n\u00f8kkeldel. Da kan tilbyderen havne innenfor CASP-regelverket eller andre regelsett, avhengig av hva den faktisk gj\u00f8r med midlene og n\u00f8klene dine.<\/p>

Skatt f\u00f8lger samme logikk uansett kontotype: Skatteetaten behandler gevinst og tap likt enten du bruker en vanlig EOA eller en modul\u00e6r smartkonto, og realisasjon utl\u00f8ser skatt (22 prosent p\u00e5 netto gevinst for de fleste private). Her gjemmer det seg en praktisk felle. Hvis en modul betaler gass i en stablecoin, eller gj\u00f8r mange sm\u00e5 automatiske disposisjoner som auto-sparing og planlagte bytter, kan hver av dem v\u00e6re en skattemessig realisasjon du m\u00e5 holde styr p\u00e5 og rapportere i skattemeldingen. Fra 1. januar 2026 rapporterer dessuten kryptotilbydere systematisk under CARF-regelverket, s\u00e5 myndighetene ser mer enn f\u00f8r. Automatisering er behagelig, men den lager ogs\u00e5 et spor du er ansvarlig for.<\/p>

I praksis betyr det at automatisering krever bokf\u00f8ring. Setter du opp en modul som kj\u00f8per litt ether hver uke eller flytter renter til en spareplass, b\u00f8r du kunne dokumentere hver disposisjon med dato, mengde og verdi i kroner, slik at gevinstberegningen holder n\u00e5r skattemeldingen skal fylles ut. Verkt\u00f8y som henter transaksjonshistorikk fra kjeden finnes, men ansvaret for at tallene stemmer, ligger fortsatt hos deg, ikke hos modulen eller lommeboken.<\/p>

Sjekkliste: slik vurderer du en modul\u00e6r lommebok<\/h2>
  • Hvilken standard bygger den p\u00e5? ERC-7579 eller ERC-6900 avgj\u00f8r hvilke moduler du kan bruke og hvor lett du kan bytte.<\/li>
  • Er modulene attestert og revidert? Se etter et register (ERC-7484) og faktiske revisjonsrapporter, ikke bare et pent grensesnitt.<\/li>
  • Kan du lese hva du signerer og installerer? Krev clear signing (ERC-7730) og forst\u00e5elige modulbeskrivelser, aldri blind godkjenning.<\/li>
  • Er kontoen portabel? St\u00f8tte for ERC-7779 betyr at du kan flytte til en annen leverand\u00f8r uten \u00e5 miste midler.<\/li>
  • Hvordan gjenoppretter du tilgang hvis n\u00f8kkelen eller enheten blir borte? Sosial gjenoppretting, multisig eller passkey-backup b\u00f8r v\u00e6re p\u00e5 plass.<\/li>
  • Bruker den hooks for bruksgrenser og hvitelister som stopper en t\u00f8mming f\u00f8r den skjer?<\/li>
  • Hvem betaler gassen, og hva koster det deg i praksis over tid?<\/li>
  • Hva er selvforvaltet, og hva ligger hos en tredjepart (og dermed potensielt innenfor CASP-regler)?<\/li><\/ul>

    Ofte stilte sp\u00f8rsm\u00e5l<\/h2>

    Hva er en modul\u00e6r smartkonto?<\/h3>

    Det er en smartkonto (en kontrakt-lommebok) som er delt i en slank kjerne pluss moduler du kan installere og fjerne, for eksempel validering, automatisering og sikkerhetsregler. Standarden ERC-7579 definerer det felles grensesnittet slik at samme modul virker p\u00e5 tvers av mange konti.<\/p>

    Hva er forskjellen p\u00e5 ERC-7579 og ERC-6900?<\/h3>

    Begge gj\u00f8r smarte kontoer modul\u00e6re, men ERC-7579 er bevisst minimal og overlater mye til modulene, mens ERC-6900 fra Alchemy er mer omfattende og p\u00e5byr blant annet navngitt lagring og en innebygd tillatelsesmodell. De er ikke kompatible med hverandre.<\/p>

    Er moduler trygge \u00e5 installere?<\/h3>

    En modul er kode som f\u00e5r rett til \u00e5 validere eller utf\u00f8re p\u00e5 kontoen din, s\u00e5 en ondsinnet eller feilbeheftet modul kan v\u00e6re farlig. Bruk moduler fra reviderte registre (ERC-7484), les hva du godkjenner med clear signing, og hold deg til attesterte moduler.<\/p>

    Kan jeg flytte en modul\u00e6r konto til en annen lommebok?<\/h3>

    Det er nettopp problemet ERC-7779 skal l\u00f8se: en standard for \u00e5 migrere en delegert konto mellom leverand\u00f8rer uten at lagringen kolliderer eller kontoen l\u00e5ses. Uten slik st\u00f8tte risikerer du innl\u00e5sing hos \u00e9n leverand\u00f8r.<\/p>

    Blir moduler overfl\u00f8dige n\u00e5r native account abstraction kommer?<\/h3>

    Neppe. Native account abstraction (som EIP-8130 og EIP-8141) flytter noen funksjoner inn i protokollen, men den modul\u00e6re app-\u00f8konomien ventes \u00e5 leve videre opp\u00e5 native konti. Base sin Cobalt-oppgradering, som skulle levere EIP-8130, har forel\u00f8pig ingen fastsatt dato p\u00e5 hovednettet.<\/p>