Smartkontoen ble moduler: ERC-7579 mot ERC-6900 i 2026

For fem år siden var en smartkonto på Ethereum i praksis ett enkelt program. Én smartkontrakt gjorde alt: sjekket signaturen din, håndhevet reglene og utførte transaksjonen. Skulle du endre noe, måtte hele kontrakten byttes ut eller oppgraderes gjennom kompliserte proxy-triks. I 2026 ser bildet helt annerledes ut. Lommeboken din er i ferd med å bli en samling moduler du kan installere, skru av og bytte ut, omtrent som apper på en telefon.

Skiftet har et navn og et nummer: ERC-7579, den minimale standarden for modulære 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øy. Resultatet er en stille standardkrig om hvordan lommeboken din skal bygges, og en ny app-økonomi for funksjoner de fleste brukere aldri kommer til å se navnet på.

Denne gjennomgangen forklarer hva modulære 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åsing 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.

Fra ett program til mange moduler

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

Modulære konti snur dette på 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år igjen er et operativsystem: kjernen er som en OS-kjerne, mens modulene er drivere og apper du legger til etter behov. ERC-7579-spesifikasjonen formaliserer nettopp dette grensesnittet, slik at en modul skrevet for én konto kan kjøre på en annen.

Hvorfor nå? Fordi account abstraction ikke lenger er et nisjeeksperiment. Gjennom ERC-4337 er det registrert over 1,26 milliarder UserOperations og drøyt 65 millioner konti med aktivitet, ifølge BundleBear. 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ær 100 millioner set-code-transaksjoner (BundleBear). Med den skalaen blir det upraktisk å 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).

Kort oppfriskning: EOA, smartkonto og de to veiene inn

En vanlig Ethereum-adresse (en EOA, «externally owned account») styres av én privat nøkkel. Har du nøkkelen, har du full kontroll; mister du den, er alt tapt. En smartkonto er derimot en kontrakt: reglene for hvem som får lov til å gjøre hva, kan programmeres. Det er dette som gjør batching (flere handlinger i én transaksjon), gassabstraksjon, sosial gjenoppretting og session keys mulig i det hele tatt.

Det finnes to veier inn. Den første er ERC-4337, som ble ferdigstilt i mars 2023 og legger et eget lag oppå Ethereum med bundlere, en felles EntryPoint-kontrakt og paymastere, uten å endre selve protokollen; EntryPoint v0.8 fra 2025 la til støtte 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åne smartkontoens egenskaper uten å flytte midler til en ny adresse. Modulene vi skal se på, sitter oppå 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ør begge mer nyttige.

For en vanlig bruker er det de praktiske følgene som teller. En smartkonto kan samle en godkjenning og et bytte i én 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å hvor mye som kan forsvinne på en dårlig dag. Modulene er byggeklossene som gjør hver av disse egenskapene til noe du kan slå på uten å bytte lommebok.

ERC-7579: den minimale modulstandarden

ERC-7579, «Minimal Modular Smart Accounts», nådde ferdig status på 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ålet er det minste felles grensesnittet, slik at en modul skrevet én gang virker på tvers av mange kontoimplementasjoner.

Standarden definerer noen få funksjoner en konto må ha: installModule, uninstallModule, isModuleInstalled og isModuleType. Den sier bevisst lite om hvordan lagringen skal se ut eller hvordan tillatelser skal håndteres; det overlates til modulene og til implementasjonen. «Minimal» er ikke en unnskyldning, det er designfilosofien. Jo mindre standarden dikterer, jo lettere er det for Safe, Kernel og Nexus å være enige om det samme grensesnittet, og jo lavere er terskelen for en uavhengig utvikler til å skrive en modul som virker overalt.

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

De fire modultypene, forklart

ERC-7579 deler moduler i fire typer etter når og hvordan de griper inn i en transaksjon. Det er denne firedelingen som gjør at en utvikler kan skrive en enkelt, avgrenset bit funksjonalitet uten å måtte forstå resten av kontoen.

Valideringsmodulene er de mest interessante for både 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økkellager; takket være RIP-7212, en precompile som kutter kostnaden for P-256-verifisering fra rundt 300 000 til cirka 3 450 gass, er dette blitt praktisk på flere L2-er. En annen validator kan implementere en multisig der flere nøkler må signere, en modell vi har sett nærmere på i gjennomgangen av MPC eller multisig. Poenget er at samme konto kan ha flere validatorer installert samtidig, for eksempel en passkey til hverdags og en multisig til de store beløpene.

Hook-modulene er den andre siden av mynten. En hook kjører rundt hver handling og kan si nei. Vil du at kontoen aldri skal sende mer enn et gitt beløp per dag, eller bare til adresser på en hviteliste, er det en hook som håndhever regelen. Executor-moduler, derimot, handler proaktivt: de kan sette opp en fast overføring den første i måneden eller flytte alt til en nødadresse hvis noe utløses. Fire typer, én konto, og du bestemmer hvilke som er installert.

Slik henger det sammen i én transaksjon: en valideringsmodul sjekker først at signaturen er ekte og at du har lov til å handle, en hook kan så gripe inn og avvise hvis beløpet bryter en grense, kontoen utfører handlingen, og en ny hook kan kjøre etterpå for å logge eller sperre. Fordi hvert steg er en egen modul, kan du bytte ut signeringen uten å røre bruksgrensene, eller stramme inn grensene uten å røre signeringen.

ERC-6900: den andre leiren

ERC-7579 er ikke den eneste måten å gjøre en konto modulær på. ERC-6900, som Alchemy foreslo i 2023, sikter mot det samme målet, men med en langt mer omfattende spesifikasjon. Der 7579 er minimal, er 6900 preskriptiv: den påbyr navngitt lagring etter ERC-7201, 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.

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

Rhinestone og modulregisteret

En standard alene lager ikke et økosystem. Det er her Rhinestone kommer inn, et infrastrukturselskap som har gjort ERC-7579 til noe utviklere faktisk kan bygge på. Rhinestone står bak tre ting som henger sammen: et modulregister, standarden ERC-7484 og utviklerverktøyet ModuleKit.

Modulregisteret løser oppdagelsesproblemet. Skal du installere en modul, hvordan vet du at den er trygg? Registeret lister moduler i to lag: et åpent fellesskapslag og et revidert lag der modulen har vært gjennom en definert revisjonsprosess, med attestering på kjeden om at koden på en gitt adresse faktisk ble revidert før den ble listet. Per første kvartal 2026 snakker vi om flere titalls moduler, med kjente revisorer som Spearbit, ChainSecurity, OpenZeppelin og Trail of Bits involvert. ERC-7484 standardiserer hvordan en konto spør registeret om slike attesteringer før en modul installeres, en mekanisme Rhinestone kaller registerhåndhevet sikkerhet.

ModuleKit er Foundry-basert og lar en utvikler teste den samme modulen mot Safe, Kernel, Nexus og Alchemys Modular Account i én testsuite. Det senker kostnaden ved å skrive en modul som virker overalt, og det er nettopp den kostnaden som avgjør om app-økonomien tar av. Attesteringer og revisjoner har med dette blitt en egen økonomi, med egne insentiver; vi har sett på hvordan slike utbetalinger avgjøres i bug bounty-maskineriet. En modul uten attestering er ikke ulovlig å bruke, men den bør behandles som ukjent kode fra en fremmed.

Verdt å forstå er hva en attestering faktisk sier. Den er ikke en garanti for at en modul er feilfri, men en signert påstand fra en navngitt part om at koden på en bestemt adresse er den som ble gjennomgått, og at den besto en definert prosess. To-lagsmodellen betyr at du selv velger risikoprofil: holder du deg til det reviderte laget, får du færre valg men mer trygghet; åpner du for fellesskapslaget, får du flere moduler men må stole mer på din egen vurdering.

Safe7579: broen mellom Safe og modulene

Ingen enkelt aktør har mer på 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å over 63 millioner konti, ifølge The Block. Safe var opprinnelig bygget rundt sin egen multisig-modell, ikke rundt ERC-7579, så spørsmålet ble hvordan man kobler en så stor installert base til det nye modulgrensesnittet.

Broen heter Safe7579, en adapter utviklet av Rhinestone og Safe som gjør Safe-konti kompatible med ERC-7579. Med den kan eksisterende Safe-brukere installere 7579-moduler, og det følger med 14 reviderte moduler (blant dem en «dead man’s switch», flash-lån og sosial gjenoppretting), etter en revisjon av Ackee (Safe-dokumentasjonen). For DAO-er og bedriftskasser blir moduler også et styringsverktøy: 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.

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å mistenkelige transaksjoner kan stanses i tide, og gi avgrensede roller til ansatte uten å gi dem nøklene til hele kassen. Det er slike moduler som gjør en multisig til et faktisk styringssystem, ikke bare en delt nøkkel.

Hvem bygger modulære konti

Bak standardene står et knippe implementasjoner som konkurrerer om utviklere og brukere. De fleste har landet på ERC-7579, men de skiller seg på modenhet, utbredelse og filosofi.

Merk den siste raden. Coinbase og Base beveger seg mot native account abstraction via en egen konfigurasjonsbasert modell (mer om det under), snarere enn å bygge på ERC-7579-moduler. Det er en påminnelse om at «modulær» og «native» er to ulike svar på samme problem, og at de største aktørene ikke nødvendigvis velger likt. For en vanlig bruker betyr det at valget av lommebok også er et valg av økosystem: hvilke moduler du får tilgang til, henger sammen med hvilken standard produktet har satset på.

App-økonomien: en butikk for lommebokfunksjoner

Når moduler blir standardiserte og reviderte, oppstår noe som ligner på en appbutikk for lommeboken. Biconomy driver for eksempel en modulbutikk som går på Rhinestones infrastruktur (Rhinestone). I stedet for å bytte lommebok for å få en ny funksjon, installerer du en modul, omtrent som du laster ned en app i stedet for å kjøpe en ny telefon.

Hva slags apper snakker vi om? Session keys som lar deg signere én gang og så spille i en time uten å godkjenne hvert trekk, en funksjon som har gjort account abstraction populær i blokkjedespill og hos AI-agenter som handler på dine vegne. Bruksgrenser som stopper en tømming før 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øpt inn i én bestemt lommebok.

Session keys er kanskje det klareste eksempelet på 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å beløp) uten å be om signatur hver gang. Den samme mekanikken driver AI-agenter som handler eller betaler på dine vegne, der hooks setter grensene for hvor langt agenten får gå. Fjern modulen, og fullmakten forsvinner.

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

Portabilitet og innlåsing: ERC-7779

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

ERC-7779, «Interoperable Delegated Accounts», 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ører uten å miste midler. Standarden er et samarbeid mellom Ethereum Foundation, Trust Wallet, Safe, Alchemy og Rhinestone, ifølge en gjennomgang hos Cointelegraph. Der moduler gjør funksjoner bærbare, gjør ERC-7779 kontoen din bærbar, og det er nettopp portabilitet som avgjør om en standard forblir en åpen allmenning eller blir en innelåst hage.

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

Sikkerheten i installerbar kode

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

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

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år lov til. En session key bør for eksempel være bundet til ett spill, ett tidsvindu og et lite beløp, 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.

Den største faren er likevel den enkleste: at brukeren godkjenner noe hun ikke forstår. 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å: angriperne (tilskrevet Lazarus-gruppen) hadde manipulert Safe-grensesnittet slik at signererne godkjente en delegatecall som byttet ut kontoimplementasjonen, mens skjermen viste en vanlig overføring (NCC Group). Ledgers teknologidirektør Charles Guillemet har beskrevet blind signering som den avgjørende svakheten: brukeren vet ikke om hun godkjenner et airdrop eller gir en ondsinnet kontrakt lov til å tømme lommeboken (NFT Plazas). Nøyaktig det samme spørsmålet gjelder når du installerer en modul.

Motmidlet er å gjøre det synlig hva du godkjenner. Clear signing, standardisert som ERC-7730, ble overført til Ethereum Foundation som nøytral forvalter i mai 2026, under prinsippet om at du skal se det du signerer (Ethereum Foundation). Tallene gir grunn til forsiktig optimisme: phishing- og drainer-tap falt 83 prosent i 2025, til 83,85 millioner dollar, ifølge Scam Sniffer (Cointelegraph), selv om nye vektorer knyttet til batch-signaturer og ondsinnede godkjenninger vokser. Lærdommen er at programmerbare konti flytter risikoen fra hvem som holder nøkkelen, til hva slags kode du slipper til.

Standardkrigen møter native account abstraction

Det store, uavklarte spørsmålet er om protokollen selv kommer til å sluke modulene. Flere forslag vil bygge account abstraction inn i Ethereum, uten et eget lag av bundlere og adaptere. To skiller seg ut.

EIP-8130, 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øring blir rundt 63 prosent billigere i gass. Forslaget var ventet i Base sin Cobalt-oppgradering, men per tidlig september 2026 står aktiveringen på hovednettet oppført som uavklart, og EIP-8130 kjører foreløpig bare på testnettet Vibenet (Bitcoinist). 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å det lommebøker faktisk trenger (@pedrouid).

Det andre forslaget, EIP-8141 fra Vitalik Buterin med flere, er mer ambisiøst. Buterin har beskrevet det som et samleforslag som løser alle gjenstående problemer account abstraction var ment å adressere, og sikter mot en fremtidig «Hegota»-fork «innen et år» (Cointelegraph). Det bruker såkalte 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å vurderes før de kan tas i bruk (DL News).

Det finnes også en tredje, mer minimalistisk retning fra Paradigm-miljøet, kalt Tempo, som holder seg til de enkleste primitivene og bevisst dropper vilkårlig 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ør. En bruker vil neppe merke grensen; hun installerer en funksjon, og under panseret avgjør leverandøren om den bor i protokollen eller i en modul.

Betyr native account abstraction at modulene blir overflødige? Neppe. Native forslag standardiserer noen funksjoner (signeringsmetoder, gass, batching) i protokollen, men den modulære app-økonomien lever trolig videre oppå native konti, og ERC-7779 forbereder allerede migrasjon mellom modeller. De to lagene konvergerer snarere enn å utrydde hverandre. For en dypere titt på selve native-kappløpet, se native account abstraction lander: Base, Cobalt og EIP-8130.

Regler for norske brukere: Finanstilsynet, MiCA og skatt

MiCA gjelder i Norge gjennom EØS-avtalen, og kryptoeiendelsloven trådte i kraft 1. juli 2025. Finanstilsynet gir tillatelser til tilbydere av kryptoeiendelstjenester (CASP) etter MiCA, enten som full tillatelse (artikkel 63) eller notifikasjon (artikkel 60), med krav om fysisk tilstedeværelse i EØS. Blant de første norske aktørene er AK Jensen Norway AS, Týr Markets AS, Firi AS og NBX.

Det avgjørende 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åsonene dukker opp når 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økkeldel. Da kan tilbyderen havne innenfor CASP-regelverket eller andre regelsett, avhengig av hva den faktisk gjør med midlene og nøklene dine.

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

I praksis betyr det at automatisering krever bokføring. Setter du opp en modul som kjøper litt ether hver uke eller flytter renter til en spareplass, bør du kunne dokumentere hver disposisjon med dato, mengde og verdi i kroner, slik at gevinstberegningen holder når skattemeldingen skal fylles ut. Verktøy som henter transaksjonshistorikk fra kjeden finnes, men ansvaret for at tallene stemmer, ligger fortsatt hos deg, ikke hos modulen eller lommeboken.

Sjekkliste: slik vurderer du en modulær lommebok

• Hvilken standard bygger den på? ERC-7579 eller ERC-6900 avgjør hvilke moduler du kan bruke og hvor lett du kan bytte.
• Er modulene attestert og revidert? Se etter et register (ERC-7484) og faktiske revisjonsrapporter, ikke bare et pent grensesnitt.
• Kan du lese hva du signerer og installerer? Krev clear signing (ERC-7730) og forståelige modulbeskrivelser, aldri blind godkjenning.
• Er kontoen portabel? Støtte for ERC-7779 betyr at du kan flytte til en annen leverandør uten å miste midler.
• Hvordan gjenoppretter du tilgang hvis nøkkelen eller enheten blir borte? Sosial gjenoppretting, multisig eller passkey-backup bør være på plass.
• Bruker den hooks for bruksgrenser og hvitelister som stopper en tømming før den skjer?
• Hvem betaler gassen, og hva koster det deg i praksis over tid?
• Hva er selvforvaltet, og hva ligger hos en tredjepart (og dermed potensielt innenfor CASP-regler)?

Ofte stilte spørsmål

Hva er en modulær smartkonto?

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å tvers av mange konti.

Hva er forskjellen på ERC-7579 og ERC-6900?

Begge gjør smarte kontoer modulære, men ERC-7579 er bevisst minimal og overlater mye til modulene, mens ERC-6900 fra Alchemy er mer omfattende og påbyr blant annet navngitt lagring og en innebygd tillatelsesmodell. De er ikke kompatible med hverandre.

Er moduler trygge å installere?

En modul er kode som får rett til å validere eller utføre på kontoen din, så en ondsinnet eller feilbeheftet modul kan være farlig. Bruk moduler fra reviderte registre (ERC-7484), les hva du godkjenner med clear signing, og hold deg til attesterte moduler.

Kan jeg flytte en modulær konto til en annen lommebok?

Det er nettopp problemet ERC-7779 skal løse: en standard for å migrere en delegert konto mellom leverandører uten at lagringen kolliderer eller kontoen låses. Uten slik støtte risikerer du innlåsing hos én leverandør.

Blir moduler overflødige når native account abstraction kommer?

Neppe. Native account abstraction (som EIP-8130 og EIP-8141) flytter noen funksjoner inn i protokollen, men den modulære app-økonomien ventes å leve videre oppå native konti. Base sin Cobalt-oppgradering, som skulle levere EIP-8130, har foreløpig ingen fastsatt dato på hovednettet.

Jonas Ellingsen dekker lommebøker, selvforvaring og account abstraction for HOGE Wire.