Blockchain Relays Explained: SPV Proofs and the tBTC Bridge

A blockchain relay is one of the more subtle pieces of infrastructure at work behind tokenized or wrapped bitcoin, and most people meet it with the same set of questions:

What is a blockchain relay?
Can a bridge function without one?
How does a relay work?
What happens to systems that depend on it when it fails?

That last question is usually about trust, and whether a relay should be read as centralized or decentralized.

This article works through each of these questions, using tBTC and its Bitcoin-to-Ethereum bridge as the running example. tBTC is a trust-minimized way to bring bitcoin onchain, and a relay determines the process of Bitcoin deposit verification.

What is a Blockchain Relay?

There is information on Bitcoin, and there is information on Ethereum. Neither chain knows anything about the other unless information is sent from one to the other. For two separate chains to learn about each other, they need a relay.

Relays are smart contracts that live on the Ethereum blockchain. Their job is to pass information between separate member blockchains, for example Bitcoin and Ethereum. A relay tracks part of the state (a technical term for data) of the chains it connects, which lets it help prove that a transaction on one chain really occurred when that proof is needed on another. Relays can also be granted partial control over assets that live on the connected chains.

A deeper explanation of relays depends on a few underlying ideas: The sections below start with SPV proofs and Merkle roots, then turn to the Difficulty Change, since each of these feeds into how a relay works.

SPV Proofs Explained

Suppose there is a list of eight numbers:

32962

48981

11326

17191

22129

18909

49568

3032

‍

The goal is to store information about this list so that, later on, someone can prove they held a number that was originally in it. There is a straightforward but naive way to do this, which is to store the whole list. When someone later provides a number, the verifier checks it against the entire list, so a match verifies the number and no match fails the check. The problem is cost, because this approach forces the verifier to hold the full list and repeat the comparison every time, which becomes expensive in both computation and storage at scale.

A better approach shifts the burden onto whoever is trying to prove their number belonged to the list. One way to do that is to pair the numbers and hash them. Hash functions are important tools in programming because they turn an arbitrary amount of data into a deterministic value of a fixed size.

‍

The first round of pairing looks like this:

hash("32962+48981") = "08836"

hash("11326+17191") = "12de5"

hash("22129+18909") = "3f79b"

hash("49568+3032") = "2e34c"

‍

This repeats until a single value remains. The second round produces:

hash("08836+12de5") = "799ea"

hash("3f79b+2e34c") = "8de9b"

‍

And the final round compresses everything into one value:

hash("799ea+8de9b") = "80e51"

‍

The process works like a single-elimination tournament bracket. One transaction is played against another, the pairing produces a hash, and that hash is then played against the next hash, round after round, until the bracket resolves to a single value. That final value is the root, called a Merkle root after its inventor, Ralph C. Merkle.

If the recomputed root matches the block's known root, and the bracket included the transaction the claimant said was in the block, then the transaction really was part of that block. Had it not been, the bracket would have produced a different root. This means a single compact hash is enough to prove that a block contained a given transaction, even though the root is the only thing that was ever recorded.

Putting the work on the prover rather than the verifier fits how Bitcoin already operates, since Bitcoin is recording all of these transactions anyway. When the time comes to prove to Ethereum that a Bitcoin transaction happened, it is far cheaper to ask Bitcoin for the bracket than to have Ethereum store and re-derive everything.

In short, an SPV proof shows that a transaction is included in a block while keeping storage and computation low. The cost stays down because the only thing that has to travel to the other chain is a single Merkle root. This is the same idea introduced in section 8 of the Bitcoin white paper, where Simplified Payment Verification lets a lightweight client confirm a transaction without downloading the full chain.

Publishing the Merkle Root to Ethereum

Each Bitcoin block carries a Merkle root that summarizes all of that block's transactions. The relay publishes these roots to Ethereum. Once a root is on Ethereum, applications like tBTC can use it to run an SPV proof and confirm that a specific transaction belonged to a specific block.

That raises a practical point about which block data has to be published, and how often it needs to happen. Both come back to a Bitcoin mechanism called the Difficulty Change.

The Difficulty Change

Bitcoin has a feature called the Difficulty Change, which keeps the average time between blocks close to ten minutes. When blocks are found too quickly, the algorithm raises the difficulty to slow things down, and when they take too long, it lowers the difficulty. Difficulty here is a measure of how hard it is to find a hash below a given target, so it maps directly onto the proof of work a miner has to perform.

A valid block has to show a hash below that target. If a block's difficulty does not match what the network expects, the block is not accepted. The target itself is recalculated every 2,016 blocks, which works out to roughly every two weeks.

For a relay, the Difficulty Change is what makes selective publishing possible. Rather than storing every block header from the start of the chain, a relay can anchor to difficulty retargets and still verify that a proof reflects recent, real proof of work.

Earlier Relay Designs, From BTC Relay to Polkadot

The first Bitcoin-to-Ethereum relay was BTC Relay, built by ConsenSys and launched in 2016. It stored Bitcoin block headers in an Ethereum contract and let anyone submit a Merkle proof to verify a Bitcoin transaction, with community relayers paid a fee for keeping the headers current. BTC Relay eventually fell out of use, largely because posting headers on Ethereum grew expensive and the incentives to keep relaying were thin, yet it established the pattern that later designs refined.

Cosmos and Polkadot took the relay idea in a different direction by making it the backbone of a whole network rather than a single contract. Polkadot runs a central relay chain whose validators check the validity and availability of the blocks that connected chains, called parachains, submit to it. Cosmos instead connects independent chains through the Inter-Blockchain Communication protocol, where each chain keeps its own validator set and lightweight clients verify the messages passing between them. The Polkadot model is the more complex of the two, since its validators carry direct responsibility for member-chain block validity.

The Relay Inside tBTC Today

tBTC has moved well past the launch phase it was in when this article first appeared in early 2023. It runs in production today as a Bitcoin-to-Ethereum bridge, with live figures published on the tBTC explorer, and it relies on a relay to do exactly what the sections above describe.

That relay is the Light Relay, a smart contract on Ethereum that stores Bitcoin block headers around difficulty retargets rather than the entire header history. When someone deposits BTC to mint tBTC, the deposit is proven to Ethereum with an SPV proof that the Light Relay checks against the difficulty rules it tracks. Because the relay knows the current and previous difficulty epochs, it can confirm that the headers behind a proof carry recent, genuine proof of work before any tBTC is minted. The contract is public and can be inspected on Etherscan.

This design keeps storage and cost low, which was the original point of using SPV, while avoiding the single points of failure that a custodial bridge introduces. The signing itself is handled by a distributed set of node operators through threshold cryptography.

The Trust Assumptions Behind a Relay

Every bridge carries trust assumptions, and the honest way to compare designs is to make those assumptions explicit. The core question comes down to who can submit headers, and whether the design leans on any single party. A relay that only one operator can update carries the risks of that operator, from downtime to censorship. tBTC's approach spreads that responsibility across the system. Its relay is a public contract, and the headers it accepts are backed by Bitcoin's own proof of work. The wallets that hold deposited BTC are run by a distributed group of independent node operators rather than a single custodian.

Those trust assumptions are what place tBTC toward the trust-minimized end of the spectrum. They are also what let bitcoin move onchain without asking holders to hand custody to an intermediary.

Frequently Asked Questions

What is a relay in crypto? A relay in crypto is a smart contract that lets one blockchain verify what happened on another. It stores a compact piece of a source chain's data, usually block headers, so applications on the destination chain can confirm a transaction without trusting a middleman.

What is a relay blockchain? The term usually describes a relay that operates at the level of an entire network. Polkadot is the common example, where a central relay chain has validators check the blocks that connected chains submit. A single-purpose relay like the one in tBTC is narrower, since it is a contract that tracks Bitcoin for Ethereum rather than a chain of its own.

How do I track tBTC on an explorer? The tBTC explorer shows deposits and redemptions alongside protocol statistics, and the tBTC token page on Etherscan shows contract-level transfers. Both draw on the same public onchain data, so the figures can be cross-checked against each other.

What are the trust assumptions of the tBTC relay? The relay's trust assumptions rest on Bitcoin's proof of work and on a public contract that anyone can inspect. No single operator controls header submission, and the wallets behind deposits are run by a distributed set of node operators, which is what keeps the design trust-minimized.

Sources and Further Reading

Want the fuller picture of how tBTC brings bitcoin into onchain finance? The tBTC documentation covers the bridge in depth, and institutions evaluating custody models can review Verifiable Bitcoin Accounts. The Unified Bitcoin Router shows how minting and redemption work in one place.

Discover how Threshold expands access to scalable, trust minimized onchain Bitcoin infrastructure for DeFi utility.