I juni 2026 forsvant rundt 127 millioner dollar fra en cross-chain bro etter det som ble beskrevet som signaturgjenbruk kombinert med fravær av en kjedespesifikk nonce. Angrepet føyer seg inn i et mønster: ifølge en rapport som siterer PeckShield sto åtte brorelaterte hack for et samlet tap på rundt 328,6 millioner dollar i 2026, i en sektor der broer til sammen holder rundt 21,94 milliarder dollar i låst verdi. Det som gjør denne typen angrep spesielt farlige, er hastigheten: midler forsvinner ofte i løpet av minutter, lenge før et menneskelig team rekker å oppdage avviket manuelt gjennom en block explorer.

Denne artikkelen viser hvordan du bygger et eget overvåkingssystem som fanger opp den typen avvik før midlene er borte, ikke etter. Du får konkret kode for hendelseslytting, supply-avstemming, validator-overvåking og varsling, pluss en full prosjektstruktur du kan sette rett i produksjon. Guiden er skrevet for utviklere og sikkerhetsansvarlige i nordiske selskaper som drifter egne broer, tilbyr kjedekryssende tjenester, eller forvalter store beholdninger på tvers av flere blokkjeder.

Hvorfor overvåking av cross-chain broer er blitt kritisk i 2026

Cross-chain broer flytter verdi mellom blokkjeder ved å låse midler på én kjede og prege en representasjon på en annen. Modellen har vært angrepsflaten i noen av de største kryptohackene som er dokumentert: Ronin-broen mistet 625 millioner dollar i 2022, Wormhole mistet 325 millioner dollar samme år, og Nomad mistet 190 millioner dollar bare uker senere. Disse sakene brukes fortsatt som referansepunkt når sikkerhetsteam designer nye forsvar, og vi har tidligere gått gjennom generell bro-sikkerhet i 12 steg på shattered.io.

Bildet har faktisk blitt bedre de siste årene. Ifølge Immunefis økosystemanalyse for 2026 falt de totale DeFi-protokolltapene til rundt 680,3 millioner dollar i 2025, ned fra 2,62 milliarder dollar i 2022, en nedgang på omtrent 74 prosent. Samme datasett viser at bro-hendelser sto for 73 prosent av DeFi-tapene i 2022, men bare 3 prosent i 2025. Median-tapet per DeFi-hendelse falt til rundt 1,5 millioner dollar i 2025, ned fra 6 millioner dollar i 2022. Bedre revisjoner, formell verifisering og strengere multisig-krav hos de store brobyggerne har tydelig gjort forskjell, se Immunefis forskningsarkiv for full metodikk.

Trenden har likevel snudd i 2026. Tall som siteres fra DefiLlama viser 26 angrep mot broer og kjedekryssende infrastruktur i 2026, mer enn 10 prosent av alle hendelser, mot bare tre tilsvarende hendelser i 2025. Ifølge TRM Labs’ trusselanalyser ble det talt 207 krypto-hack og utnyttelser i første halvår 2026, hvorav 125 ble klassifisert som smartkontrakt-utnyttelser. Infrastrukturkompromittering sto for rundt 76 prosent av tapene i samme periode, selv om slike angrep bare utgjorde 15 prosent av hendelsene. Broer angripes sjeldnere enn før, men når det skjer, er tapene uforholdsmessig store. Chainalysis anslår at det samlede krypto-tyveriet nådde rundt 3,4 milliarder dollar i 2025, se Chainalysis’ kriminalitetsrapport for 2026.

For norske og nordiske selskaper er dette ikke bare et teknisk spørsmål. Norge følger EUs kryptoregulering gjennom EØS-avtalen, og tilbydere som lar kunder flytte verdier på tvers av kjeder må kunne dokumentere operasjonell sikkerhet overfor tilsynsmyndigheter, ikke bare overfor egne kunder. Et selskap som bygger eller integrerer mot en cross-chain bro bør derfor behandle overvåking som en del av compliance-arbeidet, på linje med annen kryptovaluta-sikkerhet vi dekker på shattered.io, ikke som et rent utviklerverktøy.

Denne guiden bygger et praktisk overvåkingssystem for cross-chain broer fra bunnen av. Du kobler til to kjeder samtidig, sammenligner beholdning mellom dem, følger med på validator-settet, oppdager signaturgjenbruk og setter opp varsler som treffer Discord eller Telegram innen sekunder. Vi bygger videre på tematikken fra vår artikkel om sanntids DeFi-overvåking, men med spesifikt fokus på bro-arkitektur.

Forutsetninger: dette trenger du før du starter

Du trenger ikke være smartkontrakt-utvikler for å følge denne guiden, men grunnleggende kjennskap til JavaScript og EVM-hendelser gjør ting enklere. Sett av rundt 60 minutter til selve oppsettet.

  • Node.js LTS, versjon 20 eller nyere
  • npm eller pnpm som pakkebehandler
  • ethers.js, versjon 6 (biblioteket for å snakke med EVM-kjeder)
  • RPC-tilgang til minst to kjeder, for eksempel via Alchemy, Infura eller egen node
  • En Discord- eller Telegram-webhook for varsler
  • Grunnleggende forståelse av Solidity-hendelser og ABI-formatet
  • Foundry eller Hardhat for å teste mot en lokal testnett-node før du peker mot mainnet
  • Valgfritt: Docker og Docker Compose for produksjonsdrift
  • Valgfritt: PostgreSQL eller SQLite for historikk og etterprøving

Du trenger også kontraktadressene og ABI-en til broen du skal overvåke. De fleste seriøse broprosjekter publiserer dette åpent på GitHub eller i sin dokumentasjon. Finn adressene for både kilde- og målkjeden før du går videre, for uten dem kan ikke lytteren koble hendelser sammen.

Sett av realistisk tid per steg dersom flere personer skal jobbe med dette. Kartlegging av arkitektur og prosjektoppsett tar typisk 10–15 minutter, hendelseslytting og avstemming tar 15–20 minutter, validator- og signaturovervåking tar 10–15 minutter, og varsling pluss driftsoppsett tar de resterende 15–20 minuttene. Et erfarent team klarer hele oppsettet innenfor 60 minutter, mens et team som er nytt både i Node.js og EVM-hendelser bør regne med to til tre timer for første gjennomkjøring.

Steg 1–2: Kartlegg broens arkitektur og sett opp prosjektet

Lock-and-mint vs. burn-and-mint

Før du skriver kode, må du forstå hvilken modell broen bruker. I en lock-and-mint-modell låses midlene på kildekjeden i en hvelv-kontrakt, mens en tilsvarende mengde tokens preges på målkjeden. I en burn-and-mint-modell brennes tokens på den ene kjeden og preges på nytt på den andre, uten et permanent hvelv. Forskjellen betyr noe for overvåkingen: lock-and-mint krever at du sjekker hvelvets saldo mot totalt utstedte tokens, mens burn-and-mint krever at du teller brenn- og pregingshendelser og sjekker at de går i null over tid.

Meldingsbaserte broer vs. likviditetsbaserte broer

En annen viktig distinksjon er om broen sender en generell melding mellom kjedene, eller om den flytter likviditet direkte. Meldingsbaserte broer, som LayerZero og Wormhole, sender et signert bevis fra kildekjeden som en relayer eller et sett med “guardians” leverer til målkjeden. Vi har tidligere skrevet om hvordan LayerZero forsøker å stoppe falske bro-meldinger, og mekanismen der er et godt eksempel på hvor mye av sikkerheten som hviler på selve meldingsleveransen, ikke bare på selve tokenbevegelsen.

Likviditetsbaserte broer, som Across og Hop Protocol, fungerer annerledes. De har forhåndsfylte likviditetspooler på begge sider og betaler ut fra den lokale poolen umiddelbart, for så å avregne mellom operatørene i etterkant. For overvåkingsformål betyr dette at du må følge to helt ulike signaler: meldingsbaserte broer krever at du sjekker at hver melding faktisk kommer fra det legitime relayer- eller guardian-settet, mens likviditetsbaserte broer krever at du følger poolbalansen og avregningsfrekvensen. Bygger du overvåking for en bro du ikke kjenner arkitekturen til fra før, er dette det første du bør avklare med broteamet eller i dokumentasjonen deres, for koden i denne guiden må tilpasses riktig modell.

Sett opp prosjektmappen og installer avhengighetene. Vi bruker ethers v6 fordi det har innebygd støtte for WebSocket-providere, noe som gjør sanntidslytting enklere enn med eldre versjoner.

mkdir bridge-monitor && cd bridge-monitor
npm init -y
npm install ethers@^6.0.0 dotenv node-fetch
mkdir src config
touch src/monitor.js src/reconcile.js src/alerts.js .env

Legg kontraktadresser, RPC-URL-er og webhook-nøkler i .env-filen. Aldri sjekk denne filen inn i versjonskontroll, den inneholder hemmeligheter som kan misbrukes hvis de lekker.

SOURCE_RPC_WS=wss://eth-mainnet.g.alchemy.com/v2/DIN_NOKKEL
TARGET_RPC_WS=wss://polygon-mainnet.g.alchemy.com/v2/DIN_NOKKEL
BRIDGE_SOURCE_ADDRESS=0x...
BRIDGE_TARGET_ADDRESS=0x...
DISCORD_WEBHOOK_URL=https://discord.com/api/webhooks/...
ALERT_THRESHOLD_USD=500000

Steg 3–4: Koble til RPC-endepunkter og bygg en hendelseslytter

Neste steg er å koble til begge kjedene samtidig og lytte etter de hendelsene som faktisk betyr noe: Lock, Mint, Burn og Release. Navnene varierer mellom broprosjekter, så sjekk ABI-en for de eksakte hendelsesnavnene før du kjører koden. De fleste EVM-broer følger likevel et av disse fire mønstrene.

import { WebSocketProvider, Contract } from "ethers";
import "dotenv/config";
import { sendAlert } from "./alerts.js";

const bridgeAbi = [
  "event Locked(address indexed sender, uint256 amount, uint256 indexed destChainId, bytes32 indexed txHash)",
  "event Released(address indexed recipient, uint256 amount, bytes32 indexed sourceTxHash)"
];

const sourceProvider = new WebSocketProvider(process.env.SOURCE_RPC_WS);
const targetProvider = new WebSocketProvider(process.env.TARGET_RPC_WS);

const sourceBridge = new Contract(process.env.BRIDGE_SOURCE_ADDRESS, bridgeAbi, sourceProvider);
const targetBridge = new Contract(process.env.BRIDGE_TARGET_ADDRESS, bridgeAbi, targetProvider);

sourceBridge.on("Locked", async (sender, amount, destChainId, txHash, event) => {
  console.log("Locked:", sender, amount.toString(), txHash);
  await logEvent("lock", { sender, amount, txHash, block: event.log.blockNumber });
});

targetBridge.on("Released", async (recipient, amount, sourceTxHash, event) => {
  console.log("Released:", recipient, amount.toString(), sourceTxHash);
  await logEvent("release", { recipient, amount, sourceTxHash, block: event.log.blockNumber });
});

Legg merke til at hver hendelse logges med en lagringsfunksjon (logEvent) i stedet for å bare skrives til konsollen. Dette er avgjørende, for du trenger en historikk å avstemme mot i neste steg. Bruk SQLite for et lite oppsett, eller PostgreSQL hvis du overvåker flere broer samtidig og trenger å kjøre spørringer på tvers av dem.

Overvåking av multi-hop og flerkjede-broer

Mange nyere broprotokoller ruter ikke direkte mellom to kjeder, men gjennom en eller flere mellomliggende kjeder eller en egen konsensusmekanisme, ofte kalt en hub. Dette kompliserer overvåkingen, fordi et avvik kan oppstå midt i kjeden uten at det er synlig hverken på kilde- eller målkjeden alene. Løsningen er å utvide hendelseslytteren til å inkludere hver mellomliggende kjede i ruten, og å bygge avstemmingslogikken som en kjede av sjekkpunkter fremfor et enkelt kilde-mål-par.

I praksis betyr dette at du legger til en providerinstans og et sett med kontraktadresser for hvert hopp, og at reconcile-funksjonen kjører separat for hvert par av tilstøtende kjeder i ruten. Hvis broen for eksempel går fra Ethereum via en egen konsensuskjede og videre til Arbitrum, overvåker du både Ethereum-til-hub og hub-til-Arbitrum som to uavhengige avstemminger. Et avvik som bare dukker opp i det andre hoppet, forteller deg langt mer presist hvor i kjeden problemet oppstod, enn om du kun sammenlignet start- og sluttpunktet.

Steg 5: Bygg supply-avstemming mellom kjedene

Kjernen i overvåkingen er et enkelt regnestykke: summen av det som er låst eller brent på kildekjeden skal til enhver tid stemme med summen av det som er preget eller frigitt på målkjeden, med en liten forsinkelse for blokkbekreftelser. Når disse to tallene ikke stemmer, har noe gått galt, enten en feil i broen, en midlertidig etterslep, eller i verste fall et angrep.

export async function reconcile(db) {
  const locked = await db.get(
    "SELECT COALESCE(SUM(amount), 0) as total FROM events WHERE type = 'lock'"
  );
  const released = await db.get(
    "SELECT COALESCE(SUM(amount), 0) as total FROM events WHERE type = 'release'"
  );

  const diff = BigInt(locked.total) - BigInt(released.total);
  const diffAbs = diff > 0n ? diff : -diff;

  if (diffAbs > BigInt(process.env.ALERT_THRESHOLD_USD)) {
    return { ok: false, diff: diffAbs.toString() };
  }
  return { ok: true, diff: diffAbs.toString() };
}

Kjør avstemmingen på et intervall, for eksempel hvert femte minutt, ikke ved hver enkelt hendelse. Broer har normal etterslep på grunn av ulik blokktid mellom kjeder, og for hyppig sjekking gir falske positiver. Et intervall på fem til ti minutter fanger opp reelle avvik uten å oversvømme deg med støy.

Et konkret eksempel gjør regnestykket lettere å forstå. Si at broen din normalt har rundt 50 millioner dollar i daglig volum. Hvis avstemmingen finner et avvik på 300 000 dollar klokken 14:03, men avviket forsvinner ved neste sjekk klokken 14:08, var det trolig bare forsinkede blokkbekreftelser på den tregeste kjeden. Hvis derimot avviket vokser fra 300 000 til 2 millioner dollar over tre påfølgende sjekker, står du overfor et reelt problem som krever umiddelbar oppfølging. Denne typen trendanalyse, ikke bare enkeltmålinger, er det som skiller et pålitelig system fra ett som drukner deg i falske alarmer.

Steg 6: Overvåk validator- og signer-settet

Validatorkompromittering oppstår når settet som signerer uttak er for lite, for sentralisert, eller for lett å fiske etter med phishing. Ronin-hacket i 2022 er fortsatt skolebok-eksempelet: angriperne fikk kontroll over fem av ni validatornøkler og kunne signere falske uttak fritt. Broer publiserer normalt validator- eller guardian-settet sitt som en lesbar funksjon på kontrakten, og du bør overvåke denne funksjonen for endringer akkurat som du overvåker pengestrømmen.

let knownValidators = new Set();

async function checkValidatorSet(bridgeContract) {
  const current = await bridgeContract.getValidatorSet();
  const currentSet = new Set(current.map(v => v.toLowerCase()));

  const added = [...currentSet].filter(v => !knownValidators.has(v));
  const removed = [...knownValidators].filter(v => !currentSet.has(v));

  if (added.length || removed.length) {
    await sendAlert({
      severity: "high",
      message: `Validator-sett endret. Lagt til: ${added.join(", ") || "ingen"}. Fjernet: ${removed.join(", ") || "ingen"}.`
    });
  }
  knownValidators = currentSet;
}

Kjør denne sjekken minst hvert tiende minutt. En legitim validator-rotasjon skjer sjelden og varsles gjerne på forhånd av broteamet, mens en uventet endring midt på natten er nettopp den typen signal du vil fanges opp automatisk, ikke lese om i et nyhetsbrev dagen etter.

Et praktisk poeng er terskelen for hvor mange validatorer som må signere før et uttak godkjennes, ofte omtalt som en m-av-n-terskel. En bro med ni validatorer og krav om fem signaturer tåler at fire nøkler kompromitteres uten at angriperen kan gjøre noe, men mister denne sikkerhetsmarginen helt dersom en femte nøkkel også faller. Overvåkingssystemet bør derfor ikke bare varsle når terskelen faktisk brytes, men også når andelen kompromitterte eller mistenkelige nøkler nærmer seg terskelen, for eksempel ved tre av fem nødvendige signaturer fra samme IP-område eller med unormalt identisk tidsstempel.

Steg 7: Oppdag signaturgjenbruk og manglende kjede-ID

Domeneseparasjon med EIP-712 i praksis

Signaturgjenbruk, ofte kalt replay-angrep, oppstår når en angriper tar en gyldig signatur ment for én kjede og bruker den samme signaturen til å utløse en identisk handling på en annen kjede. Dette var trolig faktoren bak juni 2026-hendelsen på 127 millioner dollar nevnt innledningsvis. Løsningen er domeneseparasjon: signaturen skal binde seg til en spesifikk kjede-ID, kontraktadresse og versjon, ikke bare til beløp og mottaker. EIP-712-standarden definerer nøyaktig hvordan dette gjøres i praksis, og en fersk akademisk gjennomgang på arXiv om signaturgjenbruk i smartkontrakter dokumenterer hvor ofte manglende domeneseparasjon fortsatt dukker opp i produksjonskode.

function buildDomainSeparator(chainId, verifyingContract) {
  return {
    name: "BridgeProtocol",
    version: "1",
    chainId: chainId,
    verifyingContract: verifyingContract
  };
}

async function watchForReplaySignals(events) {
  const seen = new Map();
  for (const evt of events) {
    const key = evt.signatureHash;
    if (seen.has(key) && seen.get(key).chainId !== evt.chainId) {
      await sendAlert({
        severity: "critical",
        message: `Mulig signaturgjenbruk oppdaget: samme signatur brukt på kjede ${seen.get(key).chainId} og ${evt.chainId}`
      });
    }
    seen.set(key, evt);
  }
}

Overvåkeren din bør sammenligne signaturhasher på tvers av alle kjedene broen betjener, ikke bare de to du primært følger. Mange broer opererer på fem eller flere kjeder samtidig, og et replay-angrep kan i teorien ramme et kjedepar du ikke overvåker like tett. Utvid derfor listen over kjede-ID-er etter hvert som broen legger til støtte for nye nettverk.

Steg 8–9: Sett terskelverdier og bygg varslingskanalen

Et overvåkingssystem uten fungerende varsler er verdiløst, uansett hvor godt logikken er skrevet. Bygg en enkel funksjon som sender varsler til Discord eller Telegram, og sørg for at kritiske varsler også går til en sekundær kanal, for eksempel SMS via Twilio, slik at utfall av én tjeneste ikke gjør deg blind.

import fetch from "node-fetch";

export async function sendAlert({ severity, message }) {
  const emoji = { critical: "🔴", high: "🟠", medium: "🟡" }[severity] || "⚪";
  const payload = {
    content: `${emoji} **[${severity.toUpperCase()}]** ${message}`
  };

  const res = await fetch(process.env.DISCORD_WEBHOOK_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload)
  });

  if (!res.ok) {
    console.error("Varsel feilet:", res.status, await res.text());
  }
}

Discord har en grense på rundt 30 forespørsler per minutt per webhook, noe som er mer enn nok for normal drift, men kan bli en flaskehals hvis systemet ditt sender ett varsel per hendelse under et faktisk angrep med hundrevis av transaksjoner i sekundet. Legg inn enkel gruppering, slik at flere relaterte varsler innen et kort tidsvindu slås sammen til én melding fremfor å oversvømme kanalen akkurat når du trenger den mest. Mange team dupliserer også varselfunksjonen mot Telegram, siden Telegrams bot-API har en annen infrastruktur enn Discord og dermed sjeldnere rammes av samtidig nedetid.

Terskelverdiene bør ikke være tilfeldige. Sett dem ut fra hva broen normalt håndterer av volum, ikke ut fra en generisk sum. En bro som normalt flytter 200 000 dollar i timen bør varsle ved avvik på 50 000 dollar, mens en bro med daglig volum på 50 millioner dollar trenger en helt annen skala. Tabellen under viser et utgangspunkt du kan justere etter egen bros trafikkmønster.

MetrikkTerskel (forslag)AlvorlighetsgradAnbefalt handling
Avvik i supply-avstemming> 0,5 % av TVLKritiskVurder pause umiddelbart
Validator-sett endret uten forvarselEnhver endringHøyVerifiser manuelt innen 15 min
Duplisert signaturhash på tvers av kjederEnhver forekomstKritiskPause og varsle teamet
Uttak over normalt volum> 3x gjennomsnitt siste 24tMiddelsManuell gjennomgang
Manglende blokkbekreftelser> 10 min forsinkelseLavSjekk RPC-status

Steg 10–11: Definer responsprosedyrer og test mot kjente angrepsmønstre

De tre gjentakende angrepsmønstrene

Et varsel er nytteløst uten en plan for hva som skjer etterpå. Team som bygger avansert deteksjon, men aldri øver på selve responsen, opplever ofte at de første minuttene etter et reelt varsel går med til å finne ut hvem som har fullmakt til å handle, ikke til selve handlingen. Skriv derfor ned en konkret responsprosedyre før du setter systemet i produksjon, ikke etter det første varselet kommer klokken tre om natten. En god prosedyre har fire trinn: pause broen dersom kontrakten har en pause-funksjon og du har fullmakt til å bruke den, tilbakekall eventuelle kompromitterte signeringsnøkler, verifiser avviket manuelt mot begge kjedenes utforskere, og varsle brukerne gjennom offisielle kanaler før ryktene sprer seg selv.

De fleste bro-hack faller inn under tre gjentakende mønstre. Ronin-formen handler om kompromitterte validatornøkler, ofte gjennom sosial manipulering av ansatte. Wormhole-formen handler om et hull i signatur- eller bevisverifiseringen, der kontrakten godtar noe den ikke skulle. Nomad-formen handler om en initialiseringsfeil som gjorde at ethvert meldingsbevis ble godkjent som gyldig. Test overvåkingssystemet ditt ved å simulere alle tre mønstrene på en lokal Foundry- eller Hardhat-node før du stoler på det i produksjon. Legg til enhetstester som bevisst sender en falsk validator-endring, en duplisert signatur og et supply-avvik, og bekreft at systemet fanger alle tre.

import { test } from "node:test";
import assert from "node:assert";
import { reconcile } from "../src/reconcile.js";
import { watchForReplaySignals } from "../src/replay.js";

test("oppdager supply-avvik over terskel", async () => {
  const fakeDb = mockDb({ locked: 1000000n, released: 400000n });
  const result = await reconcile(fakeDb);
  assert.strictEqual(result.ok, false);
});

test("oppdager duplisert signaturhash på tvers av kjeder", async () => {
  const events = [
    { signatureHash: "0xabc", chainId: 1 },
    { signatureHash: "0xabc", chainId: 137 }
  ];
  const alerts = await watchForReplaySignals(events);
  assert.strictEqual(alerts.length, 1);
});

Kjør denne testpakken i CI-pipelinen din hver gang du endrer overvåkingslogikken, ikke bare når du først bygger systemet. Regresjonsfeil i deteksjonskode er spesielt farlige, fordi de er usynlige helt til et faktisk angrep avslører dem.

Vi har tidligere dekket hvordan LayerZero-økosystemet håndterer falske bro-meldinger, se vår gjennomgang av LayerZero-sikkerhet, og prinsippene der overlapper med testmetodikken beskrevet her.

Steg 12: Sett opp kontinuerlig drift, logging og det komplette prosjektet

Et overvåkingssystem som stopper å kjøre er like ubrukelig som et som aldri ble bygget. Kjør det som en systemd-tjeneste på en dedikert server, eller pakk det i en Docker-container for enklere drift på tvers av miljøer. Filstrukturen for et komplett prosjekt ser slik ut: src/monitor.js (hendelseslytteren fra steg 3–4), src/reconcile.js (avstemmingslogikken fra steg 5), src/validators.js (validator-sjekken fra steg 6), src/replay.js (signaturkontrollen fra steg 7), src/alerts.js (varslingsfunksjonen fra steg 8–9), pluss package.json, .env og en docker-compose.yml som binder alt sammen.

version: "3.9"
services:
  bridge-monitor:
    build: .
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./data:/app/data
    healthcheck:
      test: ["CMD", "node", "healthcheck.js"]
      interval: 60s
      timeout: 10s
      retries: 3

Legg til en healthcheck-fil som verifiserer at WebSocket-tilkoblingene faktisk lever, ikke bare at prosessen kjører. En død RPC-tilkobling som ikke krasjer prosessen er en av de vanligste årsakene til at overvåkingssystemer slutter å fange opp hendelser uten at noen merker det før det er for sent.

Vanlige fallgruver ved bygging av bridge-overvåking

  • For lav terskel gir varselutmattelse. Et team som mottar 40 varsler daglig, slutter raskt å lese dem nøye. Kalibrer terskler mot faktisk trafikkvolum for den spesifikke broen, ikke mot en generisk gjetning hentet fra en annen protokoll.
  • Kun én RPC-leverandør. Hvis leverandøren din har nedetid eller strupe hastigheten din, er du blind i akkurat den perioden. Bruk minst to uavhengige RPC-endepunkter med automatisk fallback, og test fallback-logikken jevnlig, ikke bare når den faktisk trengs.
  • Avstemming uten buffer for blokktid. Ulike kjeder bekrefter blokker i ulikt tempo, fra under ett sekund til flere minutter. Uten en kort buffer vil systemet varsle om avvik som løser seg selv i løpet av minutter, og teamet slutter å stole på varslene.
  • Å stole blindt på verifiserte kontrakter. En verifisert kildekode betyr ikke fravær av sårbarheter, den betyr bare at koden er lesbar for alle, inkludert angripere som leter etter feil. Les den likevel, og revider den på nytt ved hver oppgradering.
  • Å glemme validator-rotasjon som skjer gradvis over flere transaksjoner. Noen angripere bytter ut validatorer stegvis for å unngå å utløse en enkelt stor varsling. Sammenlign alltid mot det fullstendige historiske settet, ikke bare forrige sjekk, slik at gradvise endringer ikke glir under radaren.
  • Ingen sekundær varslingskanal. Hvis Discord er nede samtidig som broen angripes, mister du varselet helt. Dupliser kritiske varsler til minst to uavhengige kanaler, for eksempel Discord og SMS.
  • Å hardkode kjede-ID-er. Broer legger stadig til støtte for nye nettverk. Et system som ikke kan utvides med nye kjede-ID-er uten en kodeendring, blir fort utdatert og krever manuell vedlikehold hver gang broteamet ekspanderer.
  • Å teste kun mot lykkelige scenarioer. Mange team tester at systemet fungerer når alt går som normalt, men glemmer å simulere faktiske angrepsmønstre. Uten testing mot kjente feilklasser vet du ikke om systemet faktisk fanger opp et reelt angrep før det er for sent.

Feilsøking: åtte vanlige problemer og løsninger

Selv et velbygget overvåkingssystem støter på driftsproblemer, og de fleste av dem har lite med selve deteksjonslogikken å gjøre. Erfaring fra team som har driftet slike systemer over tid viser at driftsproblemer, ikke feil i selve varslingsreglene, er den vanligste årsaken til at systemer slutter å fungere som forventet. Tabellen under dekker de vanligste feilene team støter på i produksjon, sortert etter hvor ofte de faktisk dukker opp.

ProblemSannsynlig årsakLøsning
WebSocket kobles stadig fraRPC-leverandøren begrenser lange tilkoblingerImplementer automatisk reconnect med eksponentiell backoff
Falske positiver i avstemmingFor kort buffer mellom kjedeneØk buffertiden til 5–10 minutter
Manglende hendelser i loggenNode har ikke full historikk (light node)Bytt til en arkivnode eller en leverandør med full historikk
Dupliserte varsler for samme hendelseFlere prosessinstanser kjører samtidigBruk en låsemekanisme eller kjør kun én replika
Høy CPU-bruk over tidMinnelekkasje i hendelseslytterenRestart periodisk eller fiks event listener cleanup
Varsler kommer for sentAvstemmingsintervallet er for langtReduser intervallet, men ikke under 2 minutter
ABI-feil ved dekodingBroen har oppgradert kontraktenHent oppdatert ABI fra prosjektets GitHub
Discord-webhook svarer 401Webhook er slettet eller rotertGenerer en ny webhook-URL i Discord-serverinnstillingene

De fleste av disse problemene deler en fellesnevner: de oppstår fordi overvåkingssystemet antar at nettverket alltid oppfører seg som forventet. RPC-leverandører går ned, blokker forsinkes, og prosesser krasjer uten varsel. Bygg derfor inn retry-logikk og loggføring på hvert eneste steg, ikke bare i selve deteksjonslogikken. Et system som stille slutter å fungere er farligere enn intet system i det hele tatt, fordi teamet tror seg beskyttet når de faktisk ikke er det.

Avanserte tips for produksjonsmiljøer

Når grunnsystemet fungerer stabilt, er det flere forbedringer som løfter det fra et hobbyprosjekt til noe et sikkerhetsteam faktisk kan stole på. Legg til en dashbord-visning med Grafana koblet mot en tidsseriedatabase, slik at trender i uttaksvolum blir synlige over tid, ikke bare som enkeltvarsler. Bygg inn en simuleringsmodus som kjører mot en fork av mainnet via Anvil, slik at nye deteksjonsregler kan testes mot historiske angrep uten risiko for produksjonsdata.

Et annet tips som ofte overses, er å legge overvåkingen så nær kjeden som mulig. Jo lenger unna RPC-endepunktet ditt er fra selve valideringsnoden, desto større er forsinkelsen mellom at en hendelse skjer og at systemet ditt oppdager den. Team med høye krav til responstid kjører gjerne egne noder eller betaler for dedikerte, lavlatente RPC-abonnement fremfor delte gratistjenester. Vurder også å legge inn et enkelt reputasjonssystem for relayere og signere, der du logger hvor ofte hver enkelt aktør leverer gyldige versus ugyldige bevis over tid. En signer med plutselig fallende kvalitet på leveransene er ofte det første tegnet på at noe er galt, lenge før et fullstendig kompromiss er et faktum.

Vurder også å abonnere på et kommersielt overvåkingslag i tillegg til ditt eget system, ikke som erstatning. Verktøy som Forta og OpenZeppelin Defender har egne deteksjonsmotorer trent på tvers av tusenvis av kontrakter, noe et internt team sjelden har ressurser til å bygge alene. Kombinasjonen av et skreddersydd system, som vet nøyaktig hvordan din bro fungerer, og et bredt kommersielt lag, som fanger opp mønstre på tvers av hele økosystemet, gir bedre dekning enn noen av delene alene.

Dokumenter alle falske positiver systematisk. Et team som ikke fører logg over hvorfor et varsel var falskt, ender opp med å justere terskler tilfeldig i stedet for basert på data. Etter tre til seks måneder med drift har du nok historikk til å stole på tersklene dine langt mer enn du kunne ved oppstart.

Bro-angrep og overvåkingsverktøy i tall

Tabellen under oppsummerer utviklingen i DeFi- og bro-relaterte tap fra 2022 til 2025/2026, basert på tall fra Immunefi og TRM Labs referert tidligere i artikkelen.

PeriodeTotale DeFi-tapBroens andel av tapeneMedian tap per hendelse
20222,62 mrd. dollar73 %6 mill. dollar
2025680,3 mill. dollar3 %1,5 mill. dollar
H1 2026 (TRM Labs)207 hendelser totalt~15 % infrastruktur, 76 % av tapeneIkke oppgitt separat
2026 (bro-spesifikt, PeckShield)328,6 mill. dollar8 hendelserIkke oppgitt separat

Legg merke til hvor mye lavere broens andel av det totale tapet ble fra 2022 til 2025, men også hvordan andelen tapt gjennom infrastrukturkompromittering i første halvår 2026 igjen dominerer bildet uforholdsmessig, gitt hvor få hendelser det faktisk gjelder. Det underbygger at bro-overvåking fortsatt fortjener egen oppmerksomhet, ikke bare generell smartkontrakt-revisjon som beskrevet i vår tidligere gjennomgang av orakelmanipulasjon i DeFi eller flash loan-angrep testet med Foundry.

For de som vurderer kommersielle alternativer i tillegg til et eget system, viser tabellen under en grov sammenligning av tilnærminger, uten at dette er en uttømmende liste over alle leverandører i markedet.

TilnærmingDekningOppsettstidBeste bruksområde
Eget skript (denne guiden)Skreddersydd til én broTimer til dagerTeam med egen bro eller spesifikk protokoll å overvåke
Forta-nettverkBredt, crowdsourcede deteksjonsbotterMinutterRask dekning på tvers av mange protokoller
OpenZeppelin DefenderOvervåking pluss automatisert responsTimerTeam som allerede bruker OpenZeppelin i utvikling
Chainalysis KYTTransaksjonssporing og complianceDager (onboarding)Børser og regulerte aktører

Ingen av disse alternativene utelukker hverandre. Et modent sikkerhetsoppsett kombinerer typisk et skreddersydd skript som forstår nøyaktig hvordan din bro fungerer, med et bredere nettverk som Forta for å fange opp mønstre på tvers av hele økosystemet, og eventuelt et compliance-lag som Chainalysis KYT dersom virksomheten er underlagt rapporteringsplikt. Start med det skreddersydde skriptet fra denne guiden, og legg til de øvrige lagene etter hvert som driften modnes og risikobildet blir klarere.

Ofte stilte spørsmål

Må jeg være smartkontrakt-utvikler for å bygge dette systemet?
Nei. Du trenger å kunne lese ABI-er og forstå grunnleggende JavaScript. Selve overvåkingslogikken kjører utenfor kjeden og krever ikke at du skriver eller distribuerer Solidity-kode.

Hvor lang tid tar det å sette opp hele systemet?
Regn med rundt 60 minutter for et grunnleggende oppsett som dekker hendelseslytting, avstemming og varsler. Produksjonsklar drift med Docker, healthchecks og dashbord tar typisk en til to arbeidsdager ekstra.

Kan jeg bruke dette systemet på flere broer samtidig?
Ja, men kjør separate instanser per bro, eller utvid databasemodellen til å inkludere et bro-ID-felt på hver hendelse. Å blande hendelser fra ulike broer i samme avstemming gir uklare og upålitelige resultater.

Hvilken kjede bør jeg starte med å overvåke?
Start med kjedeparet som har høyest volum for din organisasjon. Ethereum og de store EVM-kompatible kjedene som Polygon og Arbitrum har best RPC-støtte og dokumentasjon, noe som gjør dem enklest å begynne med. Ikke-EVM-kjeder som Solana krever egne biblioteker i stedet for ethers.js, så vurder å utvide til slike kjeder som et eget prosjekt når EVM-oppsettet er stabilt.

Erstatter dette en profesjonell sikkerhetsrevisjon?
Nei. Overvåking fanger opp avvik etter at de oppstår i drift, mens en revisjon forsøker å finne sårbarheter før koden distribueres. De to er komplementære, ikke erstatninger for hverandre. Et team som kun har det ene laget, mangler enten evnen til å oppdage kjente sårbarhetsklasser på forhånd eller evnen til å fange opp ukjente angrep i sanntid.

Hva gjør jeg hvis systemet varsler om et falskt positiv?
Dokumenter hendelsen, juster terskelen eller bufferen som utløste varselet, og noter årsaken i en logg. Over tid bygger dette opp en kalibreringshistorikk som gjør fremtidige terskler mer presise.

Bør jeg gi overvåkingssystemet fullmakt til å pause broen automatisk?
Vær forsiktig. Automatisk pausing uten menneskelig bekreftelse kan i seg selv bli et angrepspunkt, siden en angriper som kan trigge falske varsler også kan tvinge frem unødvendige pauser. De fleste team lar systemet varsle og krever manuell bekreftelse før pause utløses.

Hvor ofte bør jeg oppdatere ABI-ene og kontraktadressene?
Sjekk dette hver gang broteamet annonserer en oppgradering, og sett opp en kvartalsvis rutinesjekk selv om ingen oppgradering er annonsert. Broer endrer seg oftere enn mange forventer, og en foreldet ABI kan gjøre overvåkingen blind uten at det er åpenbart.

Koster det noe å drifte et slikt overvåkingssystem?
Ja, men beløpet er lite sammenlignet med potensielle tap. De største løpende kostnadene er RPC-abonnement for WebSocket-tilkoblinger med god oppetid, samt en liten server eller container for kontinuerlig drift. For de fleste team med moderat trafikk holder det med et RPC-abonnement i den lave prisklassen og en enkel virtuell server, langt billigere enn ett eneste tapt uttak.