Formell verifisering: revisoren som beviser koden, ikke tester den

Den 3. november 2025 forsvant det digitale verdier for mer enn 128 millioner dollar (rundt 1,2 milliarder kroner) ut av DeFi-protokollen Balancer i løpet av noen få blokker. Det mest ubehagelige var ikke beløpet, men at koden som ble tømt, var blant de grundigst gjennomgåtte i hele bransjen: elleve separate revisjoner fra fire ulike selskaper, og en av dem var ikke en gjennomlesning, men et matematisk bevis. Feilen hadde ligget i koden siden juli 2021 og overlevd hver eneste kontroll, ifølge CryptoSlates gjennomgang.

For folk flest betyr «revidert» at noen erfarne øyne har lest koden og lett etter feil. Formell verifisering lover noe langt sterkere: et bevis, i matematisk forstand, på at koden oppfører seg slik den er spesifisert, for alle mulige inndata, ikke bare dem en tester tilfeldigvis kommer på å prøve. Det er avstanden mellom «vi fant ingen feil da vi lette» og «vi har bevist at denne feilen ikke kan oppstå». I en bransje som tapte over 1,31 milliarder dollar (rundt 12 milliarder kroner) til angrep bare i første halvår 2026, ifølge CertiKs Hack3d-rapport, er det en forlokkende forskjell.

Denne gjennomgangen ser på formell verifisering som en egen kategori kryptorevisjon: hva den faktisk beviser, hvorfor Balancer-saken viser både styrken og den innebygde begrensningen, hvem selskapene er (med Certora i sentrum), hva det koster, og hvorfor et bevis, selv et feilfritt et, ikke stopper de angrepene som i dag stjeler mest. Det er en søsterartikkel til vår gjennomgang av hva vanlige audits fanger og bommer på.

Hva formell verifisering egentlig er

Formell verifisering (FV) er en metode fra datavitenskapen som er eldre enn kryptobransjen selv. Den brukes til å sikre alt fra flykontrollsystemer og mikroprosessorer til operativsystemkjerner. Ideen er enkel å beskrive og vanskelig å gjennomføre: i stedet for å kjøre programmet med noen utvalgte testverdier og se om det krasjer, oversetter man både programmet og en presis påstand om hva det skal gjøre til matematisk logikk, og lar en datamaskin avgjøre om påstanden kan brytes.

Certora, som er blitt det mest kjente navnet i kryptosammenheng, formulerer det slik i sitt eget materiale: formell verifisering «produserer et matematisk bevis på at programmet oppfører seg i tråd med spesifikasjonen på tvers av alle kjøringer», og gir «fullstendig dekning av alle utførelsesveier for en gitt spesifikasjon». Tradisjonell testing og fuzzing, derimot, «kan bare av og til oppdage feil», og bare hvis de inndataene man velger, faktisk utløser feilen. Det skriver selskapet i sin egen innføring i formell verifisering.

Forskjellen er kategorisk. En test svarer på spørsmålet «feiler koden for akkurat disse verdiene?». Et bevis svarer på «kan koden i det hele tatt feile på denne måten, for noen verdier som helst?». Der en tester må gjette hvilke tilfeller som er farlige, dekker beviset alle tilfellene på én gang, inkludert dem ingen menneskelig revisor ville kommet på.

Et konkret eksempel Certora selv trekker fram: en usynlig regnefeil i MakerDAOs kjernematematikk, en overtredelse av selve likningen som holder DAI-systemet solvent, som hadde ligget uoppdaget siden 2018 og satte anslagsvis 10 milliarder dollar (rundt 93 milliarder kroner) i fare. Feilen ble ikke funnet av manuell gjennomlesning eller testing, men av et formelt bevis som viste at en invariant kunne brytes.

Bevis kontra stikkprøve: hvordan FV skiller seg fra en vanlig audit

For å forstå hvor formell verifisering hører hjemme, er det nyttig å sette de tre vanligste tilnærmingene ved siden av hverandre. En manuell audit er erfarne sikkerhetsforskere som leser koden linje for linje. Fuzzing og eiendomstesting kaster tusenvis eller millioner av inndata på koden og ser hva som knekker. Formell verifisering beviser eller motbeviser en presis påstand for alle inndata samtidig.

De tre utelukker ikke hverandre; de beste sikkerhetsprosessene bruker alle tre. Balancer hadde både manuelle audits, testing og formell verifisering. Men de svarer på forskjellige spørsmål, og det er avgjørende å vite hvilket spørsmål man har betalt for å få besvart.

Det er også verdt å merke seg hva FV ikke er: det er ikke et stempel som sier «trygg». Et formelt bevis er alltid et bevis om noe bestemt: «for alle inndata gir denne funksjonen aldri ut mer enn den tar inn», eller «totalbeholdningen er alltid lik summen av de enkelte saldoene». Verdien av beviset er nøyaktig så stor som verdien av påstanden man har valgt å bevise.

Slik fungerer Certora Prover

Kjernen i Certoras teknologi heter Certora Prover. En ingeniør skriver regler i et eget språk, CVL (Certora Verification Language), som ligner på Solidity, slik at kontraktsutviklere kan lese dem. En regel kan for eksempel si at «summen av alle brukersaldoer alltid er lik den totale beholdningen», eller at «ingen kan ta ut mer enn de har satt inn».

Prover oversetter så både kontraktens bytekode og regelen til logiske betingelser og sender dem til såkalte SMT-solvere, spesialiserte bevismotorer som Z3 (fra Microsoft Research) og CVC5. Solveren gjør én av to ting: enten beviser den at ingen inndata kan bryte regelen, eller så returnerer den et konkret moteksempel, en spesifikk transaksjonssekvens som bryter den. Moteksemplet er ofte det mest verdifulle utfallet, fordi det gir utviklerne en presis oppskrift på angrepet før noen angriper.

Det finnes en tredje mulighet, og den er viktig for å lese en rapport ærlig: solveren kan gå tom for tid eller ressurser og komme tilbake som ubestemt, verken bevist eller motbevist. Kompleks kode med mange forgreninger kan gi det som kalles «sti-eksplosjon», der antallet mulige utførelsesveier vokser raskere enn noen maskin kan håndtere. En redelig verifiseringsrapport skiller derfor tydelig mellom egenskaper som er bevist, egenskaper som er motbevist, og egenskaper som forble ubestemte.

Tidlig i 2025 ble Certora Prover gjort til åpen kildekode, og verktøyet dekker nå ikke bare EVM-baserte kjeder, men også Solana og Stellar. At bevismotoren er åpen, betyr at hvem som helst kan inspisere hvordan bevisene faktisk føres, noe som demper (men ikke fjerner) bekymringen for at verktøyet selv kan ha feil.

Certora, selskapet bak bevismaskinen

Certora ble grunnlagt i 2018 av Mooly Sagiv, professor og leder for programvaresystemer ved Tel Aviv-universitetet og en veteran innen formelle metoder, sammen med teknologidirektør Shelly Grossman. Selskapet hentet 36 millioner dollar (rundt 335 millioner kroner) i en serie B-runde i mai 2022, ledet av Jump Crypto, med Tiger Global og Galaxy Digital blant investorene.

Kundelisten forklarer hvorfor navnet dukker opp igjen og igjen i store DeFi-hendelser: Aave, Lido, Uniswap, Compound, MakerDAO, EigenLayer, Morpho og Safe har alle brukt Certora. Selskapet oppgir selv at teknologien har vært brukt til å sikre verdier for langt over hundre milliarder dollar (godt over 900 milliarder kroner), og at det er skrevet titusener av verifiseringsregler mot kundenes kontrakter.

Certora er ikke alene i markedet, men selskapet har vært flinkere enn de fleste til å gjøre formell verifisering forståelig for et bredere publikum, og, som vi skal se, uvanlig ærlig når metoden kommer til kort. Den ærligheten ble satt på prøve i november 2025.

Balancer: da beviset ikke var sterkt nok

Balancer V2 var ingen tilfeldig, urevidert protokoll. Kjernekoden hadde gjennomgått elleve revisjoner fra fire selskaper, deriblant OpenZeppelin, Trail of Bits og Certora. Certora hadde altså ikke bare lest koden, men ført formelle bevis på den. Likevel, den 3. november 2025, tømte en angriper protokollen for over 128 millioner dollar (rundt 1,2 milliarder kroner) ved å utnytte en avrundingsfeil i funksjonen _upscale.

Mekanikken er lærerik. Ved visse bytter rundet koden av et beløp nedover der den skulle rundet oppover i protokollens favør. Hver enkelt avrunding var forsvinnende liten, men ved å kjøre mange manipulerte bytter i samme blokk kunne angriperen forsterke feilen til hele bassenget var tomt. Feilen hadde da ligget i koden i over fire år.

Det oppsiktsvekkende er hva Certora selv skrev etterpå. I sin egen gjennomgang av angrepet erkjenner selskapet rett ut at bevisene fra 2022 dekket solvens på et overordnet nivå, men, med Certoras egne ord: «selv om de verifiserte egenskapene garanterte solvens på et høyt nivå, var de ikke sterke nok til å oppdage avrundingsfeilen som forårsaket angrepet». Og videre: «de verifiserte egenskapene begrenset ikke forholdet mellom enkeltbytter eller avrundingsatferd».

Med andre ord: Certora hadde bevist at Balancer var solvent, og det beviset holdt. Men ingen hadde bevist at avrundingen alltid gikk i protokollens favør, fordi ingen hadde skrevet ned den egenskapen. Beviset var korrekt; det var bare et bevis om feil ting.

Kontrasten til Balancer V3 gjør poenget skarpt. På V3 gjøres alle bassengoperasjoner med 18-desimalers presisjon, de såkalte composable pools er byttet ut med ERC4626-buffere, og eksplisitte avrundingsretninger er lagt inn og håndhevet for hver eneste utregning. Certora la til en ny regel, swappingBackAndForth, som beviser at det å bytte et beløp fra én token til en annen og tilbake igjen aldri kan gi gevinst. V3 ble ikke rammet i angrepet; der var avrundingen korrekt. Forskjellen mellom V2 og V3 var ikke et bedre bevis; det var en bedre spesifikasjon.

Spesifikasjonen er den nye svakheten

Balancer illustrerer tesen som løper gjennom hele denne kategorien: formell verifisering fjerner ikke usikkerheten, den flytter den. Med en manuell audit er spørsmålet «var revisoren dyktig og grundig nok?». Med formell verifisering blir spørsmålet «dekker spesifikasjonen det som faktisk kan gå galt?». Flaskehalsen forskyves fra selve beviset til påstandene man velger å bevise.

Certora er prisverdig tydelig på dette i sitt eget materiale og lister opp begrensningene metoden har. «Hvis spesifikasjonen ikke nøyaktig fanger programmets tiltenkte oppførsel, kan ikke resultatene fra den formelle verifiseringen stoles på». Og enda mer direkte: «hvis spesifikasjonen ikke dekker en egenskap, kan ikke formell verifisering gi noen garantier» mot feil knyttet til den egenskapen. Det er, i klartekst, søppel inn, søppel ut: et feilfritt bevis av en ufullstendig påstand gir en falsk trygghet som kan være farligere enn ingen trygghet.

Det finnes flere hull metoden ikke fyller. Formell verifisering av kontraktskoden sier ingenting om økonomiske designfeil, om en oracle som mates med manipulerte priser, om verdier som lekkes gjennom MEV, eller om private nøkler som kommer på avveie. Beviset gjelder koden slik den er skrevet, ikke verden koden lever i. Det er en påminnelse om at styringsangrep som det mot Term Finance ofte handler om intensjon og insentiver, ikke om en enkelt kodelinje som er «feil».

Web3-utvikleren Suhail Kakar oppsummerte stemningen etter Balancer treffende. Protokollen hadde vært gjennom over ti revisjoner, kjernehvelvet gransket av flere uavhengige selskaper, og ble likevel tømt. «Audited by X betyr nesten ingenting», skrev han; «kode er vanskelig, DeFi er vanskeligere». Poenget er ikke at revisjon er verdiløst, men at et stempel aldri var det samme som en garanti.

Landskapet: hvem andre beviser kode?

Certora er det mest synlige navnet, men formell verifisering er et felt med flere aktører og tilnærminger. Noen selger det som en tjeneste, andre bygger åpne verktøy utviklere kan bruke selv, og noen er bygget inn i verktøyene folk allerede har.

Verktøyene skiller seg mest i hvor spesifikasjonen kommer fra. Certora ber deg skrive reglene fra bunnen i CVL, noe som gir presisjon, men krever spesialkompetanse. Runtime Verifications Kontrol og a16z sitt Halmos gjenbruker tester utviklerne allerede har skrevet, som spesifikasjon, noe som senker terskelen, men gir svakere garantier: Halmos beskriver sin egen garanti som «bounded», altså begrenset av hvor dypt løkker kjøres. Veridise har spesialisert seg på zero-knowledge-kretser, et område der en feil kan være umulig å se med det blotte øye og der vanlige revisorer sjelden har verktøyene.

Det finnes også et voksende landskap av auditører som kombinerer formell verifisering med manuell gjennomgang og offensiv testing. For lesere som vil se hvordan dette ser ut utenfor EVM-verdenen, har vi tidligere gått gjennom Solana- og Move-revisorene, og for den offensive siden, der et selskap angriper deg før angriperne gjør det, hvordan red teaming fungerer i praksis.

Hva et bevis ikke fanger

Her kommer den ubehagelige delen for alle som håper formell verifisering er en sølvkule. Selv om man beviste all kontraktskode i hele bransjen feilfri, ville de fleste kronene fortsatt forsvinne. Grunnen er at pengene i økende grad ikke lekker ut gjennom kodefeil, men gjennom nøkler, mennesker og infrastruktur, alt sammen ting et kodebevis ikke tar på.

CertiKs Hack3d-rapport for første halvår 2026 er tydelig på mønsteret. Av over 1,31 milliarder dollar (rundt 12 milliarder kroner) i tap fordelte de største kategoriene seg slik: kompromitterte lommebøker og nøkler sto for over 444 millioner dollar (rundt 4 milliarder kroner) fra bare 33 hendelser, phishing for 366 millioner dollar (rundt 3,4 milliarder kroner) fra 63 hendelser, mens kodesårbarheter, som var den vanligste kategorien med 204 hendelser, likevel «bare» sto for rundt 152 millioner dollar (rundt 1,4 milliarder kroner).

Regnestykket er nedslående for kode-optimister: den vanligste angrepstypen er også en av de billigste per hendelse, mens de dyreste angrepene treffer akkurat det formell verifisering ikke ser. En angriper som stjeler en nøkkel eller lurer en signerer, bryr seg ikke om at koden er bevist korrekt.

Immunefi, som driver bransjens største bug bounty-plattform, kom fram til en lignende totalsum for første halvår 2026: rundt 972 millioner dollar (vel 9 milliarder kroner) tapt over rekordmange 207 hendelser, under halvparten av tapene fra året før til tross for flere angrep. Immunefi utbetalte selv rundt 13,45 millioner dollar (rundt 125 millioner kroner) til forskere for 837 gyldige feil de fanget før angriperne rakk det. Poenget er ikke at det ene laget slår det andre, men at et modent sikkerhetsoppsett trenger flere lag: bevis for koden, mennesker for logikken, og bounties for det alle andre bommet på.

AI skriver nå kontraktene, og det endrer regnestykket

Den ferskeste grunnen til at formell verifisering får ny oppmerksomhet, er at stadig mer av koden ikke lenger skrives av mennesker. Store språkmodeller genererer nå smartkontrakter på bestilling, ofte syntaktisk korrekte og overbevisende, men med sikkerhetsfeil under overflaten. Når koden produseres raskere enn mennesker rekker å granske den, blir en metode som kan bevise egenskaper automatisk plutselig mer attraktiv.

Certora svarte på dette i november 2025 med Certora AI Composer, som selskapet kaller «den første trygge AI-kodeplattformen for smartkontrakter». Ideen er å bygge bevismotoren inn i selve kodegenereringen, slik at hver kodebit AI-en foreslår, kontrolleres mot matematiske sikkerhetsregler før den i det hele tatt kjøres. Mooly Sagiv formulerte ambisjonen slik: «AI og formell verifisering kan jobbe sammen for å gjøre smartkontraktutvikling pålitelig som standard».

Ikke alle er like optimistiske til AI som sikkerhetssnarvei. David Schwed, driftsdirektør i sikkerhetsselskapet SVRN, advarer mot å forveksle et verktøy med en prosess. «Claude, revider smartkontrakten min, ikke gjør feil, er ikke et sikkerhetsprogram», sa han til CoinDesk, og la til at «hvis den som kjører verktøyet ikke kan vurdere det som kommer tilbake, har du ikke kjøpt sikkerhet, du har kjøpt en falsk følelse av den». Samtidig peker han på den reelle gevinsten: AI kan gi «kontinuerlig revisjon med foreslåtte utbedringer til en brøkdel av kostnaden, i stedet for en engangsgjennomgang du bare har råd til én gang».

Det er nettopp her formell verifisering og AI møtes på en interessant måte. AI kan foreslå både koden og et første utkast til spesifikasjonen; bevismotoren kan avvise begge deler hvis de ikke henger sammen. Men, som Balancer viste, er et bevis bare så godt som spesifikasjonen, og en AI som skriver både koden og påstandene om koden, risikerer å bevise nøyaktig det utvikleren håpet, ikke det angriperen faktisk vil utnytte.

Så mye koster det, og hvem har råd

Formell verifisering er dyrt, av en enkel grunn: det krever spesialister som kan både kontraktsspråket og matematisk logikk, og det tar tid å skrive gode spesifikasjoner. En full manuell audit av en middels stor protokoll ligger typisk i størrelsesorden hundretusener av kroner til godt over en million; et formelt verifiseringsoppdrag på toppen kan koste like mye eller mer, avhengig av hvor mange egenskaper som skal bevises.

Det skaper en skjevhet: de største protokollene, med mest å tape, har råd til å bevise koden sin, mens mindre prosjekter nøyer seg med en rask gjennomgang eller ingenting. Ethereum Foundation forsøkte å bøte på dette i april 2026 med et tilskuddsprogram på rundt 1 million dollar (rundt 9 millioner kroner), der over tjue sikkerhetsselskaper, Certora blant dem, kan dekke inntil 30 prosent av revisjonskostnaden for utvalgte prosjekter, og, avgjørende, pengene utbetales først etter at funnene er rettet, ikke bare etter at rapporten er levert.

For institusjonene som nå tokeniserer verdier for milliarder, endrer regnestykket seg. Når tradisjonelle finansaktører legger obligasjoner og fond på kjeden, blir et matematisk bevis på at kontrakten oppfører seg, en langt lettere salgbar forsikring enn «vi leste koden og fant ingenting». Det er en av grunnene til at etablerte revisjonsselskaper posisjonerer seg mot de tokeniserte verdiene på Wall Street, der kravene til dokumentert sikkerhet er strengere enn i det ville DeFi-landskapet.

Finanstilsynet, MiCA og hullet ingen regulator dekker

For norske lesere er det en viktig nyanse her: ingen offentlig myndighet sertifiserer eller godkjenner den som reviderer en smartkontrakt. Kryptoeiendelsloven, som trådte i kraft 1. juli 2025 og innlemmer EUs MiCA-regelverk i norsk rett gjennom EØS-avtalen, regulerer tjenesteyterne (CASP-ene), altså børsene, vekslerne og oppbevaringstjenestene, ikke koden i protokollene de kobler seg til. Det framgår av Finanstilsynets egen omtale av regelverket. Finanstilsynet fører tilsyn med at en CASP har forsvarlig drift, ikke med at en gitt DeFi-kontrakt er matematisk bevist trygg.

Det samme gjelder DORA, EUs regelverk for digital operasjonell motstandsdyktighet, som stiller krav til IT-sikkerhet og hendelseshåndtering hos de sentraliserte aktørene, men som heller ikke rekker inn i selve kontraktskoden. Med andre ord: verken MiCA eller DORA pålegger noen å formelt verifisere en smartkontrakt, og ingen tilsynsmyndighet stempler et verifiseringsselskap som «godkjent». Overgangsperioden for eksisterende aktører under den norske loven er forlenget til 30. juni 2026, men den handler om lisensiering av tjenesteytere, ikke om kodekvalitet.

Konsekvensen for en investor eller bruker er at ansvaret for å vurdere om en protokolls kode er skikkelig verifisert, faller på en selv. Det finnes ikke et offentlig register å slå opp i. Det nærmeste man kommer, er å lese verifiseringsrapportene direkte, og da hjelper det å vite hva man ser etter.

Slik leser du en verifiseringsrapport

En verifiseringsrapport ser annerledes ut enn en vanlig auditrapport, og den er lettere å feiltolke. Her er tingene som er verdt å sjekke.

• Hva ble faktisk bevist? Se etter en liste over egenskaper (regler). En rapport som beviser «totalbeholdningen er alltid korrekt», men ikke sier noe om avrunding i enkeltbytter, forteller deg like mye med det den utelater som med det den inkluderer.
• Bevist, motbevist eller ubestemt? Egenskaper som forble ubestemte (solveren ga opp) er ikke det samme som beviste. Et ærlig selskap skiller tydelig; et mindre ærlig ett gjemmer dem bort.
• Hvilke antakelser ble gjort? Bevis hviler ofte på forutsetninger («vi antar at oracle-prisen er korrekt», «vi ser bort fra denne biblioteksfunksjonen»). Antakelsene er der de virkelige hullene bor.
• Hvor gammelt er beviset? Et bevis gjelder koden slik den var da beviset ble ført. Én oppgradering senere kan det være verdiløst.
• Hvem skrev spesifikasjonen? Ble reglene skrevet av et uavhengig selskap eller av teamet selv? Et team som beviser sine egne påstander, beviser lett det de allerede trodde.

Den siste linjen er verdt å gjenta, fordi den er kjernen i alt sammen: et bevis er et svar, og svaret er bare så godt som spørsmålet. Når du leser at en protokoll er «formelt verifisert», er det riktige oppfølgingsspørsmålet ikke «av hvem?», men «verifisert for hva?».

Bunnlinjen

Formell verifisering er den sterkeste enkeltmetoden bransjen har for å si noe sikkert om kode. Den fanger klasser av feil, aritmetiske avvik, brutte invarianter, tilstander som «ikke skal kunne skje», som verken menneskelige øyne eller tilfeldig testing pålitelig oppdager. MakerDAO-saken viser at den kan avdekke feil verdt milliarder som har ligget skjult i årevis.

Men Balancer viser den andre halvdelen av sannheten like tydelig: et bevis dekker bare det du spesifiserer, og de dyreste angrepene i 2026 treffer ting ingen spesifikasjon berører, nøkler, mennesker og infrastruktur. Formell verifisering fjerner ikke risiko; den flytter den fra koden til spesifikasjonen, og der forsvinner den ikke, den bytter bare adresse.

For en bruker er den praktiske lærdommen edruelig: «formelt verifisert» er et sterkere merke enn «revidert», men det er fortsatt et merke, ikke en garanti. Spør alltid hva som ble bevist, hvilke antakelser som ble gjort, og hva som ble stående ubevist. I en bransje der selv elleve revisjoner ikke stoppet en fire år gammel avrundingsfeil, er sunn skepsis fortsatt det billigste sikkerhetslaget som finnes.

Ofte stilte spørsmål

Hva er forskjellen på formell verifisering og en vanlig smartkontrakt-audit?

En vanlig audit er erfarne sikkerhetsforskere som leser koden og leter etter feil; de finner det de rekker og kommer på. Formell verifisering oversetter koden og en presis påstand til matematisk logikk og beviser at påstanden holder for alle mulige inndata, ikke bare dem en tester prøver. FV gir sterkere garantier, men bare for de egenskapene som faktisk er skrevet ned.

Betyr «formelt verifisert» at en protokoll er trygg å bruke?

Nei. Det betyr at bestemte egenskaper er bevist for koden slik den var da beviset ble ført. Balancer var formelt verifisert og ble likevel tømt for over 128 millioner dollar i november 2025, fordi egenskapen som ble brutt, avrunding i enkeltbytter, ikke var blant dem som var bevist. Et bevis er bare så godt som spesifikasjonen bak det.

Hvem er de største selskapene innen formell verifisering av krypto?

Certora er det mest kjente, med kunder som Aave, Lido, Uniswap og MakerDAO. Andre aktører er Runtime Verification, som står bak Kontrol og en formell EVM-modell, Veridise, som er spesialisert på zero-knowledge-kretser, og det åpne verktøyet Halmos fra a16z. Solidity-kompilatoren har også en enkel innebygd sjekker, SMTChecker.

Fanger formell verifisering alle typer hackerangrep?

Nei. Formell verifisering gjelder kontraktskoden, ikke verden rundt. Den fanger ikke kompromitterte private nøkler, phishing, manipulerte oracle-priser, MEV eller økonomiske designfeil. I første halvår 2026 kom de største tapene fra kompromitterte lommebøker og phishing, ikke fra kodefeil, og ingen av dem ville blitt stoppet av et kodebevis.

Regulerer Finanstilsynet dem som reviderer smartkontrakter?

Nei. Finanstilsynet fører tilsyn med kryptotjenesteytere (CASP-er) under kryptoeiendelsloven, som innlemmer MiCA gjennom EØS-avtalen, men verken MiCA eller DORA pålegger noen å formelt verifisere kode, og ingen myndighet sertifiserer verifiseringsselskaper. Ansvaret for å vurdere om koden er skikkelig verifisert, ligger hos brukeren selv.

Av Anneke de Vries, sikkerhetsredaktør i HOGE Wire.