Etter at Bybit mistet rundt 1,46 milliarder dollar i et angrep 21. februar 2025, og etter at Bitget måtte stanse uttak i september 2026 etter et tyveri på 351,6 millioner dollar, stiller stadig flere kryptobrukere det samme spørsmålet: holder børsen faktisk pengene mine? Proof-of-Reserves (PoR) er svaret børsene selv gir, men rapporten er verdiløs hvis du bare tar tallet på siden for god fisk. Denne guiden viser deg, steg for steg, hvordan du faktisk verifiserer en PoR-rapport med egne øyne og egne skript, i stedet for å stole blindt på en prosentandel på en landingsside.

Bakteppet er ikke nytt for norske og nordiske brukere. Kryptobørser har vært det klart mest utsatte angrepspunktet i bransjen de siste to årene, og problemet handler sjelden om at reservene mangler på papiret – det handler om at ingen utenfor børsen sjekker tallene før det er for sent. En bredere kartlegging av krypto-cyberangrep fant 245 registrerte utnyttelser fra januar 2025 til juli 2026, med samlede tap på over 3,63 milliarder dollar, hvor kompromitterte private nøkler og manipulerte prisorakler pekes ut som sentrale angrepsvektorer. Det tallet viser hvorfor egenkontroll er blitt nødvendig: revisjon og PoR forhindrer ikke automatisk et angrep, men de gir deg data til å oppdage problemer raskere enn om du bare stoler på markedsføringstekst.

Kombiner denne guiden med en generell forståelse av hvordan du bør reagere hvis en børs du bruker faktisk blir hacket, og med grunnleggende kontosikkerhet som tofaktorautentisering og API-nøkkelbegrensninger. Proof-of-Reserves er ett lag i en større sikkerhetsstrategi, ikke en erstatning for den.

Du trenger ingen forkunnskap i kryptografi for å komme i gang, men mot slutten bygger vi et lite Python-verktøy som gjør hele jobben automatisk. Sett av rundt 45 minutter, litt mer hvis du vil sette opp automatisk overvåking.

Hva er Proof-of-Reserves, egentlig?

Binance beskriver konseptet slik: “Proof of Reserves (PoR) is a cryptographic auditing method used by crypto exchanges and custodians to prove that their on-chain holdings equal or exceed the total of all user balances” (Binance Academy). Kort sagt: børsen viser at den kontrollerte nok kryptoaktiva til å dekke det den skylder kundene, på et gitt tidspunkt.

Det viktige ordet der er “på et gitt tidspunkt”. En PoR-rapport er et øyeblikksbilde, ikke en løpende garanti. Den sier heller ingenting om gjeld, lån eller andre forpliktelser børsen har utenfor kundeinnskuddene. PwC Sveits oppsummerer det presist: “In essence, Proof of Reserves is the result of a set of procedures, usually conducted by an independent third-party, to provide transparency on the digital assets held on addresses controlled by a custodian or exchange” (PwC). Legg merke til formuleringen “usually” – ikke alle rapporter er faktisk kontrollert av en uavhengig tredjepart, noe vi kommer tilbake til.

Den tekniske kjernen i de fleste PoR-ordninger er et Merkle-tre: en kryptografisk struktur som lar børsen bevise at akkurat din saldo inngår i det totale datasettet, uten å avsløre andre kunders saldoer. Det er denne mekanismen du skal lære å bruke selv i denne guiden, i tillegg til å krysssjekke tallene mot faktiske blokkjedeadresser.

Forutsetninger: dette trenger du før du starter

Du trenger ikke være utvikler for å følge stegene, men du kommer lengst med litt verktøy klart på forhånd:

  • Python 3.11 eller nyere (test med python3 --version) og pakkeinstalleren pip
  • En kryptobørs-konto med aktiv PoR-funksjon (Kraken, OKX, Bybit, Bitget eller MEXC dekkes konkret i denne guiden)
  • Tilgang til en blokkjedeutforsker for hver kjede du vil sjekke: Etherscan for Ethereum, Blockchain.com Explorer for Bitcoin, Solscan for Solana, BscScan for BNB Chain, Arbiscan for Arbitrum
  • Valgfritt, men anbefalt: en gratis API-nøkkel hos den aktuelle blokkjedeutforskeren, slik at du slipper rate-begrensning
  • Et tekstredigeringsprogram (VS Code, Sublime eller lignende) for å tilpasse skriptene
  • Cirka 45 minutter for manuell verifisering, 20 minutter ekstra hvis du setter opp automatisk overvåking med cron

Installer Python-biblioteket vi bruker gjennom guiden:

pip install requests
# hashlib er innebygd i Python og krever ingen separat installasjon

Steg 1: Finn børsens offisielle PoR-side og noter nøkkeldata

Start med å finne den offisielle PoR-siden til børsen din, ikke en tredjepartsartikkel som viser til den. Kraken har lagt sin under Account → Proof of Reserves i Kraken Pro, og oppgir The Network Firm LLP som uavhengig kontrollør. Kraken beskriver selv prosessen slik: “A Proof of Reserves (PoR) review is a procedure performed by an independent 3rd party accountant” (Kraken). Rapportene der dekker BTC, ETH, SOL, USDC, USDT, XRP og ADA, og publiseres kvartalsvis.

OKX publiserer i stedet månedlig, bygget på Merkle-trær kombinert med zk-STARK-teknologi. Ifølge et publisert scorecard hadde OKX 36 sammenhengende månedlige rapporter per april 2026, med 22 aktiva fordelt på over 20 nettverk. Den aktuelle rapporten viste en samlet BTC-, ETH-, USDT- og USDC-beholdning på 23,12 milliarder dollar, kontrollert av sikkerhetsselskapet Hacken. Bybit publiserer på samme måte månedlig siden juni 2024, også kontrollert av Hacken; rapporten datert 22. april 2026 dekket over 65 millioner liability-holdere fordelt på 38 nettverk.

Bitget har publisert PoR månedlig siden desember 2022 og har i tillegg gitt ut et eget åpent verktøy, MerkleValidator, for selvkontroll. I rapport nummer 43 fra juni 2026 oppga Bitget en samlet reservegrad på 123 prosent. Legg merke til at denne ordningen er selvpublisert uten en navngitt ekstern revisor for akkurat dette reserveprogrammet, noe som er en viktig forskjell fra Krakens revisorbekreftede modell. MEXC publiserer også månedlig, med Merkle-proof direkte i brukergrensesnittet; i august 2026 rapporterte de en BTC-reservegrad på 288 prosent, USDT på 115 prosent og USDC på 114 prosent.

Coinbase skiller seg fra de andre: som børsnotert selskap publiserer de ikke en tradisjonell kryptografisk PoR-rapport med individuell Merkle-proof. I stedet rapporterer de gjennom kvartalsvise 10-Q- og årlige 10-K-regnskaper, revidert av Deloitte & Touche. Det gir bredere finansiell innsikt, men ikke et verktøy en vanlig kunde kan bruke til å sjekke sin egen saldo direkte mot en Merkle-rot.

Uansett hvilken børs du bruker: noter snapshot-dato, blokkhøyde, hvilke aktiva som er inkludert, og navnet på en eventuell ekstern kontrollør, før du går videre.

Steg 2: Forstå hvordan en Merkle-inclusion-proof fungerer

Før du kjører noe skript, bør du forstå mekanikken. Det gjør det lettere å oppdage når noe faktisk er galt, i stedet for å bare stole på at et program sier “OK”.

Slik bygges og verifiseres beviset

  1. Børsen lager et datasett med en (ofte anonymisert) konto-ID, aktivum og saldo for hver kunde.
  2. Hver rad hashes til et “leaf”: L_i = H(konto-ID || aktivum || saldo), typisk med SHA-256.
  3. Leaf-nodene parres og hashes videre oppover, nivå for nivå, til én enkelt Merkle-rot gjenstår.
  4. Børsen publiserer roten, snapshot-tidspunktet, og en individuell sibling-path til hver kunde: hashene du trenger for å bygge deg opp til roten fra ditt eget leaf.
  5. Du beregner ditt eget leaf ut fra dine egne opplysninger i rapporten.
  6. Du hasher leaf-en sammen med hver sibling-hash, i riktig venstre/høyre-rekkefølge.
  7. Stemmer resultatet med den publiserte roten, betyr det at posten din faktisk inngår i akkurat dette datasettet – verken mer eller mindre.

Det siste punktet er avgjørende: en gyldig Merkle-proof beviser inklusjon, ikke fullstendighet. Den sier ingenting om hvorvidt datasettet inneholder alle kunder, eller om børsen faktisk har nok aktiva til å dekke summen.

Steg 3: Hent din personlige Merkle-proof fra børsen

De fleste børser gir deg dette direkte i grensesnittet. Hos Binance slår du opp en Merkle-leaf eller record-ID og ser om saldoen din inngår i datasettet. Hos Bitget bruker du MerkleValidator til å laste opp eller lime inn dine egne data. Hos OKX finner du de publiserte zk-proof-filene sammen med rapporten. Last ned eller kopier følgende fire ting nøyaktig som de vises:

  • Din konto-ID eller anonymiserte kunde-ID slik børsen skriver den
  • Aktivum og eksakt saldo på snapshot-tidspunktet
  • Din sibling-path (listen med nabohash-er og venstre/høyre-retning)
  • Den publiserte Merkle-roten for hele rapporten

Ikke stol på et skjermbilde av en grønn hake i appen. Den viser bare at børsens eget skript sier “gyldig” – du har fortsatt ikke bekreftet noe selv.

Steg 4: Verifiser Merkle-roten med et Python-skript

Nå bygger vi det første verktøyet: et skript som tar dine data og sibling-path, og regner seg fram til roten selv. Lagre dette som merkle_verify.py:

import hashlib

def leaf_hash(account_id: str, asset: str, balance: str) -> bytes:
    data = f"{account_id}|{asset}|{balance}".encode("utf-8")
    return hashlib.sha256(data).digest()

def combine(a: bytes, b: bytes) -> bytes:
    # Sorter alltid parene likt som børsen din spesifiserer.
    # Mange børser sorterer hash-verdiene før sammenslåing.
    pair = sorted([a, b])
    return hashlib.sha256(pair[0] + pair[1]).digest()

def verify_proof(account_id, asset, balance, sibling_path, published_root_hex):
    node = leaf_hash(account_id, asset, balance)
    for sibling_hex, position in sibling_path:
        sibling = bytes.fromhex(sibling_hex)
        if position == "left":
            node = combine(sibling, node)
        else:
            node = combine(node, sibling)
    computed_root = node.hex()
    match = computed_root == published_root_hex.lower()
    return match, computed_root

if __name__ == "__main__":
    # Eksempel - bytt ut med dine egne verdier fra børsens PoR-side
    account_id = "acc_9f21a7"
    asset = "BTC"
    balance = "0.48213000"
    sibling_path = [
        ("3b1e0000000000000000000000000000000000000000000000000000c9a2", "right"),
        ("7f0d000000000000000000000000000000000000000000000000000044b1", "left"),
        ("a812000000000000000000000000000000000000000000000000000009ef", "right"),
    ]
    published_root = "5c2e910000000000000000000000000000000000000000000000000affa02"

    ok, computed = verify_proof(account_id, asset, balance, sibling_path, published_root)
    print(f"Beregnet rot: {computed}")
    print("RESULTAT: Gyldig proof" if ok else "RESULTAT: Stemmer IKKE med publisert rot")

Kjør skriptet med python3 merkle_verify.py. Med korrekte data fra deg selv skal utskriften se slik ut:

Beregnet rot: 5c2e91b7f3a04d9e8c1b6f2a7d0e9c4b1a8f3d6e0c9b2a5f8d1e4c7b0a3f6d9e
RESULTAT: Gyldig proof

Stemmer ikke roten, ikke anta juks automatisk. Gå videre til feilsøkingsdelen lenger ned først – den vanligste årsaken er feil venstre/høyre-rekkefølge eller feil encoding av tallene, ikke et faktisk problem hos børsen.

Steg 5: Kryssjekk on-chain-saldo med blokkjedeutforskere

En gyldig Merkle-proof bekrefter bare at din saldo er med i regnestykket. Den bekrefter ikke at børsen faktisk eier kryptoen på kjeden. Det må du sjekke separat, mot børsens offentliggjorte lommebokadresser.

KjedeAnbefalt utforskerTypisk bruk
EthereumEtherscanETH, ERC-20 som USDC/USDT
BitcoinBlockchain.com ExplorerBTC-lommebøker og UTXO-saldo
SolanaSolscanSOL og SPL-tokens
BNB ChainBscScanBNB og BEP-20-tokens
ArbitrumArbiscanL2-aktiva på Arbitrum

Bruk et enkelt skript til å hente saldo for flere adresser samtidig og summere dem. Eksempelet under bruker Etherscans offentlige API (du trenger en gratis API-nøkkel for å unngå rate-begrensning):

import requests
import time

ETHERSCAN_API_KEY = "din_api_nokkel_her"
ADDRESSES = [
    "0x28C6c06298d514Db089934071355E5743bf21d6",
    "0x21a31Ee1afC51d94C2eFcCAa2092aD10282855Aa",
]

def get_eth_balance(address: str) -> float:
    url = "https://api.etherscan.io/api"
    params = {
        "module": "account",
        "action": "balance",
        "address": address,
        "tag": "latest",
        "apikey": ETHERSCAN_API_KEY,
    }
    resp = requests.get(url, params=params, timeout=10)
    data = resp.json()
    wei = int(data["result"])
    return wei / 10**18

total = 0.0
for addr in ADDRESSES:
    bal = get_eth_balance(addr)
    print(f"{addr}: {bal:.6f} ETH")
    total += bal
    time.sleep(0.25)  # respekter rate-grensen

print(f"Sum on-chain: {total:.6f} ETH")

Forventet utskrift ligner på dette:

0x28C6c06298d514Db089934071355E5743bf21d6: 41203.887210 ETH
0x21a31Ee1afC51d94C2eFcCAa2092aD10282855Aa: 18774.502991 ETH
Sum on-chain: 59978.390201 ETH

Sammenlign summen med tallet børsen selv oppgir for samme aktivum i PoR-rapporten. Store, uforklarte avvik er et rødt flagg, men husk: en enkelt adresse kan være en multisig-, depot- eller omnibusadresse som deles med andre systemer internt, så et lite avvik trenger ikke bety noe alvorlig.

Steg 6: Bruk analyseplattformer til adressemerking

Blokkjedeutforskere viser deg saldoer, men ikke nødvendigvis hvem som eier adressen. Der kommer analyseplattformer inn: Nansen, Arkham, CryptoQuant og Chainalysis merker kjente adresser basert på flytmønstre, KYC-samarbeid og offentlig tilgjengelig informasjon. Chainalysis er et av de mest siterte selskapene i denne kategorien (Chainalysis), og brukes ofte av både børser og myndigheter til nettopp denne typen klyngeanalyse.

Bruk disse verktøyene som et støttesignal, ikke som endelig bevis. En etikett som “Bitget: Hot Wallet 3” hos Arkham er en analytisk vurdering basert på mønstergjenkjenning, ikke en juridisk bekreftet eierskapserklæring. Kombiner alltid etiketten med børsens egen offisielt publiserte adresseliste før du trekker konklusjoner.

Verktøyene brukes i praksis ikke bare av nysgjerrige kunder. Både børser selv og finansmyndigheter bruker klyngeanalyse fra selskaper som Chainalysis til å spore pengestrømmer etter hendelser, identifisere sammenhengende lommeboksklynger og bygge sannsynlige eierskapskart over tid. Som privat bruker får du ikke tilgang til de samme interne dataene, men de offentlige gratisversjonene av disse plattformene er ofte gode nok til å bekrefte om en adresse børsen oppgir faktisk har vært aktiv og konsistent over flere måneder, i stedet for å ha dukket opp rett før snapshot-tidspunktet.

Steg 7: Les revisor- eller kontrollrapporten riktig

Dette er trolig det mest oversette steget, og samtidig det viktigste. Ordet “revisjon” brukes ofte løst i markedsføring, men det finnes flere ulike nivåer av kontroll:

  • Full revisjon (audit): revisor uttaler seg om at regnskapet som helhet gir et rettvisende bilde, med full tilgang og ansvar for konklusjonen.
  • Agreed-upon procedures (AUP): revisor utfører spesifikke, avtalte kontroller (for eksempel “stemmer summen av Merkle-leaves med den publiserte roten”) uten å uttale seg om helheten.
  • Selvpublisert attestasjon: børsen publiserer tall og metode selv, uten noen ekstern part involvert.

Kraken oppgir en navngitt uavhengig kontrollør (The Network Firm LLP) for sin kvartalsvise PoR. OKX og Bybit oppgir Hacken som kontrollør for sine månedlige rapporter. Bitgets 123 prosent-tall fra juni 2026 er derimot selvpublisert, uten en navngitt ekstern part for dette konkrete reserveprogrammet. Ingen av disse er nødvendigvis “dårlige” – men de gir svært forskjellig grad av uavhengig sikkerhet, og du bør vite hvilken kategori du faktisk leser før du stoler på tallet.

Steg 8: Sammenlign reservegrad på tvers av børser og aktiva

Når du har verifisert metodikken, kan du sammenligne selve tallene. Reservegrad over 100 prosent betyr at børsen (ifølge egen rapport) har mer på kjeden enn den skylder for det aktuelle aktivumet.

BørsFrekvensMetodeKontrollørSiste kjente tall
KrakenKvartalsvisMerkle-tre + revisorgjennomgangThe Network Firm LLPDekker BTC, ETH, SOL, USDC, USDT, XRP, ADA
OKXMånedligMerkle-tre + zk-STARKHacken23,12 mrd $ i BTC/ETH/USDT/USDC (april 2026)
BybitMånedlig (siden juni 2024)Merkle-treHacken65+ mill. liability-holdere, 38 nettverk (april 2026)
BitgetMånedlig (siden des. 2022)Merkle-tre + MerkleValidatorSelvpublisert123 % samlet reservegrad (rapport 43, juni 2026)
MEXCMånedligMerkle-proof i UISelvpublisertBTC 288 %, USDT 115 %, USDC 114 % (aug. 2026)
BinancePeriodiskMerkle-tre + zk-SNARKSelvverifisering via leaf-oppslagRecord-ID/Merkle-leaf-oppslag for kunder
CoinbaseKvartalsvis (10-Q) / årlig (10-K)Tradisjonell finansiell revisjonDeloitte & ToucheIngen individuell krypto-Merkle-proof

Legg merke til at tallene i denne tabellen er hentet fra hver børs’ egne publiserte rapporter og tilgjengelige oversikter på publiseringstidspunktet. Sjekk alltid den ferskeste versjonen på børsens egen side før du legger noe til grunn, siden både frekvens og dekning kan endres. Legg også merke til at frekvens og kontrollørnavn i seg selv ikke rangerer børsene fra “trygg” til “utrygg” – en kvartalsvis, revisorbekreftet rapport gir deg sjeldnere data, men med sterkere uavhengig kontroll, mens en månedlig, selvpublisert rapport gir deg ferskere tall med mindre ekstern verifisering. Hvilken avveining som passer deg best, avhenger av hvor mye du har stående på børsen og hvor aktivt du selv følger med.

Steg 9: Bygg et komplett verifiseringsverktøy

Nå setter vi sammen alt til ett samlet, kjørbart prosjekt. Strukturen er enkel med vilje, slik at du kan tilpasse den til din egen børs og dine egne adresser.

Prosjektstruktur

por-verifier/
├── config.json          # dine kontodata og adresser
├── merkle_verify.py      # fra steg 4
├── chain_balance.py      # fra steg 5
├── por_cli.py            # samlet CLI-verktøy
└── requirements.txt

Legg kontodataene dine i en config-fil, adskilt fra selve koden, slik at du ikke ved et uhell legger sensitive tall inn i et skript du deler:

{
  "exchange": "example-exchange",
  "account_id": "acc_9f21a7",
  "asset": "BTC",
  "balance": "0.48213000",
  "sibling_path": [
    ["3b1e...c9a2", "right"],
    ["7f0d...44b1", "left"],
    ["a812...09ef", "right"]
  ],
  "published_root": "5c2e91...affa02",
  "onchain_addresses": {
    "ETH": [
      "0x28C6c06298d514Db089934071355E5743bf21d6"
    ]
  },
  "reported_onchain_total": {
    "ETH": 59978.39
  },
  "alert_threshold_percent": 2.0
}

Og selve CLI-verktøyet, som limer sammen Merkle-verifisering og on-chain-sammenligning i ett enkelt kommandolinjekall:

import json
import sys
from merkle_verify import verify_proof

def load_config(path="config.json"):
    with open(path, "r", encoding="utf-8") as f:
        return json.load(f)

def run(config_path="config.json"):
    cfg = load_config(config_path)

    ok, computed = verify_proof(
        cfg["account_id"],
        cfg["asset"],
        cfg["balance"],
        cfg["sibling_path"],
        cfg["published_root"],
    )
    print(f"[Merkle] Beregnet rot: {computed}")
    print("[Merkle] Gyldig" if ok else "[Merkle] UGYLDIG - sjekk sibling-path")

    for asset, reported_total in cfg.get("reported_onchain_total", {}).items():
        print(f"[On-chain] {asset} rapportert total: {reported_total}")
        # Her kobler du inn chain_balance.py sin get_eth_balance()
        # for hvert aktivum og sammenligner med reported_total.

    if not ok:
        sys.exit(1)

if __name__ == "__main__":
    run()

Kjør det hele med python3 por_cli.py. Verktøyet er bevisst enkelt nok til at du kan lese og forstå hver linje selv, i stedet for å stole på en ferdig app du ikke kan se inn i.

Steg 10: Sett opp automatisk overvåking med cron

PoR-tall endrer seg fra rapport til rapport. Vil du følge med automatisk, kan du legge til en enkel varsling som kjører på et fast intervall og gir beskjed hvis on-chain-saldoen avviker mer enn terskelen du satte i config.json:

# Åpne crontab-editoren
crontab -e

# Kjør sjekken hver dag klokken 08:00
0 8 * * * cd /home/din-bruker/por-verifier && /usr/bin/python3 por_cli.py >> por_log.txt 2>&1

Vil du ha varsling utover loggfilen, kan du legge til et enkelt webhook-kall i por_cli.py når avviket overstiger terskelen, for eksempel til Slack eller Discord via en innkommende webhook-URL. Har du allerede satt opp varsling for uvanlig kontoaktivitet via API-nøkler, se gjerne vår egen gjennomgang av API-sikkerhet og varsling hos kryptobørser – de to systemene utfyller hverandre godt, siden det ene fanger opp kontoinnbrudd og det andre fanger opp reserveavvik. Poenget er ikke å automatisere bort behovet for å forstå tallene, men å slippe å sjekke manuelt hver eneste gang en ny rapport publiseres.

Steg 11: Tolk advarselstegn og røde flagg

Noen mønstre bør få deg til å stoppe opp og undersøke videre, ikke bare notere avviket og gå videre:

  • Rapporteringsfrekvensen faller plutselig, eller en rapport publiseres flere uker forsinket uten forklaring
  • Reservegraden for et spesifikt aktivum synker brått mellom to påfølgende rapporter uten at børsen kommenterer det
  • Uttak stanses samtidig som en ny PoR-rapport skulle publiseres (som i Bitget-hendelsen i september 2026, der uttak ble stanset etter et tyveri på 351,6 millioner dollar)
  • Børsen bytter fra revisorkontrollert til selvpublisert metodikk uten å forklare hvorfor
  • Adresser som tidligere var merket til børsen hos Arkham eller Nansen, tømmes uten at PoR-rapporten oppdateres tilsvarende

Ingen av disse beviser i seg selv at noe er galt, men flere samtidige signaler er verdt å ta på alvor. Historikken viser at PoR sjelden er det som varsler et hack på forhånd. Bybit-angrepet i februar 2025 skjedde selv om børsen hadde løpende PoR-rapportering, fordi angrepet rammet en signeringsprosess, ikke selve reservenivået.

Steg 12: Dokumenter og arkiver bevisene dine

Til slutt: lagre alt. Ta vare på PDF-er eller skjermbilder av rapportene, de rå JSON-dataene du lastet ned, og loggfilen fra por_cli.py. Blir en børs senere involvert i en tvist eller et hack, er det disse arkivene som lar deg bevise hva som faktisk var publisert på et gitt tidspunkt – nettsider oppdateres og fjernes. Et enkelt triks er å lagre en kopi via Wayback Machine samtidig som du laster ned dine egne data, slik at du har en uavhengig tidsstemplet kopi av børsens side.

Sett dette opp som en fast rutine, ikke en engangsjobb. En enkel mappestruktur sortert på år og måned, med undermapper per børs, er nok til at du raskt kan slå opp “hva sa Kraken i sin rapport fra mars 2026” hvis det skulle bli aktuelt. Kombinert med cron-jobben fra forrige steg får du både automatisk varsling og et fullstendig historisk arkiv, uten at du selv må huske på å laste ned noe manuelt hver måned.

Hva gjør du hvis du oppdager et avvik?

Får du et negativt resultat fra por_cli.py, eller ser du et stort, uforklart gap mellom on-chain-saldo og det børsen rapporterer, ikke send panikkmeldinger på sosiale medier med en gang. Følg i stedet en fast rekkefølge, akkurat som du ville gjort ved enhver annen sikkerhetshendelse.

  1. Kjør verifiseringen på nytt fra bunnen av, med data hentet direkte fra børsens side på nytt – kopierings- og encoding-feil er den vanligste årsaken til falske avvik, som du ser i feilsøkingstabellen lenger ned.
  2. Sjekk om børsen selv har publisert en feilretting eller kommentar til rapporten; noen ganger korrigeres data timer etter første publisering.
  3. Se etter uavhengig omtale i etablerte kryptomedier som CoinDesk, som ofte er først ute med å bekrefte eller avkrefte rykter om reserveproblemer (CoinDesk).
  4. Vurder å redusere eksponeringen din midlertidig – flytt aktiva du ikke trenger aktivt på børsen over til egen kontrollert lommebok, i påvente av avklaring.
  5. Dokumenter alt du har funnet, inkludert tidsstempler, skjermbilder og rå data, i tilfelle du senere trenger det som bevis overfor børsen, en klageinstans eller Finanstilsynet.
  6. Følg den generelle responsprosessen i vår guide om hva du gjør når en kryptobørs blir hacket dersom avviket eskalerer til en bekreftet hendelse.

Husk at de aller fleste avvik du selv finner i praksis skyldes egne feil i skriptet eller feil snapshot-tidspunkt, ikke faktisk underskudd hos børsen. Det er nettopp derfor stegvis, metodisk feilsøking er viktigere enn å konkludere raskt.

PoR sammenlignet med tradisjonell bankrevisjon

Mange nordiske brukere er vant til at banker er dekket av innskuddsgarantiordninger og underlagt løpende tilsyn fra finansmyndigheter, noe som gir en helt annen type trygghet enn det en kryptobørs kan tilby i dag. En norsk bankkonto er dekket av innskuddsgarantien opp til et fastsatt beløp per kunde, uavhengig av bankens daglige balanse, og tilsynet skjer kontinuerlig gjennom året, ikke som et enkeltstående øyeblikksbilde.

Proof-of-Reserves er strukturelt noe helt annet. Det er ingen garantifond bak en kryptobørs slik det er bak et norsk bankinnskudd, og en PoR-rapport er per definisjon et øyeblikksbilde fra én bestemt snapshot-dato, ikke en løpende, forsikret garanti. Det gjør at ansvaret for kontroll i stor grad flyttes fra myndighet og garantiordning til deg som bruker – nettopp derfor er de tolv stegene i denne guiden noe du bør gjøre selv, fremfor å anta at PoR fungerer som en kryptoversjon av bankenes innskuddsgaranti. Vurderer du å oppbevare større beløp over lengre tid, er det verdt å lese om hvordan du flytter aktiva helt ut av børsen og over i egen kontrollert lagring, der du ikke er avhengig av noen tredjeparts reserverapport i det hele tatt.

Vanlige fallgruver ved PoR-verifisering

  1. Å tro at høy reservegrad betyr full sikkerhet. En reservegrad på 288 prosent for BTC sier ingenting om hvorvidt børsen har uoppgitt gjeld, lån eller rehypotekerte aktiva et annet sted i systemet.
  2. Å stole på et skjermbilde i stedet for å kjøre verifiseringen selv. Et skjermbilde av en grønn hake beviser bare at appen sa “OK”, ikke at du har bekreftet noe uavhengig.
  3. Å sjekke feil blokkhøyde eller feil tidspunkt. On-chain-saldo endrer seg kontinuerlig; du må sammenligne mot samme snapshot-tidspunkt som rapporten, ikke saldoen akkurat nå.
  4. Å anta at en adresse merket av Nansen eller Arkham 100 prosent tilhører børsen. Omnibus- og delte depotadresser kan feilmerkes eller endre eier over tid.
  5. Å blande sammen selvpublisert attestasjon med uavhengig revisjon. Bitgets selvpubliserte 123 prosent og Krakens revisorbekreftede kvartalsrapport er ikke samme grad av sikkerhet, selv om begge kalles “Proof of Reserves”.
  6. Å ikke arkivere data over tid. Uten historikk kan du ikke oppdage gradvise, mistenkelige endringer mellom rapporter.
  7. Å ignorere proof-of-liabilities-problemet helt. Klassisk PoR viser aktiva, ikke fullstendige forpliktelser – det er fortsatt et strukturelt hull i de fleste ordninger per 2026.

Feilsøking: 9 vanlige problemer og løsninger

ProblemSannsynlig årsakLøsning
Merkle-roten stemmer ikkeFeil venstre/høyre-rekkefølge ved sammenslåingSjekk børsens dokumentasjon for eksakt sorteringsregel, juster combine()
Finner ikke egen konto-ID i datasettetKontoen falt utenfor snapshot-vinduetKontakt børsens support og be om bekreftelse på inkludering
Blokkjedeutforsker viser annen saldo enn forventetFeil blokkhøyde eller ferskere data enn snapshotBruk utforskerens “block height”-parameter til å slå opp historisk saldo
API-kall feiler med rate limitFor mange forespørsler uten API-nøkkelRegistrer gratis API-nøkkel og legg til pauser mellom kall
“Hash mismatch” selv med riktige dataFeil encoding (UTF-8 vs. hex) av inputSjekk om børsen forventer hex-strenger eller rå tekst før hashing
Adresse merket “unknown” hos Arkham/NansenAdressen er ny eller ikke klassifisert ennåKryssjekk mot børsens offisielt publiserte adresseliste i stedet
PoR-siden er nede eller virker utdatertDriftsproblem eller forsinket publiseringSjekk børsens statusside, se etter arkivert versjon via Wayback Machine
zk-proof-verifisering feiler lokaltFeil versjon av verifiseringsnøkkelLast ned nyeste verifiseringsnøkkel/verktøy direkte fra børsens side
Cronjobben kjører ikkeFeil sti eller manglende rettigheterTest kommandoen manuelt først, sjekk full sti til python3 med which python3

Avanserte tips for erfarne brukere

Vil du gå lenger enn de grunnleggende stegene, er dette de forbedringene som gir mest nytte i praksis. Automatiser sammenligning over tid i stedet for å bare sjekke én rapport av gangen; lagre hver reservegrad i en enkel database eller CSV-fil, og se etter gradvise, mistenkelige trender som ikke er synlige i en enkeltstående rapport. Bruk flere uavhengige blokkjedeutforskere for samme adresse, slik at en feil eller nedetid hos én tjeneste ikke gir deg et falskt negativt resultat.

Har du aktiva spredt på flere børser og flere kjeder, lønner det seg å koble PoR-verifiseringen sammen med generell porteføljeovervåking. Vår guide om porteføljevarsling på tvers av flere kjeder viser hvordan du setter opp løpende overvåking av egne on-chain-beholdninger, som er et naturlig supplement til å sjekke børsens rapporterte tall periodisk. Følg også med på om noen børser begynner å tilby ekte proof-of-liabilities i tillegg til proof-of-reserves, siden dette er den mest etterspurte forbedringen etter FTX-kollapsen og senere hendelser som Bybit-angrepet. Og sist: sjekk alltid hvilken type kontroll som faktisk ligger bak et tall – en fullstendig revisjon, en avgrenset agreed-upon-procedures-rapport, eller ren selvpublisering – for det avgjør hvor mye vekt du bør legge på tallet.

Begrensningene ved Proof-of-Reserves

PoR har reelle, dokumenterte svakheter som du bør kjenne til, ikke bare de tekniske stegene. Den mest siterte begrensningen er fraværet av proof-of-liabilities i de fleste ordninger: rapporten viser hva børsen eier på kjeden, men ikke hva den skylder utover kundesaldoene, som interne lån, rehypotekering eller andre forpliktelser. En børs kan i teorien låne inn aktiva midlertidig rett før et snapshot og returnere dem rett etter, noe som ville gi et kunstig høyt reservetall uten at det reflekterer normal drift. Dette omtales gjerne som “snapshot-manipulasjon”, og er strukturelt vanskelig å avdekke for en enkeltkunde nettopp fordi du kun får se ett enkelt tidspunkt, ikke saldohistorikken mellom rapportene.

Kritikken økte betydelig etter FTX-kollapsen, da flere revisjons- og regnskapsmiljøer pekte på at avgrensede attestasjonsoppdrag lett kan misforstås som fullstendige revisjoner av utenforstående. OKX, som selv publiserer PoR, formulerer formålet slik: “Proof of Reserves (PoR) ensures that custodians hold sufficient funds to cover all account assets on their platform and deposit liabilities while remaining solvent” (OKX) – men også denne formuleringen forutsetter at datasettet som ligger til grunn faktisk er fullstendig, noe en ekstern bruker ikke uten videre kan bekrefte alene.

Bybit-hendelsen i februar 2025 er et godt eksempel på hvor grensen går: børsen hadde løpende PoR-rapportering, og reservene var i utgangspunktet reelle, men angrepet rammet en signeringsprosess og tømte en lommebok direkte. PoR beskytter ikke mot kompromitterte private nøkler eller manipulerte signeringsgrensesnitt – det er en helt annen trusselkategori enn det PoR er designet for å dekke.

En annen begrensning gjelder stablecoins spesifikt. Når en PoR-rapport viser at en børs har nok USDC eller USDT til å dekke kundenes stablecoin-innskudd på kjeden, sier ikke det noe om hvorvidt utstederen av selve stablecoinen har nok reserver til å dekke tokenet i utgangspunktet. Det er et eget, separat spørsmål, som du finner en egen, dedikert gjennomgang av i vår guide om å verifisere stablecoin-reserver. De to formene for verifisering utfyller hverandre: børsens PoR viser at børsen har det den sier den har, mens stablecoin-utstederens revisjon viser at selve tokenet er fullt dekket av utstederen.

Regelverk: MiCA og situasjonen i Norge

EUs Markets in Crypto-Assets-forordning (MiCA) er det sentrale rammeverket for kryptoeiendeler i EU/EØS, og regulerer blant annet autorisasjon, styring og beskyttelse av kundemidler for kryptotjenesteleverandører. Norske aktører følger utviklingen mot gjennomføring i EØS-avtalen. Det finnes derimot ikke dokumentasjon på en egen norsk regel i 2025–2026 som spesifikt pålegger alle kryptobørser å publisere en offentlig, individuell Merkle-basert PoR-rapport av den typen vi har gått gjennom i denne guiden. Skill derfor tydelig mellom MiCAs krav til autorisasjon, kundemiddelbeskyttelse og informasjonsplikt på den ene siden, og frivillig, teknisk PoR-publisering på den andre.

Det praktiske rådet for norske brukere er derfor uendret av regelverket slik det står i dag: en lisens under MiCA sier noe om at børsen driver lovlig virksomhet med visse minstekrav til styring og kundemiddelbeskyttelse, men den sier ikke automatisk noe om hvorvidt børsens faktiske on-chain-reserver dekker kundeinnskuddene på et gitt tidspunkt. De to tingene bør du vurdere hver for seg. Inntil et eventuelt fremtidig krav om standardisert proof-of-liabilities kommer på plass, er det fortsatt opp til deg som bruker å gjøre jobben denne guiden beskriver.

Ofte stilte spørsmål

Hva er Proof-of-Reserves i praksis?
Det er en metode der en børs viser, ofte via et Merkle-tre, at den på et gitt tidspunkt kontrollerer nok kryptoaktiva på kjeden til å dekke summen av kundeinnskuddene for de aktuelle aktivaene.

Er Proof-of-Reserves det samme som en revisjon?
Nei, ikke alltid. Kraken bruker en navngitt uavhengig kontrollør (The Network Firm LLP), OKX og Bybit bruker Hacken, mens andre børser som Bitget selvpubliserer tallene uten navngitt ekstern part for det konkrete reserveprogrammet. Sjekk alltid hvilken kategori du leser.

Hvilke børser publiserer PoR i 2026?
Kraken (kvartalsvis), OKX og Bybit (månedlig, Hacken-kontrollert), Bitget og MEXC (månedlig, selvpublisert), og Binance (periodisk, med Merkle-leaf-oppslag for kunder). Coinbase publiserer i stedet tradisjonelle finansielle regnskap revidert av Deloitte & Touche.

Kan jeg verifisere PoR uten tekniske ferdigheter?
Delvis. De fleste børser tilbyr et grensesnitt der du kan lime inn din konto-ID og få en automatisk gyldig/ugyldig-vurdering. For å faktisk stole på resultatet uavhengig av børsens eget verktøy, trenger du likevel skriptet fra steg 4.

Hva skjer hvis reservegraden er under 100 prosent?
Det betyr at børsen, ifølge egen rapport, hadde mindre på kjeden enn den skyldte kundene for det aktuelle aktivumet på snapshot-tidspunktet. Det er en alvorlig varsellampe som bør undersøkes videre, men kortvarige avvik kan også skyldes interne overføringer rundt snapshot-tidspunktet.

Beskytter PoR meg mot hack som Bybit- eller Bitget-angrepene?
Nei. PoR bekrefter reservenivå på et tidspunkt, ikke sikkerheten til børsens signeringsprosesser eller private nøkler. Bybit hadde løpende PoR-rapportering da børsen likevel mistet rundt 1,46 milliarder dollar i februar 2025.

Krever MiCA at børser publiserer PoR?
MiCA stiller krav til autorisasjon, styring og kundemiddelbeskyttelse for kryptotjenesteleverandører i EU/EØS, men det finnes ikke dokumentasjon på et eget, generelt krav om offentlig individuell Merkle-basert PoR i 2025–2026. Publisering av PoR er i praksis fortsatt frivillig.

Hvor ofte bør jeg sjekke PoR?
Følg børsens egen publiseringsfrekvens: kvartalsvis for Kraken, månedlig for OKX, Bybit, Bitget og MEXC. Sett opp automatisk overvåking som i steg 10, så slipper du å huske på det manuelt.