BOB (Build on Bitcoin) (BOB)

BOB: A Bitcoin- and Ethereum-Linked Network for Bitcoin DeFi

BOB is an EVM-compatible network designed to bring Bitcoin liquidity into smart-contract applications while retaining Ethereum tooling. Its architecture combines an OP Stack-based execution layer with planned Bitcoin settlement, BitVM-based verification, cross-chain gateways, and token-holder governance.

What BOB is trying to provide

BOB, short for Build on Bitcoin, is a hybrid Layer 2 designed to connect Bitcoin assets and security concepts with Ethereum’s smart-contract environment. The project describes the network as a home for Bitcoin decentralized finance: users and developers can interact with EVM applications while using Bitcoin as a settlement or security anchor in the project’s longer-term design. This positioning makes BOB less like a standalone Bitcoin sidechain and more like an interoperability and execution layer built around Bitcoin liquidity, Ethereum-compatible applications, and cross-chain movement.

The intended users are broader than traders. Developers can deploy Solidity-based applications using familiar EVM tools, while Bitcoin holders are the target users for swaps, lending, yield products, and other financial applications. BOB’s Gateway documentation describes an intents- and request-for-quote-based service in which solvers provide destination-chain liquidity and a Bitcoin light client verifies the Bitcoin-side transaction before settlement. That design is intended to reduce the need for users to interact with separate custodians or manually manage several bridging steps, although the actual safety of each route depends on its contracts, verification system, liquidity providers, and supported assets.

How the hybrid architecture is meant to work

BOB’s published architecture uses three main ideas: light clients, bridges, and optimistic verification through BitVM. A Bitcoin light client allows another chain or contract to verify relevant Bitcoin block information without processing the entire Bitcoin blockchain. BitVM is used in the project’s design as a dispute mechanism: computation occurs off-chain, while an incorrect result can be challenged by submitting a fault proof to Bitcoin. The project’s vision paper describes this as an optimistic model in which a state transition is treated as final after a challenge period if no valid dispute is raised.

The architecture is staged rather than fully complete. The token white paper describes a current phase in which a single sequencer collects transactions, produces BOB blocks, and submits state commitments to Ethereum. It also describes an OP Kailua-based proving process, with challenges and validity proofs used to address incorrect state commitments. Later phases are intended to add Bitcoin-staker participation and eventually Bitcoin-enforced rollup settlement through BitVM. The same document states that the Bitcoin-staking and Bitcoin-rollup phases remain under development, so descriptions of inherited Bitcoin security should be read as design goals for those phases rather than as a blanket description of every current transaction.

Bridges, Gateway, and practical dependencies

BOB’s Gateway is a separate practical access layer around Bitcoin swaps and cross-chain settlement. Its documented flow is: an application requests a quote, a solver locks the destination asset, the user signs a Bitcoin or EVM transaction, and BOB’s verification system triggers settlement. The documentation says the system supports routes involving native BTC, stablecoins, ETH, wrapped Bitcoin, and tokenized gold, but route availability and execution conditions can change by asset, chain, liquidity source, and integration. The Gateway therefore depends not only on BOB’s chain but also on solver liquidity, destination-chain contracts, wallet support, APIs, and the security of the relevant Bitcoin and EVM verification components.

The project repository identifies BOB as an open-source system containing Solidity contracts, Rust components for Bitcoin relay functionality, and a TypeScript software development kit. It also lists BOB token deployments on BOB Mainnet, Ethereum, and BNB Smart Chain. The repository states that the token uses Chainlink CCIP for bridging, with lock-and-unlock behavior on BOB and burn-and-mint behavior on other listed networks. Users and integrators must therefore verify the network and contract address before interacting, because the same ticker can appear on multiple chains and bridge mechanics differ by deployment.

What the BOB token does

BOB is an ERC-20 token with a stated total supply of 10 billion. The project’s token white paper describes its core role as network governance and ecosystem participation rather than a claim on protocol revenue or a guaranteed utility benefit. Proposed governance functions include voting on protocol parameters, treasury allocations, network fee assets, ecosystem incentives, and future features such as staking. The white paper also describes planned staking functionality, but that should not be treated as proof that every staking mechanism is live or available in the same form across all networks.

Governance is described as token-weighted: voting power is proportional to token holdings, and the token white paper says holders can create and vote on proposals through a governance website. It also states that initial governance decisions are made by the BOB Foundation, with a transition to DAO governance planned. This distinction matters because token voting rights do not by themselves establish complete operational decentralization. The foundation, development contributors, sequencer arrangements, privileged contracts, and implementation committees may continue to influence how approved changes are executed.

Limits and unresolved questions

BOB’s principal technical risk is execution and delivery risk. The Bitcoin-security design depends on complex light-client, data-availability, challenge, and fault-proof machinery, while the project’s own documents acknowledge trade-offs between security, cost, efficiency, and permissionless challenging. The vision paper also says that posting sufficient data to Bitcoin can be expensive and that alternative data-availability systems would introduce additional trust assumptions. These constraints could affect fees, finality times, bridge usability, and the point at which the system becomes economically practical at scale.

Users also face ordinary smart-contract and infrastructure risks: bugs in BOB contracts or connected applications, sequencer failure, incorrect or delayed bridge settlement, compromised privileged keys, liquidity shortages, and outages affecting RPCs, wallets, or solver services. The token white paper explicitly identifies BTC-bridging risk, governance concentration, consensus failures, private-key loss, scaling limits, and dependence on underlying infrastructure. The project lists audits and a bug-bounty program, but those measures reduce rather than eliminate risk, and an audit is not a guarantee that deployed contracts or future upgrades are safe.

Key takeaways

• BOB is an EVM-compatible Bitcoin-focused network aimed at bringing BTC liquidity into decentralized applications.
• Its architecture combines Ethereum-based execution and proving with a planned progression toward Bitcoin-staker and BitVM-enforced settlement.
• The Gateway uses solver liquidity, cross-chain routing, and Bitcoin transaction verification for BTC-related swaps and DeFi entry points.
• BOB is primarily documented as a governance and ecosystem-participation token with a fixed stated supply of 10 billion.
• The project’s Bitcoin-security and staking phases remain partly developmental, so architecture claims must be separated from currently deployed functionality.

Risks and open questions

• The security model differs by development phase; Bitcoin-enforced settlement and Bitcoin-staker participation are described as under development.
• Bridge and Gateway safety depends on contracts, light-client verification, solver liquidity, supported routes, privileged roles, and external chain infrastructure.
• Token-weighted governance can concentrate influence among large holders, while foundation-led implementation may limit practical decentralization.
• Data availability and Bitcoin posting costs could affect fees, throughput, and the economic viability of the planned rollup model.
• The token white paper identifies technical bugs, key-management failures, consensus faults, scaling limitations, regulatory uncertainty, and market-liquidity risks.