Solana- og Move-revisorene i 2026: hvem vokter koden?

Den 22. mai 2025 tok det noen minutter å tømme Cetus, den største desentraliserte børsen på Sui, for rundt 223 millioner dollar (nær 2,1 milliarder kroner). Det mest ubehagelige var ikke summen, men fasiten: koden hadde passert flere separate sikkerhetsrevisjoner fra ulike firmaer, den siste bare en måned før angrepet. En enkelt kontroll mot heltallsoverflyt var feil med én bit, og det holdt for å la en angriper hente en enorm likviditetsposisjon mot et innskudd på i praksis ett token.

Mye av det HOGE Wire har skrevet om revisjonsbransjen handler om Ethereum-verdenen: Solidity, EVM og firmaer som Trail of Bits, CertiK og OpenZeppelin. Men det finnes et helt parallelt sikkerhetsmarked som vokter kode skrevet i Rust (Solana) og Move (Sui og Aptos), og det fungerer etter andre regler. Feilklassene er andre, verktøyene er andre, og navnene er stort sett ukjente for folk som bare følger Ethereum.

Denne gjennomgangen tar for seg de seks viktigste revisorene utenfor EVM: OtterSec, Zellic, Neodyme, Sec3, Ackee Blockchain og MoveBit. Vi ser på hvordan de jobber, hvilke sårbarheter de faktisk leter etter, hva en revisjon koster i kroner, og hvordan du skiller et seriøst miljø fra et gummistempel. Ingen tilsynsmyndighet, verken Finanstilsynet, ESMA eller amerikanske SEC, godkjenner disse firmaene eller stiller krav om at kode skal revideres. Omdømme er hele valutaen.

Utenfor EVM: et sikkerhetsfag med egne regler

En Solidity-revisor og en Rust-revisor jakter ikke på de samme feilene. På Ethereum er reentrancy (at en kontrakt kaller tilbake inn i seg selv midt i en operasjon) selve arketypen; det var slik DAO-en falt i 2016, og mønsteret dukker opp fremdeles. På Solana finnes ikke reentrancy på samme måte. Programmer og data er skilt fra hverandre, og en transaksjon må liste opp alle kontoene den vil røre på forhånd. Til gjengjeld oppstår en helt egen familie av feil, knyttet til nettopp den kontomodellen: glemte signatur- og eierskapskontroller, kontoer som forveksles med hverandre, og usikre kall mellom programmer.

Robert Chen, som grunnla Solana-revisoren OtterSec, har argumentert for at programmer på Solana er fundamentalt sikrere på grunn av programmeringsmodellen, nettopp fordi reentrancy er ute av bildet og en stor angrepsflate forsvinner. Han peker samtidig på at bildet ikke er så enkelt: Solana hadde store hack i 2022 og 2023, og økonomiske angrep (der ingen kode egentlig brytes, men markedet manipuleres) er arkitektur-agnostiske. Tallene han kommenterte, viste at EVM-nettverk tapte 792,6 millioner dollar til hack i 2024 mot 33,5 millioner på Solana; forskjellen er reell, men den gjelder kodefeil, ikke den menneskelige eller økonomiske delen av trusselbildet.

Move, språket bak Sui og Aptos, går enda lenger i å bygge sikkerhet inn i selve språket. Verdier er modellert som ressurser med lineære typer, slik at et token ikke kan kopieres eller forsvinne ved et uhell; det fjerner en hel klasse dobbeltbruk-feil på kompileringstidspunktet. Poenget er at hverken Rust eller Move gjør en revisjon overflødig; de flytter bare grensen for hvor feilene gjemmer seg. Og fordi antallet erfarne Rust- og Move-revisorer er langt mindre enn antallet Solidity-folk, koster kompetansen mer, noe vi kommer tilbake til i prisdelen.

Cetus-saken: da tre revisjoner overså ett skift

Cetus er lærebokeksempelet på hvorfor «revidert» og «trygg» ikke er det samme ordet. Rotårsaken var en funksjon kalt checked_shlw, som skulle stoppe en heltallsoverflyt før et bitskift. Etter Dedaubs tekniske gjennomgang sammenlignet kontrollen mot 0xFFFFFFFFFFFFFFFF skiftet 192 plasser, i stedet for 0x1 skiftet 192 plasser. Grensen var altså satt feil med én bit. Det lot en angriper konstruere en likviditetsverdi som besto testen, men som likevel skapte en overflyt i regnestykket etterpå, slik at systemet krevde nesten ingenting i innskudd for en gigantisk posisjon.

Det oppsiktsvekkende er revisjonshistorikken. Koden var gjennomgått av flere av de mest anerkjente Move-revisorene, og alle rapportene ligger åpent i Cetus sitt eget revisjonsarkiv på GitHub. MoveBit reviderte i april 2023 og listet «value overflows» som en del av metodikken, men fanget ikke den konkrete feilen i den aktuelle funksjonen. OtterSec reviderte i mai 2023 og flagget faktisk en nær beslektet risiko (at en konvertering fra u256 til u64 kunne gi regnefeil hvis verdien oversteg MAX_U64), men klassifiserte det som et forslag, ikke et kritisk funn, og pekte ikke på den utnyttbare stien. Zellic reviderte så sent som i april 2025, en måned før angrepet, og fant den heller ikke. Slik oppsummerer PANews sin gjennomgang sekvensen.

Halborn, som skrev en av obduksjonene, peker på en kulturell blindsone: feilen ble aldri fanget, trolig fordi bransjen har trodd at overflyt aldri er en risiko i Move. Sui støtter 256-bits heltall nativt, og da koden ble portet dit, ble et lavnivå matematisk bibliotek behandlet som noe som «bare virker». Den typen bibliotekskode faller ofte mellom to stoler i omfangsdefinisjonen. Suhail Kakar, developer relations lead i TAC Blockchain, sa det rått etter et tilsvarende EVM-tilfelle: «Denne bransjen må godta at ‘revidert av X’ betyr nesten ingenting. Kode er vanskelig, DeFi er vanskeligere.» Poenget bærer rett over til Cetus, der tre firmaer signerte av på den samme filen.

Etterspillet ble en test på noe helt annet enn kode, nemlig desentralisering. Rundt 162 millioner dollar av byttet lå fortsatt på Sui og ble fryst, mens rundt 60 millioner rakk å flykte til Ethereum. Sui-validatorene stemte deretter, i en avstemning der de som representerte 90,9 prosent av innsatsen sa ja, for å flytte de frosne midlene til en multisig-lommebok kontrollert av Cetus, OtterSec og Sui Foundation, slik Cointelegraph rapporterte. At validatorer kan overstyre kjeden for å «hacke tilbake» er effektivt, men det åpner en debatt om sensurmotstand som ligner mye på det vi har beskrevet i gjennomgangen av styringsangrep. Merk ironien: OtterSec reviderte koden, overså feilen, og endte likevel som en av vokterne av de reddede midlene.

Audited, likevel tømt: fasiten utenfor EVM

Cetus er ikke et engangstilfelle. Listen under samler noen av de mest kjente hendelsene utenfor EVM, med hvorvidt koden var revidert og hva som faktisk sviktet. Poenget er ikke at revisjon er verdiløst, men at den fanger den vanligste feilklassen (kodefeil), sjelden den dyreste (nøkler, infrastruktur og økonomisk design).

Wormhole, brua mellom Solana og Ethereum, ble tømt for 326 millioner dollar fordi en utdatert funksjon lot en forfalsket signatur passere; systemet trodde falskt sikret verdi var ekte og preget nye tokens mot den, slik Halborns obduksjon beskriver. Mango Markets ble tappet for rundt 114 millioner dollar uten en eneste kodefeil: angriperen presset prisen på MNGO-perpen og lånte mot den oppblåste verdien, en klassisk økonomisk manøver som ingen kodegjennomgang stopper (se vår gjennomgang av prisorakler og OEV-økonomien). Helius har samlet en full historikk over Solana-hendelsene for den som vil grave dypere.

Trusselbildet på Solana: signaturer, eierskap og kontoforvirring

For å vurdere en Solana-revisor må du vite hva den skal lete etter. Etter Cantinas utviklerguide kommer de fleste Solana-utnyttelsene fra én av tre kilder: manglende kontovalidering, feil signaturkontroll eller et usikkert kall mellom programmer. De vanligste feilklassene ser slik ut:

• Manglende signaturkontroll: programmet sjekker ikke at den forventede parten faktisk signerte. Uten den kontrollen kan hvem som helst utføre en privilegert operasjon ved å oppgi de riktige kontoene.
• Manglende eierskapskontroll: programmet sjekker ikke hvilket program som eier en konto, slik at en angriper kan mate inn en forfalsket konto med data den kontrollerer selv.
• Kontoforvirring (type confusion): et løst typesystem lar to ulike kontotyper forveksles. Anchor demper dette ved å gi hver konto en åtte bytes lang diskriminator (en identifikator som binder dataene til riktig type).
• Usikkert CPI (cross-program invocation): et kall til et annet program uten å verifisere hvilket program som faktisk kalles.
• UncheckedAccount som snarvei: et vanlig antimønster der utviklere hopper over eier- og signaturkontroll for å få koden til å kompilere raskere, og dermed slipper forfalskbare input rett inn.
• Foreldede data, dupliserte kontoer og feil lukking: mindre iøynefallende, men gjentagende kilder til feil.

Anchor, rammeverket som ligger under et stort flertall av utplasserte Solana-programmer, automatiserer mange av signatur- og eierskapskontrollene og fjerner en god del av risikoen på egen hånd. Men rammeverk er ingen garanti: Wormhole-hacket var i kjernen nettopp en manglende signaturkontroll, på et flaggskipsprosjekt. En god Solana-revisor kjenner disse mønstrene i søvne og bruker verktøy som er bygget spesifikt for dem, ikke generiske Solidity-analyser som er blinde for kontomodellen.

Ironien er at Anchor både løser og skaper problemer. Rammeverket fjerner de vanligste feilene automatisk, men gir også utviklere en falsk trygghet: den dagen noen når etter en UncheckedAccount for å spare tid, eller skriver et native program uten Anchors sikkerhetsnett, er kontrollene plutselig utviklerens eget ansvar igjen. En revisor som bare kjenner Anchor, men ikke native Solana, ser ikke nødvendigvis hvor det nettet er fjernet.

Move-paradokset: språket som skulle fjerne feilene

Move ble designet av tidligere Meta-ingeniører nettopp for å gjøre digitale verdier trygge på språknivå. Ressursmodellen gjør at et token ikke kan dupliseres eller mistes, det finnes ingen dinglende referanser, og mange feil som plager Solidity er umulige å skrive. Paradokset er at nettopp denne tryggheten skaper en falsk følelse av sikkerhet. Cetus viste at aritmetikk fortsatt biter: et bitskift, en grense satt feil med én bit, og de 256-bits heltallene Sui støtter nativt, lullet alle inn i troen på at overflyt var umulig.

Svaret fra de beste Move-revisorene er formell verifikasjon, altså å bevise matematisk at koden oppfyller bestemte egenskaper, ikke bare teste den. MoveBit var først til å ta i bruk Move Prover i Move-økosystemet, verktøyet som lar utviklere spesifisere egenskaper ved kontrakter i Move Specification Language (MSL) og deretter få dem verifisert automatisk. MoveBit laget formelle spesifikasjoner for store deler av Aptos-rammeverket. Formell verifikasjon er ikke en mirakelkur (den beviser bare det du husker å spesifisere), men for kritisk matematikk som den i Cetus er det den eneste metoden som i prinsippet kunne fanget feilen med sikkerhet. Når du vurderer en Move-revisor, er spørsmålet om de faktisk behersker denne teknikken eller bare gjør manuell gjennomgang.

Utfordringen er at formell verifikasjon er dyrt og tidkrevende, og at få team spesifiserer alle de kritiske egenskapene på forhånd. I praksis brukes den derfor mest på de mest verdifulle delene av koden, som kjernematematikk og tilgangskontroll. For en kjøper er det verdt å spørre konkret hvilke deler av kontrakten som ble formelt verifisert, og hvilke som bare ble lest manuelt; forskjellen avgjør hvor mye vekt du kan legge på et bestått.

OtterSec: fra CTF-scenen til Solanas husrevisor

OtterSec, grunnlagt i 2022 av Robert Chen (med bakgrunn fra Carnegie Mellon og sikkerhetsmiljøet Dataflow Security), har på få år blitt et av de mest brukte navnene i Solana-, Sui- og Aptos-verdenen, og tar også EVM-oppdrag. Etter Solana Compass sin profil har firmaet jobbet med over hundre protokoller, blant dem Solana Foundation, Jito Labs, Aftermath og altså Cetus, og sikret milliardbeløp i verdier. Chen har også en synlig forsknings- og verktøyprofil; på Accelerate-konferansen i 2025 la OtterSec fram verktøy for å dekompilere Solana-programmer, et svar på at det store flertallet av programmer på kjeden er lukket kildekode målt i beregning. At så mye av Solana-koden er lukket, er et sikkerhetsproblem i seg selv: brukere kan ikke selv verifisere hva et program gjør, og forskere kan ikke granske det uten å reversere maskinkoden. Slike offentlige verktøy løfter hele økosystemet, ikke bare de betalte oppdragene.

OtterSec illustrerer både styrken og begrensningen ved en topprevisor. På den ene siden er de så betrodde at de ble satt til å vokte de reddede Cetus-midlene sammen med Sui Foundation. På den andre siden er de også firmaet som flagget den beslektede konverteringsrisikoen i Cetus, men rangerte den som et forslag i stedet for et kritisk funn. Det er en nyttig påminnelse om at alvorlighetsgrad er en vurdering, ikke en fasit, og at et funn som nedgraderes kan bli til et hull på hundrevis av millioner. Chens egen nøkternhet, at kodemodellen er sikrere, men at økonomiske angrep er arkitektur-agnostiske, er kanskje den mest ærlige selvbeskrivelsen en revisor kan gi.

Zellic: hacking-verdensmestrene som kjøpte Code4rena

Zellic ble grunnlagt i 2020 av Stephen Tong og Jasraj Bedi, som møttes på CTF-scenen (Capture the Flag, konkurranser i praktisk hacking) og bygget laget Perfect Blue til å bli rangert som verdens beste. Den DNA-en er poenget: firmaet rekrutterer offensive sikkerhetsforskere og dekker et bredt spekter, etter egen beskrivelse EVM, Solana, Move (Aptos og Sui), Cosmos og ZK-kretser. Kundelisten inkluderer Sui, Mysten Labs, Solana Foundation, Hyperliquid, Polymarket og Morpho. For 2025 oppgir Zellic selv 247 kritiske og 308 høyt rangerte funn, og at 153 av 338 gjennomganger avdekket minst ett kritisk eller høyt funn.

Zellic skiller seg også ut strukturelt. I august 2024 kjøpte de konkurranseplattformen Code4rena, der en hær av uavhengige «wardens» konkurrerer om å finne feil, og kombinerte den med egne fastprisrevisjoner. Historien fikk en bismak da Code4rena senere ble avviklet i 2026 og kundene og forskerne ble tatt over av bug bounty-plattformen Immunefi, en påminnelse om at selv de store konsoliderer og forsvinner. For en kjøper er lærdommen at et firmas metode og eierskap kan endre seg raskt, og at en revisjon fra 2023 ikke nødvendigvis reflekterer samme organisasjon i 2026. Zellic var også, som nevnt, det siste firmaet som gikk god for Cetus-koden før angrepet.

Neodyme: de tyske Solana-veteranene

Der OtterSec og Zellic er brede, er Neodyme smalt og dypt. Firmaet ble stiftet som Neodyme AG i januar 2021 i Tyskland av Thomas Lambertz, Nico Grundel og Sebastian Fritsch, og begynte å granske Solanas egen kodebase allerede i 2020, før hovednettet var lansert. Etter Solana Compass sin oversikt har teamet ansvarlig avslørt over hundre feil i selve kjernekoden til blokkjeder, hvorav mer enn åtti ble rapportert inn i Solanas eget bug bounty-program. Det er en annen posisjon enn de andre: Neodyme jakter ikke bare feil i enkeltprotokoller, men i infrastrukturen alt annet står på.

Kundelisten gjenspeiler det, med navn som Marinade Finance, Lido på Solana, Orca, Drift Protocol, Squads Protocol og Solana Labs selv. Neodyme deler også mye av verktøyene sine åpent, blant annet solana-security-txt (en standard for at kontrakter kan oppgi kontaktinfo for sikkerhetsvarsler), et rammeverk for proof-of-concept-angrep, og fuzzing-verktøyet Riverguard. For et norsk prosjekt som bygger på Solana, er Neodyme eksempelet på et miljø der du betaler for dyp spisskompetanse på nettopp én kjede, i motsetning til et bredt multi-kjede-firma.

Sec3, Ackee og MoveBit: spesialistene med egne verktøy

De tre siste firmaene deler en filosofi: de bygger sin egen verktøykasse og selger like mye teknologi som timer. Sec3 (tidligere kjent under navnet Soteria) er en Solana-spesialist som kombinerer PhD-drevet formell verifikasjon, manuell revisjon, automatisk skanning og overvåking på kjeden. Flaggskipet er X-Ray, en automatisk skanner bygget spesifikt for Solana-programmer som dekker mer enn femti sårbarhetstyper i Sec3 sin egen taksonomi. Verktøyet parser Rust-kode, bygger et abstrakt syntakstre, oversetter det til LLVM-mellomkode og kjører statisk analyse over resultatet. Det finnes også som åpent kommandolinjeverktøy. Da Loopscale ble utnyttet i april 2025, hadde protokollen en Sec3-revisjon pågående parallelt med en ferdigstilt revisjon fra et annet firma, et treffende bilde på at revisjon er en prosess, ikke et stempel.

Ackee Blockchain holder til i Praha og har akademiske røtter i Czech Technical University; daglig leder Josef Gattermayer har doktorgrad. Ackee bygger to mye brukte åpne verktøy: Trident, en Rust-basert fuzzer for Solana-programmer støttet av Solana Foundation, og Wake for Solidity. Etter selskapets egne tall har de gjennomført 220 revisjoner, funnet over 2 500 problemer og avdekket 269 kritiske og høye funn i 104 revisjoner siden 2021, og Trident har allerede avdekket kritiske feil i kodebaser som Kamino og Marinade. Kundelisten spenner over både Solana og EVM, med navn som Lido, Safe og Aave.

MoveBit er et undermerke av BitsLab og har posisjonert seg som pioneren for sikkerhet i Move-økosystemet. Teamet består av folk med akademisk bakgrunn og publikasjoner på sikkerhetskonferanser, og som nevnt var de først til å bringe formell verifikasjon inn i Move via Move Prover. For Sui- og Aptos-prosjekter som vil ha noe mer enn manuell gjennomgang, er MoveBit et av få reelle valg. At de samtidig var blant firmaene som reviderte Cetus, understreker at selv en pioner innen formell verifikasjon bare beviser det som faktisk står i spesifikasjonen.

Revisorene utenfor EVM på ett brett

Tabellen samler de seks firmaene etter base, kjeder, egne verktøy og kjente oppdrag. Bruk den som utgangspunkt, ikke som en rangering: rett firma avhenger av hvilken kjede og hvilket språk du bygger på.

Hva koster en revisjon utenfor EVM?

Pris henger sammen med omfang, kompleksitet og hvor knapp kompetansen er. Bransjereferanser som Sherlocks prisoversikt for 2026 viser at en enkel jobb kan starte lavt, mens en stor og kompleks protokoll fort passerer flere hundre tusen dollar. Det viktige for norske kjøpere er premien: Rust- og Move-oppdrag prises typisk 25 til 45 prosent høyere enn tilsvarende Solidity-arbeid, nettopp fordi det finnes langt færre kvalifiserte revisorer. Tabellen under omregner grove nivåer til kroner med en dollarkurs rundt 9,5.

Merk at prisen sier lite om kvaliteten alene. En billig revisjon med for kort tid (typisk to til fire uker under press) rekker sjelden å gjøre skikkelig fuzzing eller formell verifikasjon, mens en dyr rapport uten oppfølging av rettelsene også har begrenset verdi. Antall persondager og hvem som faktisk gjorde arbeidet betyr mer enn totalsummen.

Store protokoller nøyer seg sjelden med én rapport. Modellen som har festet seg, er lag på lag: flere firmaer på samme kode, en offentlig konkurranse eller et bug bounty-program på toppen, og en ny gjennomgang ved hver større oppdatering. Det koster mer, men Cetus er den dyre påminnelsen om at én enkelt revisjon, uansett hvor kjent firmaet er, er et øyeblikksbilde og ikke en forsikring.

Slik vurderer du en Solana- eller Move-revisor

Siden ingen offentlig myndighet akkrediterer disse firmaene, må du gjøre kvalitetskontrollen selv. Her er de spørsmålene som faktisk skiller et seriøst miljø fra et gummistempel utenfor EVM:

• Riktig spesialisering: reviderer de faktisk Rust eller Move til daglig, eller er de et Solidity-hus som tar et sideoppdrag? Be om referanser på samme kjede og samme språk.
• Metodikk utover manuell lesning: bruker de fuzzing (Trident, Riverguard), statisk analyse (X-Ray) og formell verifikasjon (Move Prover) der det er relevant, eller bare øyne på skjermen?
• Åpenhet: ligger rapportene offentlig, slik Cetus sine gjorde? Kan du lese hvordan tidligere funn ble klassifisert og fulgt opp?
• Ferskhet og omfang: hvilken commit ble revidert, og hva var eksplisitt utenfor omfang? Cetus-feilen lå i nettopp den typen bibliotekskode som ofte utelates.
• Oppfølging: gjorde firmaet en ny gjennomgang etter at rettelsene ble gjort, eller stoppet det ved første rapport?

Det siste punktet er undervurdert. Ronghui Gu, medgründer og toppsjef i CertiK, har beskrevet kjernesvakheten ved punkt-i-tid-revisjoner slik: «Et prosjekt blir revidert én gang før lansering, består, og går så aldri tilbake til den koden igjen. Farevinduet lukkes ikke etter lansering.» En revisjon fra april dekker ikke koden du endret i mai. For en levende protokoll er kontinuerlig overvåking og nye gjennomganger ved hver større endring like viktig som den første rapporten.

Regelverket: Finanstilsynet, MiCA og ansvaret ingen tar

Et poeng norske lesere ofte overrasker seg over: ingen tilsynsmyndighet krever at smartkontraktkode revideres, og ingen godkjenner revisorene. MiCA gjelder i Norge gjennom EØS via kryptoeiendelsloven, i kraft fra 1. juli 2025, og Finanstilsynet fører tilsyn med tilbydere av kryptoeiendelstjenester (CASP) som børser og forvaltere. Men regelverket handler om selskapene, ikke om Rust- eller Move-koden bak en protokoll. Den første norske CASP-tillatelsen gikk til AK Jensen Norway AS i februar 2026, et signal om at rammeverket nå er reelt operativt, men det endrer ikke bildet for revisjon.

DORA, som stiller krav til digital operasjonell motstandskraft, gjelder for CASP-er fra 17. januar 2025, men dekker IT-drift og hendelseshåndtering hos den sentraliserte tilbyderen, ikke en kodegjennomgang av en smartkontrakt. Fullt desentralisert DeFi faller dessuten utenfor MiCA helt: det finnes ingen CASP å holde ansvarlig, og dermed heller ingen regulatorisk garanti uansett hvor mange revisjoner koden har vært gjennom. Til sammenligning har for eksempel finansielle revisorer i tradisjonell forstand et lovfestet erstatningsansvar; en smartkontraktrevisor har det praktisk talt aldri, siden kontraktene som regel fraskriver seg ansvar og kapper erstatningen til det honoraret som ble betalt. Konklusjonen er ubehagelig, men enkel: omdømme er den eneste domstolen som virker, og den virker tregt.

Revisjon er bare første lag: bug bounties, overvåking og obduksjoner

De beste prosjektene behandler revisjonen som ett lag i et forsvar med flere lag. Etter en revisjon kommer kontinuerlig overvåking på kjeden (Sec3 og andre tilbyr dette), automatiske skannere som kjører ved hver kodeendring, og et bug bounty-program som betaler white hat-forskere for å finne det revisjonen overså. Hvordan slike belønninger prises, og hvorfor det annonserte taket sjelden er det som faktisk utbetales, har vi gått gjennom i analysen av bug bounty-prising. Loopscale-saken viser verdien av laget: pengene kom tilbake etter forhandlinger, og protokollen stoppet markedene raskt takket være overvåking, ikke revisjon.

Automatiske verktøy og AI hjelper, men erstatter ikke dømmekraft. David Schwed, driftsdirektør i sikkerhetsselskapet SVRN, har advart mot å tro at maskinen gjør jobben alene: «’Claude, revider smartkontrakten min, ikke gjør noen feil’ er ikke et sikkerhetsprogram.» Verktøy som X-Ray og Trident finner de kjente mønstrene raskt og billig, men den økonomiske designfeilen (som i Mango) eller den nedgraderte alvorlighetsgraden (som i Cetus) krever et menneske som tenker som en angriper. Det siste laget er obduksjonen: når noe likevel går galt, er en ærlig gjennomgang det som bygger tillit tilbake. Firmaer som Halborn har gjort nettopp obduksjonen til en egen disiplin, og for den som vil lære å lese en slik rapport kritisk, har vi laget en egen veiledning.

Ofte stilte spørsmål

Hvem er de beste revisorene for Solana- og Move-kode?

De mest brukte er OtterSec (Solana, Sui, Aptos), Zellic (bredt multi-kjede med sterk CTF-bakgrunn), Neodyme (Solana-kjernekode), Sec3 (Solana pluss X-Ray-skanning), Ackee Blockchain (Solana-fuzzing med Trident) og MoveBit (formell verifikasjon for Move). Rett valg avhenger av kjede, språk og om du trenger fuzzing eller formell verifikasjon, ikke bare et kjent navn.

Er Solana tryggere enn Ethereum?

På kodenivå fjerner Solanas modell reentrancy, som er en stor angrepsflate på Ethereum, og tall for 2024 viste langt lavere kodetap på Solana. Men Solana har egne feilklasser (manglende signatur- og eierskapskontroller, kontoforvirring), og økonomiske angrep som orakelmanipulasjon rammer uansett kjede. Tryggere på ett punkt betyr ikke immun.

Hvorfor ble Cetus hacket når koden var revidert tre ganger?

Feilen lå i en overflytkontroll (checked_shlw) satt feil med én bit, i lavnivå matematikk som ofte faller utenfor omfanget. MoveBit og OtterSec reviderte i 2023, Zellic i april 2025. OtterSec flagget en beslektet risiko, men rangerte den som et forslag. En medvirkende årsak var troen på at overflyt ikke kan skje i Move, noe som viste seg feil.

Hva koster en Solana- eller Move-revisjon?

Grovt sett fra rundt 75 000 kroner for en liten modul til godt over tre millioner kroner for en stor, kompleks protokoll. Rust- og Move-oppdrag koster typisk 25 til 45 prosent mer enn tilsvarende Solidity-arbeid, fordi det finnes langt færre kvalifiserte revisorer. Antall persondager sier mer om grundigheten enn totalprisen.

Fanger en revisjon alle feil?

Nei. En revisjon er et øyeblikksbilde av koden slik den var på revisjonsdagen. Den fanger sjelden økonomiske designfeil, kompromitterte nøkler eller infrastruktur, eller kode som endres etter lansering. Derfor kombinerer seriøse prosjekter revisjon med fuzzing, formell verifikasjon, kontinuerlig overvåking og et bug bounty-program.

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