{"id":184,"date":"2026-08-06T05:07:28","date_gmt":"2026-08-06T05:07:28","guid":{"rendered":"https:\/\/hoge.gg\/no\/revisjonsselskapene-krypto-hvem-kan-du-stole-pa\/"},"modified":"2026-08-06T05:07:28","modified_gmt":"2026-08-06T05:07:28","slug":"revisjonsselskapene-krypto-hvem-kan-du-stole-pa","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/revisjonsselskapene-krypto-hvem-kan-du-stole-pa\/","title":{"rendered":"Revisjonsselskapene i krypto: hvem kan du stole p\u00e5?"},"content":{"rendered":"

I l\u00f8pet av de f\u00f8rste seks m\u00e5nedene av 2026 registrerte sikkerhetsselskapet Ack3 135 separate utnyttelser av krypteringsprosjekter, med et samlet tap p\u00e5 939,86 millioner dollar, litt over 8,9 milliarder kroner ved en kurs rundt 9,5 kroner per dollar (august 2026). Gjennomsnittstapet per hendelse var p\u00e5 6,96 millioner dollar, rundt 66 millioner kroner. Men det mest oppsiktsvekkende funnet i Ack3-rapporten<\/a> var ikke summen i seg selv. Av pengene som ble stj\u00e5let fra prosjekter som faktisk var sikkerhetsrevidert, forsvant 94,4 prosent gjennom kode eller infrastruktur som revisorene aldri hadde sett p\u00e5. Og av de tjue nyeste revisjonene knyttet til de rammede prosjektene, var sytten av dem minst et halvt \u00e5r gamle da angrepet skjedde.<\/p>

Det er fristende \u00e5 lese en slik statistikk som et argument mot revisjon i seg selv. Det er feil konklusjon. Riktig konklusjon er at ordet \u00abrevidert\u00bb ikke betyr noe presist f\u00f8r du vet hvem som gjorde jobben, hva de faktisk s\u00e5 p\u00e5, hvor ferske funnene er, og hva selskapet har gjort de gangene det bommet. Denne artikkelen er en praktisk guide til \u00e5 vurdere revisjonsselskapene selv, ikke bare stole p\u00e5 en logo nederst p\u00e5 et prosjekts nettside.<\/p>

Hva en revisjon faktisk lover, og ikke lover<\/h2>

En sikkerhetsrevisjon av en smartkontrakt er en tidsavgrenset gjennomgang av kildekoden slik den forel\u00e5 p\u00e5 et bestemt tidspunkt. Et team av ingeni\u00f8rer leser koden manuelt, kj\u00f8rer automatiserte verkt\u00f8y for \u00e5 finne kjente feilm\u00f8nstre, og noen ganger bruker formell verifikasjon for \u00e5 bevise matematisk at bestemte egenskaper alltid holder. Resultatet er en rapport med funn sortert etter alvorlighetsgrad, som regel fra informasjonsfunn og lav risiko til h\u00f8y og kritisk, sammen med anbefalinger til hvordan hvert funn b\u00f8r rettes.<\/p>

Det revisjonen ikke gj\u00f8r, er \u00e5 garantere at koden forblir sikker etter at rapporten er levert. Den dekker som regel ikke kode som legges til etter at gjennomgangen er avsluttet, den dekker sjelden infrastrukturen rundt kontrakten (signeringsn\u00f8kler, oraklenettverk<\/a>, brotjenester, adminfunksjoner), og den sier ingenting om hvorvidt teamet bak prosjektet faktisk har til hensikt \u00e5 forvalte pengene \u00e6rlig. Vi har tidligere g\u00e5tt grundig gjennom n\u00f8yaktig hva en revisjon fanger opp og hva den ikke gj\u00f8r<\/a>, og konklusjonen der er den samme som Ack3-tallene bekrefter: revisjon reduserer risiko, den fjerner den ikke.<\/p>

Metodikken er ogs\u00e5 i rask endring. Trail of Bits har v\u00e6rt \u00e5pne om at de p\u00e5 enkelte oppdrag har g\u00e5tt fra \u00e5 finne rundt 15 feil i uken til rundt 200 i uken etter en omfattende intern satsing p\u00e5 KI-assisterte verkt\u00f8y, der om lag 20 prosent av alle rapporterte feil n\u00e5 f\u00f8rst blir flagget av en modell f\u00f8r et menneske verifiserer funnet. Det er en reell effektivitetsgevinst, men den endrer ikke selve grensen for hva en revisjon dekker: et raskere s\u00f8k gjennom den samme, avgrensede kodebasen finner fortsatt ingenting i infrastrukturen utenfor.<\/p>

Slik vurderer du et revisjonsselskap: seks kriterier<\/h2>

N\u00e5r et prosjekt skryter av at det er \u00abrevidert av [firma]\u00bb, er sp\u00f8rsm\u00e5let du b\u00f8r stille ikke om revisjonen fant sted, men hvor god den faktisk var. Seks kriterier fanger det meste av forskjellen mellom en revisjon som reduserer reell risiko og en som i praksis bare er markedsf\u00f8ring.<\/p>

Det er ogs\u00e5 verdt \u00e5 skille mellom tre beslektede, men ulike tjenester som ofte blandes sammen i dagligtale. En revisjon er en engangs kodegjennomgang f\u00f8r eller kort tid etter lansering. En penetrasjonstest, eller pentest, er en mer offensiv \u00f8velse rettet mot et helt system, ofte inkludert infrastruktur og tilgangskontroll, ikke bare kontraktskoden isolert. Et bug bounty-program er derimot l\u00f8pende og \u00e5pent, og betaler kun for faktiske, bekreftede funn, uten noen avtalt tidsramme for n\u00e5r arbeidet er \u00abferdig\u00bb. De beste sikkerhetsprogrammene i bransjen bruker gjerne alle tre i kombinasjon, ikke som erstatning for hverandre.<\/p>

Kriterium<\/th>Sp\u00f8rsm\u00e5l \u00e5 stille<\/th>R\u00f8dt flagg<\/th><\/tr><\/thead>
Spesialisering<\/td>Har firmaet erfaring med akkurat denne blokkjeden og dette programmeringsspr\u00e5ket?<\/td>Et EVM-spesialisert firma reviderer en kompleks Move- eller Rust-kontrakt uten synlig fartstid der<\/td><\/tr>
Metodikk<\/td>Manuell gjennomgang, automatisert skanning, formell verifikasjon, eller en kombinasjon?<\/td>Rapporten nevner bare automatisert skanning uten menneskelig gjennomgang<\/td><\/tr>
\u00c5penhet<\/td>Er selve rapporten offentlig tilgjengelig, eller m\u00e5 du ta prosjektets ord for det?<\/td>Prosjektet viser frem en logo, men lenker aldri til selve rapporten<\/td><\/tr>
Ferskhet<\/td>N\u00e5r ble koden som faktisk kj\u00f8rer i produksjon sist revidert?<\/td>Revisjonen er eldre enn seks m\u00e5neder, eller dekker en tidligere versjon av kontrakten<\/td><\/tr>
Oppf\u00f8lging<\/td>Publiserer firmaet egne retrospektiv n\u00e5r noe de har sett p\u00e5 likevel blir hacket?<\/td>Total stillhet fra revisoren n\u00e5r et revidert prosjekt mister penger<\/td><\/tr>
Omfang<\/td>Dekker revisjonen hele systemet, eller bare kjernekontraktene?<\/td>Broer, orakler, adminn\u00f8kler og oppgraderingsmekanismer er utenfor omfanget<\/td><\/tr><\/tbody><\/table><\/figure>

Ingen av kriteriene er absolutte i seg selv. Et firma kan score h\u00f8yt p\u00e5 fem av seks og likevel bomme, slik vi skal se flere eksempler p\u00e5 under. Poenget er at de seks samlet gir et langt mer presist bilde enn det ene ordet \u00abrevidert\u00bb alene noensinne kan.<\/p>

De etablerte firmaene: OpenZeppelin, Trail of Bits og Certora<\/h2>

Tre navn dukker opp igjen og igjen i de st\u00f8rste protokollenes revisjonshistorikk. OpenZeppelin bygget kontraktsbiblioteket store deler av dagens DeFi fortsatt bygger videre p\u00e5, en portef\u00f8lje bransjeoversikter ansl\u00e5r har bidratt til \u00e5 sikre verdier for over 50 milliarder dollar totalt, og har egne retrospektiv n\u00e5r noe g\u00e5r galt. Etter Balancer-hacket i november 2025 presiserte selskapet i sin egen rapport at de nye kontraktene som til slutt ble utnyttet \u00abwere added to the repository but were not within the scope of our engagement\u00bb, ti dager etter at deres andre revisjon av protokollen var avsluttet, en presis illustrasjon av hvor bokstavelig ordet \u00abomfang\u00bb faktisk skal tas.<\/p>

Trail of Bits, som vi har skrevet en egen dybdeartikkel om<\/a>, er kjent for \u00e5pen kildekode-verkt\u00f8yene Slither og Echidna, og for at de faktisk publiserer egne retrospektiv om hva de bommet p\u00e5 i Balancer- og Bunni-sakene, ikke bare hva de fant riktig. Vi har ogs\u00e5 en egen guide til hvordan du leser en revisjonsrapport fra dem<\/a> steg for steg, inkludert hvordan \u00ablevel of effort\u00bb m\u00e5lt i personuker er det enkeltpunktet som sier mest om hvor grundig en gjennomgang faktisk var. Certora tar en annen tiln\u00e6rming: formell verifikasjon, der egenskaper bevises matematisk i stedet for \u00e5 letes etter manuelt, en metode som utfyller manuell gjennomgang mer enn den erstatter den.<\/p>

Halborn: fra Miami-oppstart til institusjonell sikkerhet<\/h2>

Halborn er et av firmaene som sjeldnere nevnes i de store DeFi-overskriftene, men som har bygget seg en solid posisjon nettopp fordi virksomheten dekker mer enn ren smartkontrakt-revisjon. Tjenestetilbudet spenner fra manuelle smartkontrakt-revisjoner via offensiv \u00abred team\u00bb-testing av lommeb\u00f8ker og dApper til infrastruktur- og DevOps-sikkerhet og CISO-som-en-tjeneste, p\u00e5 tvers av EVM-kjeder, Solana, Cosmos, Move-\u00f8kosystemet og Algorand. Selskapet ble startet i Miami i 2019 av Steven Walbroehl og Rob Behnke, som drev det uten ekstern finansiering i om lag tre \u00e5r f\u00f8r de hentet 90 millioner dollar, rundt 855 millioner kroner, i en serie A-runde i juli 2022 ledet av Summit Partners.<\/p>

Halborns mest kjente enkeltfunn er trolig det som fikk navnet Rab13s. I mars 2022 fant en av selskapets sikkerhetsingeni\u00f8rer, Hossam Mohamed, en svakhet i Dogecoin-kodebasen under en rutinerevisjon. Svakheten viste seg \u00e5 p\u00e5virke over 280 andre nettverk som delte samme underliggende kodegrunnlag, blant dem Litecoin og Zcash, med eiendeler for over 25 milliarder dollar, godt over 200 milliarder kroner, potensielt utsatt. Funnet inkluderte to feil som kunne krasje noder i verste fall \u00e5pne for et 51 prosent-angrep, samt en tredje, mindre kritisk RPC-relatert svakhet. Halborn ventet med full offentliggj\u00f8ring til mars 2023, etter at de mest sentrale nettverkene hadde rukket \u00e5 patche, men langt fra alle de mindre forkene gjorde det samme.<\/p>

Selskapet fikk ny toppsjef i september 2024, da Jacques Boschung, tidligere fra Kudelski Security, overtok som CEO, mens Behnke gikk over til rollen som styreleder og president. Dreiningen siden har v\u00e6rt tydelig mot institusjonelle kunder: banker, forvaltere og utstedere av tokeniserte eiendeler, med et eget \u00abSecure by Design\u00bb-rammeverk og nye r\u00e5dgivningspartnerskap. Boschung har selv forklart hvorfor<\/a> han mener tidspunktet er riktig: \u00abFinancial services are transforming, and institutions are adopting digital assets at an unprecedented rate. The underlying infrastructure has to keep pace.\u00bb Halborn arrangerte sitt eget ACCESS-toppm\u00f8te p\u00e5 NYSE i februar 2026, nettopp rettet mot dette publikummet av banker og forvaltningsselskaper.<\/p>

CertiK, Zellic og spesialistene for Solana og Move<\/h2>

CertiK er trolig det mest kjente navnet i bransjen for norske lesere, og vi har allerede skrevet en egen artikkel om hvordan Skynet-poengsystemet deres fungerer<\/a>, samt kontroversen rundt Kraken-saken i 2024, der selskapet holdt tilbake omdiskuterte \u00abhvitehatt\u00bb-midler i flere dager. Det som er verdt \u00e5 legge til her, er hvor mye bransjen har spesialisert seg langs blokkjede- og spr\u00e5klinjer i tiden siden.<\/p>

For alt som er skrevet i Rust og Move, spr\u00e5ket Sui og Aptos bruker, er Zellic, OtterSec og MoveBit blitt referansepunktene, omtrent p\u00e5 samme m\u00e5te som Trail of Bits og OpenZeppelin er det for Solidity og EVM-kjeder. Zellic kj\u00f8pte for \u00f8vrig opp konkurranseplattformen Code4rena i 2024, noe vi kommer tilbake til lenger ned. Problemet, som Cetus-hacket under viser med all mulig tydelighet, er at spesialisering p\u00e5 et spr\u00e5k ikke er det samme som ufeilbarlighet i det spr\u00e5ket.<\/p>

Cetus-hacket: tre revisjoner, samme s\u00e5rbarhet<\/h2>

22. mai 2025 mistet<\/a> Sui-baserte DEX-en Cetus rundt 223 millioner dollar, litt over 2,1 milliarder kroner, p\u00e5 under 15 minutter. Angriperen utnyttet en avrundingsfeil i et delt matematikkbibliotek kalt integer-mate, kombinert med en ekstremt smal likviditetsposisjon som fikk en overflow-kontroll til \u00e5 returnere feil verdi. Der offeret trodde det satte inn ett enkelt token for \u00e5 hente ut en liten mengde likviditet, fikk angriperen i stedet tilgang til hele den opprinnelige, store likviditetsmengden bak posisjonen.<\/p>

Det som gj\u00f8r saken til et s\u00e6rlig godt eksempel for denne artikkelen, er ikke tapet i seg selv, men revisjonshistorikken. Cetus hadde blitt gjennomg\u00e5tt av tre forskjellige spesialistfirmaer f\u00f8r hacket. MoveBits revisjon i april 2023 nevnte kontroll av s\u00e5kalte \u00abvalue overflows\u00bb som en del av metodikken, men fanget aldri opp det spesifikke overflow-m\u00f8nsteret som senere ble utnyttet. OtterSecs revisjon i mai 2023 kom faktisk n\u00e6rmest: rapporten pekte p\u00e5 at konvertering av en u256-verdi til u64 i en beslektet funksjon kunne for\u00e5rsake regnefeil dersom verdien oversteg maksgrensen, men funnet ble klassifisert som et forslag til forbedring, ikke som et kritisk avvik som m\u00e5tte rettes f\u00f8r lansering. Zellics revisjon, avsluttet i april 2025, bare en m\u00e5ned f\u00f8r angrepet, fant heller ikke feilen.<\/p>

Tre uavhengige spesialistfirmaer, alle med reell fartstid fra nettopp Move-spr\u00e5ket, gjennomgikk beslektet kode og bommet p\u00e5 den samme underliggende svakheten. Det er trolig det klareste eksempelet i hele denne artikkelen p\u00e5 hvorfor \u00abferskhet\u00bb alene ikke er nok: en revisjon fra bare \u00e9n m\u00e5ned f\u00f8r hacket ga fortsatt falsk trygghet, fordi ingen av de tre noen gang klarte \u00e5 knytte det riktige funnet til riktig alvorlighetsgrad.<\/p>

Konkurranseformatet: Code4rena, Sherlock, Cantina og Immunefi<\/h2>

Ved siden av tradisjonelle revisjonsfirmaer med fast pris, har bransjen utviklet en konkurransemodell der mange uavhengige sikkerhetsforskere, gjerne kalt \u00abwardens\u00bb eller \u00abwatsons\u00bb avhengig av plattform, konkurrerer om \u00e5 finne feil i samme kodebase mot en delt premiepott. Sherlock og det tidligere Code4rena var lenge de to st\u00f8rste plattformene for dette, mens Cantina, Spearbits offentlige gren, tilbyr b\u00e5de \u00e5pne konkurranser og mer kuraterte team gjennom et eget \u00abFellowship\u00bb-program.<\/p>

Mekanikken varierer noe mellom plattformene. P\u00e5 Cantina kj\u00f8rer rene konkurranser typisk over alt fra tre dager til fire uker, med premiepotter fra 25.000 til over 500.000 dollar og alt fra 30 til godt over 500 deltakere, noe som gir bred, motstridende dekning av kodebasen fra sv\u00e6rt mange vinkler samtidig. Sherlock kombinerer konkurranseformatet med en egen forsikringsmekanisme: en del av premiepotten g\u00e5r til en dekningspool som kan utbetale erstatning til et protokollteam dersom en s\u00e5rbarhet som var innenfor konkurransens omfang, likevel blir utnyttet i etterkant, en modell som i praksis setter plattformens egne penger p\u00e5 spill for kvaliteten p\u00e5 funnene.<\/p>

Modellen fikk en solid knekk 13. mai 2026, da Code4rena kunngjorde at plattformen gradvis avvikler driften, og at konkurrenten Immunefi overtar b\u00e5de wardens og p\u00e5g\u00e5ende bug bounty-kunder. Ironisk nok hadde Zellic, revisjonsfirmaet fra forrige avsnitt, kj\u00f8pt opp Code4rena bare to \u00e5r tidligere, i 2024, og p\u00e5 kj\u00f8pstidspunktet ble det uttalt at plattformen ville fortsette \u00e5 drive uavhengig. Nedleggelsen<\/a> kom samtidig som den totale verdien l\u00e5st i DeFi falt kraftig gjennom 2026, og antallet sikkerhetshendelser gikk opp, en kombinasjon som gjorde det stadig vanskeligere \u00e5 holde konkurranseformatet l\u00f8nnsomt for plattformen selv.<\/p>

Immunefi er i dag den klart st\u00f8rste rene bug bounty-plattformen, med enkeltprogrammer p\u00e5 opptil 15 millioner dollar. Selskapets eget forskningsarbeid er for \u00f8vrig et av de sterkeste argumentene for \u00e5 kombinere en tradisjonell revisjon med et l\u00f8pende program: av 593 bug bounty-program<\/a> som har v\u00e6rt aktive i fem \u00e5r eller mer, har nesten 94 prosent avdekket minst \u00e9n bekreftet, betalt kritisk s\u00e5rbarhet i l\u00f8pet av den tiden, en andel som stiger jevnt fra 61 prosent etter det f\u00f8rste \u00e5ret, via 74 prosent etter to \u00e5r og 87 prosent etter tre. Immunefis egen \u00abHack Impact Estimate\u00bb-modell, bygget p\u00e5 data fra januar 2021 til februar 2026, ansl\u00e5r gjennomsnittlig skadeomfang fra et vellykket angrep til rundt 25 millioner dollar, godt over 200 millioner kroner, et tall som gj\u00f8r selv de dyreste bug bounty-utbetalingene rimelige i sammenligning. Poenget er ikke at revisjon er overfl\u00f8dig, men at en engangsgjennomgang og et l\u00f8pende program fanger opp systematisk forskjellige typer feil.<\/p>

Da revisjonen ikke var poenget: KelpDAO og infrastruktursvikten<\/h2>

Ack3-tallene fra innledningen peker p\u00e5 noe TRM Labs ogs\u00e5 har dokumentert for f\u00f8rste halv\u00e5r 2026: angrep mot infrastruktur og n\u00f8kkelh\u00e5ndtering st\u00e5r for et lite mindretall av hendelsene m\u00e5lt i antall, men for godt over halvparten av den samlede verdien som forsvinner. Det tydeligste enkelteksempelet er KelpDAO.<\/p>

18. april 2026 mistet<\/a> den likvide restaking-protokollen rundt 292 millioner dollar, nesten 2,8 milliarder kroner, i det som ved f\u00f8rste \u00f8yekast s\u00e5 ut som et klassisk brokollaps. Root cause var derimot ikke en feil i selve smartkontrakten, men en kompromittert verifiseringsnode i LayerZero-broen, kombinert med DDoS-angrep mot RPC-noder, som til sammen lot angriperen forfalske en tilsynelatende gyldig kryssjede-melding. OpenZeppelins egen etterforskningsrapport oppsummerte det presist: kontraktene fungerte n\u00f8yaktig slik de var skrevet for \u00e5 gj\u00f8re. Hendelsen spredte seg raskt til resten av DeFi ettersom store mengder av de stj\u00e5lne rsETH-tokenene allerede l\u00e5 som sikkerhet i Aave, og trakk med seg over 13 milliarder dollar i samlet likviditet p\u00e5 under 48 timer.<\/p>

Ingen revisjon av selve restaking-kontraktene ville fanget opp dette. Problemet l\u00e5 i konfigurasjonen av en ekstern bro og driften av noder utenfor prosjektets egen kode, n\u00f8yaktig den typen risiko som havner under \u00abomfang\u00bb i sekskriterie-tabellen tidligere i artikkelen.<\/p>

Et annet, uavhengig datasett peker i samme retning. CertiKs eget Hack3d-rammeverk<\/a>, som m\u00e5ler f\u00f8rste halv\u00e5r 2026 separat fra Ack3, kom til 1,31 milliarder dollar tapt fordelt p\u00e5 344 hendelser i samme periode, et annet tall enn Ack3s fordi metodikk og avgrensning er forskjellig, men konklusjonen samsvarer likevel: kompromitterte lommeb\u00f8ker alene sto for 444,5 millioner dollar fordelt p\u00e5 bare 33 hendelser, mens kodes\u00e5rbarheter, kategorien en tradisjonell revisjon faktisk er designet for \u00e5 fange opp, sto for hele 204 hendelser men et langt lavere samlet bel\u00f8p. Jo dyrere hendelsen er, desto mindre sannsynlig er det at en smartkontrakt-revisjon alene noensinne kunne forhindret den. Tabellen under samler KelpDAO sammen med de andre store sakene nevnt s\u00e5 langt, for \u00e5 vise hvor ulikt \u00abrevidert\u00bb kan bety fra sak til sak.<\/p>

Protokoll<\/th>Dato<\/th>Tap (ca.)<\/th>\u00c5rsak<\/th>Revisjonsstatus<\/th><\/tr><\/thead>
Cetus<\/td>22. mai 2025<\/td>223 mill. dollar \/ 2,1 mrd. kr<\/td>Avrundingsfeil i delt matematikkbibliotek<\/td>Revidert tre ganger, alle tre firmaene bommet<\/td><\/tr>
KelpDAO<\/td>18. april 2026<\/td>292 mill. dollar \/ 2,8 mrd. kr<\/td>Kompromittert LayerZero-verifiseringsnode<\/td>Kontraktskoden var korrekt, feilen l\u00e5 utenfor omfanget<\/td><\/tr>
Balancer v2<\/td>3. november 2025<\/td>over 100 mill. dollar \/ over 1 mrd. kr<\/td>Avrundingsfeil i Composable Stable Pools<\/td>Revidert over ti ganger av fire firmaer siden 2021<\/td><\/tr>
GMX V1<\/td>9. juli 2025<\/td>42 mill. dollar \/ 400 mill. kr<\/td>Reentrancy i en funksjon lagt til via en tidligere patch<\/td>Grunnkontrakten revidert, selve patchen aldri uavhengig revidert<\/td><\/tr>
Bunni<\/td>2. september 2025<\/td>8,4 mill. dollar \/ 80 mill. kr<\/td>Avrundingsfeil Trail of Bits selv hadde flagget tidligere<\/td>Revidert, funnet kjent p\u00e5 forh\u00e5nd, fiksen var utilstrekkelig<\/td><\/tr><\/tbody><\/table><\/figure>

Ethereum Foundation vil gj\u00f8re revisjoner billigere<\/h2>

Et av de mer konkrete fors\u00f8kene p\u00e5 \u00e5 l\u00f8se et reelt strukturelt problem, nemlig at ordentlige revisjoner er dyre nok til at mindre team ofte dropper dem helt, kom fra Ethereum Foundation i april 2026. Stiftelsen lanserte et tilskuddsprogram<\/a> p\u00e5 1 million dollar, litt over 9,5 millioner kroner, som gir utviklere tilgang til over 20 revisjonsfirmaer, blant dem Certora, BlockSec, Quantstamp, Spearbit, Sherlock, Zellic, Hacken, Cyfrin og Dedaub, gjennom plattformen Areta.<\/p>

Utvalgte team kan f\u00e5 dekket opptil 30 prosent av revisjonskostnaden, men f\u00f8rst etter at funnene faktisk er rettet, ikke bare etter at rapporten er levert, en detalj som knytter finansieringen direkte til oppf\u00f8lging fremfor til selve gjennomgangen. Chainlink og teamet bak Ethereum-klienten Nethermind bidrar til \u00e5 vurdere hvilke prosjekter som slipper til i de m\u00e5nedlige kohortene. Programmet er lite i kronebel\u00f8p sammenlignet med de virkelig store hendelsene i denne artikkelen, men det sier noe om hvor bransjen selv mener svakheten ligger: ikke prim\u00e6rt i mangel p\u00e5 dyktige revisorer, men i at de beste revisjonene ofte er for dyre for nettopp de minste og mest s\u00e5rbare prosjektene.<\/p>

Slik sjekker du en revisjonsrapport selv<\/h2>

Du trenger ikke ta et prosjekts ord for at revisjonen faktisk sier det de hevder. Solodit, som ble kj\u00f8pt opp av sikkerhetsselskapet Cyfrin tidlig i 2024, samler funn fra de aller fleste store revisjonsfirmaene og konkurranseplattformene i \u00e9n s\u00f8kbar database, og lar deg lese den faktiske teksten i tidligere funn, ikke bare overskriften. De fleste seri\u00f8se firmaer, deriblant Trail of Bits<\/a>, publiserer i tillegg egne arkiv med hundrevis av offentlige rapporter direkte p\u00e5 egne nettsider.<\/p>

Utover selve rapportarkivene finnes DeFiSafety, som gir prosjekter en uavhengig prosesskvalitet-score fra 0 til 100 basert p\u00e5 dokumentasjon, testing, tilgangskontroll og driftsrutiner, ikke bare selve kodegjennomgangen. Og for den som vil helt ned i detaljene: bytekoden som faktisk kj\u00f8rer p\u00e5 kjeden kan sammenlignes direkte mot commit-hashen som er nevnt i revisjonsrapporten, via en vanlig block explorer, en \u00f8velse som raskt avsl\u00f8rer om koden som ble revidert faktisk er den samme koden som er i produksjon i dag.<\/p>

N\u00e5r du faktisk \u00e5pner en rapport, se spesielt etter to ting utover selve funnlisten. Det f\u00f8rste er hvordan firmaet vekter alvorlighetsgrad mot sannsynlighet, siden et funn med middels alvorlighetsgrad men h\u00f8y sannsynlighet for \u00e5 faktisk bli utnyttet ofte er farligere i praksis enn et kritisk funn som krever en usannsynlig kombinasjon av forhold for \u00e5 ramme noen. Det andre er oppf\u00f8lgingsstatusen p\u00e5 hvert enkelt funn: seri\u00f8se firmaer skiller tydelig mellom \u00abFixed\u00bb (rettet og bekreftet i en navngitt versjon) og \u00abAcknowledged\u00bb eller \u00abrisk accepted\u00bb (prosjektet er informert, men har bevisst valgt \u00e5 ikke rette det f\u00f8r lansering). Et prosjekt som viser frem en rapport uten samtidig \u00e5 vise den oppdaterte statusen p\u00e5 hvert funn, viser deg bare halve bildet.<\/p>

Hva det faktisk koster \u00e5 bli revidert<\/h2>

Prisbildet i bransjen har blitt tydeligere etter hvert som flere firmaer publiserer egne referansepunkter. For enkle, standardiserte kontrakter ligger prisen typisk mellom 8.000 og 25.000 dollar, om lag 76.000 til 238.000 kroner. Standard DeFi-protokoller havner gjerne mellom 25.000 og 80.000 dollar, 238.000 til 760.000 kroner, mens komplekse systemer med mye egenutviklet logikk fra de aller mest etablerte firmaene koster fra 80.000 dollar og oppover, i enkelte tilfeller godt over tre millioner kroner for de aller st\u00f8rste engasjementene. Konkurranseformatet har en annen prisstruktur, gjerne en fast premiepott p\u00e5 mellom 20.000 og over 200.000 dollar for hele konkurransen samlet.<\/p>

Det beste eksempelet p\u00e5 hva et virkelig stort budsjett faktisk kj\u00f8per, er Aaves eget \u00abSecurity by Design\u00bb-program for versjon 4, gjennomf\u00f8rt fra mars 2025 til februar 2026. Aave Labs satte av 1,5 millioner dollar, i overkant av 14 millioner kroner, og brukte tre firmaer parallelt, Trail of Bits, ChainSecurity og Blackthorn, til sammen over 345 dagsverk med gjennomgang, en egen suite med invariant-tester og en seks uker lang offentlig kodekonkurranse p\u00e5 toppen. Resultatet, if\u00f8lge Aave Labs egen gjennomgang<\/a>: ingen funn av kritisk eller h\u00f8y alvorlighetsgrad. Det er ingen garanti for at ingenting noensinne vil g\u00e5 galt i fremtiden, men det illustrerer godt hvor mye et budsjett i den \u00f8vre delen av skalaen faktisk kj\u00f8per, sammenlignet med et minimumsoppdrag p\u00e5 noen titalls tusen dollar.<\/p>

Regelverket: hva Finanstilsynet faktisk krever<\/h2>

Her kommer det som overrasker mange norske lesere: verken norsk eller europeisk regelverk krever at et kryptoprosjekt blir sikkerhetsrevidert i det hele tatt. Kryptoeiendelsloven, som gjennomf\u00f8rer MiCA-forordningen i Norge etter at den tr\u00e5dte i kraft 1. juli 2025 gjennom E\u00d8S-avtalen, regulerer tilbydere av kryptoeiendelstjenester, s\u00e5kalte CASP-er<\/a>: b\u00f8rser, oppbevaringsl\u00f8sninger og lignende sentraliserte akt\u00f8rer. Finanstilsynet vurderer egnetheten til ledelsen, behandler s\u00f8knader om tillatelse og f\u00f8rer l\u00f8pende tilsyn med etterlevelse. Ingenting i dette regelverket stiller krav til at den underliggende smartkontrakt-koden skal revideres av noen bestemt type firma, og det finnes verken en norsk eller en europeisk godkjenningsordning for revisorer av smartkontrakter, i sterk kontrast til den strenge, lovregulerte godkjenningen som gjelder for revisorer av ordin\u00e6re regnskaper.<\/p>

DORA-forordningen (Digital Operational Resilience Act), som har v\u00e6rt i kraft for CASP-er siden 17. januar 2025, kommer n\u00e6rmest et krav om ekstern gjennomgang, men ogs\u00e5 den er myntet p\u00e5 operasjonell IT-motstandsdyktighet og hendelsesh\u00e5ndtering hos den sentraliserte tilbyderen, ikke p\u00e5 revisjon av selve smartkontrakt-koden en protokoll bygger p\u00e5. En kryptob\u00f8rs regulert av Finanstilsynet m\u00e5 dermed dokumentere robusthet i egne IT-systemer, mens den underliggende DeFi-protokollen b\u00f8rsen kanskje lister et token fra, ikke er omfattet av noen tilsvarende plikt overhodet.<\/p>

Fullt ut desentraliserte protokoller uten noen sentral tilbyder faller for \u00f8vrig helt utenfor MiCA-regelverket. Det betyr at dersom en slik protokoll blir hacket, uansett hvor mange ganger den er revidert tidligere, har brukerne ingen klageinstans hos Finanstilsynet \u00e5 henvende seg til. Omd\u00f8mme, ikke regelverk, er dermed det som i praksis holder revisjonsbransjen ansvarlig. Suhail Kakar<\/a>, som jobber med utviklerrelasjoner hos TAC Blockchain, formulerte problemet presist etter Balancer-hacket i november 2025: \u00abBalancer went through 10+ audits. The vault was audited three separate times by different firms still got hacked for $110M. This space needs to accept that \u2018audited by X\u2019 means almost nothing. Code is hard, DeFi is harder.\u00bb<\/p>

David Schwed<\/a>, driftssjef i sikkerhetsselskapet SVRN og grunnlegger av masterprogrammet i cybersikkerhet ved Yeshiva University, pekte i juni 2026 p\u00e5 en beslektet, nyere fare: at kunstig intelligens gj\u00f8r det fristende \u00e5 behandle en automatisert kodegjennomgang som en fullverdig erstatning for et menneskelig sikkerhetsprogram. \u00ab\u2018Claude, audit my smart contract, make no mistakes\u2019 is not a security program,\u00bb sa han til CoinDesk. Poenget hans overlapper med hovedbudskapet i denne artikkelen: verkt\u00f8yet, enten det er en KI-modell eller et etablert revisjonsfirma, er aldri bedre enn forst\u00e5elsen til den som tolker resultatet.<\/p>

Tre ting norske lesere b\u00f8r ta med seg<\/h2>

Oppsummert handler det meste av denne artikkelen om tre praktiske vaner.<\/p>

  • Sp\u00f8r alltid om lenken til selve rapporten, ikke bare navnet p\u00e5 revisjonsfirmaet. En logo uten en fungerende lenke til en publisert rapport er verdt sv\u00e6rt lite.<\/li>
  • Sjekk datoen og omfanget n\u00f8ye. Kode endrer seg, og en revisjon fra for et \u00e5r siden sier lite om koden som faktisk kj\u00f8rer i dag, s\u00e6rlig etter en st\u00f8rre oppgradering eller ny funksjonalitet.<\/li>
  • Se etter om prosjektet kombinerer en tradisjonell revisjon med et l\u00f8pende bug bounty-program, gjerne gjennom Immunefi eller Cantina. Gitt at nesten 94 prosent av langvarige bug bounty-program til slutt finner en kritisk feil, er kombinasjonen systematisk sterkere enn en engangsrevisjon alene.<\/li><\/ul>

    Og til slutt, kanskje det viktigste: husk at selv de beste revisorene i verden, med de beste verkt\u00f8yene og mest erfarne folkene, har bommet p\u00e5 ekte, utnyttbare feil i kode som allerede l\u00e5 i produksjon. Det er ikke et argument mot \u00e5 bruke dem, revidert kode er fortsatt langt tryggere i snitt enn urevidert kode. Det er derimot et argument for \u00e5 aldri behandle ordet \u00abrevidert\u00bb som et synonym for \u00abtrygt\u00bb.<\/p>

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

    Hva er et revisjonsselskap i krypto?<\/h3>

    Et revisjonsselskap i krypto er et team av sikkerhetsingeni\u00f8rer som gjennomg\u00e5r kildekoden til en smartkontrakt for \u00e5 finne s\u00e5rbarheter, enten f\u00f8r den settes i produksjon eller etter at den allerede kj\u00f8rer. De st\u00f8rste, som OpenZeppelin, Trail of Bits, Halborn og CertiK, kombinerer manuell kodelesing med automatiserte verkt\u00f8y og formell verifikasjon, og leverer en rapport der funnene er sortert etter alvorlighetsgrad. Modellen ligner regnskapsrevisjon i navn, men det finnes ingen tilsvarende offentlig godkjenningsordning for smartkontrakt-revisorer noe sted i verden.<\/p>

    Betyr en revisjon at en smart kontrakt er trygg?<\/h3>

    Nei. En revisjon reduserer risikoen for kjente feiltyper i koden slik den forel\u00e5 p\u00e5 revisjonstidspunktet, men den garanterer ingenting om fremtidig kode, om infrastruktur som broer og orakler, eller om hvorvidt teamet bak prosjektet faktisk har \u00e6rlige hensikter. If\u00f8lge sikkerhetsselskapet Ack3 forsvant 94,4 prosent av pengene stj\u00e5let fra reviderte prosjekter i f\u00f8rste halv\u00e5r 2026 gjennom kode eller infrastruktur revisorene aldri hadde sett p\u00e5, og protokoller som Balancer og Cetus ble hacket etter henholdsvis over ti og tre separate revisjoner. Selv de mest erfarne revisjonsfirmaene i verden har g\u00e5tt glipp av reelle, utnyttbare feil i kode de selv har gjennomg\u00e5tt, s\u00e5 en revisjon b\u00f8r leses som risikoreduksjon, ikke som en garanti.<\/p>

    Hvilket revisjonsselskap er best for smart-kontrakt-revisjon?<\/h3>

    Det finnes ikke noe entydig svar, fordi det beste valget avhenger sterkt av hvilken blokkjede og hvilket programmeringsspr\u00e5k prosjektet er skrevet i. OpenZeppelin og Trail of Bits har lengst merittliste p\u00e5 Solidity og EVM-kjeder, Zellic, OtterSec og MoveBit er de n\u00e6rmeste referansene for Rust og Move p\u00e5 Sui og Aptos, mens Halborn og CertiK dekker et bredere spekter som inkluderer infrastruktur, pentesting og institusjonelle kunder. Se etter dokumentert spesialisering p\u00e5 riktig spr\u00e5k og kjede, fremfor \u00e5 velge bare basert p\u00e5 merkenavn.<\/p>

    Hva koster en smart-kontrakt-revisjon?<\/h3>

    Prisen varierer sterkt med kompleksitet. Enkle, standardiserte kontrakter koster typisk mellom 8.000 og 25.000 dollar, om lag 76.000 til 238.000 kroner. Standard DeFi-protokoller havner gjerne mellom 25.000 og 80.000 dollar, 238.000 til 760.000 kroner, mens komplekse systemer fra de mest etablerte firmaene starter fra 80.000 dollar og kan koste flere millioner kroner for de aller st\u00f8rste engasjementene, slik som Aaves eget 1,5 millioner dollar-program for versjon 4.<\/p>

    Krever Finanstilsynet at kryptoprosjekter blir revidert?<\/h3>

    Nei. Verken kryptoeiendelsloven, som gjennomf\u00f8rer MiCA i Norge, eller noe annet europeisk regelverk krever sikkerhetsrevisjon av smartkontrakt-kode. Finanstilsynet f\u00f8rer tilsyn med tilbydere av kryptoeiendelstjenester (CASP), alts\u00e5 b\u00f8rser og oppbevaringsl\u00f8sninger, ikke med koden til desentraliserte protokoller. Fullt desentraliserte prosjekter faller helt utenfor MiCA-regelverket, og det finnes ingen norsk eller europeisk godkjenningsordning for revisorer av smartkontrakter.<\/p>