Engineering The Unhappy Path: Understanding BitVM2 Architecture Part One: Security Lives in the Dispute Path A Bitcoin L2 lives or dies on its unhappy path. On Bitcoin, you don’t get “run the verifier on-chain and move on”. You get a constrained execution environment, pre-signed transaction graphs, and timelocks that define exactly when each party can act. BitVM2 is an optimistic enforcement pattern for Bitcoin: execute off-chain, then make correctness enforceable via an on-chain dispute protocol built from pre-signed transactions. That leads to a simple engineering rule: If disputes are expensive or can be fee-stalled, the security model simply doesn’t work. BitVM-based systems work by letting operators execute off-chain, then giving anyone the ability to challenge on-chain and force the protocol onto a dispute path under a 1-of-n honesty assumption (at least one honest challenger for validity; at least one honest operator for liveness). This dispute path is the mechanism. Pre-signed transactions and one-time signatures (challenge windows, response deadlines, finalization) are the “runtime” of the bridge and its exits. So when we talk about building on BitVM2, the north star is not marketing terms like “trustless”. The north star is: • disputes that are cheap enough to execute, • chain context that’s objective enough to prevent “prove the wrong state” exits • transaction flows that keep progressing under real fee conditions. This series breaks down how we approached those constraints in the GOAT BitVM2 design, one piece at a time. Coming up in Part Two: the practical blockers to deploying a production-ready zkRollup on Bitcoin.