{"id":264,"date":"2026-08-20T05:07:01","date_gmt":"2026-08-20T05:07:01","guid":{"rendered":"https:\/\/hoge.gg\/no\/prisorakler-fire-lag-oev-okonomi-2026\/"},"modified":"2026-08-20T05:07:01","modified_gmt":"2026-08-20T05:07:01","slug":"prisorakler-fire-lag-oev-okonomi-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/prisorakler-fire-lag-oev-okonomi-2026\/","title":{"rendered":"Prisorakler forklart: de fire lagene og OEV-\u00f8konomien i 2026"},"content":{"rendered":"

Hver DeFi-protokoll har \u00e9n komponent som m\u00e5 gj\u00f8re noe resten av systemet ikke kan: strekke seg ut av blokkjeden og hente inn et tall fra virkeligheten. Hva er ett ether verdt akkurat n\u00e5? Hva koster en tokenisert Google-aksje dette sekundet? Svaret kommer fra et prisorakel, og i det \u00f8yeblikket smartkontrakten leser tallet, handler den p\u00e5 det uten \u00e5 stille sp\u00f8rsm\u00e5l. Den l\u00e5ner ut mot det, likviderer mot det, utsteder mot det. Er tallet feil, er ikke feilen teoretisk. Den utf\u00f8res p\u00e5 millisekunder, og pengene er borte f\u00f8r noen rekker \u00e5 reagere.<\/p>

Gjennom 2026 har vi sett angrepspunktet flytte seg. De klassiske angrepene dyttet en tynn markedspris med et flash-l\u00e5n. De nyeste g\u00e5r h\u00f8yere opp i stabelen, mot selve infrastrukturen som signerer og leverer prisen, eller lenger ned, mot m\u00e5ten en protokoll tolker et tall den egentlig aldri burde ha stolt p\u00e5. Denne artikkelen tar ikke for seg nok en liste over hack. Den bryter oracle-risiko ned i de fire lagene et pristall passerer p\u00e5 vei fra markedet til smartkontrakten, og ser p\u00e5 \u00f8konomien som har vokst frem rundt disse tallene: hvem som tjener p\u00e5 at en pris oppdateres, og hvem som betaler.<\/p>

Sergey Nazarov, medgr\u00fcnder av Chainlink, har en teori om hvorfor temaet er underkommunisert. Til The Defiant sa han<\/a> at \u00abI think the only reason these very dangerous patterns are not as discussed is because the losses have not been Mt. Gox level\u00bb. Med andre ord: problemet er ikke l\u00f8st, det har bare ikke kostet nok enn\u00e5 til \u00e5 tvinge frem oppmerksomheten. Summene i 2026 antyder at den tiden er i ferd med \u00e5 ta slutt.<\/p>

Hva et prisorakel egentlig er, og hvorfor det er DeFis svakeste ledd<\/h2>

En blokkjede er med vilje en lukket verden. Den er deterministisk: hver node m\u00e5 komme frem til n\u00f8yaktig samme resultat, ellers blir de aldri enige om tilstanden. Derfor kan ikke en smartkontrakt ringe et API, sjekke en nettside eller sp\u00f8rre en b\u00f8rs hva noe koster. Alt den vet, er det som allerede ligger p\u00e5 kjeden. Et orakel er broen over dette gapet: en mekanisme som henter et tall fra utsiden, pakker det inn i en transaksjon og legger det on-chain, slik at kontrakten kan lese det.<\/p>

Problemet er at en bro ogs\u00e5 er et tillitsforhold. Smartkontrakten kan ikke se forskjell p\u00e5 en ekte pris og en manipulert pris, s\u00e5 lenge tallet er levert p\u00e5 riktig format fra en kilde den er satt opp til \u00e5 stole p\u00e5. Den ser et tall, ikke en historie. Denne blindheten er grunnen til at Open Web Application Security Project rangerer nettopp prismanipulasjon som SC03 p\u00e5 sin Smart Contract Top 10 for 2026<\/a>, blant de mest utnyttede feilklassene i bransjen. Chainalysis har p\u00e5 sin side pekt p\u00e5 at oracle-manipulasjon er en angrepstype som nesten er unik for DeFi<\/a>: i tradisjonell finans finnes det ikke ett enkelt tall som automatisk og uigjenkallelig utl\u00f8ser millioner i utbetalinger i det sekundet det endrer seg.<\/p>

For \u00e5 forst\u00e5 hvor et orakel brister, hjelper det \u00e5 slutte \u00e5 behandle det som \u00e9n ting. Et pristall er ikke f\u00f8dt ferdig. Det reiser gjennom fire lag f\u00f8r en smartkontrakt handler p\u00e5 det, og hvert lag har sin egen m\u00e5te \u00e5 svikte p\u00e5. Deler du en hendelse opp etter hvilket lag som falt, ser du ogs\u00e5 med \u00e9n gang hvorfor forsvaret som stoppet forrige angrep var virkningsl\u00f8st mot det neste.<\/p>

Orakel-problemet i fire lag: fra marked til smartkontrakt<\/h2>

Tenk p\u00e5 reisen et tall tar. F\u00f8rst finnes det en kilde: ett eller flere markeder der en pris faktisk oppst\u00e5r gjennom handel. S\u00e5 kommer aggregeringen, der mange kilder sl\u00e5s sammen til ett representativt tall, gjerne en median, et tidsvektet snitt eller et tall med et konfidensintervall. Deretter leveringen, der tallet signeres kryptografisk og sendes on-chain, enten dyttet ut av orakelet selv (push) eller hentet inn p\u00e5 foresp\u00f8rsel av brukeren (pull). Til slutt konsumet, der protokollen leser tallet og gj\u00f8r noe med det, som \u00e5 avgj\u00f8re om en posisjon skal likvideres.<\/p>

Nesten alle oracle-angrep kan plasseres i ett av disse fire lagene. Det er en nyttig linse, fordi forsvaret som stopper et angrep p\u00e5 kildelaget (for eksempel et tidsvektet snitt) er fullstendig virkningsl\u00f8st mot et angrep p\u00e5 leveringslaget (en stj\u00e5let signeringsn\u00f8kkel). Tabellen under viser lagene, hva de gj\u00f8r, og hvordan de typisk brister.<\/p>

Lag<\/th>Hva det gj\u00f8r<\/th>Typisk sviktm\u00e5te<\/th>Eksempel<\/th><\/tr><\/thead>
1. Kilden<\/td>Henter r\u00e5 markedspris fra b\u00f8rser og DEX-er<\/td>Prisen leses fra ett marked som er for tynt til \u00e5 motst\u00e5 et dytt<\/td>bZx, Mango, YieldBlox<\/td><\/tr>
2. Aggregeringen<\/td>Sl\u00e5r sammen mange kilder til ett tall (median, TWAP, konfidensintervall)<\/td>For f\u00e5 kilder, eller et snitt som kan mettes over flere blokker<\/td>Harvest, UwU Lend<\/td><\/tr>
3. Leveringen<\/td>Signerer tallet og sender det on-chain (push eller pull)<\/td>Kompromittert signeringsn\u00f8kkel, eller en verifikator som godtar en ugyldig signatur<\/td>Ostium, Bonzo<\/td><\/tr>
4. Konsumet<\/td>Protokollen tolker tallet og handler p\u00e5 det<\/td>Et internt regnskapstall (andelskurs, vekslingsrate) forveksles med en ekte pris<\/td>Venus, Edel, Aave CAPO<\/td><\/tr><\/tbody><\/table><\/figure>

Lag 1, kilden: en pris hentet fra et for tynt marked<\/h2>

Det klassiske oracle-angrepet lever her. Et orakel leser spotprisen fra \u00e9n DEX-pool eller ett tynt marked. Angriperen forvrenger det markedet et kort \u00f8yeblikk, orakelet rapporterer den forvrengte prisen som om den var ekte, protokollen handler p\u00e5 den, og angriperen tar gevinsten f\u00f8r markedet knipser tilbake til normalen. Ingen kode ble brutt. Orakelet gjorde n\u00f8yaktig jobben sin: det rapporterte prisen i markedet det var satt til \u00e5 lese. Feilen var \u00e5 stole p\u00e5 et marked som var billig \u00e5 flytte.<\/p>

Her kommer flash-l\u00e5net inn, og det er verdt \u00e5 sl\u00e5 fast tidlig at flash-l\u00e5net er forsterkeren, ikke selve feilen. Et flash-l\u00e5n er et l\u00e5n uten sikkerhet som m\u00e5 tas opp og betales tilbake i samme transaksjon; g\u00e5r tilbakebetalingen ikke i orden, reverseres alt. Det gir en angriper tilgang p\u00e5 hundretalls millioner i kapital i noen millisekunder, uten \u00e5 eie en krone selv. Men kapitalen gj\u00f8r bare skade fordi orakelet stoler p\u00e5 et marked som kan dyttes. Mot et robust orakel er uendelig kapital verdil\u00f8st.<\/p>

Det f\u00f8rste flash-l\u00e5n-drevne oracle-angrepet var bZx i februar 2020, p\u00e5 rundt 350 000 dollar (cirka 3,3 millioner kroner, omregnet til en kurs p\u00e5 rundt 9,53 kroner per dollar), der ETH ble pumpet p\u00e5 et tynt marked. CertiK regner det som starten p\u00e5 hele angrepsklassen<\/a>. Samme h\u00f8st tok Harvest Finance rundt 24 millioner dollar (cirka 229 millioner kroner) da et flash-l\u00e5n skjevstilte en Curve-pool protokollen brukte til prising, og i juni 2024 ble UwU Lend tappet for rundt 19,3 millioner dollar (cirka 184 millioner kroner) via en manipulert sUSDE-pris; Halborn har samlet flere av disse i sin oversikt over de st\u00f8rste oracle-hackene<\/a>.<\/p>

2026-utgaven av n\u00f8yaktig samme id\u00e9 rammet YieldBlox p\u00e5 Stellar i februar. Protokollen brukte et VWAP-orakel for token-paret USTRY mot USDC. Den eneste markedsakt\u00f8ren hadde trukket likviditeten, slik at det ikke var registrert en eneste handel p\u00e5 et kvarter. Angriperen la inn \u00e9n salgsordre til rundt 501 USDC per USTRY, omtrent hundre ganger for h\u00f8yt, og dyttet prisen fra rundt 1,06 til 106,74 dollar. Deretter satte angriperen inn mer USTRY, som n\u00e5 ble lest som sikkerhet verdt rundt 15,99 millioner dollar mot en reell verdi p\u00e5 rundt 158 500 dollar. Resultatet ble et tap p\u00e5 rundt 10,2 millioner dollar (cirka 97 millioner kroner). Sikkerhetsselskapet Halborn, som HOGE Wire har portrettert tidligere<\/a>, dokumenterte forl\u00f8pet<\/a> og pekte p\u00e5 det \u00e5penbare: et orakel m\u00e5 aldri stole p\u00e5 et marked der ingen handler.<\/p>

Lag 2, aggregeringen: median, TWAP og konfidensintervaller<\/h2>

Kildelaget er der de fleste forsvarsmekanismene bor, fordi det er der de klassiske angrepene traff. Den f\u00f8rste og enkleste er \u00e5 aldri lese fra \u00e9n kilde. Chainlink bygger p\u00e5 et desentralisert nettverk av uavhengige node-operat\u00f8rer (et DON, Decentralized Oracle Network) som hver rapporterer en pris, og medianen tas. For \u00e5 flytte tallet m\u00e5 du korrumpere et flertall av operat\u00f8rene samtidig, ikke bare dytte ett marked. Dette er en push-modell: nettverket skyver oppdaterte priser ut p\u00e5 kjeden med jevne mellomrom eller n\u00e5r avviket blir stort nok.<\/p>

Den andre er TWAP, et tidsvektet gjennomsnitt. I stedet for \u00f8yeblikksprisen brukes snittet over en periode, gjerne flere blokker. Det gj\u00f8r et flash-l\u00e5n nesten nyttel\u00f8st, fordi en manipulasjon som lever og d\u00f8r i \u00e9n transaksjon knapt r\u00f8rer et snitt m\u00e5lt over mange blokker. Svakheten er like viktig \u00e5 forst\u00e5: TWAP motst\u00e5r manipulasjon i \u00e9n blokk, men ikke manipulasjon over flere blokker. Klarer en angriper \u00e5 holde prisen forvrengt lenge nok, siger snittet etter, og forsvaret forsvinner.<\/p>

Den tredje kommer fra pull-baserte orakler som Pyth, som henter priser fra f\u00f8rstepartspublisister (b\u00f8rsene og markedsakt\u00f8rene selv) og leverer hver oppdatering med et konfidensintervall, alts\u00e5 et m\u00e5l p\u00e5 hvor sikker prisen er. En godt bygget protokoll blir mer forsiktig n\u00e5r konfidensen er lav, for eksempel ved \u00e5 utsette likvidasjoner eller utvide marginene. Men intervallet hjelper bare hvis protokollen faktisk leser og respekterer det. Og her ligger den store begrensningen ved hele lag 2: uansett hvor god aggregeringen er, forsvarer den kilden. Den gj\u00f8r ingenting hvis tallet i utgangspunktet er et regnskapstall og ikke en markedspris, eller hvis selve leveringen er kompromittert. Det er nettopp dit angriperne flyttet i 2026.<\/p>

Lag 3, leveringen: n\u00e5r selve infrastrukturen blir v\u00e5penet<\/h2>

Hvis du kan f\u00e5 orakelet til \u00e5 signere et falskt tall, trenger du ikke \u00e5 flytte noe marked i det hele tatt. Da spiller det ingen rolle hvor mange kilder som aggregeres eller hvor langt TWAP-vinduet er. Signaturen blir stolt p\u00e5, og alt nedstr\u00f8ms f\u00f8lger. Dette er leveringslaget, og det var her de mest urovekkende hendelsene i 2026 traff.<\/p>

Bonzo Lend p\u00e5 Hedera, 11. juli 2026, er det reneste eksempelet. Angriperen satte f\u00f8rst inn 250 SAUCE, og elleve minutter senere sendte inn en prisoppdatering til Supras on-demand-orakel som bl\u00e5ste opp SAUCE-prisen med rundt tolv st\u00f8rrelsesordener. Det oppsiktsvekkende: signaturen besto utelukkende av nuller. Supras verifikatorkontrakt hadde en feil i signatursjekken og godtok den likevel. Med den falske prisen p\u00e5 plass l\u00e5nte angriperen 6,63 millioner USDC og 34,5 millioner wHBAR, til sammen rundt 9,05 millioner dollar (cirka 86 millioner kroner), og Bonzos totale verdi l\u00e5st falt 77 prosent p\u00e5 et d\u00f8gn. En annen lommebok tok ytterligere rundt en million dollar, meldte seg selv som white hat og lovet \u00e5 levere tilbake. Supra rullet ut en retting i l\u00f8pet av timer, if\u00f8lge CoinDesk<\/a>.<\/p>

Ostium p\u00e5 Arbitrum, midt i juli 2026, var verken markedsmanipulasjon eller en signaturfeil, men en kompromittert n\u00f8kkel. Angriperen fikk tak i orakelets private signeringsn\u00f8kkel, registrerte en egen PriceUpKeep-forwarder og sendte inn fremtidsdaterte, korrekt signerte rapporter for \u00e5 konstruere falske handelsgevinster. Det initiale tapet var rundt 18 millioner dollar (cirka 172 millioner kroner), med senere anslag opp mot 23,75 millioner, rundt en tredel av protokollens verdi. Overv\u00e5kingsselskapet Blockaid fanget opp m\u00f8nsteret, skriver CoinDesk<\/a>. L\u00e6rdommen fra begge sakene er den samme: ingen median og ingen TWAP hjelper n\u00e5r signaturen selv er brutt. Det ligner mer p\u00e5 et bro-hack, der en tillitsmodell brister<\/a>, enn p\u00e5 klassisk prismanipulasjon, og det b\u00f8r leses deretter.<\/p>

Lag 4, konsumet: n\u00e5r et regnskapstall forveksles med en pris<\/h2>

Det subtile laget er det siste, og det minst forst\u00e5tte. Noen ganger er orakelet helt korrekt og markedet ur\u00f8rt, men protokollen leser feil tall. Den behandler et internt regnskapstall, som hvem som helst kan p\u00e5virke, som om det var en ekstern markedspris. Angrepet flytter ingen pris. Det utnytter at protokollen aldri burde ha brukt tallet som en pris i det hele tatt.<\/p>

Det klareste eksempelet er ERC-4626-vaulter. En vault utsteder andeler, og andelskursen er totale eiendeler delt p\u00e5 antall andeler. Det er et regnskapsforhold, ikke en markedspris. Bruker en utl\u00e5nsprotokoll andelskursen til \u00e5 verdsette sikkerhet, kan en angriper bl\u00e5se den opp med et donasjonsangrep: donere eiendeler rett inn i vaulten, eller kj\u00f8re en l\u00f8kke av innl\u00f8sning og ny donasjon, slik at forholdstallet stiger. S\u00e5 l\u00e5nes det mot de kunstig oppbl\u00e5ste andelene, og angriperen g\u00e5r. Et lignende angrep rammet en wUSDM-basert vault p\u00e5 Venus i februar 2025, der en donasjonssl\u00f8yfe finansiert av et flash-l\u00e5n dyttet vekslingsraten oppover og etterlot protokollen med tapsbringende gjeld.<\/p>

Samme mekanisme gjelder wrappede token, der vekslingsraten mellom det wrappede og det underliggende ogs\u00e5 bare er et internt tall. Det er dette som gj\u00f8r lag 4 s\u00e5 farlig: hvert eneste forsvar p\u00e5 lag 1 og 2, median og TWAP og konfidensintervall, er nyttel\u00f8st, fordi tallet som manipuleres aldri var en markedspris. Det er protokollens egen bokf\u00f8ring. Rhea Finance p\u00e5 NEAR i april 2026 er en beslektet variant: her lurte angriperen validerings- og prislaget ved \u00e5 opprette falske token-kontrakter og selv fylle nye pooler med likviditet, slik at protokollen trodde verdiene var reelle, og tappet rundt 7,6 millioner dollar (cirka 72 millioner kroner). Halborn beskriver forl\u00f8pet i detalj<\/a>. Men den vakreste illustrasjonen kom fra en tokenisert aksje.<\/p>

Aksjen som \u00absteg\u00bb 7 700 prosent: Edel Finance og den tokeniserte fronten<\/h2>

1. juli 2026 ble Edel Finance rammet. Sikkerheten var wGOOGLx, en wrappet utgave av en tokenisert Google-aksje fra xStocks-familien. Angriperen tok et flash-l\u00e5n p\u00e5 180 000 USDC fra Morpho Blue og kj\u00f8rte en l\u00f8kke der GOOGLx gjentatte ganger ble innl\u00f8st og donert p\u00e5 nytt inn i en ERC-4626-vault. Wrapping-forholdet ble dyttet fra rundt 6 til rundt 79, en oppbl\u00e5sing p\u00e5 cirka 7 700 prosent. Angriperen l\u00e5nte mot den n\u00e5 voldsomt overvurderte wGOOGLx-sikkerheten og tok med seg rundt 403 000 dollar (cirka 3,8 millioner kroner), som ble vasket gjennom Tornado Cash i l\u00f8pet av timer. Protokollen ble satt p\u00e5 pause, lovet \u00e5 gj\u00f8re balansene hele igjen \u00e9n til \u00e9n og bygger seg opp igjen som Edel V2.<\/p>

Det avgj\u00f8rende poenget, og grunnen til at denne saken h\u00f8rer hjemme \u00f8verst i enhver forklaring av lag 4, er dette: Chainlinks underliggende prisfeed for Google-aksjen var korrekt hele veien. Google-aksjen beveget seg ikke. Orakelet ble aldri manipulert. Feilen l\u00e5 utelukkende i wGOOGLx-wrappingen, et regnskapstall protokollen feilaktig behandlet som en pris. CoinDesk kalte det sjeldent<\/a>, men det er egentlig et forvarsel: du kan ha et feilfritt orakel og likevel tape alt, hvis du gir protokollen feil tall \u00e5 lese.<\/p>

Og her ligger 2026-relevansen. Tokeniserte virkelige verdier (RWA), alts\u00e5 aksjer, statsobligasjoner og fond lagt p\u00e5 kjeden, er \u00e5rets vekstfortelling. Hver eneste av dem multipliserer angrepsflaten p\u00e5 lag 4. Hver wrapper, hver renteberegnende vault-andel, hvert rebasing-token er et nytt internt tall som ser ut som en pris, men ikke er det. N\u00e5r RWA-sektoren vokser, vokser denne angrepsflaten i takt, og Edel-saken er det f\u00f8rste tydelige tegnet p\u00e5 at angriperne allerede har oppdaget det. En protokoll som legger tokeniserte aksjer inn som sikkerhet uten \u00e5 skille skarpt mellom den ekte prisen og wrapping-tallet, gjentar Edels feil f\u00f8r eller siden.<\/p>

OEV: den skjulte \u00f8konomien i hver likvidasjon<\/h2>

Ikke all verdi som str\u00f8mmer ut av en oracle-oppdatering er tyveri. Det finnes en legitim, men omstridt \u00f8konomi som kalles Oracle Extractable Value, OEV. N\u00e5r et orakel legger ut en ny pris som dytter et l\u00e5n under vann, skaper selve oppdateringen en gevinstmulighet: den som utf\u00f8rer likvidasjonen f\u00f8rst, tjener likvidasjonsbonusen. Den bonusen betales i praksis av l\u00e5ntakeren, og historisk har den lekket ut til en tilfeldig tredjepart.<\/p>

OEV er slektningen til MEV (Maximal Extractable Value), men knyttet spesifikt til \u00f8yeblikket et orakel oppdateres. Der MEV handler om verdi som kan presses ut n\u00e5r transaksjoner ordnes i en blokk, handler OEV om verdien som frigj\u00f8res i det pristallet endrer seg. Poenget er at den som kontrollerer eller kan snike seg foran akkurat den oppdateringen, kontrollerer verdien. Tradisjonelt vant block-byggere og validatorer det kappl\u00f8pet, og likvidasjonsbonusen endte hos dem i stedet for hos protokollen eller brukerne som skapte verdien. API3, en av oracle-leverand\u00f8rene, beskriver OEV som oraklers evne<\/a> til \u00e5 fange verdi fra sin egen privilegerte posisjon.<\/p>

Dette er verdt \u00e5 forst\u00e5 selv om du aldri kj\u00f8rer en likvidasjonsbot, fordi OEV er speilbildet av manipulasjon. Det er den samme spaken, kontroll over \u00f8yeblikket oppdateringen skjer, men vendt mot \u00e5 ta verdien tilbake til brukerne i stedet for \u00e5 stjele den. \u00c5 forst\u00e5 OEV er \u00e5 forst\u00e5 at et orakel ikke bare er en datastr\u00f8m. Det er et \u00f8konomisk trangt punkt, et sted der store verdier passerer og kan omdirigeres.<\/p>

\u00c5 ta verdien tilbake: Chainlink SVR og API3s OEV Network<\/h2>

To ulike svar p\u00e5 OEV-problemet har modnet i 2025 og 2026. Det f\u00f8rste er Chainlink SVR (Smart Value Recapture), lansert sammen med Aave p\u00e5 Ethereum, bygget i samarbeid med blant andre BGD Labs og Flashbots. SVR pakker oracle-oppdateringen sammen med en auksjon som fanger likvidasjons-MEV-en og returnerer den til protokollen i stedet for \u00e5 la den lekke til validatorer. Mekanismen er bevisst begrenset til likvidasjoner og kan ikke misbrukes til front-running eller sandwich-angrep. Chainlink har oppgitt at SVR har gjenvunnet godt over en million dollar i ikke-toksisk likvidasjons-MEV p\u00e5 tvers av titalls millioner i behandlede likvidasjoner, med inntektene delt rundt 65 mot 35 til fordel for Aave-DAO-en, if\u00f8lge Chainlinks egen redegj\u00f8relse<\/a>.<\/p>

Det andre svaret er API3s OEV Network, som tar en annen vei: en dedikert auksjonskjede (en ZK-rollup) der s\u00f8kere byr p\u00e5 retten til \u00e5 utf\u00f8re en bestemt datafeed-oppdatering for en bestemt applikasjon. Vinnerbudet betales til nettopp den applikasjonen som skapte verdien. Begge tiln\u00e6rmingene gj\u00f8r en lekkasje om til en inntektsstr\u00f8m, og begge illustrerer det samme underliggende poenget som resten av denne artikkelen: den som styrer oracle-oppdateringen, styrer pengene. Forskjellen mellom en OEV-mekanisme og et oracle-angrep er ikke teknologien. Det er hvem verdien til slutt havner hos.<\/p>

Leverand\u00f8rene og avveiningene: Chainlink, Pyth, RedStone, API3 og Supra<\/h2>

Det finnes ikke ett orakel som er \u00abdet trygge\u00bb. Hver leverand\u00f8r veier avveiningene ulikt, og valget avgj\u00f8r hvilke lag en protokoll faktisk forsvarer. Chainlink er den klart st\u00f8rste akt\u00f8ren, med anslagsvis rundt 70 prosent av verdien som sikres av orakler if\u00f8lge DefiLlamas oversikt<\/a>, og bygger p\u00e5 push og desentralisert median. Styrken er at det kreves et flertall av \u00e6rlige operat\u00f8rer for \u00e5 flytte tallet; svakheten er nettopp den samme antakelsen. Pyth henter priser on-demand fra f\u00f8rstepartspublisister med konfidensintervall, spredt over mange kjeder, men er bare s\u00e5 trygt som protokollens vilje til \u00e5 respektere intervallet. Tabellen oppsummerer landskapet.<\/p>

Leverand\u00f8r<\/th>Modell<\/th>N\u00f8kkeltrekk<\/th>Kjent svakhet eller hendelse<\/th><\/tr><\/thead>
Chainlink<\/td>Push, desentralisert nettverk (DON), median<\/td>St\u00f8rst; SVR for OEV-gjenvinning<\/td>Avhenger av at et flertall av operat\u00f8rer er \u00e6rlige<\/td><\/tr>
Pyth<\/td>Pull, f\u00f8rstepartspublisister med konfidensintervall<\/td>Hentes on-demand; mange kjeder<\/td>Intervallet m\u00e5 faktisk brukes av protokollen<\/td><\/tr>
RedStone<\/td>Modul\u00e6r pull og push<\/td>Popul\u00e6r for LST\/LRT og RWA<\/td>Ferskere akt\u00f8r, mindre kamptestet<\/td><\/tr>
API3<\/td>F\u00f8rsteparts-dAPI-er pluss OEV Network<\/td>Auksjonerer OEV tilbake til applikasjonen<\/td>Mindre markedsandel<\/td><\/tr>
Supra<\/td>Push og pull med egen verifikator<\/td>Rask endelighet<\/td>Verifikatorfeil utnyttet i Bonzo-saken<\/td><\/tr><\/tbody><\/table><\/figure>

Konklusjonen for en leser er ikke \u00e5 lete etter et logo-stempel. Sp\u00f8rsm\u00e5let er aldri bare \u00abbruker den Chainlink\u00bb, men \u00abhvilket lag forsvarer dette oppsettet faktisk, og hvilket lar det st\u00e5 \u00e5pent\u00bb. En protokoll kan bruke en helt solid leverand\u00f8r p\u00e5 kildelaget og likevel st\u00e5 vid\u00e5pen p\u00e5 konsumlaget, slik Edel gjorde.<\/p>

Da forsvaret bommet: Aave, CAPO og et regnskapstall som ble for gammelt<\/h2>

Aave bygde et eget svar p\u00e5 lag 4-problemet: CAPO (Correlated Asset Price Oracle). For renteberegnende eiendeler som wstETH setter CAPO et tak p\u00e5 hvor raskt den avledede vekslingsraten f\u00e5r lov til \u00e5 vokse, slik at et donasjonsangrep ikke kan bl\u00e5se den opp momentant. Det er et gjennomtenkt forsvar, plassert n\u00f8yaktig i riktig lag. I mars 2026 bommet det likevel, og p\u00e5 en l\u00e6rerik m\u00e5te.<\/p>

Feilen var ikke et angrep, men en feilkonfigurasjon. Et misforhold mellom snapshotRatio og snapshotTimestamp gjorde at tidsstemplet ble hengende rundt syv dager for gammelt, og det fikk CAPO til \u00e5 undervurdere wstETH med rundt 2,85 prosent. Den kunstig lave verdien utl\u00f8ste uberettigede likvidasjoner: 34 kontoer, rundt 26 millioner dollar i likvidasjonsvolum, rundt 382 ETH til likvidatorene, men null tapsbringende gjeld for protokollen. Chaos Labs-gr\u00fcnder Omer Goldberg lovet full kompensasjon og slo fast at \u00abEvery affected user will be fully reimbursed\u00bb, i protokollens egen obduksjon<\/a>.<\/p>

Ironien er verdt \u00e5 dvele ved. CAPO er en avledet-pris-vokter, og den sviktet som en avledet-pris-mekanisme: et internt tall (tidsstemplet) ble for gammelt og forgiftet resultatet. Forsvaret levde i samme lag som trusselen. Den dypere l\u00e6rdommen gjelder alle mitigeringer: en beskyttelsesmekanisme er ogs\u00e5 bare kode som leser et tall og handler p\u00e5 det. Den har sitt eget orakel-problem, ett niv\u00e5 opp. Du m\u00e5 vokte vokteren.<\/p>

Mango-presedensen: er det en forbrytelse \u00e5 manipulere en tillatelsesl\u00f8s pris?<\/h2>

Den st\u00f8rste og mest gjennomprosederte oracle-manipulasjonen er fortsatt Mango Markets fra oktober 2022, p\u00e5 rundt 110 millioner dollar (cirka 1,05 milliarder kroner). Avraham Eisenberg finansierte to kontoer, tok motsatte long- og short-posisjoner i MNGO-perper, og kj\u00f8pte deretter MNGO p\u00e5 tvers av b\u00f8rsene som matet Mangos orakel, slik at prisen steg rundt 2 300 prosent p\u00e5 minutter. Den oppbl\u00e5ste MNGO-prisen fikk sikkerheten hans til \u00e5 se enorm ut, han l\u00e5nte over 100 millioner dollar mot den og t\u00f8mte kassen. Senere leverte han tilbake rundt 67 millioner mot et l\u00f8fte fra DAO-en om ikke \u00e5 bli anmeldt, og beholdt rundt 47 millioner, if\u00f8lge det amerikanske tilsynet CFTC<\/a>.<\/p>

Det som gj\u00f8r saken til en presedens, er at han ikke skjulte noe. Dagen etter omtalte han det selv som at han hadde v\u00e6rt \u00abinvolved with a team that operated a highly profitable trading strategy last week\u00bb, som CoinDesk gjenga<\/a>. B\u00e5de CFTC og SEC anla sivile s\u00f8ksm\u00e5l, og p\u00e5talemyndigheten fikk ham d\u00f8mt i 2024.<\/p>

S\u00e5, i mai 2025, opphevet en f\u00f8deral dommer alle de strafferettslige domfellelsene. Delvis handlet det om verneting (handlingene ble utf\u00f8rt fra Puerto Rico), men mest avgj\u00f8rende om frav\u00e6ret av en vesentlig uriktig fremstilling: Mango hadde ingen brukervilk\u00e5r, ingen regler mot manipulasjon og ingen tilbakebetalingsplikt. Dommeren p\u00e5pekte at koden brukte ordet \u00abborrow\u00bb, men at \u00abthat word could have been ‘Access Collateral,’ ‘Utilize Assets,’ or anything else for that matter\u00bb, gjengitt av TRM Labs<\/a>. Lover en tillatelsesl\u00f8s protokoll ingenting, har p\u00e5talemyndigheten ingenting \u00e5 peke p\u00e5 som en l\u00f8gn.<\/p>

Dette er det ul\u00f8ste sp\u00f8rsm\u00e5let en norsk leser b\u00f8r sitte igjen med. N\u00e5r \u00abmanipulasjonen\u00bb bare er \u00e5 bruke en protokoll n\u00f8yaktig slik koden tillater, er det da bedrageri, eller er det protokollens egen designfeil? Svaret er reelt uavklart, og det avgj\u00f8r om ofre noen gang ser en krone igjen. Denne uklarheten er n\u00e6rt beslektet med sp\u00f8rsm\u00e5lene rundt styringsangrep, der avstemningen blir v\u00e5penet<\/a>: ogs\u00e5 der brukes systemets egne regler mot det. Eisenberg soner for \u00f8vrig i dag en fengselsstraff i en helt urelatert sak.<\/p>

Slik leser du et orakels sikkerhet f\u00f8r du setter inn en krone<\/h2>

Du trenger ikke \u00e5 lese Solidity for \u00e5 vurdere oracle-risiko. Du trenger \u00e5 sp\u00f8rre hvilke lag en protokoll forsvarer, og g\u00e5 gjennom de fire som en sjekkliste. P\u00e5 kilden: brukes en median av flere dype markeder, eller \u00e9n DEX-pool? P\u00e5 aggregeringen: finnes TWAP og avvikssjekker? P\u00e5 leveringen: er signatur- og verifikatorkoden revidert, og roteres n\u00f8klene? P\u00e5 konsumet, det farligste i 2026: brukes r\u00e5 vault-andeler eller wrapping-rater som pris, eller er de avledede tallene beskyttet med et veksttak av CAPO-typen?<\/p>

To metasignaler er verdt like mye som de tekniske. Det f\u00f8rste er obduksjonskultur. En protokoll som legger frem en klar og \u00e6rlig gjennomgang etter en hendelse, er tryggere enn en som blir stille. \u00c5 l\u00e6re \u00e5 lese slike obduksjoner er en ferdighet i seg selv, og HOGE Wire har en egen guide til \u00e5 lese en exploit-obduksjon<\/a>. Det andre er en aktiv bug bounty. Et seri\u00f8st og godt priset dus\u00f8rprogram gir white hats en lovlig og lukrativ grunn til \u00e5 melde en feil i stedet for \u00e5 utnytte den; Bonzo-hvithatten som leverte tilbake rundt en million dollar, er nettopp det m\u00f8nsteret som virker. Hvordan slike dus\u00f8rer prises, er en egen \u00f8konomi<\/a>. Tabellen under er en rask m\u00e5te \u00e5 score et oppsett p\u00e5.<\/p>

Sjekk<\/th>Gr\u00f8nt flagg<\/th>R\u00f8dt flagg<\/th><\/tr><\/thead>
Kilde<\/td>Median av flere dype markeder<\/td>\u00c9n DEX-pool brukt som pris<\/td><\/tr>
Aggregering<\/td>Desentralisert nettverk med avvikssjekk<\/td>R\u00e5 spotpris uten filter<\/td><\/tr>
Tid<\/td>TWAP over flere blokker<\/td>Ren \u00f8yeblikkspris<\/td><\/tr>
Avledede tall<\/td>Andelskurs med veksttak (CAPO-lignende)<\/td>Vault-andel brukt r\u00e5tt som pris<\/td><\/tr>
Sirkelbrytere<\/td>Automatisk pause ved unormalt avvik<\/td>Ingen stans, uansett avvik<\/td><\/tr>
Levering<\/td>Revidert verifikator og n\u00f8kkelrotasjon<\/td>Ukjent eller ny signaturkode<\/td><\/tr>
\u00c5penhet<\/td>Offentlig obduksjon og aktiv bug bounty<\/td>Ingen obduksjonskultur<\/td><\/tr><\/tbody><\/table><\/figure>

Hva dette betyr for norske brukere og byggere<\/h2>

Det norske regelverket gir mindre tr\u00f8st enn mange tror. MiCA gjelder i Norge gjennom E\u00d8S-avtalen, og Finanstilsynet f\u00f8rer tilsyn med kryptotjenestetilbydere (CASP-er), alts\u00e5 b\u00f8rser og forvaringstjenester. Men MiCA regulerer mellomleddene, ikke selve protokollen. En fullt desentralisert DeFi-protokoll uten en operat\u00f8r faller utenfor CASP-reglene. Taper du penger p\u00e5 en oracle-manipulasjon i en slik protokoll, finnes det typisk ingen CASP, ingen norsk motpart og ingen vei om Finanstilsynet. Juridisk st\u00e5r du alene.<\/p>

En viktig nyanse gjelder derivater. Krypto-perper og CFD-er er finansielle instrumenter under MiFID II, ikke under MiCA, og tilsynet ligger hos markedsregulatoren. Et Mango-lignende angrep p\u00e5 en regulert handelsplass ville v\u00e6rt markedsmisbruk med et klart h\u00e5ndhevingsspor. P\u00e5 en tillatelsesl\u00f8s perp-DEX viser Mango-presedensen hvor vanskelig det samme er \u00e5 forf\u00f8lge. P\u00e5 skattesiden kan et tap etter en exploit etter omstendighetene v\u00e6re fradragsberettiget som et realisert tap i skattemeldingen, men dokument\u00e9r alt n\u00f8ye; dette er ikke skatter\u00e5d, og reglene er avhengige av de konkrete forholdene. Ved tvil, ta det opp med Skatteetaten eller en r\u00e5dgiver.<\/p>

Den praktiske konklusjonen er den samme for brukere og byggere: forsvaret ditt ligger oppstr\u00f8ms for enhver regulator. Vurder orakelet f\u00f8r du setter inn penger, med firelagslinsen som verkt\u00f8y. For byggere viser 2026-hendelsene at fronten har flyttet seg til lag 3 og 4. Reviderer du leveringsveien og nekter \u00e5 behandle et regnskapstall som en pris, har du lukket de to d\u00f8rene angriperne n\u00e5 g\u00e5r inn. Og som Aave viste, blir selv gode team bitt; det er ingen skam \u00e5 anta at ditt eget oppsett ogs\u00e5 har et svakt lag, og lete etter det f\u00f8r noen andre gj\u00f8r det.<\/p>

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

Hva er oracle-manipulasjon i DeFi?<\/h3>

Oracle-manipulasjon er n\u00e5r en angriper f\u00e5r en DeFi-protokoll til \u00e5 handle p\u00e5 et feil pristall. Protokollen henter prisen fra et orakel og kan ikke se forskjell p\u00e5 en ekte og en forvrengt pris, s\u00e5 lenge tallet er levert riktig. Angriperen forvrenger enten kilden (et tynt marked), leveringen (en signatur eller n\u00f8kkel) eller konsumet (et internt regnskapstall protokollen feilaktig leser som en pris), og tapper verdi mens protokollen tror den handler korrekt.<\/p>

Er et flash-l\u00e5n \u00e5rsaken til oracle-angrep?<\/h3>

Nei. Et flash-l\u00e5n er forsterkeren, ikke selve feilen. Det gir en angriper enorm kapital i \u00e9n transaksjon, men kapitalen gj\u00f8r bare skade fordi orakelet stoler p\u00e5 et marked som er billig \u00e5 flytte. Mot et robust orakel, som bruker median av flere dype markeder eller et tidsvektet snitt, er selv ubegrenset kapital nyttel\u00f8st. Den egentlige feilen ligger i orakel-oppsettet, ikke i l\u00e5net.<\/p>

Beskytter Chainlink mot all oracle-manipulasjon?<\/h3>

Nei. Chainlink forsvarer kilde- og aggregeringslaget godt gjennom desentralisert median, men beskytter ikke automatisk mot alt. Angrep p\u00e5 leveringslaget (kompromitterte n\u00f8kler eller verifikatorer) og p\u00e5 konsumlaget (donasjonsangrep p\u00e5 vault-andeler eller wrapping-rater) kan fortsatt ramme. Edel Finance-saken i juli 2026 er beviset: Chainlinks prisfeed var korrekt hele tiden, men protokollen tapte likevel penger fordi den leste feil internt tall.<\/p>

Hva er OEV (Oracle Extractable Value)?<\/h3>

OEV er verdien som frigj\u00f8res i det \u00f8yeblikket et orakel oppdaterer en pris, s\u00e6rlig likvidasjonsbonuser n\u00e5r en ny pris dytter et l\u00e5n under vann. Historisk lekket denne verdien til block-byggere og validatorer. Mekanismer som Chainlink SVR og API3s OEV Network fanger den n\u00e5 og returnerer den til protokollen som skapte den, ofte som en ny inntektsstr\u00f8m for et DAO.<\/p>

F\u00e5r jeg pengene tilbake fra Finanstilsynet hvis en DeFi-protokoll blir hacket?<\/h3>

Vanligvis ikke. MiCA og Finanstilsynet regulerer kryptotjenestetilbydere (CASP-er) som b\u00f8rser og forvaringstjenester, ikke tillatelsesl\u00f8se protokoller. En fullt desentralisert DeFi-protokoll uten en operat\u00f8r har ingen CASP og dermed ingen norsk motpart \u00e5 rette et krav mot. Ditt beste vern er \u00e5 vurdere oracle-risikoen f\u00f8r du setter inn penger, ikke \u00e5 regne med regress i etterkant.<\/p>