Smartkontrakt-Revisjon: Les Riktig i 12 Steg [2026]

Et revisjonsfirma godkjenner koden. Seks uker senere er protokollen tømt. Dette mønsteret har gjentatt seg gjennom store deler av 2025 og inn i 2026, og det skyldes sjelden dårlig arbeid fra revisorene. Problemet er at de fleste som leser en revisjonsrapport, leser den feil eller stopper etter overskriften “Passed”.

Et studie fra sikkerhetsselskapet Ack3, som dekker perioden 1. januar til 29. juni 2026, dokumenterte 122 bekreftede angrep og 13 mistenkte hendelser i DeFi. I et utvalg på 68 hendelser sto tap utenfor revisjonens opprinnelige omfang for 94,4 prosent av pengene som forsvant, 680,97 av 721,24 millioner dollar totalt. Tallet forteller noe konkret: en revisjonsrapport er ikke et sertifikat for trygghet. Den er et kart over hva som faktisk ble sjekket, og enda viktigere, hva som ble utelatt.

Denne veiledningen viser deg, steg for steg, hvordan du leser en smartkontrakt-revisjon slik en sikkerhetsanalytiker gjør det. Du får kommandoene, skriptene og sjekklisten som skiller et forsvarlig DeFi-prosjekt fra det neste tapet i nyhetsbildet. Sett av rundt 45 minutter til de ti stegene, pluss litt ekstra tid hvis du bygger Python-verktøyet i eksempelprosjektet mot slutten.

Hvorfor revisjon alene ikke holder i 2026

Ethereum satte ny rekord med 8,7 millioner smartkontrakt-utrullinger i fjerde kvartal 2025, langt over forrige rekord på 6 millioner fra andre kvartal 2021. De aller fleste av disse kontraktene blir aldri sett av et revisjonsfirma. Ifølge tall fra Blockhertz har trolig under 5 prosent av utrullede ERC-20-tokener blitt gjennomgått av et anerkjent sikkerhetsselskap. DeFi-protokoller med 1 til 10 millioner dollar i låst verdi ligger på 60 til 70 prosent revisjonsgrad, mens prosjekter under 1 million dollar i verdi ofte havner så lavt som 20 til 30 prosent.

Det paradoksale er at revisjon likevel ikke garanterer trygghet. Bare 11 prosent av eksploateringene i en gjennomgang av hendelser siden 2025 skyldtes feil i den delen av koden som faktisk ble revidert, men disse alene drenerte 396 millioner dollar. Resten, altså brorparten av tapene, kom fra ting rapporten aldri dekket: nøkkelhåndtering, frontend-kompromittering og driftsfeil. Samtidig viser data at reviderte kontrakter har rundt 98 prosent færre vellykkede angrep enn sammenlignbar urevidert kode, når man justerer for kompleksitet og størrelse. Konklusjonen er ikke at revisjon er verdiløs. Den er at du må lese rapporten riktig for å få verdien ut av den, noe vi tidligere har vist praktisk i vår guide til sikker smartkontrakt-utvikling i Solidity.

For lesere i Norge og Norden er dette mer enn en teoretisk øvelse. Selveie av kryptovaluta er fullt lovlig, og stadig flere nordiske brukere og utviklerteam interagerer direkte med DeFi-protokoller uten en norsk børs eller bank som mellomledd. Det betyr at ansvaret for å vurdere en protokoll før du kobler til lommeboken din, ligger helt og holdent hos deg selv. Ingen innskuddsgaranti eller klageordning dekker et tap som skyldes en sårbarhet revisjonen aldri fanget opp.

Slik ser en typisk revisjonsrapport ut

Før du går løs på stegene, hjelper det å kjenne strukturen de fleste rapporter følger. Nesten alle revisorer, fra boutique-firmaer til CertiK og Trail of Bits, bygger rapporten rundt de samme byggeklossene, selv om formuleringene varierer litt fra selskap til selskap. Kjenner du strukturen på forhånd, sparer du tid, siden du vet nøyaktig hvilken seksjon du kan hoppe rett til, avhengig av hva du leter etter i den aktuelle vurderingen.

Forsiden og metadata: prosjektnavn, revisjonsdato, commit-hash som ble testet, og hvilken versjon av Solidity-kompilatoren som ble brukt
Executive summary: en kort oppsummering myntet på ledelsen, ofte for optimistisk formulert til å stå alene som beslutningsgrunnlag
Omfang og metodikk: hvilke filer og funksjoner som ble gjennomgått, og om det ble brukt manuell lesing, statisk analyse, formell verifisering eller en kombinasjon
Funnliste sortert etter alvorlighetsgrad: hvert funn med beskrivelse, påvirkning, anbefaling og status
Vedlegg: testresultater, verktøykonfigurasjon og noen ganger rådata fra automatiserte skannere

Interessant nok har selve fordelingen av funntyper endret seg over tid. Reentrancy, som dominerte overskriftene mellom 2018 og 2020, har falt til rundt sjetteplass blant alvorlighetskategoriene og utgjør nå anslagsvis 6 til 8 prosent av alle høyalvorlige funn på tvers av store revisjonsfirmaer. Tilgangskontroll har tatt over som den kategorien du bør bruke mest tid på, noe vi kommer tilbake til i steg 4 og 5.

Vær også oppmerksom på tegn til at en rapport er blitt redigert før publisering. Se etter brutte sidetall, seksjoner som virker klippet av midt i en setning, eller et “Acknowledgements”-avsnitt som mangler helt. De fleste revisorer publiserer også rapporten på sin egen nettside eller sitt eget GitHub, i tillegg til prosjektets versjon. Finnes det avvik mellom de to kopiene, stol på revisorens egen versjon.

Hva du trenger før du starter

Du trenger ikke være sikkerhetsforsker for å følge denne veiledningen, men noen verktøy gjør jobben langt raskere. Sett opp følgende før du går videre:

Python 3.11 eller nyere, med pip installert
Foundry (forge og cast), installert via foundryup, alltid siste stabile versjon
Slither, installert med pip install slither-analyzer -U for nyeste versjon
En gratis Etherscan-konto med API-nøkkel (v2 av API-et støtter flere kjeder med samme nøkkel)
Tilgang til selve revisjonsrapporten, som PDF eller markdown fra prosjektets GitHub-mappe under “audits”
En RPC-endepunkt-URL, for eksempel fra Alchemy, Infura eller en offentlig node for kjeden du undersøker

Sjekk versjonsnumrene dine med python3 --version, forge --version og slither --version før du starter, slik at du vet nøyaktig hva du kjørte hvis noe feiler senere. Grunnen til at Foundry er valgt fremfor Hardhat i denne veiledningen, er at cast gir deg direkte lesekommandoer mot kjeden uten å måtte skrive et helt skript for hvert enkelt kall. Slither dekker den statiske analysen, mens Python-skriptene mot slutten binder sammen rapportlesing og on-chain-verifisering i ett verktøy du kan gjenbruke neste gang du vurderer en ny protokoll.

Steg 1: Finn riktig revisjonsrapport og versjon

Start med å finne den originale rapporten, ikke et sammendrag på prosjektets nettside. De fleste seriøse prosjekter legger PDF- eller markdown-versjonen i en “audits”-mappe på GitHub, eller lenker direkte til revisorens egen publisering, for eksempel CertiK Skynet eller Trail of Bits’ offentlige repo. Unngå å stole på et Medium-innlegg som oppsummerer funnene, siden slike tekster ofte utelater alvorlighetsgrad og status på retting. Mange revisorer publiserer også en offentlig katalog over alle oppdrag de har gjennomført, søkbar på prosjektnavn. Finner du ikke rapporten der prosjektet selv hevder den ligger, er det verdt å sjekke om revisoren i det hele tatt har prosjektet i sin egen liste, siden det hender at prosjekter overdriver eller feilrepresenterer hvilket firma som faktisk sto for gjennomgangen.

Det viktigste du sjekker først, er hvilken commit-hash eller kodeversjon rapporten faktisk dekker. Sammenlign den mot koden som er deployet i dag. Prosjekter oppdaterer ofte kontraktene etter at revisjonen er ferdig, uten ny gjennomgang. Med rekordhøye 8,7 millioner nye kontrakter bare i fjerde kvartal 2025, er sjansen stor for at du står overfor en rapport som ikke lenger matcher den faktiske koden på kjeden.

Sjekk også om det finnes flere rapporter for samme prosjekt. Store protokoller bestiller ofte en ny revisjon for hver større oppdatering, mens mindre team noen ganger kun har den opprinnelige rapporten fra lansering, uten oppfølging av senere kodeendringer. Finner du flere rapporter, les den nyeste først, men bla gjennom de eldre også, siden et funn som ble merket “Acknowledged” i en tidlig rapport noen ganger dukker opp igjen uendret i den neste.

Steg 2: Vurder revisor-tier og hva prisen forteller deg

Ikke alle revisjoner er like grundige, og prisen henger tett sammen med dybden. Boutique-firmaer jobber raskt og billig, mens de store navnene bruker flere uker og flere titalls sikkerhetsforskere på hvert oppdrag. Tabellen under viser de tre vanligste nivåene i 2026, basert på tall fra Blockhertz sin sikkerhetsstatistikk.

Revisor-nivå	Typisk pris	Varighet	Kjennetegn
Boutique	$5 000–15 000	1–2 uker	Mindre, spesialiserte firmaer, begrenset manuell gjennomgang
Mid-tier	$15 000–50 000	2–4 uker	Etablerte firmaer, dekker mellomstore protokoller grundig
Top-tier	$50 000–200 000+	4–8 uker	For eksempel CertiK og Trail of Bits, brukes til store L1/L2-prosjekter

Som referansepunkt: CertiK alene har gjennomført over 5 500 revisjoner og avdekket nesten 83 000 sårbarheter i smartkontrakter ifølge tall fra Blockedens gjennomgang av revisjonslandskapet i 2026. Et boutique-firma med to ukers frist rekker rett og slett ikke det samme volumet av testing, manuell kodegjennomgang og formell verifisering som et team som bruker to måneder på oppdraget. Det betyr ikke at boutique-revisjoner er verdiløse, men du bør vekte dem lavere i din egen risikovurdering. Omregnet til norske kroner tilsvarer prisspennet grovt sett fra rundt 50 000 kroner for et boutique-oppdrag til over 2 millioner kroner for en full top-tier-gjennomgang, avhengig av valutakurs. Et prosjekt som forvalter flere hundre millioner kroner i brukermidler, men kun har betalt for det billigste alternativet, bør vekke ekstra skepsis.

Nivået du bør kreve, henger sammen med hvor mye kapital protokollen faktisk forvalter og hvor komplisert logikken er. En enkel token-kontrakt med standard funksjonalitet trenger sjelden en åtte ukers top-tier-gjennomgang. En protokoll som håndterer lånefunksjoner, orakler eller flere sammenkoblede kontrakter, bør derimot ikke nøye seg med et boutique-firma alene, uansett hvor overbevisende markedsføringen deres er. Spør gjerne prosjektet direkte om hvorfor de valgte det nivået de gjorde, svaret sier ofte mer enn selve rapporten.

Steg 3: Les omfang og begrensninger før noe annet

Hopp rett til “Scope” eller “Out of Scope” i innholdsfortegnelsen før du leser et eneste funn. Denne seksjonen definerer nøyaktig hvilke filer, kontrakter og funksjoner som ble testet. Alt utenfor listen er ukjent territorium, uansett hvor mange grønne haker resten av rapporten har.

Husk Ack3-tallet fra innledningen: 94,4 prosent av tapene i deres 68-hendelses utvalg kom fra ting utenfor det opprinnelige omfanget. Vanlige blindsoner inkluderer frontend-kode, backend-servere, deployment-skript, oracle-integrasjoner og administrasjonsverktøy som ikke er en del av selve smartkontrakten. Noter deg spesifikt om orakelintegrasjonen er inkludert, siden det har vært en gjentakende kilde til store tap i DeFi, noe vi har dekket i detalj i vår artikkel om orakelmanipulasjon i DeFi.

En typisk omfangsformulering kan se slik ut: “Denne revisjonen dekker kontraktene Vault.sol, Staking.sol og Governance.sol, commit 4a1f9c2. Frontend, backend-infrastruktur, deployment-skript og eventuelle eksterne oracle-kontrakter er utenfor omfang.” Legg merke til hvor mye som utelates i den siste setningen alene. Hvis protokollen din bruker en ekstern pris-orakel, som svært mange lånemarkeder og derivatprotokoller gjør, og den orakelen er “utenfor omfang”, har du akkurat identifisert den mest sannsynlige inngangsporten for et fremtidig angrep.

Steg 4: Sorter funn etter alvorlighetsgrad

De fleste revisjonsrapporter bruker en skala fra Critical til Informational. Ikke bland disse sammen. Ett kritisk funn som ikke er rettet, veier tyngre enn ti lav-funn til sammen. Tabellen under viser hvilke kategorier som faktisk kostet mest i 2025, ifølge Blockhertz sin statistikk.

Sårbarhetskategori	Tap i 2025 (USD)
Tilgangskontroll (access control)	$953,2 millioner
Logikkfeil	$63,8 millioner
Reentrancy	$35,7 millioner
Flash loan-angrep	$33,8 millioner

Kritisk, høy, middels og lav, hva betyr det i praksis

Tallene over forklarer hvorfor tilgangskontroll fortjener mest av oppmerksomheten din. En revisjonsrapport fra 2026 viser at tilgangskontroll og sentralisering er de klart hyppigste funnene, foran logikkfeil, svakheter i orakeldesign og usjekket aritmetikk, ifølge funnrapporten fra Smart Contract Audit. Et firårig studie publisert på arXiv bekrefter mønsteret over tid: andelen Critical- og High-funn har ligget stabilt i et 15 til 17 prosent-bånd fra 2022 til 2026, og de samme fem kategoriene, tilgangskontroll, logikk, initialisering, input-validering og aritmetikk, har dominert hele perioden. Solidity og EVM-baserte kjeder står for mellom 79 og 84 prosent av alle årlige funn, ifølge den fireårige empiriske studien av revisjonsgapet. Når du sorterer funn, spør alltid: er dette en kodefeil som kan rettes med en linje, eller er det et strukturelt tillitsproblem knyttet til hvem som har makt over kontrakten?

Ikke se helt bort fra “Informational”-funnene heller, selv om de ikke direkte truer midlene dine. De peker ofte på dårlig kodepraksis, manglende hendelseslogging eller uklare kommentarer, som gjør det vanskeligere for deg og andre å oppdage fremtidige endringer i kontrakten. Et prosjekt som ignorerer ti informational-funn på rad, sier noe om hvor seriøst teamet tar tilbakemeldinger generelt, og det er relevant informasjon når du veier helhetsinntrykket.

Steg 5: Grav i tilgangskontroll og sentralisering

Siden tilgangskontroll er den dyreste kategorien, bør du verifisere den selv, ikke bare stole på rapportens ord. Bruk Foundrys cast-verktøy til å lese eierskap og roller direkte fra kjeden. Kommandoene under fungerer mot enhver EVM-kompatibel kjede så lenge du bytter ut adresse og RPC-URL.

RPC_URL="https://eth-mainnet.g.alchemy.com/v2/DIN_NOKKEL"
CONTRACT="0xKontraktAdresseHer"

# Les hvem som eier kontrakten
cast call $CONTRACT "owner()(address)" --rpc-url $RPC_URL

# Sjekk om en spesifikk adresse har en gitt rolle (OpenZeppelin AccessControl)
ROLE=$(cast keccak "DEFAULT_ADMIN_ROLE")
cast call $CONTRACT "hasRole(bytes32,address)(bool)" $ROLE 0xAdresseDuSjekker --rpc-url $RPC_URL

Et typisk svar på det første kallet ser slik ut: 0x8f3a2B1c9E4d5F6a7B8c9D0e1F2a3B4c5D6e7F80. Slå opp adressen på Etherscan. Er det en vanlig lommebok (EOA)? Det er et rødt flagg, siden én enkelt privat nøkkel da kontrollerer protokollen. Er det merket “Gnosis Safe” med flere signaturer krevd, er risikoen langt lavere. Best er det hvis eierskapet ligger i en tidslås-kontrakt (timelock), som gir brukere varsel og tid til å reagere før endringer trer i kraft. Finner du en timelock, sjekk også hvor lang forsinkelsen faktisk er. En tidslås på 24 timer gir deg i praksis knapt nok tid til å reagere før en ondsinnet oppgradering trer i kraft, mens et team som bruker 48 til 72 timer, gir brukerne en reell mulighet til å trekke ut midlene sine først.

Steg 6: Sjekk om funnene faktisk ble rettet

En revisjonsrapport lister ofte funn med status “Fixed”, “Acknowledged” eller “Won’t Fix”. Problemet er at “Fixed” i rapporten ikke alltid betyr at koden som faktisk kjører på kjeden, inneholder rettelsen. Prosjekter kan committe en fiks etter revisjonen, men deploye en annen versjon. Hent verifisert kildekode direkte fra Etherscan og sammenlign selv.

curl "https://api.etherscan.io/v2/api?chainid=1&module=contract&action=getsourcecode&address=0xKontraktAdresseHer&apikey=DIN_ETHERSCAN_NOKKEL"

Svaret kommer som JSON med et felt kalt SourceCode. Kopier innholdet inn i en lokal fil og søk etter funksjonen eller linjen revisjonsrapporten nevner som problematisk. Finner du fortsatt den samme sårbare koden, uavhengig av hva statusfeltet i rapporten sier, har du funnet en reell risiko som ingen andre har fanget opp ennå. Sjekk også at feltet SourceCode ikke er tomt, for det betyr at kontrakten ikke er verifisert i det hele tatt.

Har prosjektet et offentlig GitHub-repo, gjør sammenligningen enda enklere. Klon repoet, sjekk ut commit-hashen fra revisjonsrapporten, og kjør git diff <revidert-commit> <siste-commit> -- src/ for å se nøyaktig hva som er endret siden gjennomgangen. Selv små, tilsynelatende ufarlige endringer i en tilgangskontroll-funksjon fortjener en ny gjennomlesning, siden det nettopp er den typen endringer som historisk har kostet mest.

Steg 7: Kryssjekk med egne automatiserte verktøy

Ikke stol blindt på at revisjonsteamet fanget alt, selv fra et top-tier firma. Kjør din egen statiske analyse som en ekstra kontroll. Slither er raskt å sette opp og gir deg en strukturert liste over potensielle problemer på minutter.

cd prosjektmappe/
slither . --checklist --exclude-informational > slither-rapport.md

# Sammenlign spesifikt mot funnene i revisjonsrapporten
grep -i "access control\|reentrancy\|unchecked" slither-rapport.md

Vi har tidligere gått grundig gjennom hvordan du setter opp og tolker resultater fra Slither og Echidna for å teste smartkontrakter, inkludert hvordan du fanger opp feil manuell gjennomgang kan overse.

Automatiserte verktøy finner ikke alt

Husk statistikken fra innledningen: bare 11 prosent av eksploateringene siden 2025 skyldtes feil i koden som faktisk lå innenfor revisjonens omfang, mens de resterende tapene kom fra drift og infrastruktur. Verken Slither, Echidna eller den dyreste revisjonen fanger opp en kompromittert bærbar PC hos en multisig-signatar. Automatisert skanning er et supplement, ikke en erstatning for stegene som følger.

Steg 8: Vurder operasjonell risiko utenfor revisjonens omfang

Ifølge en gjennomgang av angrepsmønstre fra Smart Contract Audit dominerer operasjonelle svikt og forsyningskjede-angrep tapene når man måler i dollar, langt foran klassiske kodefeil. Kompromittert signeringsinfrastruktur, dårlig nøkkelhåndtering og angrep mot frontend-koden er alle utenfor det en typisk smartkontrakt-revisjon dekker, ifølge DeFi-eksploateringstrender for 2025 til 2026.

Still deg selv disse spørsmålene, som ingen revisjonsrapport svarer på: Hvor mange signaturer kreves i multisig-lommeboken, og hvem eier nøklene? Er frontend-koden hostet på en tredjepartstjeneste som kan kompromitteres uavhengig av smartkontraktene? Har teamet en dokumentert prosess for nøkkelrotasjon? Flash loan-angrep og orakelmanipulasjon faller også ofte i denne kategorien, temaer vi har dekket separat i vår gjennomgang av flash loan-angrep testet med Foundry.

Antall signaturer som kreves i multisig, og om terskelen faktisk gir mening for hvor mye kapital som er låst
Om deployment-nøklene er de samme som brukes til daglig drift, eller om de er separert og lagret i kaldlagring
Hvor frontend-koden er hostet, og om DNS- og domeneregistrering er beskyttet med tofaktorautentisering
Om det finnes en dokumentert nødprosedyre for å pause kontrakten dersom noe går galt

Ingen av disse punktene står i revisjonsrapporten. De krever at du enten spør prosjektet direkte, eller leser dokumentasjonen og governance-forumet deres for å finne svarene selv. Et team som svarer utfyllende og konkret på slike spørsmål i en offentlig kanal, gir deg langt mer trygghet enn et team som kun viser til revisjonsrapporten og avslutter samtalen der.

Steg 9: Bygg en sjekkliste-poengsum og overvåking med Python

Manuell gjennomgang blir fort inkonsekvent når du vurderer flere protokoller. Et enkelt Python-skript kan gi deg en konsistent poengsum basert på nøkkelord og alvorlighetsgrad hentet direkte fra rapportteksten.

import re

VEKTING = {"critical": 25, "high": 15, "medium": 7, "low": 2}

def score_rapport(tekst: str) -> int:
    tekst = tekst.lower()
    total = 100
    for niva, vekt in VEKTING.items():
        antall = len(re.findall(rf"\b{niva}\b", tekst))
        total -= antall * vekt
    return max(total, 0)

with open("revisjonsrapport.txt", encoding="utf-8") as f:
    innhold = f.read()

poeng = score_rapport(innhold)
print(f"Risikoscore: {poeng}/100")

Kjører du dette mot en rapport med tre “high”-funn og fem “medium”-funn, får du typisk en utskrift som ser slik ut: Risikoscore: 20/100, altså høy risiko med mindre alt er rettet. Utvid gjerne skriptet til å hente rapporten som PDF med biblioteket pdfplumber, siden mange revisorer fortsatt leverer PDF fremfor markdown. Poengsummen er bevisst enkel, den skal ikke erstatte den manuelle lesingen fra steg 3 og 4, men gi deg et raskt, konsistent tall å sammenligne flere protokoller mot hverandre med. Vurderer du fem ulike låneprotokoller samme uke, forteller en poengsum på 20 mot en på 85 deg umiddelbart hvor du bør bruke resten av tiden din.

Legg deretter til enkel overvåking som varsler deg hvis administrasjonsroller endres etter at du har tatt beslutningen din. Dette er steget flest hopper over, men det er også det som fanger opp risiko som oppstår etter at du allerede har investert eller integrert mot protokollen. En admin-nøkkel som var trygg i multisig ved lansering, kan bli flyttet til en enkelt EOA måneder senere uten at noen varsler brukerne direkte.

import requests, time

def sjekk_eier_endring(contract, rpc_url, webhook_url, kjent_eier):
    payload = {
        "jsonrpc": "2.0", "id": 1, "method": "eth_call",
        "params": [{"to": contract, "data": "0x8da5cb5b"}, "latest"]
    }
    svar = requests.post(rpc_url, json=payload, timeout=10).json()
    ny_eier = svar.get("result", "")
    if ny_eier.lower() != kjent_eier.lower():
        requests.post(webhook_url, json={"tekst": f"Eierskap endret for {contract}"})

while True:
    sjekk_eier_endring("0xKontrakt", "https://rpc-url", "https://din-webhook", "0xKjentEier")
    time.sleep(300)

Steg 10: Ta go/no-go-beslutningen og dokumenter den

Samle alt du har funnet i en enkelt beslutningsmatrise: revisor-tier, andel av koden som var innenfor omfang, antall uløste kritiske og høye funn, status på tilgangskontroll, og operasjonell risiko rundt nøkler og frontend. Sett en enkel terskel for deg selv, for eksempel at ethvert uløst kritisk funn automatisk betyr nei, uavhengig av hvor god resten av rapporten ser ut.

Skriv ned begrunnelsen din, selv om det bare er noen setninger i et delt dokument. Når CoinGecko sin sikkerhetsrapport for 2026 viser at flertallet av de 245 dokumenterte hendelsene siden tidlig 2025 rammet protokoller som faktisk hadde vært gjennom en revisjon, er dokumentasjon av din egen vurdering det som lar deg lære av utfallet senere, uansett hvordan det går.

Vanlige fallgruver når du leser revisjonsrapporter

De fleste feilene som gjentar seg, handler ikke om manglende teknisk kompetanse, men om snarveier folk tar når de har det travelt. Her er de vi ser oftest, både hos enkeltbrukere og hos team som burde vite bedre.

Å anta at “revidert” betyr “trygt”. Et flertall av hendelsene registrert siden tidlig 2025 rammet protokoller som hadde vært gjennom minst én revisjon før de ble hacket.
Å hoppe over omfangsseksjonen. Uten å vite hva som ble testet, vet du ikke hva risikoen faktisk dekker.
Å stole på en gammel rapport for oppgradert kode. En rapport fra Bitcoin Foundation i juli 2026 dokumenterte 204 kodesårbarheter for til sammen 151,6 millioner dollar, med en økende andel angrep mot kontrakter eldre enn ett år, ofte fordi kode ble endret uten ny gjennomgang.
Å hoppe over sjekk av administrasjonsnøkler. Tilgangskontroll er den dyreste sårbarhetskategorien, likevel er det steget flest hopper over fordi det krever litt kommandolinjearbeid.
Å forveksle automatisert skanning med en fullverdig revisjon. Verktøy som Slither fanger mønstre, ikke forretningslogikk eller økonomiske angrepsvektorer.
Å ikke bekrefte at kritiske funn faktisk er rettet i den deployerte koden. “Fixed” i en rapport er en påstand, ikke et bevis, før du har sjekket bytecoden selv.
Å ignorere hvem som faktisk bestilte og betalte for revisjonen. En revisjon bestilt og publisert av prosjektet selv kan ha vært redigert eller forkortet før offentliggjøring, sammenlign om mulig med revisorens egen kopi.
Å la deg blende av kjente navn i rapportens forord. Et stort revisorlogo øverst på siden er ikke det samme som at hvert eneste funn i rapporten faktisk er rettet.

Feilsøking: 8 vanlige problemer og løsninger

Selv med riktig oppsett vil du støte på feilmeldinger underveis, spesielt i stegene som krever direkte kommunikasjon med kjeden. De fleste problemene under har en enkel løsning, men de stopper fort opp en nybegynner som ikke vet hvor de skal lete.

Problem	Løsning
Finner ikke revisjonsrapporten noe sted	Sjekk prosjektets GitHub under en mappe kalt “audits” eller “security”, eller søk direkte på revisorens egen nettside
cast call feiler med “execution reverted”	Kontrakten bruker trolig et proxy-mønster. Finn implementasjonsadressen med `cast implementation` og kall den i stedet
Etherscan API returnerer “Contract source code not verified”	Stort rødt flagg i seg selv. Vurder å avstå, eller undersøk bytecode manuelt med et dekompileringsverktøy
Slither krasjer med kompileringsfeil	Solidity-versjonen i konfigurasjonen matcher ikke installert kompilator. Kjør `solc-select install <versjon>` og `solc-select use <versjon>`
Python-skriptet gir feil score fordi rapporten er PDF	Konverter til ren tekst først med `pdfplumber` eller kommandolinjeverktøyet pdftotext
Multisig-adressen ser ut som en vanlig lommebok	Sjekk kontraktsnavnet på Etherscan for “Gnosis Safe”, eller kall `getOwners()` direkte for å bekrefte
Rapportdatoen er eldre enn siste kodeendring	Sammenlign commit-hashen nevnt i rapporten mot den faktiske deployerte bytecoden via Etherscan
RPC-tilkoblingen timer ut under cast- eller web3-kall	Bytt RPC-leverandør eller sjekk om du har truffet rate-grensen på gratisnivået ditt

Avanserte tips for erfarne team

Når du har gjennomført de ti stegene noen ganger, begynner mønstrene å bli tydelige. Disse fem punktene tar deg fra en solid enkeltvurdering til en gjentakende prosess du kan stole på over tid.

Følg revisorenes egne retrospektiver. Mange sikkerhetsfirmaer publiserer detaljerte post-mortem-analyser av egne blindsoner på GitHub og X etter at et revidert prosjekt likevel har blitt hacket, og disse er ofte mer lærerike enn selve originalrapporten
Bruk bug bounty-historikk som et ekstra signal. Et prosjekt uten aktiv bounty på en plattform som Immunefi etter lansering signaliserer mindre kontinuerlig sikkerhetstrykk enn ett som betaler ut jevnlig
Sett opp sanntidsvarsling, ikke bare en engangssjekk. Verktøy som Forta eller OpenZeppelin Defender kan varsle deg automatisk hvis en administrasjonstransaksjon skjer, lenge etter at du tok den opprinnelige beslutningen
Automatiser kildekode-sammenligningen i egen CI. Forvalter du kapital på vegne av andre, bør sjekken i steg 6 kjøre automatisk hver dag, ikke bare den ene gangen du gjorde due diligence
Vurder infrastrukturrisiko utover selve koden. Hvilke kjeder og broer er protokollen avhengig av, og hvor mange av dem har egne, uavhengige revisjoner? Et sikkert kontraktlag hjelper lite hvis broen det er bygget på, ikke er det

Komplett eksempelprosjekt: revisjonssjekkeren

Sett nå sammen stegene over til ett samlet verktøy. Opprett en mappe med denne strukturen:

revisjonssjekker/
├── audit_checker.py
├── requirements.txt
└── rapporter/
    └── revisjonsrapport.txt

Legg requests og pdfplumber i requirements.txt, og bruk følgende skript som binder sammen tekstscoring og on-chain-sjekk av eierskap i én kommando. Skriptet har tre funksjoner: score_rapport teller alvorlighetsord fra teksten, hent_eier gjør et direkte eth_call mot kontrakten for å lese ut adressen som eier den, og anbefaling kombinerer de to til en konklusjon du faktisk kan handle på.

import re, sys, requests

VEKTING = {"critical": 25, "high": 15, "medium": 7, "low": 2}

def score_rapport(tekst: str) -> int:
    tekst = tekst.lower()
    total = 100
    for niva, vekt in VEKTING.items():
        antall = len(re.findall(rf"\b{niva}\b", tekst))
        total -= antall * vekt
    return max(total, 0)

def hent_eier(contract: str, rpc_url: str) -> str:
    payload = {"jsonrpc": "2.0", "id": 1, "method": "eth_call",
               "params": [{"to": contract, "data": "0x8da5cb5b"}, "latest"]}
    svar = requests.post(rpc_url, json=payload, timeout=10).json()
    return svar.get("result", "ukjent")

def anbefaling(poeng: int, eier: str) -> str:
    if poeng < 40:
        return "IKKE GA VIDERE: for mange uloste alvorlige funn"
    if eier == "ukjent":
        return "STOPP: klarte ikke a verifisere eierskap on-chain"
    return f"POENG {poeng}/100: ga videre til manuell gjennomgang av admin-rolle {eier}"

if __name__ == "__main__":
    with open("rapporter/revisjonsrapport.txt", encoding="utf-8") as f:
        tekst = f.read()
    poeng = score_rapport(tekst)
    eier = hent_eier(sys.argv[1], sys.argv[2])
    print(anbefaling(poeng, eier))

Kjør det med python3 audit_checker.py 0xKontraktAdresse https://din-rpc-url. Et typisk resultat for en protokoll med to "medium"-funn og verifisert multisig-eierskap ser slik ut: POENG 86/100: gå videre til manuell gjennomgang av admin-rolle 0x8f3a...7F80. Score under 40, eller manglende mulighet til å verifisere eierskap i det hele tatt, bør stoppe deg før du går videre til stegene med operasjonell risiko. Utvid prosjektet videre ved å legge til en enkel loggfil som lagrer hver kjøring med tidsstempel, slik at du bygger en egen historikk over protokollene du har vurdert, og kan sammenligne notatene dine hvis en av dem senere havner i nyhetsbildet. Neste naturlige steg er å legge til støtte for flere kjeder i hent_eier, siden mange protokoller i dag er deployert på både Ethereum, Arbitrum og andre EVM-kjeder samtidig, ofte med ulike administrasjonsroller på hver kjede.

Rask sjekkliste: fra rapport til beslutning

Har du fulgt alle ti stegene minst én gang, kan du bruke denne kortversjonen neste gang du vurderer en ny protokoll raskt.

Last ned rapporten fra revisorens egen kilde, ikke fra et sammendrag
Sjekk commit-hashen mot deployert kode
Les omfangsseksjonen og noter alt som er utenfor
Tell antall uløste kritiske og høye funn
Kjør cast call for å verifisere hvem som faktisk eier kontrakten
Kjør Etherscan-sjekken for å bekrefte at "Fixed"-funn faktisk er borte fra koden
Kjør Slither som en uavhengig andre mening
Vurder nøkkelhåndtering, frontend og deployment-prosess
Kjør poengsum-skriptet og noter tallet
Ta beslutningen, skriv den ned, og sett opp overvåking hvis svaret er ja

Ofte stilte spørsmål

Er en revisjon nok til å stole fullt ut på en DeFi-protokoll?

Nei. Data fra CoinGecko sin sikkerhetsrapport for 2026 viser at et flertall av de dokumenterte hendelsene siden tidlig 2025 rammet protokoller som allerede hadde vært gjennom en revisjon. En revisjon reduserer risiko betydelig, men den fjerner den ikke, spesielt ikke for operasjonelle og driftsmessige svakheter. Bruk revisjonen som ett av flere datapunkter i vurderingen din, ved siden av alderen på koden, hvem som kontrollerer admin-nøklene og hvordan teamet har håndtert tidligere funn.

Hvor lang tid tar en grundig smartkontrakt-revisjon?

Det varierer med nivå. Boutique-firmaer bruker gjerne én til to uker, mid-tier-firmaer to til fire uker, mens top-tier-firmaer som CertiK og Trail of Bits ofte bruker fire til åtte uker på større protokoller, ifølge tall fra Blockhertz. Tidsbruken påvirkes også av hvor mye kontraktkode som faktisk er i omfang, en protokoll med mange sammenkoblede moduler tar naturlig nok lengre tid å gå gjennom enn en enkelt, isolert kontrakt.

Hva koster en revisjon vanligvis?

Prisen spenner fra rundt 5 000 dollar for et enkelt boutique-oppdrag til over 200 000 dollar for en fullverdig top-tier-revisjon av en stor protokoll. De fleste mellomstore DeFi-prosjekter havner i sjiktet 15 000 til 50 000 dollar. Som bruker betaler du ikke for dette direkte, men prisen sier noe om hvor mye protokollen selv har investert i egen sikkerhet, noe som er verdt å vurdere sammen med resten av sjekklisten.

Hvordan vet jeg om et revisjonsfunn faktisk er rettet?

Ikke stol på statusordet alene. Hent verifisert kildekode fra Etherscan med det aktuelle API-kallet vist i steg 6, og søk manuelt etter funksjonen eller linjen rapporten flagget. Bare da vet du at rettelsen faktisk er en del av koden som kjører på kjeden i dag. Ligger prosjektet åpent på GitHub, er en git diff mellom den reviderte commit-hashen og gjeldende hovedgren den raskeste måten å få et fullstendig bilde på, fremfor å lete etter én enkelt funksjon om gangen.

Er automatiserte verktøy som Slither nok alene, uten en profesjonell revisjon?

Nei. Automatiserte verktøy fanger mønstre og kjente svakhetstyper, men de forstår ikke forretningslogikken eller de økonomiske insentivene i en protokoll. Bruk dem som et supplement til, ikke en erstatning for, en gjennomlest revisjonsrapport og din egen manuelle vurdering. Et prosjekt som kun viser til en ren Slither-rapport uten noen profesjonell revisjon i det hele tatt, bør vurderes langt strengere enn ett som har begge deler.

Hvilke røde flagg bør stoppe meg umiddelbart?

Et uverifisert kontraktkode på Etherscan, et uløst kritisk funn i rapporten, eierskap som ligger hos en enkelt vanlig lommebok uten multisig, og en revisjonsrapport som er betydelig eldre enn siste kodeendring. Alle fire bør normalt bety nei, uavhengig av hvor lovende resten av prosjektet ser ut. Legg også merke til om prosjektet blir defensivt eller unnvikende når du stiller konkrete spørsmål om disse punktene i deres Discord eller på GitHub, det er ofte et sosialt signal som er like pålitelig som de tekniske sjekkene.

Betyr en uverifisert kontrakt automatisk at protokollen er farlig?

Det er i det minste et alvorlig tillitsproblem. Uten verifisert kildekode kan du ikke lese logikken, ikke kryssjekke med Slither, og ikke bekrefte at revisjonens funn faktisk gjelder den deployerte koden. Behandle det som en showstopper med mindre du selv kan dekompilere og verifisere bytecoden. I praksis betyr dette at du bør avstå helt om du ikke har den tekniske kompetansen til å gjøre den jobben selv, uansett hvor attraktivt tilbudet ellers fremstår.

Er selveie av krypto og bruk av egne lommebøker lovlig i Norge?

Ja. Det finnes ingen lov som forbyr å eie eller bruke en selvforvaltet programvare- eller maskinvarelommebok i Norge per juni 2026, ifølge en oversikt over norsk kryptoregelverk. Ansvaret for å sikre nøklene og gjøre egne vurderinger, som denne veiledningen dekker, ligger likevel helt og holdent hos deg selv.

Smartkontrakt-Revisjon: Les Riktig i 12 Steg, 45 Min [2026]