h hoge.gg
Subscribe
BTC$67,432.18+2.34%ETH$3,521.44+1.08%SOL$178.62-0.62%BNB$612.30+0.41%XRP$0.6234-0.18%ADA$0.4521+3.12%DOGE$0.1623+1.86%AVAX$38.71-1.24%LINK$17.84+0.92%HOGE$0.00004120+4.21%
BTC$67,432.18+2.34%ETH$3,521.44+1.08%SOL$178.62-0.62%BNB$612.30+0.41%XRP$0.6234-0.18%ADA$0.4521+3.12%DOGE$0.1623+1.86%AVAX$38.71-1.24%LINK$17.84+0.92%HOGE$0.00004120+4.21%
● Security & Exploits

Falske kryptoaudits i 2026: stempelet du ikke kan stole på

«Revidert» er blitt kryptos mest forfalskede tillitssignal. Slik lyver et audit-stempel på tre måter, og slik skiller du en ekte revisjon fra rent teater.

Du gjorde alt riktig. Du fant prosjektet, du leste dokumentasjonen, og øverst på nettsiden så du det: et lite skjold med teksten «Audited by» og logoen til et kjent sikkerhetsselskap. Du pustet lettet ut og satte inn pengene. Problemet er at nettopp det skjoldet var det svindleren regnet med at du skulle se.

I 2026 er «revidert» samtidig det mest ettertraktede og det mest misbrukte tillitssignalet i krypto. Chainalysis anslo at svindel og bedrageri tappet kryptobrukere for rundt 17 milliarder dollar (i overkant av 158 milliarder kroner) i 2025, og at etterligningssvindel, der noen utgir seg for å være en betrodd aktør, vokste med hele 1 400 prosent på ett år, samtidig som gjennomsnittsbeløpet per svindel steg 253 prosent til 2 764 dollar. Et forfalsket revisjonsstempel er akkurat dette: etterligning. Det låner tilliten til et selskap som aldri har sett koden. Du kan lese Chainalysis sin gjennomgang av svindeltallene for 2025 for hele bildet.

Denne artikkelen handler ikke om hvilket revisjonsselskap som er best. Den handler om noe mer grunnleggende: hvordan du selv kan lese, verifisere og mistro et «audited»-stempel. For et revisjonsstempel er starten på en sjekk, aldri konklusjonen, og et falskt stempel er ofte første ledd i et rug pull der du ender opp som utgangslikviditeten. Vi går gjennom de tre måtene «revidert» lyver på, en konkret oppskrift for å skille en ekte revisjon fra teater, og den ubehagelige norske fotnoten: ingen myndighet godkjenner dem som godkjenner koden.

Hva «audited» faktisk betyr, og ikke betyr

En sikkerhetsrevisjon (audit) er en gjennomgang av en bestemt versjon av bestemt kode, gjort av mennesker med hjelp av verktøy, på et bestemt tidspunkt. Resultatet er en rapport der funn rangeres etter alvorlighetsgrad, og der prosjektet selv velger om det vil rette dem eller ikke. En revisjon er ikke en garanti, ikke en forsikring, ikke et godkjentstempel, og slett ikke en bekreftelse på at teamet bak er ærlig. Den sier én ting: på den datoen, for den koden, i det omfanget, fant disse menneskene disse svakhetene.

Selv bransjen selv formulerer det slik. Hugh Brooks, sikkerhetssjef i CertiK, har sagt at «en revisjon er ikke et godkjentstempel eller en bestått eller ikke bestått, den er en objektiv gjennomgang av et prosjekts kode». Sitatet falt i forbindelse med et prosjekt som ble drenert kort tid etter å ha blitt revidert, og det er verdt å feste seg ved: en revisjon rangerer risiko, den fjerner den ikke.

Det er også verdt å skille en revisjon fra de andre merkene et prosjekt kan vise fram. Et KYC-stempel betyr at teamet har vist legitimasjon til en tredjepart. Et «verifisert»-merke på en børs betyr at tokenet er listet. Ingen av dem sier noe om koden er trygg. En revisjon er det eneste av disse som faktisk handler om koden, og selv da bare om en avgrenset del av den, på et avgrenset tidspunkt. Å blande disse merkene sammen er akkurat den forvirringen svindlere lever av.

Skjoldet på nettsiden komprimerer hele denne nyansen til ett ord. Og ordet holder ikke. Da DeFi-protokollen Balancer ble tappet for over 100 millioner dollar høsten 2025, hadde koden vært revidert mer enn ti ganger av flere selskaper. Utvikleren Suhail Kakar, som leder utviklerrelasjoner i TAC-blokkjeden, oppsummerte reaksjonen i bransjen skarpt: «Dette feltet må innse at «revidert av X» betyr nesten ingenting. Kode er vanskelig, DeFi er enda vanskeligere.» Du finner sitatet og hele saken i Cointelegraphs dekning av Balancer-exploiten. Poenget er ikke at revisjoner er verdiløse. Poenget er at rapporten er produktet, ikke skjoldet. Finner du ikke rapporten, vet du ikke hva som ble revidert.

Hvorfor «audited» er blitt selve agnet

En moderne svindel settes sammen på en helg: en forseggjort nettside, en Telegram-gruppe med tusenvis av «medlemmer», en nedtellingsklokke, og et audit-skjold. Skjoldet er det billigste elementet å forfalske og det dyreste i troverdighet. Å kopiere en logo koster ingenting, og å generere en overbevisende PDF tar minutter. Med generativ AI er både språket, formateringen og de oppdiktede funnene blitt gratis og nærmest feilfrie. Chainalysis fant at AI-drevne svindeloperasjoner var omtrent 4,5 ganger mer lønnsomme enn tradisjonelle, nettopp fordi de masseproduserer det som før krevde håndarbeid. Et forfalsket revisjonsstempel er den perfekte anvendelsen: lav kostnad, høy tillitsverdi, og et offer som er trent opp til å lete etter akkurat det symbolet.

Grunnen til at nettopp revisjonsstempelet forfalskes så ofte, er at det virker. En bruker som har lært at «se etter en audit» er god praksis, senker skuldrene i det sekundet skjoldet dukker opp, og slutter å stille spørsmål. Svindleren trenger ikke å knekke koden; han trenger bare å knekke tilliten din, og tillit er den mest omsettelige varen i krypto. Det er også derfor etterligning, det å utgi seg for en betrodd aktør, vokste 1 400 prosent i 2025 og gikk forbi rene cyberangrep som den største trusselen mot vanlige brukere. Stempelet er ikke pynt på svindelen. I mange tilfeller er stempelet svindelen.

Tre måter «revidert» lyver på

For å komme forbi skjoldet lønner det seg å tenke i tre feilmoduser. Et audit-stempel kan svikte deg på tre helt ulike måter, og de krever tre helt ulike sjekker. Den første er den enkleste å forstå, men vanskeligst å oppdage i farten. Den siste er den mest ærlige, men også den som tapper mest penger.

FeilmodusHva som er galtTypisk tegnEksempel
Det rene falskeIngen revisjon har skjeddLogo uten lenke til rapport; PDF kun på prosjektets eget domeneForfalskede CertiK-stempler; kapret CertiK-konto
Det ekte, men villedendeRevisjonen dekker ikke koden som kjørerFeil versjon, kontraktadresse eller omfang; oppgraderbar proxySwaprum (byttet ut den reviderte kontrakten)
Det ekte, men utilstrekkeligeGod revisjon, men angrepet gikk utenom kodenTap via nøkler, infrastruktur eller styringKelp DAO; Cetus; Balancer

Resten av artikkelen tar for seg én feilmodus av gangen, med et virkelig eksempel til hver, før vi bygger sjekklisten som fanger alle tre.

Feilmodus 1: det rene falske

Den mest direkte løgnen er at det aldri fant sted noen revisjon. Svindleren kopierer en logo, lager en PDF som ser offisiell ut, eller legger ut et skjermbilde av en «rapport» som ikke finnes noe annet sted enn på prosjektets egen nettside. En logo er tross alt bare et bilde. Hvem som helst kan lime det inn, og et bilde beviser ingenting.

Selskapene som blir kopiert, kjenner problemet godt. CertiK driver en egen side som advarer mot nettopp dette: svindlere legger selskapets logo på falske nettsteder, forfalsker revisjoner selskapet aldri har utført, og oppretter falske profiler på plattformer som LinkedIn for å megle «revisjonsavtaler» og lokke ofre. CertiK viser blant annet til et exit-scam der bakmennene utga seg for å være revidert av selskapet, og som ifølge CertiK kostet ofrene rundt 300 000 dollar (nær 2,8 millioner kroner). Rådet selskapet gir, er å slå opp prosjektet i deres eget register, Skynet, i stedet for å stole på et skjold. Advarslene ligger i CertiKs gjennomgang av misbruk av merkevaren.

En vanlig variant er stempelet fra et revisjonsselskap ingen har hørt om. Svindleren oppretter et helt fiktivt «sikkerhetsselskap» med egen nettside, og lar det «revidere» sitt eget prosjekt. Alt ser legitimt ut, helt til du prøver å finne selskapet utenfor prosjektets egne kanaler og oppdager at det ikke har noen historikk, ingen andre kunder og ingen spor før for noen uker siden. Et audit-stempel er aldri sterkere enn revisoren bak, og en revisor du ikke kan verifisere uavhengig, er verdiløs som garantist.

Ironien er at selv revisorens eget tillitssignal kan kapres. I januar 2024 ble CertiKs gull-verifiserte konto på X kapret via en kapret konto knyttet til et kjent medium. Fra den offisielle kontoen, med hundretusener av følgere, gikk det ut et falskt varsel om en re-entrancy-sårbarhet i Uniswap V3 sin Router-kontrakt, med oppfordring om å «tilbakekalle» godkjenninger via en lenke som i virkeligheten ledet til et falskt Revoke.cash-nettsted bygget for å tømme lommebøker. Lenken ble fjernet etter kort tid, og Revoke.cash advarte nesten umiddelbart, men episoden kom bare et par dager etter at CertiK hadde publisert sin egen hackrapport for 2023. BleepingComputer dokumenterte kapringen. Lærdommen er nøktern: hvis til og med sikkerhetsselskapets egen kanal kan forfalskes, kan et skjold på en tilfeldig nettside det åpenbart også.

Feilmodus 2: det ekte, men villedende

Den mest lumske feilmodusen er ikke en løgn i det hele tatt. Revisjonen er ekte. Rapporten finnes, selskapet er reelt, og funnene er skikkelig arbeid. Problemet er at rapporten peker på noe annet enn koden du faktisk bruker. Stempelet er sant, men villedende.

Det tydeligste eksempelet er Swaprum, en desentralisert børs på Arbitrum. Prosjektet var genuint revidert av CertiK. Den 18. mai 2023 gjorde utvikleren likevel noe rapporten ikke kunne fange: i stedet for å manipulere den reviderte MasterChef-kontrakten byttet de den rett og slett ut med en urevidert, ondsinnet versjon, og tappet så likviditetspoolene for rundt 1 628 ETH (den gang verdt om lag 2,95 millioner dollar, eller nær 27 millioner kroner). Midlene ble hvitvasket gjennom Tornado Cash. Revisjonen var ekte; koden som kjørte da pengene forsvant, var det ikke. CertiK beskrev selv mekanismen i sin analyse av Swaprum-svindelen, og Cointelegraph dekket tappingen mens den pågikk.

Det som gjør dette mulig, er oppgraderbare kontrakter og proxy-mønstre. Når en kontrakt kan oppgraderes, kan den reviderte implementasjonen skiftes ut i etterkant av den som holder admin-nøkkelen. «Revidert i dag» kan dermed bli «ikke revidert i morgen». Men villedende stempler har flere former enn ren utbytting. Revisjonen kan dekke en perifer kontrakt, ikke kjernen. Den kan gjelde en gammel versjon fra før en større ny utrulling. Funnene kan være merket «erkjent» i stedet for «rettet», altså sett, men ikke fikset. Eller omfanget kan uttrykkelig unnta nettopp den modulen som senere blir angrepet.

Konklusjonen er alltid den samme: du må matche rapporten mot virkeligheten. Navn, nettverk, kontraktadresse, kodeversjon, omfang og dato må stemme med prosjektet du ser på. Gjør de ikke det, er stempelet dekorasjon. Og skjer skaden først, er veien tilbake kort og bratt; som vi har beskrevet i gjennomgangen av hvor lite som faktisk lar seg hente tilbake etter et rug pull, er tapte midler oftest tapt for godt.

Det gode er at denne feilmodusen er synlig hvis du ser etter. På en blokkutforsker kan du se når en kontrakt sist ble utrullet eller oppgradert. Ligger den datoen etter revisjonsrapportens dato, er det et varsel om at koden kan ha endret seg siden revisoren så på den. Kombinerer du det med å sjekke om kontrakten er en oppgraderbar proxy, ser du raskt om «revidert» fortsatt gjelder, eller om det bare gjaldt en gang i fortiden.

Feilmodus 3: det ekte, men utilstrekkelige

Den siste feilmodusen er den ærligste, og på mange måter den mest lærerike. Revisjonen er god. Den dekker riktig kode. Funnene ble rettet. Og prosjektet blir hacket likevel, fordi pengene aldri forlot systemet gjennom koden.

Det klareste eksempelet er Kelp DAO, som mistet rundt 292 millioner dollar (nær 2,7 milliarder kroner) i april 2026. OpenZeppelins obduksjon fikk tittelen «$292 Million Lost, Zero Bugs Found», altså 292 millioner tapt, null feil funnet. Konklusjonen var at «kontraktene gjorde nøyaktig det de var skrevet til å gjøre»: bruddet lå i infrastruktur og konfigurasjon, ikke i en kontraktfeil. Hele resonnementet ligger i OpenZeppelins gjennomgang av Kelp DAO-hacket. En perfekt kodrevisjon var her helt uten betydning, fordi angrepet aldri traff koden.

Og selv når feilen faktisk ligger i koden, er en revisjon ingen garanti. Da Cetus på Sui ble tappet for rundt 223 millioner dollar i mai 2025, hadde den sårbare funksjonen passert gjennom hele tre revisjoner, fra OtterSec, MoveBit og Zellic, uten at noen av dem klassifiserte problemet som kritisk. Halborn har lagt ut en teknisk gjennomgang av Cetus-hacket. Tre revisjoner, én oversett feil: «i omfang» er heller ingen forsikring.

En egen kategori er økonomiske angrep og designfeil. Et flash-loan-angrep som manipulerer prisen et orakel rapporterer, eller en styringsavstemning som tømmer statskassen helt etter reglene, bryter ingen kodelinje; det utnytter forutsetningene systemet er bygget på. En revisor kan påpeke at et orakel er en risiko, men kan sjelden bevise at hele den økonomiske modellen holder under press. Nettopp derfor står orakelmanipulasjon og designsvakheter for noen av de største tapene, også i prosjekter med plettfrie revisjonsrapporter.

Ronghui Gu, medgründer i CertiK, formulerer kjernen presist. Slik han oppsummerte det til Forbes, kan «et prosjekt bestå en feilfri kodegjennomgang og likevel tape millioner på grunn av en kompromittert admin-nøkkel», og både Kelp DAO og Drift var etter hans vurdering «svikt i drifts- og infrastruktursikkerhet, ikke kodesårbarheter i tradisjonell forstand». Vurderingen står i Forbes sin gjennomgang av hacktallene for 2026. Det finnes en lang liste over hva en kodrevisjon strukturelt ikke ser på:

  • Private nøkler og hvordan de signeres og oppbevares
  • Konfigurasjon av multisig og styring (governance)
  • Infrastruktur utenfor kjeden: RPC-noder, frontend, byggekjeder
  • Økonomiske antakelser, design og orakler
  • Tredjepartsintegrasjoner prosjektet ikke kontrollerer selv
  • Kodeendringer gjort etter at revisjonen ble avsluttet
  • Det menneskelige laget: social engineering og infiltrasjon

Nettopp det menneskelige laget er blitt den farligste vektoren. Nordkoreanske operatører har gjentatte ganger tatt seg inn gjennom folk snarere enn kode, noe vi har beskrevet i saken om falske jobber og ekte tyveri av privatnøkler. En revisor leser Solidity, ikke CV-en til den nyansatte «utvikleren».

Tapsbildet: hva revisjoner faktisk dekker

Hvorfor er dette skillet så viktig? Fordi tallene viser at «revidert» og «trygg» rett og slett ikke er det samme. CertiKs Hack3d-rapport for første halvår 2026 registrerte over 1,31 milliarder dollar tapt fordelt på 344 hendelser. Fordelingen mellom angrepsvektorene forteller hele historien.

AngrepsvektorTap i H1 2026Antall hendelserDekkes av en kodrevisjon?
Lommebok- og nøkkelkompromiss444,5 mill. dollar33Nei (nøkler ligger utenfor omfanget)
Phishing og social engineering366,3 mill. dollar63Nei (rammer mennesket, ikke koden)
Kodesårbarhet151,6 mill. dollar204Ja (dette er kjernen i en revisjon)
Totalt (alle vektorer)1,31 mrd. dollar344Delvis

Les tabellen sakte. Kodesårbarheter er den vanligste vektoren målt i antall hendelser, hele 204, men den billigste målt i tap. Den dyreste vektoren, lommebok- og nøkkelkompromiss, sto for 444,5 millioner dollar (rundt 4,1 milliarder kroner) på bare 33 hendelser, og phishing for 366,3 millioner dollar, der fire enkelthendelser alene utgjorde omtrent 85 prosent av phishing-tapene. Av de totale tapene ble om lag 115 millioner dollar frosset eller returnert, slik at det justerte tallet lander rundt 1,2 milliarder dollar. Tallene ligger i CertiKs Hack3d-rapport for første halvår 2026.

Legg merke til hvor lite som ble hentet tilbake: rundt 115 millioner dollar frosset eller returnert av over 1,3 milliarder tapt. Det er den virkelige kostnaden ved en falsk trygghetsfølelse. Et skjold som får deg til å hoppe over de andre sjekkene, flytter deg ikke bare inn i et risikabelt prosjekt, det flytter deg inn i en verden der pengene sjelden kommer tilbake når noe går galt.

Konklusjonen er ubehagelig, men klar: en kodrevisjon adresserer den hyppigste vektoren, men ikke den dyreste. Pengene forlater systemet gjennom nøkler og mennesker, og ingen gjennomgang av Solidity rører ved det. Vi så det samme mønsteret i analysen av bro-hacket der 4 000 bitcoin forlot Liquid: reviderte systemer, angrep som gikk utenom selve koden.

Slik verifiserer du at en audit er ekte

Nok diagnose. Her er den praktiske delen. Å skille en ekte revisjon fra teater tar noen minutter, og det handler nesten alltid om å nekte å stoppe ved skjoldet. Gå gjennom disse stegene før du stoler på et «audited»-merke:

  • Ikke stol på skjoldet, finn rapporten. Et ekte stempel lenker til en lesbar rapport. Gjør det ikke det, er det allerede et rødflagg.
  • Gå til revisorens egen kanal. Åpne rapporten på revisjonsselskapets eget nettsted, register eller GitHub. En PDF som bare finnes på prosjektets eget domene, kan være hva som helst. CertiKs eget råd er å slå opp prosjektet i Skynet.
  • Sammenlign seks ting. Prosjektnavn, nettverk eller kjede, kontraktadresse, kodeversjon eller commit, omfang (scope) og dato må stemme med prosjektet du vurderer.
  • Les funnene, ikke bare karakteren. Se på alvorlighetsgraden, og sjekk om de kritiske og høye funnene er merket «rettet» eller bare «erkjent».
  • Sjekk datoen mot oppgraderinger. Er revisjonen eldre enn siste store utrulling, dekker den kanskje ikke koden som kjører nå.

Å lese noen få ekte rapporter er den beste treningen som finnes. Når du har sett hvordan en reell revisjon ser ut, med navngitt omfang, commit-referanser og et statusfelt for hvert funn, blir de falske og de villedende nesten pinlig åpenbare.

Et konkret eksempel: du ser «Audited by CertiK» på en ny DeFi-app. I stedet for å stole på merket, søker du opp prosjektet på Skynet. Finnes det ikke der, har alarmen allerede gått. Finnes det, åpner du rapporten og sjekker at kontraktadressen i rapporten er den samme som appen faktisk bruker, at nettverket stemmer (Ethereum, Arbitrum, Base), og at datoen ligger etter siste store oppgradering. Tar dette fem minutter? Ja. Er det billigere enn å bli utgangslikviditet? Utvilsomt.

Slik sjekker du at koden på kjeden er den som ble revidert

Steget de fleste hopper over, er å bekrefte at koden som faktisk kjører, er den koden rapporten omtaler. Det var her Swaprum-ofrene ble tatt. En god revisjonsrapport navngir en commit-hash eller en kontraktadresse. Den referansen kan du bruke.

  • Sammenlign koden på kjeden. Blokkutforskere viser verifisert kildekode og utrullet bytekode for en kontrakt. Match den mot commit-en eller adressen rapporten oppgir.
  • Undersøk oppgraderbarhet. Er kontrakten en proxy som kan oppgraderes? I så fall kan den reviderte logikken byttes ut senere, akkurat som hos Swaprum.
  • Finn ut hvem som holder nøkkelen. Hvem kontrollerer admin- eller oppgraderingsnøkkelen? Finnes det en tidslås (timelock) som gir brukerne tid til å reagere før en endring trer i kraft?
  • Sjekk styringen. Hvor mange signaturer kreves i en multisig, hva er terskelen, og er nøklene kalde?

Dette er hele avstanden mellom «prosjektet er revidert» og «tingen jeg bruker akkurat nå, er revidert». En oppgraderbar kontrakt med én enkelt admin-nøkkel og ingen tidslås er en revisjon som kan oppheves med ett tastetrykk.

Rødflagg og grønnflagg

Alt over kan destilleres til noen mønstre du kan kjenne igjen på sekunder. Ingen enkelt av dem avgjør saken alene, men jo flere rødflagg, desto større grunn til å holde pengene i lommeboken.

Rødflagg (vær skeptisk)Grønnflagg (mer betryggende)
Stempel uten lenke til en lesbar rapportRapport ligger på revisorens eget nettsted
Rapporten er kun et skjermbilde på prosjektets domeneRapporten navngir commit-hash og kontraktadresse
Revisjonsselskapet lar seg ikke finne eller verifisereKritiske og høye funn er rettet og etterkontrollert
Omfanget utelater kjerne- eller hvelvkontraktenFlere revisjoner pluss aktiv bug bounty og overvåking
Alle funn er «erkjent», ingen «rettet»Tidslås på oppgraderinger
Oppgraderbar proxy med én admin-nøkkel, ingen tidslåsÅpen kildekode som matcher den reviderte versjonen
Et «KYC-stempel» presenteres som om det var en revisjonIngen nedtellingsklokker eller kunstig kjøpepress

Legg spesielt merke til den nest siste raden. Et KYC-stempel bekrefter at teamet har levert identitetsdokumenter til en tredjepart, ikke at koden er trygg. Svindlere blander de to bevisst, fordi «KYC-verifisert» høres ut som «gjennomgått og godkjent». Det er det ikke.

Hvor du leser ekte funn

Du trenger ikke være revisor for å lese en revisjon. Du trenger å vite hvor de ekte ligger. Det viktigste stedet er alltid revisjonsselskapets eget nettsted eller GitHub-arkiv, der rapportene publiseres uredigert. Blokkutforskere gir deg den verifiserte kildekoden for kontrakter, slik at du kan sammenligne.

Vil du se hvordan reelle funn faktisk formuleres, er Solodit et nyttig utgangspunkt. Tjenesten, som eies av Cyfrin, samler over 20 000 sårbarhetsrapporter fra plattformer som Code4rena, Sherlock og CodeHawks i én søkbar database, med filtrering på alvorlighetsgrad. En halvtime i Solodits samling av revisjonsfunn lærer deg raskt hvordan et ekte funn ser ut, hvilket språk som brukes, og hvordan alvorlighetsgrad begrunnes. Etter det er et forfalsket skjermbilde lett å gjennomskue.

Når du først har rapporten foran deg, les den i denne rekkefølgen: sammendraget og omfanget øverst (hva ble faktisk dekket), listen over funn i midten (hvor mange kritiske og høye, og statusen deres), og revisorens forbehold nederst. Er alle de alvorlige funnene merket «rettet» og etterkontrollert, er det et godt tegn. Er de «erkjent» og fortsatt åpne, vet du at prosjektet valgte å leve med risikoen, uansett hvor pent skjoldet ser ut på forsiden.

Ingen myndighet godkjenner kryptorevisorer

Her kommer den ubehagelige, strukturelle sannheten, og den er spesielt tydelig sett fra Norge. I tradisjonell finans er «revisor» et beskyttet, autorisert yrke. Tittelen statsautorisert revisor kan bare gis av Finanstilsynet, den som bærer den må stå oppført i det offentlige Revisorregisteret, oppfylle krav om etterutdanning på 120 timer, og revisoren har et lovfestet ansvar for arbeidet sitt. Vilkårene fremgår av Finanstilsynets regler for godkjenning av revisorer.

For smartkontraktrevisorer finnes ingen slik ordning, ikke i Norge, ikke noe sted. Hvem som helst kan kalle seg «blokkjedesikkerhetsrevisor». Ingen lisens, ingen offentlig register, intet lovpålagt ansvar, ingen minstestandard for hva en revisjon skal inneholde. En 19-åring med en fin nettside og en velformet PDF er, juridisk sett, like mye «revisor» som et selskap med hundre ingeniører.

Regelverket som finnes, treffer ikke koden. Norge fikk kryptoeiendelsloven, som trådte i kraft 1. juli 2025 og gjennomfører EUs MiCA-forordning i norsk rett, med Finanstilsynet som tilsynsmyndighet for kryptoeiendelstjenesteytere (CASP), altså børser og forvarere. Overgangsordningen for tilbydere som allerede var i drift, løp til 1. juli 2026. DORA stiller i tillegg krav til operasjonell IT-motstandsdyktighet hos disse tjenesteyterne. Men verken MiCA, kryptoeiendelsloven eller DORA pålegger noen å få smartkontrakter revidert, og ingen av dem godkjenner dem som utfører revisjonen. Rammeverket, som Finanstilsynet oppsummerer på sin temaside om MiCA og kryptoeiendelsloven, regulerer tjenesteyteren, ikke koden.

Forskjellen blir enda skarpere når noe går galt. En statsautorisert revisor har et lovfestet erstatningsansvar og er pålagt ansvarsforsikring, slik at et forsømt oppdrag kan få reelle økonomiske følger. En smartkontraktrevisor skriver derimot nesten alltid inn ansvarsfraskrivelser: rapporten leveres «som den er», dekker bare et bestemt øyeblikk, og garanterer ingenting. Er protokollen i tillegg fullt desentralisert, finnes det ingen CASP å holde ansvarlig i det hele tatt; da faller prosjektet utenfor MiCA, og revisjonen pluss en eventuell obduksjon er den eneste «garantien» du får.

Konsekvensen er at kvaliteten på kryptorevisjoner utelukkende holdes oppe av omdømme. Og omdømme er nøyaktig det et forfalsket skjold stjeler. Der en statsautorisert revisor risikerer tittel, register og erstatningsansvar, risikerer en falsk kryptorevisor ingenting, fordi det ikke finnes noe å miste.

Hva bransjen prøver, og ikke kan fikse

Bransjen er ikke passiv. Rundt den klassiske punktrevisjonen har det vokst fram flere lag som skal dekke hullene. Ingen av dem lukker gapet helt, men til sammen gjør de deg tryggere enn et enslig skjold.

  • Kontinuerlig overvåking. Tjenester som overvåker kontrakter i sanntid fanger mistenkelig aktivitet etter lansering, der en punktrevisjon bare ser ett øyeblikk.
  • AI-revisorer. Maskinlæring gir raskere triage og bredere dekning, men modellene overser kontekst og finner opp funn. Et verktøy, ikke en garanti.
  • Bug bounties. Dusører betaler forskere for nettopp de svakhetene en revisjon overså. Prislistene varierer sterkt mellom økosystemer, noe vi har sett i saken om bug bounty på Solana og Move. Et supplement, ikke en erstatning.
  • Formell verifisering. Matematiske bevis kan slå fast at koden oppfyller en spesifikasjon, men bare for de egenskapene noen faktisk har spesifisert.
  • Forsikring og dekning på kjeden. Kan betale ut etter et tap, men markedet er lite, og de fleste protokoller er uforsikret.

Den røde tråden er at alt dette er lag. «Audited» er ett tynt lag, ofte det tynneste, og det klart enkleste å forfalske. En seriøs protokoll stabler flere lag oppå hverandre; en svindel kjøper ett skjold og håper du stopper der.

Sjekkliste før du stoler på et «audited»-stempel

Til slutt, det du kan ta med deg videre og bruke neste gang du ser et skjold. Ikke som en garanti, men som en rutine som luker ut de fleste fellene:

  • Finn rapporten. Ingen lesbar rapport betyr ingen verifiserbar revisjon.
  • Åpne den på revisorens egen kanal, ikke på prosjektets domene.
  • Match navn, nettverk, kontraktadresse, versjon, omfang og dato.
  • Sjekk om de alvorlige funnene er rettet, ikke bare erkjent.
  • Undersøk oppgraderbarhet, admin-nøkkel og tidslås.
  • Se etter flere lag: bug bounty, overvåking, formell verifisering.
  • Husk at nøkler, phishing og infrastruktur ligger utenfor revisjonens omfang.
  • Behandle stempelet som starten på undersøkelsen, aldri som slutten.

Et «audited»-stempel er verdt akkurat like mye som din evne til å verifisere det. I 2026 er det ikke lenger et spørsmål om et prosjekt kan vise til en revisjon, men om du kan bekrefte at revisjonen er ekte, at den dekker koden som kjører, og at pengene ikke uansett kan gå ut en dør revisoren aldri så på.

Ofte stilte spørsmål

Betyr et «audited»-stempel at kryptoprosjektet er trygt?

Nei. En revisjon er en gjennomgang av en bestemt versjon av bestemt kode på et bestemt tidspunkt, og den dekker verken private nøkler, infrastruktur, styring eller phishing. Stempelet kan dessuten være forfalsket eller peke på feil kode. Behandle det som starten på en sjekk, aldri som konklusjonen.

Hvordan sjekker jeg om en kryptoaudit er ekte?

Ikke stol på selve skjoldet: finn rapporten. Åpne den på revisjonsselskapets eget nettsted eller register (for eksempel CertiKs Skynet), og sammenlign prosjektnavn, nettverk, kontraktadresse, kodeversjon, omfang og dato mot prosjektet du ser på. Les til slutt om de alvorlige funnene faktisk ble rettet.

Hvorfor blir prosjekter hacket selv etter en revisjon?

Fordi de fleste pengene forsvinner gjennom vektorer en kodrevisjon ikke dekker: kompromitterte nøkler, phishing, infrastruktur, styring og kodeendringer gjort etter revisjonen. I CertiKs Hack3d-rapport for første halvår 2026 var lommebok- og nøkkelkompromiss den dyreste vektoren, ikke kodefeil.

Finnes det en norsk myndighet som godkjenner kryptorevisorer?

Nei. Finanstilsynet tildeler den beskyttede tittelen statsautorisert revisor for finansiell revisjon, men ingen myndighet godkjenner eller fører register over smartkontraktrevisorer. MiCA, kryptoeiendelsloven og DORA regulerer tjenesteyteren (børsen eller forvareren), ikke koden i seg selv.

Hva er forskjellen på et falskt og et villedende revisjonsstempel?

Et falskt stempel betyr at ingen revisjon har skjedd: logoen eller PDF-en er forfalsket. Et villedende stempel betyr at en ekte revisjon finnes, men at den ikke dekker koden som faktisk kjører (feil versjon, omfang eller kontraktadresse), eller at funnene aldri ble rettet.

Anneke de Vries dekker sikkerhet og exploits for HOGE Wire.

Share 𝕏 Post Telegram