Skip to main content

Goldsky

Wrapped bitcoin reserve monitoring

Talk to our team

What is wrapped bitcoin reserve monitoring?

Wrapped bitcoin reserve monitoring is checking, around the clock, that the supply of a wrapped bitcoin token on EVM chains is matched by the BTC its custodian holds at published reserve addresses.

Issuers run it to show holders the backing between attestations, and lending protocols that accept wrapped bitcoin as collateral use the result to freeze the asset when the backing falls short.

Goldsky keeps the token’s supply per chain and streams Bitcoin activity into your database, and a scheduled task compares supply with the BTC you total, publishes the figure onchain and alerts on a shortfall; holding the BTC and deciding what a shortfall triggers stay with the custodian and with you.

Who uses wrapped bitcoin reserve monitoring?

Wrapped bitcoin issuers and their custodians, exchanges that issue their own wrapped bitcoin, and DeFi lending protocols that accept it as collateral.

How wrapped bitcoin reserve monitoring works

The diagram follows one check from a mint or burn and the BTC in reserve to the figure lending protocols read onchain. Your setup may differ.

Your business, step 2: CustodianHold BTC in reserveAt addresses it publishes
Blockchains, step 1: Mint or burn the tokenSupply changes on each EVM chain
Goldsky, step 3: TurboKeep supply per chainMints minus burns, in your database
Goldsky, step 4: TurboStream Bitcoin activityTransactions, into your database
Your business, step 5: Total the BTC heldPer reserve address, from its transactions
Goldsky, step 6: ComposeCompare supply with reservesOn a schedule, across every chain
Goldsky, step 7: ComposePublish the reserve figureFor lenders and apps to read
Goldsky, step 8: ComposeAlert on a shortfallWhen supply passes the BTC held
Blockchains, step 9: Lenders act on itSome freeze the asset on a shortfall
  • Goldsky
  • Your provider

How to monitor wrapped bitcoin reserves

A pipeline keeps the token’s supply on each chain from its mints and burns and streams Bitcoin transactions into your database, where you total the reserve addresses. A scheduled task compares the two, publishes the reserve figure onchain and alerts your team on a shortfall.

What you’ll need

  • Goldsky Turbo
  • Goldsky Compose
  • The token’s contract address on each chain it’s issued on
  • The custodian’s published reserve addresses
  • A Postgres database for the supply ledger
  • An endpoint that returns your BTC reserve total
  • An oracle or attestor contract to publish to
  • An alerting endpoint for your team

  1. Mint and burn against BTC deposits

    A wrapped bitcoin is minted when BTC is deposited with the custodian and burned when it’s redeemed, so supply should track the BTC held.

    Mints and burns usually show up as token transfers from and to the zero address. A token issued on several chains needs its supply counted on every one of them.

  2. Hold the BTC at published reserve addresses

    Anyone can check the backing once the custodian says where the BTC sits.

    The custodian publishes the Bitcoin addresses that hold the reserve and updates the list when it moves funds. An address missing from the list understates the reserve.

  3. Keep supply on each chain

    Handled by Goldsky Turbo

    The supply side of the check is every mint minus every burn, chain by chain.

    Track mints and burns on each chain from the token’s first block and keep the figure current as new blocks arrive. A token on several chains needs a figure for each, so a gap can be traced to the chain it came from.

    With Goldsky, Turbo Pipelines’ curated erc20_transfers datasets show mints as transfers from the zero address and burns as transfers to it, and the PostgreSQL aggregate sink keeps supply per token and chain as a running sum.

    Keep running totals in Postgres (opens in a new tab)

  4. Stream the reserve addresses’ Bitcoin activity

    Handled by Goldsky Turbo

    Reading the reserve from the Bitcoin blockchain lets you check the custodian’s figure independently.

    Every Bitcoin transaction that pays into or spends from a reserve address changes the reserve, so each one has to be captured, back to the first time the address was used. Bitcoin’s full history is large, so filter to the reserve addresses as early as you can.

    Turbo Pipelines’ bitcoin.raw.transactions dataset carries each transaction’s inputs, outputs and values. With start_at: earliest the pipeline replays history before new blocks, and a database sink writes the rows to your database.

    Stream Bitcoin transactions (opens in a new tab)

  5. Total the BTC held

    The reserve is the sum of what every reserve address holds.

    Your database parses each transaction’s inputs and outputs, which arrive as JSON, adds what paid into each reserve address and subtracts what it spent. An input points to the earlier output it spends, so where an input lacks the address and value, take them from that output.

  6. Compare supply with reserves on a schedule

    Handled by Goldsky Compose

    Backing can slip between attestations, so the comparison has to run continuously.

    A job runs on a schedule, reads the token’s supply on each chain and your BTC total, and works out the ratio of reserves to supply. Supply and reserves have to be read close together, or a mint caught on one side and not the other shows up as a false gap.

    Goldsky’s Compose runs the check as a cron task that reads supply with readContract and fetches your reserve total with fetch, retried on failure, and it traces every input and output.

    Run a task on a cron schedule (opens in a new tab)

  7. Publish the reserve figure onchain

    Handled by Goldsky Compose

    Lending protocols and apps can only act on the backing if they can read it onchain.

    Write the reserve figure, or the ratio, to an oracle or attestor contract with the time it was measured. Readers compare it with supply themselves, so a stale figure is as risky as a wrong one.

    The same Compose task can write the figure with wallet.writeContract from a gas-sponsored wallet, and the NAV oracle guide shows one figure published to several chains behind a Chainlink-compatible interface.

    Publish a figure to several chains (opens in a new tab)

  8. Alert your team on a shortfall

    Handled by Goldsky Compose

    A shortfall needs someone on your team to look into it right away, whatever caused it.

    Set the threshold at which supply exceeding reserves becomes an alert, and send it with both figures so the team can tell a timing gap from a real one.

    When the ratio falls below your threshold, the Compose task posts the supply, reserves and ratio to your alerting endpoint with fetch.

    Call your endpoint with fetch (opens in a new tab)

  9. Lending protocols act on the figure

    Lenders that accept wrapped bitcoin as collateral protect themselves when the backing falls short.

    Some lending protocols compare the published reserve figure with the token’s supply and freeze the asset or stop borrowing against it when reserves fall short. What happens is set by each protocol, so a shortfall can play out differently market by market.

What you control

Your team
  • Total the BTC held
Your providers
  • Custodian

Questions and answers

What powers WBTC proof of reserves?

An oracle network’s proof of reserve feed powers WBTC proof of reserves: it reads the BTC held at the custodian’s reserve addresses and posts the total onchain, where lending protocols compare it with WBTC’s supply. The issuer also publishes reserve data on its own dashboard, so anyone can check the BTC side on the Bitcoin blockchain. An issuer or lender can run the same comparison on its own data by totalling the reserve addresses, reading supply on each chain and comparing the two on a schedule.

Is WBTC safe?

Whether WBTC is safe depends on the custody behind it: each token is meant to be backed one to one by BTC a custodian holds, so the risks are a shortfall in that reserve and who controls the keys to it. Reserve monitoring covers the first, by checking WBTC’s supply on every chain against the BTC at the published reserve addresses. The second depends on the custody arrangement, meaning who holds the keys to the reserve wallets and how many of them must sign, which the issuer’s custody disclosures describe.

Security and deployment

  • SOC 2 Type IIIndependently audited security controls.
  • Dedicated infrastructureSingle-tenant options for production workloads.
  • Data residencyCloud, on-premises or co-located.

More use cases that tokenize securities

Use cases built the same way

Monitor wrapped bitcoin reserves with Goldsky

We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.

Talk to our team

© Endless Sky Inc. All rights reserved.

PrivacyTermsSecurity

System status