BitVM Overview

BitVM is the verification model that lets GOAT Network anchor complex offchain computation to Bitcoin without requiring Bitcoin consensus changes.

For the canonical background material, start with bitvm.org and then compare it with the GOAT Network bridge design in GOAT BitVM Bridge.

Why BitVM Exists

Bitcoin scripts can express bounded computation, but direct verification of complex programs is impractical. BitVM moves the heavy work offchain and only brings disputes onchain.

Limitation	Why it matters
Block size	Large verifier programs cannot fit into a single Bitcoin block.
Execution environment	Bitcoin Script has strict stack and resource limits.
Opcode coverage	Complex primitives such as pairing-based proof verification are not natively available.

Optimistic Verification Model

BitVM uses the same core economic idea as optimistic rollups: honest execution is cheap, disputes are expensive for dishonest actors.

Optimistic verification lifecycle

Operator claims valid execution
        |
        v
Challenge window opens
        |
        +--> No challenge ----------> Claim is accepted
        |
        +--> Challenge raised ------> Faulty step is proven on Bitcoin
                                         |
                                         v
                                  Collateral is slashed

Protocol roles

Role	Responsibility
Operator	Executes the offchain process and posts the claim that can later be challenged.
Challenger	Monitors claims and forces dispute resolution when an assertion is wrong.
Watchtower	In the GOAT Network design, watches Bitcoin and bridge state to help validate public inputs.

How BitVM Verifies Computation

BitVM does not run arbitrary applications directly on Bitcoin. Instead, it verifies a proof system that attests to the offchain computation.

Compress the program

The target computation is proven offchain with a SNARK or a similar proof system.

Split the verifier

The verifier logic is decomposed into chunks that can be challenged on Bitcoin.

Commit to the verifier path

Participants agree on the verification path during setup so disputes can later target a single faulty step.

Resolve disputes selectively

If an operator posts a false result, challengers isolate the faulty step and prove it onchain, rather than re-running the full computation.

BitVM Evolution

Version	Main improvement	Main tradeoff
BitVM	Introduced Bitcoin-native optimistic verification	Heavy two-party dispute flow and long resolution windows
BitVM2	Permissionless challenges, lower trust assumptions, fewer onchain dispute transactions	Still expensive onchain assertions
BitVM 3s	Research direction that moves more work offchain with garbled circuits and smaller assertion footprints	Large offchain storage and more complex setup

GOAT Network's current public bridge and user flows are documented against BitVM2. BitVM 3s is relevant as a published successor direction, not as the active bridge version described in the operational docs here.

Trust Model

BitVM-based systems typically rely on a 1-of-n honesty assumption.

Property	Requirement
Safety	At least one honest challenger must be able to detect and dispute fraud.
Liveness	At least one rational operator must continue serving valid requests.

This is materially stronger than a multisig bridge that requires an honest majority to preserve funds.

Why GOAT Network Uses BitVM

GOAT Network uses BitVM2 as the bridge verification layer for BTC deposits and withdrawals. The bridge combines:

Bitcoin-side transaction graphs and dispute logic
ZK-backed state transition proofs
Watchtower validation of Bitcoin public inputs
Economic slashing for dishonest operators

The result is a Bitcoin bridge that is more trust-minimized than threshold-signature custody designs while still giving users a practical deposit and withdrawal path.

Research on BitVM 3s is relevant to future optimization paths, but the currently documented GOAT Network bridge flows remain BitVM2-based.

Peg-In and Peg-Out in Context

Peg-in

BTC is locked on Bitcoin.
The deposit is proven to GOAT Network.
PegBTC is minted on GOAT Network.

Peg-out

PegBTC is burned on GOAT Network.
An operator fronts the BTC withdrawal to the user.
The operator later claims reimbursement through the BitVM flow.

The full operational flow, participant responsibilities, and GOAT Network-specific optimizations are documented in GOAT BitVM Bridge.