DeFi-Overvåking i Sanntid: 12 Steg [2026]

DeFi-protokoller mistet minst 1,3 milliarder dollar til angrep i løpet av de første åtte månedene av 2026, ifølge tall fra Forbes og CertiK som ble sitert av crypto.news i september 2026. For første gang noensinne har kompromitterte private nøkler og signeringsflyter forbigått rene smart-kontrakt-bugs som den vanligste tapsårsaken. Broer står fortsatt for de fleste enkeltstore hendelsene. Det som derimot har endret seg er responstiden: team med sanntidsovervåking oppdager angrep før midlene flyttes, mens team uten det leser om hacket sitt på Twitter, gjerne flere timer etter at siste transaksjon allerede er bekreftet.

Denne guiden viser deg, steg for steg, hvordan du setter opp en fungerende overvåkings- og varslingsstabel for en DeFi-protokoll med Forta Network, OpenZeppelin Defender Sentinels og Tenderly Alerts, komplett med automatisert respons og et eksempelprosjekt du kan kjøre selv. Du trenger ingen tidligere erfaring med overvåkingsverktøy, men du bør kunne lese Solidity og ha jobbet med et Foundry- eller Hardhat-prosjekt før. Alt du trenger for å komme i gang koster ingenting de første 45 minuttene, og vi viser deg nøyaktig når det begynner å lønne seg å betale for mer.

Hvorfor sanntidsovervåking av DeFi er blitt kritisk i 2026

I februar 2026 lanserte ZK-lotteriet Foom.cash en Groth16-verifikator med en ufullstendig trusted setup. Feilen gjorde at alle uttaksbevis kunne forfalskes, en type sårbarhet som er nesten umulig å fange i en manuell kodegjennomgang. Sikkerhetsselskapet Defimon oppdaget imidlertid det uferdige oppsettet gjennom løpende overvåking og hentet preventivt ut 1,84 millioner dollar fra Ethereum-utrullingen før noen rakk å utnytte hullet, ifølge Defimons egen hendelseslogg. Ingen revisjon fanget feilen på forhånd. Det var overvåkingslaget, ikke revisjonslaget, som reddet pengene.

Et lignende mønster gjentok seg på Flare Network, der plattformen Hypernative oppdaget et pågående angrep mot utlånsprotokollen Kinetic før den første ondsinnede transaksjonen i det hele tatt ble kringkastet. Teamet fikk varsel i sanntid, trigget en nødpause, og reddet dermed rundt 5 millioner dollar i brukermidler, ifølge Hypernatives egen produktdokumentasjon. Selskapet oppgir at den samme tilnærmingen har bidratt til å forhindre over 3 milliarder dollar i hacks og utnyttelser for kundeporteføljen samlet de siste tre årene.

Vi har tidligere skrevet om de grunnleggende sikkerhetstiltakene som følger av 942 millioner dollar i DeFi-tap, og om hvordan orakelmanipulasjon alene har kostet protokoller 135 millioner dollar. Det disse hendelsene har til felles er at skaden skjer i løpet av sekunder til minutter etter at en sårbarhet blir utnyttet, ikke i løpet av timer. Chainalysis rapporterte at totale kryptotyverier i 2025 endte på rundt 3,4 milliarder dollar, og selv om DeFi-spesifikke tap var relativt lave sammenlignet med veksten i total verdi låst (TVL), peker Chainalysis’ egen analyse på bedre deteksjon som en direkte årsak.

Poenget med denne guiden er ikke å erstatte revisjon, fuzzing eller systematisk testing av smart-kontraktene dine før lansering. Poenget er å bygge laget som fanger det revisjonen aldri kunne fange: konfigurasjonsfeil som dukker opp etter deploy, kompromitterte signeringsnøkler, ondsinnede governance-forslag og frontend-kapringer som ikke rører en eneste linje Solidity-kode. Du trenger 45 minutter, en testnett-kontrakt og kontoene som er listet i forutsetningene under.

To ferske eksempler viser hvorfor bredden i overvåkingen betyr like mye som dybden. Den 11. september 2026, klokken 04:28 UTC, utnyttet en angriper en svakhet i broen Symbiosis BridgeV2, som aksepterte en unormal melding og myntet rundt 2^62 udekkede enheter syBTC, ifølge Cryptopolitans dekning av hendelsen. Protokollen stanset BTC-rutene sine, men lot resten av broen fortsette å kjøre, noe som viser at selv en delvis nedstenging krever presis overvåking av hvilke ruter som faktisk er trygge. Tidligere samme år, i mai 2026, flagget Chainalysis et lignende blindpunkt da et 292 millioner dollar stort utnyttelse omgikk en burn-verifiseringsmekanisme i KelpDAO-broen. Begge hendelsene handler om logikk som en revisjon i teorien kunne ha fanget, men som i praksis krevde sanntidsdeteksjon for å begrense skaden før den eskalerte.

Forutsetninger: verktøy, kontoer og kunnskap du trenger

Du trenger ikke være sikkerhetsekspert for å følge denne guiden, men du bør kunne lese Solidity og ha satt opp et Foundry- eller Hardhat-prosjekt tidligere. Sett av rundt 45 minutter til selve oppsettet, pluss ekstra tid hvis du vil teste alt grundig mot testnett før du går videre til mainnet. Tabellen under viser alt du trenger, med versjoner der det er relevant.

Komponent	Krav / versjon	Formål i denne guiden
Node.js	20 LTS eller nyere	Kjører Forta-agenter og Defender Autotasks lokalt
Foundry (forge, cast, anvil)	Nyeste via foundryup	Testnett-deploy og simulering av angrep
Forta CLI	Nyeste via npm	Bygg og publiser deteksjonsboter
OpenZeppelin Defender-konto	Gratis til Team-nivå	Sentinels, Autotasks og automatisert respons
Tenderly-konto	Gratis prøveperiode, betalt for produksjon	Transaksjonssimulering og gass-varsler
Slack- eller Telegram-arbeidsområde	Admin-tilgang for webhooks	Mottak av sanntidsvarsler
PagerDuty- eller Opsgenie-konto (valgfritt)	Free eller Team-nivå	On-call-rotasjon for kritiske hendelser
RPC-tilgang (Alchemy/Infura)	Arkivnode for historiske spørringer	Kjøring av invariant-sjekker mot historisk state

Merk at ingen av kjerneverktøyene krever betaling for å komme i gang. Forta tilbyr gratis community-boter for protokoller under 10 millioner dollar i TVL, mens OpenZeppelin Defender har et gratisnivå som dekker de fleste av stegene i denne guiden. Du trenger først et budsjett når protokollen din vokser forbi terskelverdiene vi går gjennom i budsjett-seksjonen mot slutten. Har du fra før satt opp et Foundry-prosjekt med tester, slik vi beskrev i vår guide til statisk analyse med Slither og fuzzing med Echidna, kan du gjenbruke store deler av samme prosjektstruktur og bare legge overvåkingskonfigurasjonen til side for seg selv.

Forta, Defender, Tenderly eller Hypernative: hvilket verktøy passer deg?

Et vanlig spørsmål før man setter i gang er hvilket av verktøyene som er “best”. Svaret er at de fire mest brukte plattformene i 2026 løser forskjellige deler av problemet, og de fleste modne team ender opp med å bruke to eller tre av dem samtidig, ikke bare én. Forta er et desentralisert deteksjonsnettverk du abonnerer på, Defender er et rammeverk du selv bygger egendefinert logikk i, Tenderly er sterkest på simulering før en transaksjon bekreftes, og Hypernative er en enterprise-plattform som pakker alt dette sammen med automatisert respons på tvers av over 75 kjeder.

Verktøy	Sterkest på	Egnet for
Forta Network	Bransjebrede angrepsmønstre, community-drevne deteksjonsboter	Alle protokoller, spesielt de under 50 millioner dollar i TVL
OpenZeppelin Defender	Egendefinerte regler og automatisert on-chain-respons	Team som selv skriver og eier overvåkingslogikken
Tenderly Alerts	Transaksjonssimulering og gass-anomalier før confirm	Utviklingstunge team med tett CI/CD-integrasjon
Hypernative	Automatisert respons på tvers av 75+ kjeder, AI-drevet deteksjon	Protokoller over 100 millioner dollar i TVL med enterprise-budsjett

Ifølge Hypernatives egen produktside overvåker plattformen kontrakter, lommebøker og on-chain-interaksjoner på over 75 kjeder i sanntid, og samarbeider med over 350 organisasjoner om å sikre driften deres. Det gjør Hypernative til det bredeste alternativet, men også det dyreste, og for de fleste team gir det mer mening å starte med kombinasjonen Forta og Defender som vi bygger videre på i resten av guiden, og heller vurdere en enterprise-plattform når TVL og kompleksitet vokser forbi det ett internt team kan følge med på manuelt.

Chainalysis-analyser peker dessuten på at gapet mellom protokoller med og uten fungerende overvåking blir tydeligere for hvert år som går, siden angriperne selv har blitt mer systematiske i hvordan de leter etter svakheter. En protokoll uten noen form for sanntidsdeteksjon er i praksis avhengig av at et community-medlem eller en hvit-hatt-hacker oppdager problemet manuelt og varsler teamet, noe som kan ta alt fra minutter til dager. Den forskjellen i responstid er nøyaktig det resten av denne guiden handler om å lukke.

Steg 1-2: Kartlegg angrepsflaten og sett opp Forta Network

Før du kobler til et eneste verktøy, lag en liste over alt som kan overvåkes: kontraktsadresser, eieradresser, multisig-signere, orakel-feeds og frontend-domener. Denne listen blir input til hvert eneste verktøy du setter opp videre i guiden, så bruk 10-15 minutter på å gjøre den fullstendig. Legg spesielt merke til hvilke funksjoner som flytter midler direkte, siden det er disse som trenger tettest overvåking.

Forta Network er et desentralisert nettverk av deteksjonsboter som skanner mempool og bekreftede blokker i sanntid. Forta Foundations egen kunngjøring beskriver en General Plan-modell priset til 250 FORT per måned, tilsvarende rundt 32 dollar da planen ble innført, med ubegrenset API-tilgang til ikke-premium-boter. Premium Feeds, som eies og driftes av tredjeparts sikkerhetsteam, koster typisk rundt 500 FORT per 30-dagers periode og fornyes automatisk on-chain så lenge lommeboken har dekning. Start med å installere Forta CLI og koble deg til Attack Detector-boten, som ifølge samme kilder har en gjennomsnittlig deteksjonstid på rundt 950 sekunder før utnyttelse basert på 2024-hendelser, med 83 prosent av rammede protokoller uten falske positiver de siste 60 dagene før angrepet.

# Installer Forta CLI
npm install -g @forta-network/forta-agent

# Initialiser et nytt deteksjonsprosjekt
mkdir defi-overvaking && cd defi-overvaking
forta-agent init --typescript

# Konfigurer hvilke adresser botene skal følge
cat > forta.config.json << 'EOF'
{
  "chainIds": [1, 42161, 10],
  "watchedContracts": [
    "0xDIN_VAULT_ADRESSE",
    "0xDIN_ORAKEL_ADRESSE"
  ],
  "subscriptions": [
    { "botId": "0xa2e07f...attack-detector", "alertId": "*" }
  ]
}
EOF

# Test agenten lokalt mot en spesifikk blokk
forta-agent run --tx 0xTRANSAKSJONSHASH

Når testkjøringen fungerer, publiserer du agenten til Forta Network slik at den kjører kontinuerlig hos nodeoperatørene i nettverket i stedet for bare lokalt hos deg. Dette er viktig: en lokal instans som stopper å svare gir deg ingen varsel om at overvåkingen har feilet, mens det desentraliserte nettverket har innebygd redundans.

Et konkret tips for kartleggingsdelen: skill mellom adresser du eier og adresser du kun avhenger av. Din egen Timelock-kontrakt hører til førstnevnte, men et eksternt orakel eller en likviditetspool på en annen protokoll hører til sistnevnte. Begge må overvåkes, men reaksjonsmønsteret er ulikt. Endringer i egne kontrakter kan ofte håndteres automatisk med en pause-funksjon, mens endringer hos en avhengighet som regel krever et menneske som vurderer hvorvidt din protokoll bør pause seg selv midlertidig i påvente av mer informasjon.

Steg 3-4: Konfigurer OpenZeppelin Defender Sentinels og automatisert respons

Der Forta gir deg bransjebrede deteksjonsmønstre, gir OpenZeppelin Defender Sentinels deg skreddersydde regler for din egen kontraktlogikk. En 2026-oversikt over sikkerhetsbudsjetter i DeFi anslår kostnaden til mellom 0 og 5000 dollar per måned avhengig av volum, ifølge smartcontractaudit.com sitt rammeverk for sikkerhetsbudsjetter. Gratisnivået dekker som regel det du trenger for en mindre protokoll.

Opprett først en Sentinel som lytter på Transfer- og Withdraw-hendelser fra hvelvet ditt, med en terskelregel som trigger dersom mer enn en gitt prosentandel av total TVL forlater kontrakten i en enkelt transaksjonsblokk. Deretter kobler du regelen til en Autotask, som er Defenders serverløse funksjon for automatisk respons.

// autotask-emergency-pause.js
const { DefenderRelaySigner } = require('defender-relay-client/lib/ethers');
const { ethers } = require('ethers');

exports.handler = async function (event) {
  const { alert } = event.request.body;
  const withdrawnPercent = alert.matchReasons[0].value;

  // Trigger nødpause hvis mer enn 15% av TVL forlater hvelvet i én blokk
  if (withdrawnPercent > 15) {
    const provider = new DefenderRelaySigner(event, undefined, { speed: 'fast' });
    const vault = new ethers.Contract(
      process.env.VAULT_ADDRESS,
      ['function pause() external'],
      provider
    );
    const tx = await vault.pause();
    await tx.wait();
    return { paused: true, txHash: tx.hash, reason: 'tvl-drain-anomaly' };
  }
  return { paused: false };
};

Dette er nøyaktig samme mønster Hypernative beskriver i sin egen dokumentasjon om automatisert hendelsesrespons: en pre-autorisert on-chain-handling som utføres i løpet av sekunder uten at et menneske først må lese og vurdere varselet, ifølge Hypernatives beskrivelse av automatisert respons. Husk at pause-funksjonen må testes grundig på testnett før du gir Autotasken tilgang til mainnet-kontrakten, siden en feilaktig trigger kan pause en frisk protokoll unødvendig og skade brukertilliten.

Vurder å bygge inn en gradert respons i stedet for kun av/på. En Autotask kan for eksempel først senke en uttaksgrense i stedet for å pause protokollen fullstendig, og først eskalere til full pause dersom mønsteret vedvarer over flere blokker. Dette reduserer risikoen for at en enkelt falsk positiv stenger ned hele protokollen, samtidig som du fortsatt begrenser eksponeringen umiddelbart. Relayer-lommeboken som utfører pause-transaksjonen bør dessuten holdes adskilt fra andre administrative nøkler, slik at en kompromittert Autotask-nøkkel ikke automatisk gir angriperen tilgang til andre funksjoner i kontrakten.

Steg 5-6: Tenderly Alerts og invarianter for TVL, orakel og governance

Tenderly Alerts dekker et annet lag: transaksjonssimulering og gass-anomalier før en transaksjon i det hele tatt havner i en bekreftet blokk. Prisnivået ligger typisk mellom 500 og 2000 dollar per måned for profesjonelle team, ifølge samme budsjettrammeverk som over. Sett opp et alert-prosjekt og koble det til kontraktadressene dine, deretter definerer du invarianter, altså påstander som alltid skal være sanne for at protokollen fungerer som forventet. Fordelen med simulering før bekreftelse er at du i noen tilfeller kan varsle, eller til og med reagere, før en ondsinnet transaksjon i det hele tatt blir en del av kjedens historikk, i motsetning til Forta og Defender som i hovedsak reagerer på hendelser som allerede har skjedd on-chain.

// invariant-sjekk.js - kjøres som en Tenderly Web3 Action
module.exports = async (context, event) => {
  const vault = await context.getContract('Vault', process.env.VAULT_ADDRESS);
  const totalAssets = await vault.totalAssets();
  const totalShares = await vault.totalSupply();

  // Invariant 1: verdi per andel kan aldri synke brått
  const pricePerShare = totalAssets.mul(1e18).div(totalShares);
  const lastKnown = await context.storage.getStr('lastPricePerShare');
  if (lastKnown && pricePerShare.lt(lastKnown * 0.95)) {
    await context.alert('KRITISK: verdi per andel falt over 5% i ett steg');
  }

  // Invariant 2: orakelpris kan ikke avvike mer enn 3% fra sekundærkilde
  const primaryPrice = await context.getContract('Oracle', process.env.ORACLE).latestAnswer();
  const secondaryPrice = await context.fetchExternalPrice('chainlink-backup');
  const deviation = Math.abs(primaryPrice - secondaryPrice) / secondaryPrice;
  if (deviation > 0.03) {
    await context.alert('Orakelavvik over 3% oppdaget - mulig manipulasjon');
  }

  await context.storage.putStr('lastPricePerShare', pricePerShare.toString());
};

Legg til en tredje invariant for governance: en Sentinel eller Web3 Action som varsler så snart et nytt forslag registreres på en Timelock- eller Governor-kontrakt, uavhengig av innholdet. Vi har tidligere dekket hvordan svake orakelfeeds alene har kostet DeFi-protokoller 135 millioner dollar, og orakel-invarianten over er direkte inspirert av den typen hendelser. Tabellen viser hvilket av de tre verktøyene som dekker hvilken risikokategori, slik at du unngår å bygge duplikatregler.

Sekundærkilden i orakel-invarianten er det viktigste enkeltvalget i hele denne seksjonen. Bruker du to feeds som i praksis henter data fra samme underliggende børs eller samme likviditetspool, fanger du kun nedetid, ikke manipulasjon. En robust løsning kombinerer minst to uavhengige kilder, for eksempel en on-chain Chainlink-feed og en separat TWAP-beregning (time-weighted average price) fra en annen pool, slik at et avvik faktisk betyr at noe er galt og ikke bare at én leverandør har driftsproblemer.

Risikokategori	Beste verktøy	Typisk reaksjonstid
Flash loan- og reentrancy-mønstre	Forta Attack Detector	Sekunder til minutter (mempool)
Egendefinert kontraktlogikk (TVL-terskler)	OpenZeppelin Defender Sentinels	Sekunder (on-chain event)
Transaksjonssimulering før confirm	Tenderly Alerts	Millisekunder til sekunder (pre-confirm)
Orakelavvik og prismanipulasjon	Egendefinert Web3 Action + sekundær feed	Sekunder
Governance- og admin-endringer	Defender Sentinel på Timelock/Governor	Umiddelbart ved forslag
DNS/frontend-kapring	Certificate Transparency-overvåking	Minutter

Steg 7-8: Koble varsler til Slack, PagerDuty og overvåk frontend

Et varsel ingen ser er verdiløst. Koble Forta, Defender og Tenderly til samme Slack-kanal via webhooks, men splitt varslene i to alvorlighetsgrader: informasjonsvarsler til en kanal alle følger med på i normal arbeidstid, og kritiske varsler som trigger PagerDuty eller Opsgenie uansett tid på døgnet. En vanlig feil er å sende alt til én og samme kanal, noe som over tid fører til at teamet slutter å lese kanalen fordi den er full av lavterskel-støy, og dermed også overser de virkelig kritiske varslene når de faktisk kommer.

# webhook-router.js - enkel Node.js-ruter foran Slack og PagerDuty
const express = require('express');
const app = express();
app.use(express.json());

app.post('/varsel', async (req, res) => {
  const { severity, source, message, contractAddress } = req.body;

  const slackPayload = {
    text: `[${severity.toUpperCase()}] ${source}: ${message} (${contractAddress})`
  };
  await fetch(process.env.SLACK_WEBHOOK_URL, {
    method: 'POST',
    body: JSON.stringify(slackPayload)
  });

  if (severity === 'critical') {
    await fetch('https://events.pagerduty.com/v2/enqueue', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        routing_key: process.env.PAGERDUTY_KEY,
        event_action: 'trigger',
        payload: { summary: message, severity: 'critical', source }
      })
    });
  }
  res.sendStatus(200);
});

app.listen(3000);

En analyse fra sikkerhetsselskapet Zealynx peker på det de kaller «Web2-blindsonen»: revidert og velfungerende Solidity-kode kompromitteres likevel gjennom DNS-kapring, sertifikatendringer eller falske frontend-oppdateringer som aldri rører selve kontrakten, ifølge Zealynx' forskning på motstandsdyktig sikkerhet. Legg derfor til Certificate Transparency-overvåking på domenet ditt, slik at du får varsel innen minutter dersom noen utsteder et nytt SSL-sertifikat for domenet uten din viten. De fleste CT-overvåkingstjenester tilbyr gratis webhook-varsler for et enkelt domene.

I tillegg til CT-overvåking bør du sette opp en enkel daglig sjekk som sammenligner kontraktadressen frontend-koden din faktisk kaller mot listen over godkjente adresser du definerte i steg 1. Angripere har i flere tilfeller byttet ut kun én adresse i en bundlet JavaScript-fil, uten å endre noe på selve nettsiden visuelt, slik at brukerne signerer transaksjoner mot en ondsinnet kontrakt de tror er den ekte hvelvkontrakten. En slik sjekk krever verken Forta, Defender eller Tenderly, bare et lite skript som kjører i en cron-jobb og varsler gjennom samme webhook-ruter du allerede har satt opp.

Steg 9-10: Test systemet med en simulert exploit og etabler hendelsesrespons

Et overvåkingssystem du aldri har testet er et overvåkingssystem du ikke kan stole på. Deploy testkontrakten din til en testnett-fork med Anvil, og simuler deretter et flash loan-angrep for å bekrefte at hele kjeden fra deteksjon til varsel til automatisk pause faktisk fungerer. Vi har gått grundig gjennom selve angrepsteknikken i vår tidligere guide til flash loan-angrep med Foundry, så her fokuserer vi kun på overvåkingsdelen.

# Start en lokal fork av mainnet
anvil --fork-url $MAINNET_RPC_URL --fork-block-number latest

# Kjør en simulert flash loan-manipulasjon mot testkontrakten
forge script script/SimulateAttack.s.sol \
  --rpc-url http://127.0.0.1:8545 \
  --broadcast \
  --unlocked

# Bekreft at Sentinel-en trigget innen forventet tid
# (sjekk Defender-dashbordet eller spør API-et direkte)
curl -s -H "X-Api-Key: $DEFENDER_API_KEY" \
  https://defender-api.openzeppelin.com/monitor/alerts?limit=5

Mål tiden fra simulert transaksjon til Slack-varsel dukker opp. Alt over to minutter bør undersøkes, siden mange virkelige angrep tømmer et hvelv fullstendig i løpet av én enkelt blokk. Etter en vellykket test, skriv ned en enkel hendelsesresponsplan: hvem eier pause-nøkkelen, hvem varsles først, og hvilken kommunikasjonskanal brukes mot brukerne dersom protokollen faktisk må pauses. En plan som finnes kun i hodet til én utvikler er ingen plan når den personen er utilgjengelig midt på natten.

Del hendelsesresponsplanen i tre faser: umiddelbar respons de første fem minuttene (bekreft varselet, vurder pause, varsle kjernegruppen), stabilisering de neste to timene (skriv en foreløpig statusoppdatering til brukerne, koordiner med eventuelle børser eller broer som er berørt), og etterarbeid i dagene etter (fullstendig hendelsesrapport, oppdatering av overvåkingsregler basert på det som faktisk ble lært). Test gjerne hele denne planen, ikke bare den tekniske deteksjonen, ved å kjøre en øvelse der noen i teamet spiller angriper og resten av teamet følger planen fra start til slutt.

Steg 11-12: Skaler og budsjettér overvåkingen etter TVL

Overvåkingsbehovet ditt vokser ikke lineært med TVL, det vokser i trinn. Budsjettrammeverket fra smartcontractaudit.com deler anbefalingene inn etter TVL-nivå, og vi har oppsummert dette i tabellen under sammen med egne anbefalinger for nordiske team som gjerne drifter mindre protokoller med begrenset sikkerhetsbudsjett.

TVL-nivå	Anbefalt månedlig budsjett	Minimumsoppsett
Under 10 millioner dollar	0 dollar	Gratis Forta community-boter + Defender gratisnivå
10-50 millioner dollar	Etter behov, ofte under 500 dollar	Forta General Plan + noen Premium Feeds + Sentinels
Over 50 millioner dollar	1000-3000 dollar	Sentinels + Tenderly Alerts + dedikert on-call-rotasjon
Over 100 millioner dollar	Enterprise-avtale (kontakt salg)	Plattform som Hypernative med automatisert respons på 80+ kjeder

Vår anbefaling er å starte i det billigste laget uansett protokollstørrelse, og heller la faktiske hendelser eller nesten-hendelser styre når du beveger deg opp én tabellrad. De fleste team overbygger overvåkingen fra dag én og bruker budsjett på enterprise-plattformer før de i det hele tatt har en kritisk pause-funksjon som fungerer, noe som er baklengs prioritering. Bygg deteksjon og respons i riktig rekkefølge først, skaler kapasitet etterpå.

For nordiske team er det verdt å nevne at flere av abonnementene, blant annet Fortas General Plan, faktureres i prosjektets eget token og krever at lommeboken har tilstrekkelig dekning til automatisk fornyelse hver 30. dag. Sett en kalendererinnelse for å sjekke saldoen månedlig, siden et utløpt abonnement stopper varslene dine stille i bakgrunnen. Det er en overraskende vanlig årsak til at overvåkingssystemer slutter å virke uten at noen legger merke til det før det er for sent.

Komplett eksempelprosjekt: overvåkingsstabel fra bunnen

Under følger en samlet mappestruktur for et minimalt, men fullt fungerende overvåkingsprosjekt som kombinerer alle stegene over. Du kan kopiere denne strukturen direkte og fylle inn dine egne kontraktadresser og API-nøkler.

defi-overvaking/
├── forta/
│   ├── forta.config.json          # Adresser og bot-abonnementer
│   └── src/agent.ts                # Egendefinert deteksjonslogikk
├── defender/
│   ├── sentinels/
│   │   └── tvl-drain-sentinel.json
│   └── autotasks/
│       └── emergency-pause.js
├── tenderly/
│   └── actions/
│       └── invariant-sjekk.js
├── varsling/
│   └── webhook-router.js           # Ruter mellom Slack og PagerDuty
├── test/
│   └── SimulateAttack.s.sol        # Foundry-script for testing
├── .env.example
└── docker-compose.yml              # Kjører varsel-ruteren lokalt

# docker-compose.yml
version: "3.9"
services:
  webhook-router:
    build: ./varsling
    ports:
      - "3000:3000"
    env_file: .env
    restart: unless-stopped

Med denne strukturen på plass har du et system der Forta og Tenderly dekker deteksjon, Defender Autotasks dekker automatisert respons, og webhook-ruteren sikrer at riktig alvorlighetsgrad havner hos riktig person. Legg gjerne hele mappen i et privat GitHub-repo med grener for testnett og mainnet, slik at endringer i overvåkingsreglene går gjennom samme code review-prosess som resten av kodebasen din.

Behandle .env-filen med samme forsiktighet som du behandler en privat nøkkel, siden den inneholder API-nøkler for både Defender og Tenderly, samt webhook-URL-er for Slack og PagerDuty. Legg .env til .gitignore fra første commit, og bruk i stedet en hemmelighetstjeneste (GitHub Actions Secrets, Doppler eller lignende) for CI-miljøet der prosjektet eventuelt bygges og deployes automatisk. Et vanlig, men alvorlig feiltrinn er å teste webhook-ruteren lokalt med ekte nøkler og deretter ved et uhell committe .env-filen sammen med resten av testkoden.

Når prosjektet er satt opp, kjør en full ende-til-ende-test minst én gang i uken de første månedene: trigger et falskt varsel gjennom hvert av de tre verktøyene og bekreft at det dukker opp riktig sted i Slack, med riktig alvorlighetsgrad, og at PagerDuty faktisk varsler for de kritiske tilfellene. Automatiser gjerne denne testen som en egen GitHub Action som kjører hver mandag morgen, slik at du ikke er avhengig av å huske det manuelt.

Ikke glem å overvåke selve overvåkingssystemet. Webhook-ruteren i eksempelet over er en enkeltpunktfeil: krasjer den serveren, forsvinner varslene dine stille uten at noen merker det før neste hendelse. Legg til en enkel "heartbeat"-sjekk, der ruteren sender et harmløst signal til en ekstern overvåkingstjeneste (for eksempel Healthchecks.io eller en tilsvarende gratis tjeneste) hvert femte minutt. Uteblir signalet, får du et eget varsel om at selve overvåkingskjeden er nede, uavhengig av hva som skjer med protokollen din.

Vanlige fallgruver ved DeFi-overvåking

De fleste team som setter opp sanntidsovervåking for første gang gjør de samme feilene, og de fleste av dem handler ikke om verktøyvalg, men om hvordan reglene konfigureres og vedlikeholdes over tid. Gå gjennom listen under og sjekk om noen av punktene allerede gjelder for ditt oppsett.

Å sette terskler for stramt. En TVL-drain-terskel på 2 prosent høres trygt ut, men trigges av helt normal brukeraktivitet på en travel dag og lærer teamet ditt å ignorere varsler.
Å gi Autotasken for mye makt uten testing. En pause-funksjon som trigges feilaktig på en frisk protokoll skader brukertilliten omtrent like mye som et faktisk hack.
Å overvåke kun kontraktene, ikke frontend og DNS. Som beskrevet i Web2-blindsone-seksjonen over rammes flere protokoller gjennom kompromitterte nettsider enn gjennom selve Solidity-koden.
Å la ett enkelt menneske eie alle nøklene. Hvis pause-funksjonen eller Autotask-nøkkelen kun ligger hos én person, er systemet sårbart for at akkurat den personen er utilgjengelig når det gjelder.
Å glemme å teste selve varslingskjeden. Mange team tester deteksjonslogikken grundig, men glemmer å bekrefte at Slack-webhooken faktisk fortsatt fungerer etter at noen roterte API-nøkkelen tre måneder tidligere.
Å stole på én enkelt orakelkilde i invariant-sjekken. Hvis sekundærkilden i orakel-invarianten din er den samme underliggende datastrømmen som primærkilden, fanger du ikke manipulasjon, du fanger kun nedetid.
Å ikke dokumentere hvem som gjør hva under en hendelse. Et team som improviserer ansvarsfordeling midt i et pågående angrep mister verdifulle minutter som en skrevet plan ville spart.

Legg merke til at ingen av disse syv fallgruvene krever et dyrere verktøy for å løses. De handler nesten utelukkende om disiplin: testing, dokumentasjon og bevisste valg av terskelverdier. Et gratis Forta-oppsett som er konfigurert riktig slår et dyrt enterprise-abonnement som er satt opp i hui og hast.

Feilsøking: vanlige problemer og løsninger

Selv med et gjennomtenkt oppsett vil du støte på feil underveis, spesielt de første ukene mens reglene fortsatt kalibreres mot faktisk trafikk. Tabellen under dekker de ni vanligste problemene team melder inn når de setter opp denne typen stabel, sammen med den mest sannsynlige årsaken og en konkret løsning.

Problem	Sannsynlig årsak	Løsning
Forta-agenten publiserer ingen varsler	Feil chainId eller adresse i forta.config.json	Bekreft med forta-agent run --tx mot en kjent transaksjon
Defender Sentinel trigger ikke	ABI-mismatch mellom Sentinel og deployet kontrakt	Reimporter ABI-en fra Etherscan etter siste deploy
Autotask feiler med "insufficient funds"	Relayer-lommeboken mangler gass	Fyll på Defender Relayer med ETH på riktig kjede
Tenderly Web3 Action timer ut	Ekstern prisoppslag tar for lang tid	Legg til timeout og fallback-verdi i invariant-sjekken
Slack-webhook returnerer 404	Webhook-URL utløpt eller kanal slettet	Generer ny webhook i Slack-appens innstillinger
PagerDuty trigges ikke ved kritiske varsler	Feil routing_key eller event_action-verdi	Bekreft routing_key mot PagerDuty-tjenestens innstillinger
For mange falske positiver fra TVL-terskel	Terskel satt for lavt i forhold til normal volatilitet	Analyser 30 dager historisk data før du setter endelig terskel
Anvil-forken speiler ikke faktisk mainnet-state	Fork-block-number for gammel eller RPC-node bak	Bruk --fork-block-number latest og en arkivnode
CT-overvåking varsler ikke ved nytt sertifikat	Domenet bruker wildcard-sertifikat fra før overvåkingen startet	Registrer eksplisitt både rot- og subdomener i CT-tjenesten

Hvis du fortsatt sliter etter å ha gått gjennom denne listen, er neste steg som regel å isolere hvert verktøy og teste det helt alene, uten resten av stabelen koblet til. Fjern midlertidig alle andre integrasjoner, kjør ett enkelt testvarsel gjennom kun Forta, deretter kun Defender, deretter kun Tenderly. Dette avslører raskt om problemet ligger i selve verktøyet eller i webhook-ruteren som binder dem sammen.

Avanserte tips for modne sikkerhetsteam

Når grunnoppsettet er stabilt, er neste steg å korrelere varsler på tvers av kilder i stedet for å behandle hver Forta-, Defender- og Tenderly-hendelse isolert. Et enkelt orakelavvik er sjelden farlig alene, men et orakelavvik kombinert med en uvanlig stor lånetransaksjon i samme blokk er nesten alltid et forsøk på prismanipulasjon. Bygg en enkel korrelasjonsregel i webhook-ruteren som eskalerer alvorlighetsgraden når to eller flere kilder varsler om samme kontraktadresse innenfor et kort tidsvindu.

Vurder også å legge til et eget invariant-lag for governance-endringer med tidsforsinkelse: la en Sentinel varsle umiddelbart ved et nytt forslag, men bygg samtidig en automatisk sjekk som sammenligner kalldataene i forslaget mot en liste over kjente farlige funksjonssignaturer, som ownership-overføring eller endring av en oppgraderbar proxy-implementasjon. Kombiner dette med den type reentrancy- og tilgangskontrollsjekker vi beskrev i guiden om statisk analyse og fuzzing før deploy, slik at overvåkingen din dekker hele livssyklusen fra utvikling til produksjon. Til slutt, sett opp en kvartalsvis "game day" der teamet kjører en fullstendig simulert hendelse fra start til slutt, inkludert varsling og kommunikasjon, ikke bare den tekniske deteksjonen.

Hvis protokollen din håndterer innskudd via en API mot en sentralisert komponent, for eksempel en frontend-tjeneste eller en relayer, gjelder mange av de samme prinsippene som for API-sikkerhet og varsling hos kryptobørser: rate-begrensning, IP-basert anomalideteksjon og separate varslingsterskler for API-laget kontra selve kontraktlaget. Et team som kun overvåker on-chain-hendelser, men ignorerer unormal trafikk mot egne API-er, mister ofte det tidligste varselet av alle, siden mange angripere tester og verifiserer et exploit mot et API-endepunkt før de i det hele tatt sender en transaksjon til kjeden.

Til slutt: sett et konkret mål for hvor lang tid det skal ta fra en anomali oppstår til et menneske har sett varselet, og mål faktisk denne tiden hver måned. Team som aldri måler egen responstid har en tendens til å anta at oppsettet fungerer bedre enn det faktisk gjør, helt til den dagen det testes av en ekte hendelse i stedet for en øvelse.

Ofte stilte spørsmål

Er DeFi-overvåking et alternativ til smart-kontraktrevisjon?
Nei. Revisjon og overvåking dekker forskjellige risikoer. Revisjon finner feil i koden før lansering, mens overvåking fanger konfigurasjonsfeil, kompromitterte nøkler og angrep som oppstår etter at koden allerede er live og verifisert.

Hvor mye koster det å komme i gang med sanntidsovervåking?
For protokoller under 10 millioner dollar i TVL kan du starte helt gratis med Forta community-boter og OpenZeppelin Defenders gratisnivå. Kostnaden øker først når du trenger Premium Feeds, Tenderly Alerts i produksjonsvolum eller en enterprise-plattform.

Kan automatisert respons, som en nødpause, gjøre mer skade enn nytte?
Ja, hvis terskelverdiene er satt for stramt eller aldri er testet mot ekte trafikkmønstre. Test alltid pause-logikken grundig på testnett og analyser historisk data før du kobler den til en mainnet-kontrakt.

Trenger en liten protokoll virkelig en on-call-rotasjon?
Ikke nødvendigvis en formell rotasjon med vaktordning, men minst to personer bør ha tilgang til å reagere på et kritisk varsel. Ett enkelt punkt for feil i hendelsesresponsen er en av de vanligste fallgruvene vi beskrev over.

Hvilket verktøy bør jeg velge først hvis jeg bare har tid til ett?
Start med Forta Network, siden community-botene er gratis og gir bred dekning av kjente angrepsmønstre uten at du selv må skrive egendefinert deteksjonslogikk fra dag én.

Hvordan overvåker jeg cross-chain-broer spesifikt?
Broer krever ekstra oppmerksomhet på signeringsnøkler og nonce-validering, siden flere 2026-hendelser har vist at manglende nonce-sjekk i signerte meldinger tillater replay av tidligere gyldige signaturer. Legg til en egen Sentinel som sammenligner utstedte og innløste meldinger på begge sider av broen.

Fanger sanntidsovervåking angrep som utnytter feilkonfigurerte tilgangsroller?
Delvis. En Defender Sentinel som varsler ved enhver endring i en tilgangsrolle eller eieradresse gir deg rask beskjed, men selve konfigurasjonsfeilen må fortsatt fanges av god testpraksis og kodegjennomgang før deploy.

Hvor ofte bør jeg gå gjennom og justere terskelverdiene i overvåkingssystemet?
Gjør en full gjennomgang minst hver tredje måned, og alltid etter enhver betydelig endring i protokollens brukstall, TVL eller kontraktlogikk. Terskler satt for en protokoll med 5 millioner dollar i TVL gir ofte støy eller blindsoner når TVL har vokst til 50 millioner dollar.

DeFi-Overvåking i Sanntid: 12 Steg, 45 Min [2026]