BTC On-Chain Verification

This document explains how xBTC verifies Bitcoin block hashes on smart contract blockchains (Ethereum, Solana, and other EVM-compatible chains) in a trustless manner, without relying on oracles or centralized validators.

1. Overview

1.1 The Problem

Cross-chain applications need to verify Bitcoin transactions on other blockchains. Traditional approaches rely on:

• Trusted Oracles - Third parties that attest to Bitcoin state
• Centralized Validators - Single points of failure
• Multi-sig Committees - Trust assumptions on committee members

All these approaches introduce trust assumptions and potential failure points.

1.2 Our Solution: Optimistic Verification with Challenge

We use an optimistic verification model that leverages Bitcoin's own Proof-of-Work security:

1.3 Why This Works

The security comes from a simple insight:

• Honest Submission: If challenged, anyone can submit real Bitcoin block headers. The real chain always has the most accumulated work.
• Fraudulent Submission: An attacker mining alone cannot outpace all Bitcoin miners combined. They will lose their deposit.

2. Implementation Details

Our implementation is based on the SelfValidator smart contract. This section focuses on how block headers form a tree structure during the challenge period.

2.1 Core Concept: Block Tree

During the challenge period, submitted block headers form a tree structure with two types of branches:

2.2 Tree Structure Visualization

2.3 State Transitions in submitBlockHeader

When a user calls submitBlockHeader(id, blockHeaderBytes), the contract determines which state transition applies based on three key conditions:

State Variables

All Possible State Combinations

Case 1: Supporting Tree Root

// hashCurrentBlock == validation.blockHash && not exists
if (hashCurrentBlock == validation.blockHash) {
    require(currentBlockInfo.firstBlockHash == bytes32(0), "dup");
    addNewBlock(id, hashCurrentBlock, bytes32(0), ...);
}

Case 2: Duplicate Validation Target

Case 3: New Opposing Tree Root

// hashCurrentBlock != validation.blockHash && prevBlock not exists && current not exists
if (prevBlockInfo.firstBlockHash == bytes32(0)) {
    require(currentBlockInfo.firstBlockHash == bytes32(0), "dup");
    addNewBlock(id, hashCurrentBlock, bytes32(0), ...);
}

Case 4: Duplicate Without Valid Path

Case 5: Normal Extension

// prevBlock exists && current not exists
addNewBlock(id, hashCurrentBlock, hashPrevBlock, ...);

Case 6: Block Overwrite

// prevBlock exists && current exists && addTime condition met
if (currentBlockInfo.addTime > firstBlockInfo.addTime) {
    player.transfer(refundValue);  // Refund original submitter
    addNewBlock(id, hashCurrentBlock, hashPrevBlock, ..., refundValue, oldFirstBlockHash);
}

Case 7: Overwrite Rejected

2.4 Chain Work and Winner Selection

After each block submission, the contract compares chain work:

// Update winner if this chain has more cumulative work
if (currentBlockInfo.chainWork > winnerBlockInfo.chainWork) {
    validation.winnerBlockHash = hashCurrentBlock;
}

The winnerBlockHash always points to the block with the highest chainWork.

Chain Work Calculation

if (prevBlockHash == bytes32(0)) {
    // First block in branch
    currentBlock.chainWork = difficulty;
    currentBlock.blockAmount = 1;
} else {
    // Extending existing branch
    currentBlock.chainWork = prevBlock.chainWork + difficulty;
    currentBlock.blockAmount = prevBlock.blockAmount + 1;
}

2.5 Stake Tracking

The contract tracks total stakes on each side:

// Step 1: Set addTime based on tree position
if (prevBlockHash == bytes32(0)) {
    currentBlock.addTime = block.timestamp;  // Tree root
} else {
    currentBlock.addTime = prevBlock.addTime;  // Inherit from tree root
}

// Step 2: Track stakes and override addTime for supporting branch
if (currentBlock.firstBlockHash == validation.blockHash) {
    validation.valueYes += value;
    currentBlock.addTime = 0;  // Supporting branch has highest priority
} else {
    validation.valueNo += value;
}

2.6 Final Resolution

After the deadline passes, setBlockHashStatus determines the outcome:

function setBlockHashStatus(uint256 id) public nonReentrant {
    require(block.timestamp > validation.deadline);

    bytes32 winnerBlockHash = validation.winnerBlockHash;
    BlockHeaderInfo storage winnerBlockInfo = blockHeaderInfo[id][winnerBlockHash];

    // Check if winner belongs to supporting branch (or no challenge occurred)
    if (winnerBlockInfo.firstBlockHash == validation.blockHash ||
        winnerBlockInfo.firstBlockHash == bytes32(0)) {
        // Supporting branch wins → blockHash is VALID
        blockMapping[validation.blockHash] = true;
        payable(validation.player).transfer(validation.value);  // Refund only
    } else {
        // Opposing branch wins → blockHash is INVALID
        blockMapping[validation.blockHash] = false;
    }
}

Outcome Summary

2.7 Deadline Extension Strategy

Each block submission resets the challenge deadline:

validation.deadline = block.timestamp + TIMEOUT;

This creates an important defense mechanism for honest participants:

How It Works

Key Points

• Valid PoW Required: The delay block only needs hash <= target. Any valid Bitcoin block header works.
• Deposit Refunded: Winners can call claimRefund(id, blockHash) to recover deposits for each block they submitted on the winning branch.
• Gas-Only Cost: The only irreversible cost is the gas fee for submitting the delay block.
• Buys Time: Each submission adds another TIMEOUT (15 minutes) to wait for real Bitcoin blocks.

2.8 Configuration Parameters