# BOB Developer Docs - The Bank of Bitcoin
> BOB is the Bank of Bitcoin. Get started building in the BTCFi ecosystem where you can swap, save, earn and borrow - all on Bitcoin rails.
This file contains all documentation content in a single document following the llmstxt.org standard.
## Bitcoin Vaults and Liquidation Engine
## Overview
Bitcoin vaults enable native BTC as collateral for lending and stablecoins on DeFi chains like Ethereum, Base, BOB, and Solana. Using BitVM technology, these vaults provide trust-minimized access to DeFi while maintaining Bitcoin's security guarantees.
## How Bitcoin Vaults Work
Bitcoin vaults leverage BitVM to create trust-minimized bridges that allow users to:
1. **Lock native BTC** in a BitVM-style vault on Bitcoin
2. **Mint an NFT** on the DeFi chain representing the locked BTC value
3. **Use NFT as collateral** to borrow stablecoins (USDT/USDC) or mint CDP-style stablecoins
4. **Withdraw BTC** at any time by generating a ZK proof that the loan was repaid
### Key Advantages over Traditional Wrappers
Unlike fungible BTC wrappers (wBTC, cbBTC), Bitcoin vaults ensure:
- **Enforced withdrawals**: Depositors can withdraw via cryptographic proof without requiring bridge operator cooperation
- **No UTXO mixing**: Users receive precisely the BTC they deposited from their original UTXO
- **Trust minimization**: No third-party trust assumptions under normal operations
## BOB Bitcoin Vault Liquidation Engine
The BOB Liquidation Engine addresses critical limitations in basic Bitcoin vault implementations:
### Traditional Vault Limitations
1. **Delayed liquidations**: Cannot trigger until loan repayment deadline expires
2. **All-or-nothing liquidation**: Entire BTC amount must be liquidated
3. **Static liquidator set**: Predefined liquidators limit available capital during market stress
4. **Non-atomic process**: Creates inefficiencies and risks for lenders and borrowers
### Liquidation Engine Solutions
#### Base Engine Features
**Open Liquidator Set**
- Removes predefined liquidator restrictions
- Anyone can participate in liquidations
- Eliminates trust assumptions about liquidator availability and liquidity
**Multi-party Liquidations**
- Multiple liquidators can collaborate on single liquidations
- Reduces individual capital requirements
- Improves market resilience during high-volume liquidation events
**Bridge Integration**
- Routes liquidations through Bitcoin bridge deposit addresses
- Compatible with existing bridges (wBTC, LBTC, BitVM bridges)
- No modifications required to bridge infrastructure
#### Optional Extensions
**Partial Liquidations**
- Liquidate only to safe LTV ratio, not entire position
- Depositor opt-in with bridge trust for non-liquidated portion
- Significantly reduces collateral loss for borrowers
**Fast Liquidations**
- Reduces settlement from days to 1-6 Bitcoin blocks (10-60 minutes)
- Trust model options:
- n-of-n consensus: All operators must agree (strongest security)
- m-of-n consensus: Majority/supermajority agreement
- Emulated covenants: Spending restrictions prevent operator theft
- Automatic BitVM fallback if consensus fails
**Atomic Liquidations**
- Single-transaction liquidation when bridges support pre-deposits
- Eliminates settlement risk for liquidators
- Enables flash loan liquidations
- Requires deep bridge integration
## Architecture
### Components
1. **Bitcoin Vault**
- BitVM implementation with BTC deposit input
- Multiple outputs: depositor and bridge addresses
- Fraud-proof challenge mechanism
2. **Liquidation Engine Smart Contract**
- Tracks liquidator contributions and owed collateral
- Manages bridged BTC distribution
- Deployed on DeFi chain (can serve multiple chains)
3. **Operators**
- Facilitate BTC withdrawals to bridges during liquidations
- Receive fees from liquidation profits
- Can reuse existing BitVM bridge operator sets
4. **Bridge Integration**
- Accepts vault deposits at predefined addresses
- Mints wrapped BTC to liquidation engine
- Handles BTC return for partial liquidations
### Liquidation Flow
1. **Vault Setup**: Depositor and operators create vault with outputs to depositor and bridge
2. **Loan Liquidation**: Liquidators repay loan via smart contract using own capital
3. **Bitcoin Withdrawal**: Operators assert liquidation and submit to Bitcoin vault
4. **Bridge Minting**: BTC deposited to bridge, wrapped tokens minted to engine
5. **Distribution**: Liquidators claim bridged BTC proportional to contributions
6. **Operator Fees**: Operators receive percentage of liquidated BTC
## Trust Models
| Component | Basic Vault | Base Engine | With Extensions |
|-----------|-------------|-------------|-----------------|
| **Depositor Withdrawal** | Trust minimized | Trust minimized | Trust minimized (+ optional bridge trust) |
| **Liquidator Access** | Static set only | Anyone | Anyone |
| **Liquidation Speed** | Multiple days | Multiple days | Minutes to instant |
| **Partial Liquidation** | Not possible | Not possible | Available (opt-in) |
| **Capital Requirements** | Single liquidator | Distributed | Distributed |
## Use Cases
### Lending Protocols
- Native BTC collateral without wrapping
- Efficient liquidations during market volatility
- Reduced bad debt through fast liquidations
### CDP Stablecoins
- BTC-backed stablecoin minting
- Partial liquidations preserve user capital
- Open liquidator participation ensures stability
### Cross-chain DeFi
- Use BTC collateral on Ethereum, Base, BOB, Solana
- Maintain Bitcoin security while accessing DeFi yields
- Bridge-agnostic design enables wide compatibility
## Implementation Status
:::info Development Phase
The Bitcoin Vault Liquidation Engine is currently in research and development, with mainnet deployment planned as part of BOB's Phase 2 BitVM integration.
:::
### Current Progress
- Liquidation engine design finalized
- Basic Bitcoin vault tested on mainnet (Babylon experiment)
- Integration with lending protocols in development
### Upcoming Milestones
- BitVM3 optimizations for improved capital efficiency
- Bridge partner integrations for atomic liquidations
- Mainnet deployment with select lending protocols
## Technical Resources
- [Liquidation Engine Whitepaper](/liquidation-engine.pdf)
- [BitVM Documentation](./index.mdx)
- [Hybrid Nodes Overview](../bob-chain/hybrid-nodes.md)
## Security Considerations
### Depositor Safety
- Maintain self-custody throughout lending process
- Cryptographic proof ensures withdrawal rights
- Original UTXO return prevents tainted coin concerns
### Protocol Security
- 1-of-n BitVM security model
- Fraud proofs protect against malicious operators
- Economic incentives align all participants
### Market Stability
- Open liquidations prevent liquidity crises
- Partial liquidations reduce cascade effects
- Fast settlement minimizes price impact risks
---
## BitVM: A New Paradigm for Bitcoin
import BitvmDiagram from "./bitvm-diagram.svg";
# BitVM: A New Paradigm for Bitcoin
## Introduction
BitVM plays a crucial role in BOB's [Hybrid Chain Roadmap](/docs/bob-chain/hybrid-chain) by [enabling superior Bitcoin bridging](https://blog.gobob.xyz/posts/bob-announces-trust-minimized-bitcoin-bridge-prototype-powered-by-bitvm) for our rollup. BOB will integrate a native Bitcoin bridge via BitVM that will serve as a backbone for Bitcoin DeFi in synergy with the [Babylon LSTs and LRTs](https://blog.gobob.xyz/posts/bob-integrates-with-babylon-to-become-a-bitcoin-secured-network-bringing-bitcoin-finality-to-the-hybrid-l2). From the network infrastructure to the tokens in your wallet, BitVM unlocks huge security advancements for Bitcoin DeFi.
Read on to learn how BitVM enables Bitcoin rollups and a new type of BTC bridge with a "1-of-n" trust assumption - all without a soft fork to Bitcoin.
## Why BitVM Matters
tl;dr:
- BitVM2 is a major improvement over previous BitVM versions.
- [BitVM Bridge](https://blog.gobob.xyz/posts/bob-announces-trust-minimized-bitcoin-bridge-prototype-powered-by-bitvm) is now the most secure BTC bridge design.
- BOB co-authored [the most comprehensive write-up of the BitVM2 design so far](/docs/reference/research#bitvm2-bridging-bitcoin-to-second-layers).
BitVM2 is:
- Secure: optimistic computation secured by Bitcoin.
- Practical: only three transactions to complete a challenge.
- Permissionless: anyone can challenge.
[BitVM Bridge](https://blog.gobob.xyz/posts/bob-announces-trust-minimized-bitcoin-bridge-prototype-powered-by-bitvm) is the most secure BTC bridge to date.
- BTC Bridges so far: t-of-n multisigs, honest majority assumption.
- BitVM Bridge: 1-of-n security model, where anyone can challenge and prevent theft.
## BitVM Summary
_BitVM_ is a way to expand the range of what is possible to do on Bitcoin. It does this by performing computation off-chain that is held accountable by an on-chain fraud proving mechanism. Since Bitcoin Script is very limited in what it can do, running more advanced programs on Bitcoin requires a way to verify that the results of off-chain calculations are correct.
Existing bridges typically rely on centralized entities—such as Wrapped Bitcoin (WBTC) and Coinbase Wrapped Bitcoin (cbBTC)—or semi-trusted networks like tBTC, where security depends on the honesty of the majority of participants. In contrast, BitVM bridges introduce a superior security model: BTC deposits cannot be stolen as long as there is a single honest and online node in the network, and this node can be the depositor themself.
BitVM verifies off-chain computation similarly to optimistic rollups:
1. An _operator_ performs a computation off-chain,
1. then makes an on-chain claim about the results of that computation.
1. If the claim is incorrect, a _verifier_ will invalidate it directly on the Bitcoin blockchain.
In practice, this would look like a collection of operators depositing their collateral and committing to manage a pool of BTC according to the rules of a specific, pre-defined computer program (a bridge, for example).
**If an operator attempts to withdraw BTC in a way that violates those rules, any verifier can prevent the withdrawal and slash the dishonest operator's collateral for the malicious attempt.** The verifier does this by submitting a specific kind of transaction on Bitcoin that will be explained in a moment.
This reveals two important aspects of the setup:
1. An operator only needs to provide enough collateral to cover the cost of disproving plus some extra amount to deter them from cheating and being slashed. This capital efficiency is exactly why BitVM is much better than other bridges, including collateralized bridges.
2. The verifier can challenge a dishonest transaction directly to Bitcoin, slashing the operator and preventing the malicious withdrawal from happening. In other words, one honest verifier can prevent an infinite number of operators from cheating.
This setup is called _optimistic_ because normal operation is assumed to be correct, allowing compute to happen at web2 prices while also maintaining a strong mechanism of on-chain accountability to prevent a dishonest claim from any operators.
## Technical Details
1. Compress a program into a SNARK verifier implemented in Bitcoin Script. With Groth16, this will be about 1GB in size.
1. Split the verifier into discrete sub-program chunks that are optimized for Bitcoin transaction size limits. These chunks are under 400kb each, eliminating the need for special miner cooperation at any step.
1. During the setup step, each operator commits to the program by depositing collateral.
1. Each operator continually runs the original program (e.g. a bridge) off-chain to determine the correct outputs of each input (e.g. how much BTC to withdraw and who to send it to during a bridge peg-out).
1. The operator uses their own funds to cover the program's output (e.g. sends their own BTC to a withdrawing user), then requests a reimbursement by withdrawing funds from BitVM (i.e. the set of funds being managed by the operators).
1. If challenged, the operator must reveal all of the intermediary program results (i.e. each of the inputs and outputs of the sub-program chunks). If the operator is cheating, at least one of the sub-program results will be fake.
1. **Anyone can disprove the operator by executing that specific sub-program in a Bitcoin transaction, showing that the operator's attempted withdrawal was invalid.**
1. The bad operator is kicked out and cannot access the BitVM funds.
:::tip Practical and Permissionless
Anyone can challenge a dishonest operator with only three Bitcoin transactions.
:::
## BitVM Bridge Summary
One of the most exciting applications of BitVM is a BTC light-client bridge on Bitcoin. Specifically, BitVM reduces the trust assumptions needed for a safe _peg-out_ when users want to withdraw or unwrap their BTC back to Bitcoin.
1. Operators pay BTC to the withdrawing user from their own funds and then reclaim the BTC from BitVM.
1. A smart contract on BOB uses the [BTC relay](/docs/bob-chain/relay) to verify that there is a correct peg-out on Bitcoin corresponding to the withdrawal request by a user on BOB. If this check passes, a burn event on BOB is emitted.
1. BitVM checks that there is a correct peg-out on Bitcoin matching the burn event on BOB.
1. The operator uses the BitVM light client to create a SNARK, proving that:
- there is a burn event on BOB that burns bobBTC,
- the BOB block that includes the burn event was correctly created,
- the BOB block is signed by Babylon Finality Providers (FPs) staked on Bitcoin,
- the BOB block hash that includes the burn event is stored on the Babylon chain, and
- the BOB block hash is part of a Babylon checkpoint on Bitcoin with at least 100 Bitcoin confirmations.
1. If all is correct, the operator gets the BTC refunded.
1. If the operator has committed fraud (e.g. by sending BTC to their wallet instead of the user's), the refund transaction is prevented and the operator is slashed and kicked out.
Under correct operation, the bridging process completes in less than one hour in each direction for users bridging in and out. This is much faster than existing Ethereum L1 or L2 bridges to Bitcoin.
### Recent Technical Improvements
- **Optimized Transaction Size**: All transactions are under 400kb, eliminating the need for special miner cooperation. This was achieved through Fiamma's optimization of the disprove script chunk size and splitting the Assert transaction into multiple linked transactions.
- **Enhanced Security Model**: Correct behavior is enforced through bit commits, following the BitVM2 standard, reducing trust assumptions compared to previous implementations.
- **Streamlined Verification**: Our implementation uses hardcoded public inputs rather than checking them in complex scripts, allowing us to run unmodified RISC0 circuits.
- **Smart Contract Integration**: Instead of [superblock](https://www.fairgate.io/post/3-a-review-of-the-the-bitvm2-based-linus24-bridge) logic, additional verification is performed by BOB smart contracts using an [on-chain relay](/docs/bob-chain/relay), with double-checking of payments and block correctness in the prover.
- **User-Friendly Offramp**: We're making it easy to convert wrapped tokens back to native bitcoin by integrating the BitVM bridge with [BOB Gateway](https://docs.gobob.xyz/gateway).
## Common Misconceptions
- "BitVM" is not a virtual machine (VM) like the Ethereum Virtual Machine (EVM) or the Java Virtual Machine (JVM); it is not an execution environment for arbitrary programs. Rather, each instance of BitVM is a way to use existing tools in Bitcoin to create on-chain fraud proofs for off-chain execution of a specific, pre-determined program (e.g. a bridge or rollup).
- In its current design, a specific BitVM instance only supports deposits and withdrawals of a fixed amount defined at setup, such as exactly 0.1 BTC. A user can only `PegOut` (i.e. withdraw) an amount that exactly matches a previous `PegIn`. A potential workaround is to create several instances of BitVM for the same purpose (e.g. bridge), each corresponding to a different `PegIn` size (e.g. 0.1 BTC, 1 BTC, 10 BTC).
- The 1GB program is never put on-chain. That would require 1,000 separate transactions, each the size of an entire Bitcoin block! Instead, the setup process includes the creation of a Taproot tree that represents the relationship between the inputs and outputs of all the intermediary sub-programs. The last Tapleaf in the tree is used for the `Payout` transaction, enabling the operator to claim the funds if the program execution is not challenged.
- Operators pay out using their own money, then are _reimbursed_ by spending the UTXO from a previous `PegIn` after the challenge period. These settings (challenge period duration, operator capital) are what constrain the throughput of the bridge(/other collateralized program)
---
## Resources
## BitVM Papers
- [BitVM2: Bridging Bitcoin to Second Layers](https://bitvm.org/bitvm_bridge.pdf)
- [BitVM3: Efficient Computation on Bitcoin](https://bitvm.org/bitvm3.pdf)
## Written resources on BitVM
- [BitVM Bridge Prototype on Signet](https://blog.gobob.xyz/posts/bob-announces-trust-minimized-bitcoin-bridge-prototype-powered-by-bitvm)
- [Deep dive into BitVM Computing Paradigm - Ichiro Kuwahara](https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca).
- [The BitVM Primer - Tyler Whittle](https://mirror.xyz/twhittle.eth/zXzocAl-wWiMSBAzhKnd6w0AJsftqgPTUfnh115fVPM)
- [BitVM: A Breakthrough in Computing on the Bitcoin Layer - Trust Machines](https://trustmachines.co/blog/bitvm-a-breakthrough-in-computing-on-the-bitcoin-layer/)
- [The Big Deal with BitVM - Bitcoin Magazine](https://bitcoinmagazine.com/technical/the-big-deal-with-bitvm-arbitrary-computation-now-possible-on-bitcoin-without-a-fork)
- [BitVM FAQs](https://github.com/PraiseTheMithra/BitVm-FAQ)
## Video and audio resources on BitVM
- [BitVM Uses a 'Compilation of a Couple Tricks' to Overcome Limitations of Bitcoin's Script: Robin Linus](https://finance.yahoo.com/video/bitvm-uses-compilation-couple-tricks-141723622.html)
- [What is BitVM? with Robin Linus and Super Testnet (SLP520) - Stephan Livera Podcast](https://www.youtube.com/watch?v=XxqQU6j6jI8)
- [Zero Sync - Bitcoin Amsterdam](https://www.youtube.com/watch?v=rubs5SrkGsM)
- [BitVM two way peg design - Ordinals Show](https://twitter.com/i/spaces/1YqKDgYMqlvxV?s=20)
- [BitVM - A Tiny Web3 Podcast](https://twitter.com/cartesiproject/status/1729893087143759950)
- [Everything on Bitcoin with Robin Linus & Super Testnet - Bitcoin Audible](https://pod.link/1359544516/episode/413027f0bdb982a8593d50f4466930f5)
- [BitVM Takeover with Super Testnet - Layer Two Labs](https://x.com/LayerTwoLabs/status/1712855344764834076?s=20)
- [BitVM, Convenants and Scaling - Bitcoin News](https://x.com/BitcoinNewsCom/status/1715392573555040265?s=20)
- [BitVM and UTXO Dealership](https://twitter.com/i/spaces/1OyJAWapbAOKb)
- [BitVM Discussion - Ordinals Show](https://x.com/TO/status/1716265121373172075?s=20)
## Related Github Repos
- [BitVM Official Implementation](https://github.com/BitVM/BitVM)
- [Things BitVM Needs](https://github.com/supertestnet/things-bitvm-needs)
- [Awesome BitVM - Rsync25, an amazing resource on technical resources regarding BitVM](https://github.com/Rsync25/awesome-bitvm)
## Tweet threads on BitVM
- [BitVM2 and BitVM Bridge: TLDR - Alexei Zamyatin](https://x.com/alexeiZamyatin/status/1824034904516051335)
- [Decentralized two way peg on BitVM - Alex Emidio](https://x.com/AlexEmidio7/status/1735276812198986210)
- [BitVM Explainer - Bob Bodily](https://x.com/BobBodily/status/1712305639366811997)
- [BitVM Explainer, BitVM GPT - Dylan LeClair](https://x.com/DylanLeClair_/status/1722995043932270854?s=20)
## Communities
- [BitVM Telegram](https://x.com/robin_linus/status/1711757377983086894?s=20)
---
## BitVM on BOB
:::info
BOB mainnet is live. BitVM is a new BTC bridge and is set to go live on mainnet in Q4 2025. You can try it out on testnet at [bitvm-testnet.gobob.xyz](https://bitvm-testnet.gobob.xyz/en).
:::
## Current Status: BitVM Testnet
[BitVM](https://blog.gobob.xyz/posts/what-is-bitvm) is currently running on testnet with significant improvements and new features that set it apart from previous iterations. The testnet represents a major step forward in bringing native BTC to DeFi applications while maintaining Bitcoin's security guarantees.
### Key Testnet Features
#### 1. **BitVM Operator Split**
BOB has pioneered splitting the BitVM operator role into two distinct parts:
- **Operator Node**: Acts like a validator, performing complex BitVM operations
- **Operator LP**: Supplies BTC temporarily during pegout operations
This separation mirrors the validator/staker relationship in PoS networks, reducing the capital requirements for individual operators.
#### 2. **Data Availability on Ethereum**
Leveraging BOB's hybrid L2 design, BitVM uses Ethereum's cheaper data storage instead of Bitcoin:
- Challengers can access required data from Ethereum blobs
- Maintains the same censorship resistance as Ethereum rollups like Arbitrum or Base
- Significantly reduces costs compared to posting data to Bitcoin
#### 3. **Collateral Re-use**
Based on research by Citrea and CommonPrefix, BOB implements collateral re-use for operators:
- Fixed BTC collateral amount instead of scaling with BitVM instances
- Reduces capital requirements for operators
- Enables more efficient capital utilization
### Testnet Integration Partners
The current testnet features integration with partners running BitVM:
- **P2P.org**: Infrastructure and staking services
- **Lombard**: Digital asset management and institutional services
- **Solv Protocol**: DeFi infrastructure and yield optimization
- **Amber Group**: Digital asset platform and trading services
- **Ankr**: Web3 infrastructure and node services
- **RockawayX**: Blockchain infrastructure and investment
- **Fiamma**: DeFi protocol and yield strategies
- **UTXO Management**: Bitcoin-focused investment and infrastructure
- **Luganodes**: Blockchain infrastructure and node services
- **SatLayer**: Bitcoin Layer 2 infrastructure and development
### User Access via Gateway
Users can access BitVM BTC on BOB through the Gateway interface at [bitvm-testnet.gobob.xyz](https://bitvm-testnet.gobob.xyz/en). Gateway provides:
- Fast and cheap access to BitVM BTC
- 3-block confirmation time
- Complementary service to direct BitVM usage
## Roadmap
### Q4 2025: Mainnet Launch
The BitVM bridge, built by BOB and bitvm/acc partners, will launch on mainnet in Q4 2025. This launch represents:
- **Institutional Adoption**: Early collaboration with future operators to ensure BitVM meets real-world needs
- **Product Shaping**: Partners have the opportunity to influence product and client design
- **Security Alignment**: BitVM aligns BTC bridge security with Ethereum L2 standards through fraud-proof "1-of-N" security
### Beyond Mainnet
The roadmap extends beyond the initial mainnet launch with ongoing development focused on:
- **Ecosystem Growth**: Expanding the network of operators and partners
- **Security Enhancements**: Continuous improvement of the fraud-proof system
- **User Experience**: Streamlining access and reducing barriers to entry
- **Cross-chain Integration**: Expanding BitVM's reach across the broader blockchain ecosystem
### Long-term Vision
BitVM's long-term vision is to enable native BTC in DeFi applications while maintaining Bitcoin's security guarantees. This includes:
- **DeFi Integration**: Seamless BTC usage in DeFi protocols
- **Institutional Adoption**: Meeting the needs of institutional players
- **Decentralization**: Maintaining maximal decentralization and censorship resistance
- **Scalability**: Supporting growing demand while maintaining security
---
## Run a Full Node
:::info
There is no protocol level incentive to run a BOB full node. If you're interested in accessing the BOB chain, but you don't want to set up your own node, see our [Node Providers](/docs/tools/node-providers) to get RPC access to fully-managed nodes hosted by a third-party provider.
To stay updated on node upgrades and announcements, join our [Telegram channel](https://t.me/bobupgradechannel).
:::
## Requirements
As of April 2026 we recommend you have at least the following hardware configuration to run a node:
- at least 8 GB RAM
- an SSD, preferably NVME drive with at least 100 GB free
Software stack:
- [Docker](https://docs.docker.com/engine/install/)
- [Docker Compose](https://docs.docker.com/compose/install/)
## Configuration
We provide a simple Docker Compose configuration to get you started. This guide assumes all data will be stored under `/opt/`.
### 1. Create data directories
```sh
mkdir -p /opt/op-reth /opt/op-node
```
### 2. Generate a JWT secret
The JWT secret authenticates the connection between `op-node` and `op-reth`.
```sh
openssl rand -hex 32 > /opt/op-reth/jwt.hex
```
### 3. Download the BOB genesis file
The built-in `bob` chain spec in `op-reth` does not yet include the Jovian hardfork timestamp. You must download the genesis file from Conduit and pass it to op-reth via `--chain`.
```sh
curl -o /opt/op-reth/genesis.json \
https://api.conduit.xyz/file/v1/optimism/genesis/bob-mainnet-0
```
Verify the genesis file includes the Jovian fork time:
```sh
jq '.config.jovianTime' /opt/op-reth/genesis.json
# Expected: 1773325801
```
### 4. Create the op-node environment file
Ensure you have an Ethereum L1 full node RPC available and set `OP_NODE_L1_ETH_RPC` and `OP_NODE_L1_BEACON` to the respective RPC endpoints.
```sh title="op-node.env"
OP_NODE_L1_ETH_RPC=.....
OP_NODE_L1_BEACON=......
OP_NODE_L1_TRUST_RPC=true
OP_NODE_LOG_LEVEL=WARN
OP_NODE_P2P_BOOTNODES=enode://09acd29625beb40604b12b1c2194d6d5eb290aee03e0149675201ed717ce226c506671f46fcd440ce6f5e62dc4e059ffe88bcd931f2febcd22520ae7b9d00b5e@34.83.120.192:9222?discport=30301,enode://d25ce99435982b04d60c4b41ba256b84b888626db7bee45a9419382300fbe907359ae5ef250346785bff8d3b9d07cd3e017a27e2ee3cfda3bcbb0ba762ac9674@bootnode.conduit.xyz:0?discport=30301,enode://2d4e7e9d48f4dd4efe9342706dd1b0024681bd4c3300d021f86fc75eab7865d4e0cbec6fbc883f011cfd6a57423e7e2f6e104baad2b744c3cafaec6bc7dc92c1@34.65.43.171:0?discport=30305,enode://9d7a3efefe442351217e73b3a593bcb8efffb55b4807699972145324eab5e6b382152f8d24f6301baebbfb5ecd4127bd3faab2842c04cd432bdf50ba092f6645@34.65.109.126:0?discport=30305
OP_NODE_P2P_STATIC=/ip4/34.83.120.192/tcp/9222/p2p/16Uiu2HAkv5SVdeF4hFqJyCATwT87S3PZmutm8akrgwfcdFeqNxWw
OP_NODE_P2P_SYNC_ONLYREQTOSTATIC=true
OP_NODE_L2_ENGINE_RPC=http://localhost:9551
OP_NODE_L2_ENGINE_KIND=reth
OP_NODE_L2_ENGINE_AUTH=/reth/jwt.hex
OP_NODE_NETWORK=bob-mainnet
OP_NODE_SYNCMODE=execution-layer
OP_NODE_SYNCMODE_REQ_RESP=true
OP_NODE_OVERRIDE_JOVIAN=1773325801
OP_NODE_ROLLUP_LOAD_PROTOCOL_VERSIONS=true
OP_NODE_RPC_ENABLE_ADMIN=true
OP_NODE_SAFEDB_PATH=/data
OP_NODE_METRICS_ENABLED=true
OP_NODE_METRICS_ADDR=127.0.0.1
```
### 5. Create the Docker Compose file
```yml title="docker-compose.yml"
services:
op-reth:
image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-reth:v2.1.0-rc.1
command:
- node
- --chain=/data/genesis.json
- --full
- --storage.v2
- --datadir=/data
- --rollup.sequencer-http=https://rpc-bob-mainnet-0.t.conduit.xyz
- --rollup.historicalrpc=https://rpc-bob-mainnet-0.t.conduit.xyz
- --rollup.disable-tx-pool-gossip
- --http
- --http.api=web3,debug,eth,txpool,net
- --ws
- --ws.api=web3,debug,eth,txpool,net
- --authrpc.port=9551
- --authrpc.jwtsecret=/data/jwt.hex
- --metrics=127.0.0.1:9001
volumes:
- /opt/op-reth:/data
network_mode: host
restart: unless-stopped
op-node:
image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:v1.16.12
command:
- op-node
env_file: op-node.env
volumes:
- /opt/op-node:/data
- /opt/op-reth:/reth
network_mode: host
restart: unless-stopped
depends_on:
op-reth:
condition: service_started
```
### 6. Start the node
```sh
docker compose up -d
```
## Verifying Sync Progress
Sync proceeds in pipeline stages. You can monitor progress with:
```sh
curl -s -X POST http://localhost:8545 \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' | jq .
```
While syncing, `eth_syncing` returns a status object with per-stage block checkpoints (Headers → Bodies → Execution). Once all stages are complete, it returns `false` and `eth_blockNumber` will reflect the live chain head.
Expected sync time from scratch is several hours depending on hardware and network.
## Rollup Configuration and Genesis
The genesis and rollup configuration files for BOB Mainnet are available from Conduit:
- [Genesis](https://api.conduit.xyz/file/v1/optimism/genesis/bob-mainnet-0)
- [Rollup Configuration](https://api.conduit.xyz/file/v1/optimism/rollup/bob-mainnet-0)
- [Contracts](https://api.conduit.xyz/file/getOptimismContractsJSON?network=036d1667-e469-424e-9db9-5b09cf4d460d&organization=610ec5c5-8b4c-444a-b2b4-a94c1835defe)
## BOB Sepolia (Testnet)
You can also run a full node for BOB Sepolia. Configuration information can be found on [Conduit's BOB Sepolia hub page](https://hub.conduit.xyz/bob-sepolia-dm6uw0yhh3).
:::info
We do not provide support for running a full node on the testnet. If you have any issues, please refer to the [Conduit's node documentation](https://docs.conduit.xyz/guides/run-a-node/op-stack-node) for more information.
:::
## Resources
Additional information on how to self-host a node for an OP Stack rollup is available on [Conduit's node documentation](https://docs.conduit.xyz/guides/run-a-node/op-stack-node). Full details on the rollup configuration are available on the [Conduit BOB Mainnet hub page](https://hub.conduit.xyz/bob-mainnet-0).
## External Links
1. [BOB Mainnet rollup configuration](https://hub.conduit.xyz/bob-mainnet-0)
1. [Conduit's node documentation](https://docs.conduit.xyz/guides/run-a-node/op-stack-node)
1. [Optimism's guide for running a node with Docker](https://docs.optimism.io/builders/node-operators/tutorials/node-from-docker)
---
## Hybrid Chain
BOB is a _Hybrid Chain_, a new kind of Hybrid ZK Rollup that inherits Bitcoin finality while providing trust-minimized bridges directly to Ethereum and Bitcoin. Through its unique multi-layered architecture, BOB combines Bitcoin's security with Ethereum's innovation, ultimately bringing BTC to any app on any chain.
## Native Bridges
BOB's hybrid architecture is built on two native bridges that provide secure asset transfers to both Bitcoin and Ethereum.
### BitVM Bridge: BTC on BOB
:::info R&D
BOB has released its BitVM testnet bridge. Mainnet is planned for Q4 2025. For details, see the dedicated [BitVM Bridge](/docs/bitvm) page.
:::
BOB has [released its BitVM testnet bridge](https://blog.gobob.xyz/posts/bob-bitvm-testnet-launch) a two-way light-client BTC bridge powered by [BitVM](/docs/bitvm) in partnership with [bitvm/acc](https://bitvm-acc.org/) members. The BitVM bridge represents the most secure BTC bridge design to date, operating under a superior 1-of-n security model where BTC deposits cannot be stolen as long as there is a single honest and online node in the network.
Withdrawals of bridged BTC from BOB to Bitcoin through this BitVM bridge are verified by a ZK SNARK fraud-proof mechanism that relies on a 1-of-N trust assumption for operation. Unlike traditional bridges that rely on trusted multisigs or honest majorities, the BitVM bridge uses optimistic computation secured by Bitcoin's own consensus, allowing anyone to challenge fraudulent withdrawals and prevent theft through on-chain fraud proofs. A bridged version of BTC secured by BitVM is a massive improvement in BTC safety because it unlocks unilateral exit back to Bitcoin.
### Ethereum Bridge: ETH, ERC20s, and NFTs on BOB
BOB utilizes the [OP Stack's native bridge contracts](https://docs.optimism.io/app-developers/bridging/standard-bridge) for secure and free asset transfers between Ethereum and BOB. This allows users to deposit and withdraw assets directly through L1 smart contracts, inheriting Ethereum's security guarantees and censorship-resistance. The bridge supports 1-click onboarding of ERC-20 tokens, stablecoins, and ETH, with over $250M in TVL secured by Ethereum's validator network.
Users can already force withdraw their assets from BOB to Ethereum, even if BOB's sequencer goes offline. An Ethereum transaction can directly call the [Native Ethereum Bridge](/docs/reference/contracts#ethereum-l1) that BOB has as an OP Stack rollup. For technical details, see the OP Stack [deposit flow](https://docs.optimism.io/stack/transactions/deposit-flow) and [withdrawal flow](https://docs.optimism.io/stack/transactions/withdrawal-flow) documentation.
## Consensus: Hybrid ZK Rollup
### Hybrid ZK Rollup
BOB operates as a hybrid ZK rollup powered by [Kailua](https://github.com/boundless-xyz/kailua), combining the efficiency of optimistic rollups with the security of ZK proofs. Under normal operation, the BOB proposer posts state updates that can be challenged like other optimistic rollups, but disputes are resolved through single ZK proofs rather than expensive multi-round verification games. This approach reduces withdrawal times to 4 days (with plans to reduce to hours as the system matures) and makes fault proofs accessible with just 0.5 ETH collateral, ~$3 proof generation cost, and 250k gas for SNARK verification.
On demand, the hybrid model allows proposers to submit validity proofs directly with their proposals for instant finality, enabling users to choose between cost-optimized (optimistic) and speed-optimized (validity proof) modes based on their needs. The Kailua integration provides:
- **Mathematical Certainty:** ZK proofs guarantee the correctness of all BOB state transitions during disputes
- **Flexible Finality:** Users can choose between cost-optimized (optimistic) or speed-optimized (validity proof) modes based on their needs
- **Progressive Enhancement:** Seamless upgrade path from optimistic to full validity rollup without disruption
This upgrade positions BOB to achieve Stage 0 status on [L2Beat](https://l2beat.com/scaling/projects/bob).
### Under the Hood: OP Stack
BOB uses the [OP Stack](https://docs.optimism.io/stack/getting-started) as its foundation. In the OP Stack, the "Sequencer" actually consists of multiple services that are run together. The main services are:
- **Proposer:** The proposer is responsible for submitting the latest proposals of BOB to Ethereum.
- **Batcher:** The batcher is responsible for submitting all data from BOB to Ethereum blobs to ensure that the BOB state can be entirely reconstructed just from data on Ethereum without any dependency on the BOB sequencer.
- **Execution (op-reth):** The execution client is responsible for processing transactions and BOB blocks.
- **Consensus (op-node):** The consensus client is responsible for ordering of transactions and BOB blocks from both Ethereum blobs and the L2 data. Full nodes use the consensus client to verify the BOB blocks and transactions purely from Ethereum data.
- **Fraud Proof:** The fraud proof client usually consists of a verifier and a challenger. The verifier checks if BOB blocks are valid and triggers the challenger to submit a counter-proposal in case the proposer submitted an invalid proposal.
### Under the Hood: Kailua
Traditionally, rollups have followed two separate models: optimistic rollups, which assume transactions are valid but require a 7-day challenge window, and validity rollups, which verify transactions instantly via ZK proofs but are expensive to operate. Kailua introduces a third Hybrid ZK option by applying ZK proofs to the fraud resolution process in optimistic rollups.
**Sequencing**
In Kailua, proposer need to stake 0.5 ETH to be the proposer. The proposer submits ["mini proposals"](https://boundless-xyz.github.io/kailua/design.html#sequencing) frequently. In the case of BOB, every 6 BOB blocks a mini proposal is created. Every 12 hours, the proposer submits a full proposal to BOB's Ethereum contracts that reference all the mini proposals. The mini proposals are stored in Ethereum blobs.
**On Demand Validity Proofs**
The proposer can optionally submit a validity proof with their proposal. If a correct validity proof is submitted, the proposal is finalized instantly. If no validity proof is submitted, the proposal is finalized after 4 days unless successfully disputed.
:::info Validity Proof on BOB Mainnet
See here for an example of a validity proof for BOB on mainnet: https://etherscan.io/tx/0xe3d5ed2b47c9b19fa777e8a3d5103b72d05abfa5d5c79c7289389acb9eafda0f
:::
**Dispute Resolution**
Once a full proposal is submitted by a proposer, it can be challenged by anyone. The challenger needs to submit a full proposal (including their own mini proposals) that is different from the proposer's proposal. The challenger also needs to stake 0.5 ETH as collateral. Then either the proposer or the challenger submit a fault proof. The fault proof proves the correctness of one of the mini-proposals and thereby invalidates one of the proposals. This allows cheap proving cost: instead of having to prove all 21,600 blocks in a 12 hour period, the challenger only needs to prove 6 blocks. If a proposal is not disproven for 4 days, it is considered finalized.
**Vanguard Mode**
BOB is currently in [vanguard mode](https://boundless-xyz.github.io/kailua/parameters.html?highlight=vanguard#vanguard-advantage). This means that the BOB proposer has priority to submit proposals. If no proposal is made by the proposer within 30 days, then any user can submit their own proposal.
**Finality**
Once a proposal is finalized on Ethereum, it is considered final and cannot be disputed. At this point, pending withdrawals from BOB to Ethereum can be executed.
### Bitcoin Finality
:::info R&D
The Bitcoin finality gadget is currently in R&D.
:::
BOB will introduce BTC-staked Finality Providers (FPs) through [Babylon](https://babylonlabs.io/)'s Bitcoin Staking Network. These FPs will sign BOB state proposals and receive sequencer fees in exchange for providing economic security through their staked BTC. If FPs sign competing chains, their staked BTC will be slashed, creating strong economic incentives against chain forks.
The consensus process will combine three key building blocks:
- **Kailua Validity Proofs:** ZK proofs that cryptographically guarantee the correctness of all BOB state transitions, with on-demand generation for fast withdrawals
- **BTC-staked FPs:** Finality Providers that sign state proposals, with ⅔ stake required for finalization
- **Hybrid Architecture:** Default optimistic mode with optional validity proofs for enhanced security and flexibility
BOB blocks will be fast-finalized by Bitcoin stakers within seconds, providing economic security without waiting for Ethereum inclusion, then checkpointed to Bitcoin for reorganization-resistance through Bitcoin's proof-of-work security.
## Hybrid Data Availability: Ethereum Blobs with Bitcoin Fallback
:::info R&D
BOB is currently using Ethereum blobs as DA. The Bitcoin DA is currently in R&D.
:::
BOB implements a hybrid data availability architecture that combines Ethereum's cost efficiency with Bitcoin's censorship resistance. BOB uses EIP-4844 blobs as the primary data availability layer, following the standard OP Stack derivation pipeline while processing transactions in a specific order: Bitcoin forced withdrawals first, followed by Ethereum deposits and transaction batches.
BOB is researching modifications to the `op-node` to add a check for forced withdrawal transactions on Bitcoin as part of the derivation pipeline. Bitcoin serves as a highly censorship-resistant fallback mechanism, enabling users to force withdrawals using only BTC without requiring ETH. This is implemented through a two-phase commit/reveal scheme on Bitcoin using Taproot outputs to store transaction data, requiring both a commit transaction and a reveal transaction to complete the forced withdrawal process.
This hybrid DA model offers:
- **Censorship Resistance:** Leverages Bitcoin's battle-tested security as fallback storage
- **Forced Transaction Inclusion:** Enables forced withdrawals back to Bitcoin through the [BitVM bridge](/docs/bitvm#bitvm-bridge-summary), even if BOB's Sequencer is offline
This unique approach defaults to Ethereum for data availability while allowing users to force include transactions on BOB via special Bitcoin transactions, providing enhanced censorship resistance and ensuring users can always exit their funds even if BOB's sequencer goes offline. Learn more about the technical implementation in our [hybrid data availability research](https://blog.gobob.xyz/posts/hybrid-data-availability-enforcing-bitvm-withdrawals-on-bob).
## Development Phases
### ✅ Phase 1: Bootstrapping as an Ethereum L2
BOB launched as an Ethereum L2 built with the [OP stack](https://docs.optimism.io/) and has now upgraded to a hybrid ZK rollup with [Kailua](https://github.com/risc0/kailua). The network operates with native Ethereum bridge contracts and supports multiple third-party Bitcoin bridges, providing familiar UX, wallets, tokens, and dapps as other EVM chains like Ethereum, Arbitrum, and Base.
BOB tracks Bitcoin's state with an onchain BTC light client, verifying block headers and accepting transaction inclusion proofs. **This enables smart contracts on BOB to trustlessly use Bitcoin state in real time**, powering applications like [BOB Gateway](/docs/user-hub/onboard-to-bob/bob-gateway) for cross-chain Bitcoin DeFi.
### ⌛ Phase 2: Bitcoin "Soft" Finality
_In Phase 2, BOB will add Bitcoin finality to the Ethereum L2 setup._
Once per epoch (one or more BOB blocks), the Sequencer will request sign-off by participants of the Bitcoin finality protocol, who fully validate the BOB chain state. Using BitVM, BOB can then construct a trust-minimized Bitcoin bridge secured by this Bitcoin "soft" finality protocol. To attack the Bitcoin bridge, one would need to corrupt the majority of Bitcoin finality protocol participants ([hash rate](https://gobob.xyz/optimine) or [BTC stake](/docs/reference/research#bitvm2-bridging-bitcoin-to-second-layers)). The Ethereum bridge will remain secured by Ethereum.
**This Bitcoin "soft" finality can be used to accelerate withdrawals of the Ethereum bridge, reducing the delay from 7 days to a few minutes or hours.**
### Phase 3: Full Bitcoin Security
_The final step is inheriting Bitcoin security by posting BOB's state transition proofs on Bitcoin._
In the absence of a Bitcoin fork enabling on-chain zk-verifiers, BOB will leverage optimistic verification via BitVM. Achieving optimistic rollups on Bitcoin without additional trust assumptions requires using the Bitcoin mainchain as a data availability layer. The associated costs are onerous and pose a challenge in terms of economics. As a result, to complete the transition to Phase 3, BOB must reach sufficient scale in terms of active users such that incurring additional data availability fees does not increase transaction fees beyond that of competing Ethereum L2s. Alternative data availability layers can be considered as a trade-off between cost and security, as they introduce additional trust assumptions beyond that of Bitcoin.
## Further Reading
To learn more about the background, motivations, and technical details of the BOB Hybrid Chain, read the [BOB Hybrid Chain Vision Paper](https://docs.gobob.xyz/whitepaper.pdf).
---
## Hybrid Nodes
Hybrid Nodes are technical infrastructure providers that operate core BOB services. All node operators on BOB are called "Hybrid Nodes" and serve critical roles in enabling Bitcoin DeFi functionality through BitVM operations, Bitcoin finality, and cross-chain infrastructure.
## Node Types and Ranking
### Delegation as a Ranking Mechanism
BOB requires a decentralized way to select and rank infrastructure providers. Since BOB cannot support arbitrarily many operators due to technical constraints (e.g., BitVM operators introduce off-chain data requirements that scale with each new operator), BOB token delegations serve as a ranking instrument. Operators most trusted by the community, as demonstrated by BOB token delegations they receive, serve as the infrastructure providers for BOB.
This creates an alignment mechanism where:
- Operators are selected based on their service performance and BOB token delegations received
- BOB token holders delegate to reliable operators that expand liquidity and pioneer new products
- The system naturally limits operator numbers while ensuring quality through community selection via BOB token delegation
### Current Infrastructure Roles
:::info R&D
BitVM operators and Bitcoin finality providers are currently in development, planned for Phase 2.
:::
**Native BTC through BitVM Operators**
BitVM achieves 1-of-n security, meaning if there's one honest provider, native BTC on BOB is secure. BitVM operators serve as safekeepers of all BitVM for BOB. The trust model allows users to verify their own BTC deposits while relying on ranked operators to trigger fault-proof processes if anyone attempts to cheat. Operators are selected and prioritized according to their reliability and BOB token delegations received.
**Bitcoin Finality through Finality Providers (FPs)**
FPs attest to BOB's finality on Bitcoin, enabling BitVM verification that BOB has finalized on Bitcoin. This can be achieved through [Babylon's BSN architecture](https://docs.babylonlabs.io/guides/overview/bitcoin_secured_networks/) or BOB's [OptiMine](https://gobob.xyz/optimine) optimistic merged mining protocol. BOB maintains hybrid ZK proof security on Ethereum while adding Bitcoin "soft" finality. FPs are selected based on their ecosystem contribution and BOB token delegations received.
### Future Infrastructure Roles
**Bitcoin Staking through Block Builders**
BOB's approach to BTC staking leverages tight control over block production to eliminate harmful MEV while enabling "good" MEV like DEX rebalancing and liquidation execution. Users stake BTC assets on BOB, builders use these assets for ecosystem health activities, creating transparent yield from DeFi activity. Builders require BOB token delegations to participate in fast block building.
**Fast BTC Access through Gateway Solvers**
Gateway solvers provide liquidity for quick BTC swaps between Bitcoin and BOB, and integrate with bridges for optimal cross-chain routing. BOB token delegations ensure only reliable solvers offering fast transfers are selected, with the system limiting solver numbers to reduce coordination overhead.
## Rollout Phases
### Phase 1: Pre-staking
- Users delegate BOB tokens to Hybrid Nodes
- Nodes establish themselves without active infrastructure
### Phase 2: Infrastructure Launch
- Bitcoin finality providers and BitVM operators go live
- FPs prioritized based on BOB token delegations and ecosystem contributions
- BitVM operators selected based on bridging capability and reliability
### Phase 3: Role Extension
- Gateway solvers extended to facilitate BTC swaps between chains
- Block builders enable MEV searching and DeFi optimization
- Additional node types based on ecosystem needs
## Technical Architecture
### Security Model
- **BitVM**: 1-of-n trust assumption with fraud proofs on Bitcoin
- **Finality**: Economic security through staked BTC with slashing
- **Delegation**: Non-custodial smart contracts where nodes cannot access delegated BOB tokens
- **Transparency**: On-chain monitoring and verification of all operations
---
## BOB Chain Overview
BOB is a Hybrid Chain that combines Bitcoin's security with Ethereum's DeFi innovation.
## Architecture
Learn more about BOB's architecture:
- [Hybrid Stack](./stack-overview) - The layered architecture enabling Bitcoin and Ethereum interaction
- [Hybrid Chain](./hybrid-chain) - BOB's core chain architecture and security model
- [Transactions](./transactions) - How transactions work on BOB
- [Hybrid Nodes](./hybrid-nodes) - Technical infrastructure providers securing the network
## Key Features
- **Hybrid Zero-Knowledge Rollup**: BOB has upgraded to [Kailua](https://risczero.com/op-kailua), making it a hybrid zk rollup. By default, state proposals are made optimistically. When competing proposals arise, they're settled by validity proofs. Proposers can also submit validity proofs on-demand for fast withdrawals.
- **Fast Bitcoin Finality**: All transactions are finalized by Bitcoin. This is achieved through Bitcoin checkpointing and BTC staking via Babylon's [BSN](https://docs.babylonlabs.io/guides/overview/bitcoin_secured_networks/) architecture.
- **EVM Compatibility**: Deploy and interact with EVM smart contracts. BOB uses the OP Stack with [minimal modifications](https://op-geth.optimism.io/) to the EVM - 100% compatibale with Base, Optimism and all other [Superchains](https://docs.optimism.io/superchain/superchain-explainer).
- **Low Fees**: Significantly lower transaction costs than Bitcoin or Ethereum.
- **Native BTC Support**: Use BTC directly in DeFi - with a single transaction through the power of [Gateway](https://docs.gobob.xyz/gateway) and with full Bitcoin-security by [BitVM](/docs/bitvm).
## Use Cases
- **DeFi**: Lending, borrowing, trading, and yield farming with BTC, stablecoins, ETH, and other assets.
- **NFTs**: Mint and trade NFTs with Bitcoin security.
- **Payments**: Fast, low-cost payments using BTC and stablecoins.
- **Staking**: Earn yield on BTC and other assets.
## Network Information
### Mainnet
- **Mainnet Chain ID**: 60808
- **Mainnet RPC**: https://rpc.gobob.xyz/
- **Explorer**: https://explorer.gobob.xyz/
- **App**: https://app.gobob.xyz/
### Testnet
- **Testnet Chain ID**: 808813
- **Testnet RPC**: https://bob-sepolia.rpc.gobob.xyz
- **Testnet Explorer**: https://bob-sepolia.explorer.gobob.xyz/
- **App**: https://bob-sepolia.gobob.xyz/
---
## Bitcoin Light Client
We have chosen to use the production-ready [**tBTC-v2**](https://github.com/keep-network/tbtc-v2/blob/main/solidity/contracts/relay/LightRelay.sol) (summa / keep-network) relay contracts and supporting libraries to support the initial development of the BOB stack. The contracts are already well-optimized for gas consumption and have been used on mainnet Ethereum for quite some time.
A specific advantage of using the Simple Payment Verification (SPV) "Light Relay" developed for tBTC is that we do not need to store all block headers from the genesis / initialization height. It uses stateless SPV proofs and provides some recency guarantee using Bitcoin's difficulty adjustment based on the latest retarget.
## Features
- Proof that a Bitcoin transaction happened on Bitcoin to a smart contract on BOB
- Verify Bitcoin block headers from smart contracts on BOB
## How Does it Work?
- The light relay is initialized to the beginning of a difficulty period (epoch)
- A "maintainer" submits `proofLength` block headers before and after the retarget
- The relay validates the chain and updates the expected difficulty for blocks in that epoch
- A user can then submit a transaction proof in that or the last period
- Requires header chain of at least `txProofDifficultyFactor`
## Using The Relay
The code for the light relay is in [`src/relay/LightRelay.sol`](https://github.com/bob-collective/bob/blob/master/src/relay/LightRelay.sol) which stores the difficulty for the current and previous epoch. To update this it is possible to use `retarget(headers)` with `proofLength * 2` block headers from Bitcoin (before and after the retarget) serialized sequentially.
### Adding BOB contracts as dependency
To add the BOB contracts to your own projects, if your project is using Foundry, you can simply run `forge install bob-collective/bob` to add BOB contracts as a dependency to your project.
### Build the code
To build all the contracts, run `forge build`.
### Run the tests
To run the built-in tests, run `forge test`.
### Using the Contracts from TypeScript
:::tip BOB SDK
To get the required input data for the contract, use the `getBitcoinHeaders` function to automatically read `numBlocks` from the configured Electrs REST API.
:::
### Validating Merkle Proofs (SPV)
To check the inclusion of a specific transaction, the `BitcoinTx.validateProof` function can be used. See [`test/LightRelay.t.sol`](https://github.com/bob-collective/bob/blob/master/test/LightRelay.t.sol) for an example. This requires the serialized transaction and merkle proof with `txProofDifficultyFactor` block headers to prove sufficient work has been built on top.
:::tip BOB SDK
Refer to the `getBitcoinTxProof` and `getBitcoinTxInfo` functions to encode the expected arguments.
:::
### Validating Merkle Proofs (SPV + Witness)
:::info
Why might you want to do this? Under normal SPV assumptions it is not possible to prove witness data (such as Ordinal inscriptions) are included on the main chain.
:::
To check that witness data is also included according to the relay we need to do the following:
1. Verify coinbase is included (tx + merkle proof)
2. Verify payment is included (tx + merkle proof)
3. Validate witness commitment (extract root from coinbase, provide merkle proof for wtxids)
Use the `WitnessTx.validateWitnessProof` function to verify witness data is included. See [`test/WitnessTx.t.sol`](https://github.com/bob-collective/bob/blob/master/test/WitnessTx.t.sol) for an example. As above, this requires the serialized transaction and merkle proof for the **coinbase** transaction. To verify the witness data is included we need to encode the **payment** arguments differently. Check the expected structs in [`src/bridge/WitnessTx.sol`](https://github.com/bob-collective/bob/blob/master/src/bridge/WitnessTx.sol), it requires a `witnessVector` and separate witness merkle root hash built using the block's "wtxids" - transactions serialized with the witness data and then hashed according to Bitcoin's double sha2.
:::warning BOB SDK
This approach is still experimental and not yet fully supported by the SDK. To construct the arguments as before use `getBitcoinTxProof` but set `forWitness` to `true` for `getBitcoinTxInfo` to get the `witnessVector`. To construct the witness merkle proof follow the test in [`sdk/test/utils.test.ts`](https://github.com/bob-collective/bob/blob/master/sdk/test/utils.test.ts) using `getMerkleProof` with the full raw block data.
:::
### Checking Output Amounts
To extract the output amount `BitcoinTx.processTxOutputs` can be used to extract the amount transferred to a specific address. See [`test/BitcoinTx.t.sol`](https://github.com/bob-collective/bob/blob/master/test/BitcoinTx.t.sol) for an example. The address is the `keccak256` hash of the expected `scriptPubKey`.
:::tip BOB SDK
Use `getBitcoinTxInfo` and pass the `outputVector`.
:::
---
## Hybrid Stack
The BOB ecosystem is built as a layered stack that enables seamless interaction between Bitcoin and Ethereum ecosystems, providing users with cryptographic security via ZK proofs, Ethereum's innovation, and Bitcoin-secured finality.
## Accounts and Wallets
Users interact with BOB through familiar EVM wallets like MetaMask and Rabby, as well as native Bitcoin wallets including Xverse, Unisat, and Phantom. Account abstraction is supported via ERC-4337 smart accounts and [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) (which provides [superior UX](https://blog.thirdweb.com/eip-7702/)) for gasless transactions and enhanced user experience. Bitcoin wallet integration allows users to control EVM funds directly from their Bitcoin wallets through providers. Or users can skip wallets altogether and use social logins with providers like [Dynamic](https://dynamic.xyz/), [Reown](https://reown.com/), and others.
## BOB SDK
The [BOB SDK](https://docs.gobob.xyz/gateway) abstracts Bitcoin cross-chain complexity for developers, enabling single-transaction BTC deposits and withdrawals from and into any DeFi protocol on any chain. Developers can build and extend their existing applications to accept native BTC deposits that are converted to wBTC or other BTC-wrappers. They can also offer their users to receive native BTC. The SDK provides familiar web3 APIs and comprehensive tooling for seamless Bitcoin DeFi integration powered by [BOB Gateway](https://docs.gobob.xyz/gateway).
## DeFi Ecosystem
BOB hosts a [growing ecosystem](https://app.gobob.xyz/en/apps) of leading DeFi applications including Uniswap v3, Avalon, Euler, Solv, Lombard, Bedrock, and more. The ecosystem leverages BOB's Bitcoin position to offer BTC-yields, BTC trading, and BTC lending use cases.
## Interoperability
BOB's interoperability layer consists of [BOB Gateway](https://docs.gobob.xyz/gateway), an intent-based Bitcoin bridge optimized for speed and programmability. BOB is specialized in optimizing the Bitcoin to BOB route. For multichain connection to Base, Arbitrum, Solana, Binance Smart Chain, and many more, BOB relies on multiple third-party bridges including [Chainlink CCIP](https://chain.link/cross-chain), [LayerZero](https://layerzero.network/), [Hyperlane](https://hyperlane.xyz/), [deBridge](https://debridge.finance/), and many more.
## BOB Hybrid Chain
BOB's foundation consists of native bridges to both Ethereum (via the OP stack) and Bitcoin (developed by BOB via [BitVM](/docs/bitvm)). Just like "ETH" is "ETH" on Arbitrum, BTC on BOB will just be "BTC". In addition, EVM smart contracts for full programmability, and a hybrid ZK rollup consensus powered by OP stack and Kailua complete the rollup. Data availability uses Ethereum blobs as primary storage with Bitcoin as a censorship-resistant fallback. This infrastructure enables unilateral exit to both Bitcoin and Ethereum while providing cryptographic security guarantees through validity proofs.
---
## Transactions
BOB inherits its transaction mechanics from the [OP Stack](https://docs.optimism.io/stack/transactions), providing users with fast, cost-effective transactions while maintaining the security guarantees of Ethereum.
## Transaction Fees
BOB's transaction fees are calculated differently from Ethereum to account for the cost of posting transaction data to Ethereum for data availability.
### Fee Components
BOB transaction fees include:
- **L1 data fee**: Cost of posting transaction data to Ethereum (the largest component)
- **L2 execution fee**: Cost of executing the transaction on BOB (typically much smaller)
### Fee Calculation
BOB uses the [Isthmus upgrade](https://docs.optimism.io/stack/transactions/fees) fee mechanism which calculates total fees as:
```
operatorFee = operatorFeeConstant + operatorFeeScalar * gasUsed / 1e6
totalFee = operatorFee + gasUsed * (baseFee + priorityFee) + l1Fee
```
Where:
- **operatorFee**: Fixed operator cost plus variable component based on gas usage
- **gasUsed**: Amount of gas consumed by the transaction
- **baseFee**: Dynamic base fee (EIP-1559)
- **priorityFee**: Optional tip for transaction prioritization
- **l1Fee**: Cost of posting transaction data to Ethereum
### EIP-1559 Support
BOB fully supports [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) fee mechanism, including:
- **Base fee**: Dynamic fee that adjusts based on network congestion
- **Priority fee**: Optional tip to prioritize transaction inclusion
- **Blob transactions**: Uses Ethereum's blob storage for more cost-effective data availability
### Onchain Costs
BOB's actual onchain costs and fee statistics can be tracked on [L2Beat](https://l2beat.com/scaling/projects/bob#onchain-costs), which shows:
- Total annual costs for data posting to Ethereum
- Average cost per transaction
- Data posted to Ethereum over time
### Cost Efficiency
BOB transactions are typically much cheaper than Ethereum transactions because:
- **Batch processing**: Multiple transactions share the cost of L1 data posting
- **Optimized data compression**: Transaction data is compressed before posting to Ethereum
- **Blob transactions**: Uses Ethereum's blob storage for more cost-effective data availability
For detailed fee calculations and mechanisms, see the [OP Stack transaction fees documentation](https://docs.optimism.io/stack/transactions/fees).
## Transaction Finality
BOB transactions follow a three-stage finality process that inherits Ethereum's security guarantees:
### Finality Stages
1. **Unsafe** (0-1 minute): Transaction is included in a BOB block but not yet posted to Ethereum
2. **Safe** (1-60 minutes): Transaction data is posted to Ethereum and included in an Ethereum block (BOB posts data every hour)
3. **Finalized** (15-74 minutes): Ethereum block containing the transaction is finalized (2 epochs + 14 minutes after safe)
### Kailua Enhancement
With BOB's [hybrid zk rollup](/docs/bob-chain/hybrid-chain) powered by Kailua, state proposals can be finalized instantly using validity proofs. While this service is not yet exposed to users, the technical capability exists to enable **on-demand fast withdrawals** in the future, potentially reducing withdrawal times from the current 4-day period to as little as 1 hour.
### Finality Guarantees
- **Unsafe transactions**: Can be reorganized by the sequencer
- **Safe transactions**: Protected from sequencer reorgs, require Ethereum reorg to reverse
- **Finalized transactions**: Irreversible under normal Ethereum consensus conditions
### Common Misconception: 7-Day Finality
A common misconception is that transactions on BOB take 7 days to finalize. **This is incorrect.** Transactions on BOB become finalized when their data is included in a finalized Ethereum block, typically between 15-74 minutes after submission.
This misconception often arises due to BOB's Standard Bridge, which includes a 4-day delay on _withdrawals_ of ETH and ERC-20 tokens. Withdrawing tokens from BOB to Ethereum using the Standard Bridge requires a minimum 4-day wait. This delay affects only withdrawals through the Standard Bridge and does not impact transaction finality on BOB itself.
**Important:** A transaction is finalized before the state proposal that references the transaction is finalized. Transaction finality depends on Ethereum's consensus mechanism, not on the OP Stack's fault proof system.
For comprehensive details on transaction finality, see the [OP Stack transaction finality documentation](https://docs.optimism.io/stack/transactions/transaction-finality).
## Transaction Flow
1. **Submission**: User submits transaction to BOB network
2. **Sequencing**: BOB sequencer includes transaction in a block
3. **Data Availability**: Transaction data posted to Ethereum via blob transactions
4. **Finalization**: Transaction becomes finalized when included in finalized Ethereum block
## Withdrawals
BOB supports two withdrawal mechanisms:
### Standard Bridge Withdrawals
- **4-day delay**: Standard OP Stack bridge withdrawals require 4-day challenge period
- **High security**: Inherits Ethereum's security guarantees
- **Universal support**: Works with all ERC-20 tokens and ETH
### Fast Withdrawals (Kailua)
- **Future feature**: Technical capability exists for 1-hour finality via validity proofs
- **Not yet available**: Service not currently exposed to users
- **Cost optimization**: Will allow users to pay for proofs only when speed is needed
This hybrid approach will eventually give users the flexibility to choose between cost-optimized standard withdrawals (4-day delay) and speed-optimized fast withdrawals (1-hour finality) based on their specific needs.
---
## BOB Pay
:::warning Deprecation Notice
BOB Pay was deprecated on May 22, 2025.
:::
## What is BOB Pay?
[BOB Pay](https://bob-pay.gobob.xyz/) aims to showcase how easy crypto UX can be by focusing on a simple use case popular within the Bitcoin ecosystem: payments.
With BOB Pay, you can send Bitcoin and stablecoins to someone's email address. No wallet, no app, no seed phrase - just simple, cheap, non-custodial, and lightning-fast payments. BOB Pay showcases the power of wallet abstraction with [Dynamic](https://www.dynamic.xyz/), smart accounts from [ZeroDev](https://zerodev.app/), and paymasters from [Pimlico](https://www.pimlico.io/).
We're offering projects on BOB free access to Dynamic and Pimlico if you'd like to do the same.
## Video Tutorial
## High-Level Technical Summary
1. Alice logs into [BOB Pay](https://pay.gobob.xyz) and sends WBTC to John's email address.
2. [Dynamic generates](https://docs.dynamic.xyz/wallets/embedded-wallets/create-wallets/overview#during-signup-automatic) a deterministic [ZeroDev smart account wallet](https://docs.dynamic.xyz/account-abstraction/aa-providers/zerodev) for John on BOB.
3. John claims their WBTC by [sending their first transaction](https://docs.dynamic.xyz/wallets/embedded-wallets/pregenerated-wallets#after-signup) to Charlie. The transaction fees are paid to a [Paymaster](https://docs.pimlico.io/infra/paymaster/erc20-paymaster) in WBTC so John can transact without holding any ETH.
4. A [guarantor from Pimlico sponsors John's first transaction fees](https://docs.pimlico.io/infra/paymaster/erc20-paymaster/architecture#eoa-guarantor-signature), then claims back the funds after John's first transaction. This solves the problem of John needing ETH to approve the Paymaster's access to their WBTC.
## Step-by-Step Guides
### Sending Bitcoin from a wallet to an Email Address
1. Open the [BOB Pay website](https://pay.gobob.xyz).
2. Sign in with your wallet.
3. Sign to prove you own your wallet. You can toggle this security step off if you like.
4. Click Send.
5. Enter the email address and amount of Bitcoin to transfer, then click Send.
6. After signing the transaction, the transfer is complete.
### Sending Bitcoin from an Email Address to a Wallet
1. Open the [BOB Pay website](https://pay.gobob.xyz).
2. Enter your email address.
3. Enter the six-digit verification code sent to your email.
4. Click Send.
5. Enter the recipient's wallet address and the amount of Bitcoin you would like to transfer, then click Send.
6. Click Sign.
7. The transfer is complete.
### Receiving Bitcoin or Stablecoins from Someone Else
1. Open the [BOB Pay website](https://pay.gobob.xyz).
2. Enter your email address and click Continue. You can also sign in with your wallet.
3. Enter the six-digit verification code sent to your email.
4. Click Receive.
5. Scan this QR code from the device that will send you tokens. This will open the BOB Pay website with your address already filled in for the sender. Alternatively, click Copy Address then send your address to the sender in a messaging app or email.
6. The sender can follow the rest of the steps in [the guide above](#sending-bitcoin-from-a-wallet-to-an-email-address) to finish sending you tokens.
## Conclusion
BOB offers a complete package for builders looking to bring world-class UX to Bitcoin. We're offering projects on BOB free access to Dynamic and Pimlico if you'd like to do the same.
We look forward to seeing what you Build on Bitcoin!
## Code References
- [BOB Pay](https://github.com/bob-collective/ui/pull/57/files) front-end and back-end code.
---
## Account Abstraction (ERC-4337)
In this example, we will show how wBTC can be used for gas fee payment using the [ERC-4337 account abstraction standard](https://eips.ethereum.org/EIPS/eip-4337) on BOB Sepolia (Testnet). This enables users to use smart contract wallets and transact without the need to own ETH.
:::info Example Code
Check out the code of the demo in [this repository](https://github.com/bob-collective/demo-account-abstraction-transfer/).
:::
## Smart Contract wallets
This demo showcases wBTC transfer from the smart contract wallet. Smart contract wallets utilize smart contracts rather than single private keys found in Externally Owned Address (EOA) wallets. The programmable nature of smart contract wallets allows for diverse use cases. Unlike EOAs, smart contract wallets can contain logic but rely on EOAs to sign the user operations. Therefore, integration of the smart contract wallet into UI adds an additional complexity - users need to distinguish between the signer (EOA) and the account that holds assets (smart contract wallet).
## Using the dApp
This application uses the ERC-4337 standard and showcases how a smart contract wallet can be integrated. It contains an implementation of a custom account abstraction client that simplifies the integration of this standard into the UI.
The application consists of a simple form that allows you to send wBTC from the smart contract account with the gas fee paid in wBTC. To use it enter the wBTC amount and the recipient's EVM address. Then the injected wallet will ask for a user operation signature. After that, a signed user operation will be sent to the bundler which will broadcast it to the network.
:::note
Before the first user operation can be made, the paymaster smart contract has to be approved to spend your wBTC. That is why the first wallet prompt will be the wBTC approval transaction request.
:::
### Try it out
#### Connecting MetaMask and funding your account
1. Clone [the repo](https://github.com/bob-collective/demo-account-abstraction-transfer/) and [start the front-end locally](#local-development).
1. Fund your account with Sepolia ETH from the [Sepolia testnet faucet](https://faucetlink.to/sepolia).
1. Transfer Sepolia ETH to BOB Testnet using [Superbridge](https://puff-bob-jznbxtoq7h.testnets.rollbridge.app/).
1. Connect with your MetaMask account and get wBTC by clicking on the `Get Tokens` button in the application header. (You will receive 30,000 wBTC that you can spend.)
1. Add wBTC to your MetaMask, wBTC address is `0x2868d708e442A6a940670d26100036d426F1e16b`.
1. Transfer wBTC to the smart contract account via MetaMask (displayed above the amount field in the form).
#### Making a transfer
1. Input the amount you wish to send and the recipient`s address into the form fields.
2. Click on `Transfer`. This will require three interactions with MetaMask: first one will deposit small amount of ETH to the entry point contract so that you can sign the user operation that allows the paymaster contract to spend your wBTC. Then you will sign the approval user operation. Finally, you will sign the transfer user operation.
3. Wait for the transfer user operation to be executed.
## Limitations
Given that ERC-4337 is still relatively new, there is not a lot of support for this standard available yet on "traditional" crypto wallets like MetaMask, Ledger, and others.
## Opportunities
There are interesting use cases that account abstraction enables being pushed by several team. Some places to look for inspiration:
- [Privy](https://docs.privy.io/): Privy allows users to choose from traditional crypto wallets and social logins to create accounts.
- [Safe](https://docs.safe.global/getting-started/readme): Safe allows complex multi-sig setups, simple authentication, and onramping.
- [Pimlico](https://docs.pimlico.io/): Pimlico tracks several products around account abstraction and it is worthwhile checking out the rapid and new developments in this space.
## Local development
### Contract addresses and links
- wBTC contract address: `0x2868d708e442A6a940670d26100036d426F1e16b`
- Entry point contract address: `0x8b57d6ec08e09078Db50F265729440713E024C6a`
- wBTC paymaster address: `0x777FA19ea9e771018678161ABf2f1E2879D3cA6C`
- Bundler (eth-infinitism): `https://bundler-sepolia.gobob.xyz/rpc`
### Installing the project
1. Install [pnpm](https://pnpm.io/installation)
2. Run `pnpm install`
### Starting the project
1. Run `pnpm run dev`
2. Open `localhost:5173` in browser.
## Using account abstraction client
To allow easy integration of ERC-4337 into dApps, a simple account abstraction client is included in this repository. This client handles smart account creation and bundler connection, manages user operations and allows paymaster usage. This repository also includes a React hook and context provider which enable straightforward usage of the client in the React application.
To use `AaClient` in your app wrap it in the `AccountAbstractionProvider`:
```typescript
```
Now you can use the `useAccountAbstraction` hook anywhere within the app to get the client and utilize its functionality:
```typescript
const { client } = useAccountAbstraction();
...
const userOp = await client.createUserOp({
address: contract.address,
callData,
value: 0,
nonce: approvalUserOpNonce
});
const transferResult = await client.signAndSendUserOp(userOp);
```
To view the example of a full account abstraction flow please navigate to the `src/App.tsx` component.
---
## Pay Fees with BTC
## wBTC, tBTC, and other ERC-20 as Gas Token
On Ethereum rollups, gas fees need to be paid in ETH as the base currency. While a rollup can in theory choose to use their gas token, part of the gas fees on the rollup are used on Ethereum to pay for data availability.
In many cases, it is desirable to pay gas fees in other tokens. In particular, on BOB, we want to allow users to pay gas fees in bridged BTC to create a seamless experience for Bitcoin users.
There are two approaches to how gas fees can be paid in bridged BTC (or any other ERC-20 token like USDT or USDC) that can be implemented directly on the rollup without changing the rollup client:
- [Meta Transactions (ERC-2771)](meta-transactions): Let someone else submit a transaction on your behalf.
- [Account Abstraction (ERC-4337)](account-abstraction): Use a smart contract wallet with a paymaster to pay gas fees.
BOB supports both approaches and leaves it up to projects to decide which approach they want to use.
## Meta Transactions vs. Account Abstraction
Both approaches have their pros and cons. The following table briefly summarizes the differences between the two approaches but we recommend reading the individual pages for more details:
| | Meta Transactions | Account Abstraction |
| ---------------------- | ---------------------------------------- | -------------------------------------------------------------------------- |
| Smart contract changes | Requires changes to smart contracts. | No changes to smart contracts needed. |
| UX changes | Uses standard crypto-wallet UX approach. | New UX approach is needed to distinguish between signer and smart account. |
| Wallets compatibility | Compatible with standard EOA wallets. | Requires new smart contract wallets. |
| Production readiness | OpenGSN v3 is in beta. | New standard that is currently getting adopted. |
---
## Meta Transactions (ERC-2771)
In this example, we will show how wBTC can be used for gas fee payments using the OpenGSN and [ERC-2771 standard](https://eips.ethereum.org/EIPS/eip-2771) on BOB Sepolia (Testnet). This enables users to transact without the necessity to own ETH.
:::tip Live Demo
Check out the live demo at [demo-meta-transactions.gobob.xyz](https://demo-meta-transactions.gobob.xyz).
:::
:::info Example Code
Check out the code of the demo in [this repository](https://github.com/bob-collective/demo-meta-transactions-transfer/).
:::
## OpenGSN
[OpenGSN](https://opengsn.org/), or the Ethereum Gas Station Network, is a decentralized solution abstracting gas fee payments away from users. OpenGSN enables gasless transactions, allowing users to interact with smart contracts without needing ETH. It provides use cases such as privacy-focused transactions, payments in ERC-20 tokens, off-chain payments, and onboarding subsidies. Learn more in [OpenGSN docs](https://docs.opengsn.org/).
### Smart contract changes
To enable OpenGSN functionality in smart contracts, developers need to make specific modifications. The smart contracts must inherit from the `ERC2771Recipient` contract. It's crucial to note that, when working with GSN recipient contracts, developers must refrain from using `msg.sender` directly. Instead, they should utilize `_msgSender()`, a function provided by `ERC2771Recipient`. This ensures accurate retrieval of user addresses during transactions and facilitates seamless integration with the Gas Station Network.
[Read the full smart contract modification instructions here.](https://docs.opengsn.org/contracts/#writing-gsn-capable-contracts)
## Using the dApp
This application contains a simple form that allows you to transfer wBTC between accounts with the gas fee paid in wBTC. Simply enter the wBTC amount and the recipient's EVM address and the transaction will be sent to the Open Gas Network relay and relayed using the wBTC paymaster.
:::note
Before the first relayed transaction is done, the paymaster smart contract has to be approved to spend your wBTC. That is why there will be a transaction request before the first relayed transfer transaction.
:::
### Try it out
#### Connecting MetaMask and funding your account
1. Go to [demo-meta-transactions.gobob.xyz](https://demo-meta-transactions.gobob.xyz)
2. Fund your account with Sepolia ETH from the [Sepolia testnet faucet](https://faucetlink.to/sepolia).
3. Transfer Sepolia ETH to BOB using [our Bridge](https://app.gobob.xyz/).
4. Connect with your MetaMask account and get wBTC by clicking on the 'Get Tokens' button in the application header. (You will receive 30,000 wBTC that you can spend.)
5. Add wBTC to your MetaMask, wBTC address is `0x2868d708e442A6a940670d26100036d426F1e16b`
#### Making a transfer
1. Input the amount you wish to send and the recipient's address into the form fields.
2. Click on 'Approve & Transfer' to approve the paymaster to spend your wBTC and to sign the relayed transaction.
3. Wait for the transfer transaction to be relayed.
## Local development
### Contract addresses and links
- WBTC contract address: `0x2868d708e442A6a940670d26100036d426F1e16b`
- Paymaster contract address: `0x25Aa86d188E37A47dd2011535534E53Cf994559d`
- OpenGSN relayer: `https://gsn-relay-sepolia.gobob.xyz/`
### Installing the project
1. Install [pnpm](https://pnpm.io/installation)
2. Run `pnpm install`
### Starting the project
1. Run `pnpm run dev`
2. Open `localhost:5173` in browser.
## Interacting with OpenGSN relay
To allow simple interaction with the relay `ethers.Contract` instance is created using OpenGSN provider:
```typescript
const getRelayedContract = async (contractType: ContractType) => {
if (!window.ethereum) {
throw new Error("Injected provider not found!");
}
const { address, abi } = contracts[contractType];
const config = {
preferredRelays: ["https://gsn-relay-sepolia.gobob.xyz/"],
performDryRunViewRelayCall: false,
gasPriceSlackPercent: 1000,
maxPaymasterDataLength: 100,
paymasterAddress: erc20PaymasterAddress,
};
const gsnProvider = await RelayProvider.newProvider({
provider: window.ethereum,
config,
overrideDependencies: { asyncPaymasterData: getErc20PaymasterData },
}).init();
const ethersProvider = new providers.Web3Provider(gsnProvider);
const relayedContract = new Contract(
address,
abi,
ethersProvider.getSigner(),
);
return relayedContract;
};
```
Then the `Contract` instance can be used in a standard way:
```typescript
const transferTx = await relayedContract.transfer(
form.address,
atomicAmount.toString(),
);
await transferTx.wait();
```
---
## Hello Bitcoin
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
# Hello Bitcoin
This guide provides step-by-step instructions on how to deploy a smart contract on BOB that interacts with Bitcoin.
BOB is EVM-based and we recommend using the [Solidity](https://docs.soliditylang.org/en/v0.8.24/) language to write your smart contracts. The base currency on BOB is ETH. Since BOB is a rollup on Ethereum, you can bridge over ETH from Ethereum to pay for transactions.
:::tip
If you are new to Solidity, we recommend checking out the [Solidity getting started guide](https://docs.soliditylang.org/en/v0.8.24/introduction-to-smart-contracts.html#subcurrency-example) to get a better understanding of the language.
:::
Developing Solidity contracts is made a lot easier using a development toolchain. Two of the most popular ones are [Remix](https://remix.ethereum.org/) and [Foundry](https://book.getfoundry.sh/). We will use these tools to develop and deploy our smart contract.
We will provide instructions for using Remix and Foundry.
- [Remix](https://remix.ethereum.org/) is a web-based IDE for writing smart contracts. This is a great option if you do not want to install any software on your computer.
- [Foundry](https://book.getfoundry.sh/) is a Rust-based development environment for writing smart contracts. This is a great option if you want to use a local development environment.
Solidity and a toolchain are sufficient to get you started deploying contracts on BOB. However, since BOB's purpose is to make it easy to interact with Bitcoin, we will also add parts of the BOB SDK as part of the starter kit.
- [BOB Starter Kit](https://github.com/bob-collective/bob-starter-kit): The kit serves as a quick start way to develop on BOB using the BOB SDK. Note: you can deploy any EVM contract on BOB without having to use the BOB SDK contracts. They are primarily a helper when you want to interact with Bitcoin from your smart contracts.
## HelloBitcoin Contract
### Overview of the contract
- The contract allows swapping between BTC->USDT and Ordinal->USDT using the BTC relay on testnet without requiring the BTC or ordinals to be bridged to BOB.
- The contract integrates the [BTC relay](https://github.com/bob-collective/bob/blob/master/contracts/src/relay/LightRelay.sol) to enable trustless communication between the Bitcoin blockchain and BOB Sepolia (Testnet).
### Objectives
- **Set up a development environment**: Learn how to set up a development environment for your BOB smart contract development.
- **Create a Smart Contract for BOB**: We will use [HelloBitcoin smart contract](https://github.com/bob-collective/StarterKit/blob/main/src/HelloBitcoin.sol) present in the developer kit.
- **Compile a Smart Contract for BOB**: Compile your HelloBitcoin smart contract using the development environment.
- **Deploy a Smart Contract to BOB**: Deploy your compiled smart contract to BOB Sepolia (Testnet).
- **Interact with a Smart Contract Deployed on BOB**: Learn how to interact with the smart contract you've deployed on BOB Sepolia (Testnet).
### Prerequisites
We start with installing the prerequisites for the development environment.
- Get Sepolia ETH and bridge them to BOB. Use the links on the [Networks Guide](/docs/user-hub/networks) page.
- Setup either Remix or Foundry as your development environment. If you want to get started without having to install software, use Remix. If you are planning to develop more complex contracts, use Foundry.
Follow the steps from the [foundry book](https://book.getfoundry.sh/getting-started/installation) to install the Foundry toolsuite, which contains the `forge`, `cast`, `anvil` and `chisel` tools.
Open the [Remix IDE](https://remix.ethereum.org/) in your browser.
### Creating the HelloBitcoin Contract
Clone the starter toolkit provided.
```shell
git clone https://github.com/bob-collective/bob-starter-kit.git
cd bob-starter-kit
```
The `HelloBitcoin` contract should already be present inside the src directory.
Checkout the contract by opening it in your favorite editor or IDE.
:::tip
If you are using [VSCode](https://code.visualstudio.com/), use the [Solidity plugin](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) to get syntax highlighting and other features.
:::
:::tip
It's not required to create a new contract, but if you want to create a new contract, you can do so by creating a new file in the `src` directory.
```shell
touch src/.sol
```
:::
Create a new project with Remix. Under `contracts` folder create a new file `HelloBitcoin.sol`.
Add the following remappings in `compiler_config.json` under `settings`
```json
{
"language": "Solidity",
"settings": {
"optimizer": {
"enabled": true,
"runs": 200
},
"outputSelection": {
"*": {
"": ["ast"],
"*": [
"abi",
"metadata",
"devdoc",
"userdoc",
"storageLayout",
"evm.legacyAssembly",
"evm.bytecode",
"evm.deployedBytecode",
"evm.methodIdentifiers",
"evm.gasEstimates",
"evm.assembly"
]
}
},
"remappings": [
"@openzeppelin/contracts/=https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.5.0/contracts/",
"@bob-collective/bitcoin-spv/=https://github.com/bob-collective/bitcoin-spv/blob/master/src/",
"@bob-collective/bob/=https://github.com/bob-collective/bob/blob/master/src/"
]
}
}
```
Enter the below code in `HelloBitcoin.sol` file.
To learn more about the Solidity contracts in general [checkout the Solidity tutorial guide](https://docs.soliditylang.org/en/v0.8.21/introduction-to-smart-contracts.html#subcurrency-example).
```solidity
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import {BTCUtils} from "@bob-collective/bitcoin-spv/BTCUtils.sol";
import {BitcoinTx} from "@bob-collective/bob/utils/BitcoinTx.sol";
import {IRelay} from "@bob-collective/bob/relay/IRelay.sol";
import {TestLightRelay} from "@bob-collective/bob/relay/TestLightRelay.sol";
using SafeERC20 for IERC20;
contract HelloBitcoin {
/**
* @dev Mapping to store BTC to USDT (or other ERC20) swap orders based on their unique identifiers.
* Each order is associated with a unique ID, and the order details are stored in the BtcSellOrder struct.
*/
mapping(uint256 => BtcSellOrder) public btcSellOrders;
/**
* @dev Mapping to store ordinal sell orders for swapping BTC to USDT (or other ERC20) based on their unique identifiers.
* Each ordinal sell order is associated with a unique ID, and the order details are stored in the OrdinalSellOrder struct.
*/
mapping(uint256 => OrdinalSellOrder) public ordinalSellOrders;
/**
* @dev The address of the ERC-20 contract. You can use this variable for any ERC-20 token,
* not just USDT (Tether). Make sure to set this to the appropriate ERC-20 contract address.
*/
IERC20 public usdtContractAddress;
/**
* @dev Counter for generating unique identifiers for BTC to USDT swap orders.
* The `nextBtcOrderId` is incremented each time a new BTC to USDT swap order is created,
* ensuring that each order has a unique identifier.
*/
uint256 nextBtcOrderId;
/**
* @dev Counter for generating unique identifiers for ordinal sell orders.
* The `nextOrdinalOrderId` is incremented each time a new ordinal sell order is created,
* ensuring that each ordinal order has a unique identifier.
*/
uint256 nextOrdinalOrderId;
/**
* @dev Struct representing a BTC to USDT swap order.
*/
struct BtcSellOrder {
uint256 sellAmountBtc; // Amount of BTC to be sold in the order.
uint256 buyAmount; // Amount of USDT (or other ERC20) to be bought in the order.
address btcSeller; // Address of the seller initiating the order.
BitcoinAddress btcBuyer; // Bitcoin address of the buyer (initialized with an empty scriptPubKey).
bool isOrderAccepted; // Flag indicating whether the order has been accepted.
}
/**
* @dev Struct representing an ordinal sell order for swapping Ordinal to USDT.
*/
struct OrdinalSellOrder {
OrdinalId ordinalID; // Unique identifier for the ordinal sell order.
uint256 buyAmount; // Amount of USDT (or other ERC20) to be bought in the order.
BitcoinTx.UTXO utxo; // UTXO associated with the BTC to USDT swap order.
address ordinalSeller; // Address of the seller initiating the ordinal order.
BitcoinAddress ordinalBuyer; // Bitcoin address of the buyer (initialized with an empty scriptPubKey).
bool isOrderAccepted; // Flag indicating whether the ordinal order has been accepted.
}
/**
* @dev Struct representing a unique identifier for an ordinal sell order.
*/
struct OrdinalId {
bytes32 txId; // Transaction ID associated with the ordinal order.
uint32 index; // Index associated with the ordinal order.
}
/**
* @dev Struct representing a Bitcoin address with a scriptPubKey.
*/
struct BitcoinAddress {
bytes scriptPubKey; // Script public key associated with the Bitcoin address.
}
event btcSellOrderSuccessfullyPlaced(uint256 indexed orderId, uint256 sellAmountBtc, uint256 buyAmount);
event btcSellOrderBtcSellOrderAccepted(uint256 indexed id, BitcoinAddress bitcoinAddress);
event btcSuccessfullySendtoDestination(uint256 id);
event ordinalSellOrderSuccessfullyPlaced(uint256 indexed id, OrdinalId ordinalID, uint256 buyAmount);
event ordinalSellOrderBtcSellOrderAccepted(uint256 indexed id, BitcoinAddress bitcoinAddress);
event ordinalSuccessfullySendtoDestination(uint256 id);
IRelay internal relay;
TestLightRelay internal testLightRelay;
/**
* @dev Constructor to initialize the contract with the relay and ERC20 token address.
* @param _relay The relay contract implementing the IRelay interface.
* @param _usdtContractAddress The address of the USDT contract.
*
* Additional functionalities of the relay can be found in the documentation available at:
* https://docs.gobob.xyz/docs/contracts/src/src/relay/LightRelay.sol/contract.LightRelay
*/
constructor(IRelay _relay, address _usdtContractAddress) {
relay = _relay;
testLightRelay = TestLightRelay(address(relay));
usdtContractAddress = IERC20(_usdtContractAddress);
}
/**
* @dev Set the relay contract for the bridge.
* @param _relay The relay contract implementing the IRelay interface.
*/
function setRelay(IRelay _relay) internal {
relay = _relay;
}
/**
* @notice Places a BTC sell order in the contract.
* @dev Emits a `btcSellOrderSuccessfullyPlaced` event upon successful placement.
* @param sellAmountBtc The amount of BTC to sell.
* @param buyAmount The corresponding amount to be received in exchange for the BTC.
* @dev Requirements:
* - `sellAmountBtc` must be greater than 0.
* - `buyAmount` must be greater than 0.
*/
function placeBtcSellOrder(uint256 sellAmountBtc, uint256 buyAmount) public {
require(sellAmountBtc > 0, "Sell amount must be greater than 0");
require(buyAmount > 0, "Buy amount must be greater than 0");
uint256 id = nextBtcOrderId++;
btcSellOrders[id] = BtcSellOrder({
sellAmountBtc: sellAmountBtc,
buyAmount: buyAmount,
btcSeller: msg.sender,
btcBuyer: BitcoinAddress({scriptPubKey: new bytes(0)}),
isOrderAccepted: false
});
emit btcSellOrderSuccessfullyPlaced(id, sellAmountBtc, buyAmount);
}
/**
* @notice Accepts a BTC sell order, providing the Bitcoin address for the buyer.
* @dev Transfers the corresponding currency from the buyer to the contract and updates the order details.
* @param id The unique identifier of the BTC sell order.
* @param bitcoinAddress The Bitcoin address of the buyer to receive the BTC.
* @dev Requirements:
* - The specified order must not have been accepted previously.
* - The buyer must transfer the required currency amount to the contract.
* @dev Emits a `btcSellOrderBtcSellOrderAccepted` event upon successful acceptance.
*/
function acceptBtcSellOrder(uint256 id, BitcoinAddress calldata bitcoinAddress) public {
BtcSellOrder storage placedOrder = btcSellOrders[id];
require(placedOrder.isOrderAccepted == false, "Order has already been accepted");
// "lock" selling token by transferring to contract
IERC20(usdtContractAddress).safeTransferFrom(msg.sender, address(this), placedOrder.buyAmount);
placedOrder.btcBuyer = bitcoinAddress;
placedOrder.isOrderAccepted = true;
emit btcSellOrderBtcSellOrderAccepted(id, bitcoinAddress);
}
/**
* @notice Completes a BTC sell order by validating and processing the provided Bitcoin transaction proof.
* @dev This function is intended to be called by the original seller.
* @param id The unique identifier of the BTC sell order.
* @param transaction Information about the Bitcoin transaction.
* @param proof Proof associated with the Bitcoin transaction.
* @dev Requirements:
* - The specified order must have been previously accepted.
* - The caller must be the original seller of the BTC.
* - The Bitcoin transaction proof must be valid.
* - The BTC transaction output must match the expected amount and recipient.
* @dev Effects:
* - Sets the relay difficulty based on the Bitcoin headers in the proof.
* - Transfers the locked USDT amount to the original seller.
* - Removes the order from the mapping after successful processing.
* @dev Emits a `btcSuccessfullySendtoDestination` event upon successful completion.
*/
function completeBtcSellOrder(uint256 id, BitcoinTx.Info calldata transaction, BitcoinTx.Proof calldata proof)
public
{
// Retrieve the accepted order based on the provided ID
BtcSellOrder storage acceptedOrder = btcSellOrders[id];
// Ensure that the order has been accepted and the caller is the original seller
require(acceptedOrder.isOrderAccepted == true, "Order must be accepted");
require(acceptedOrder.btcSeller == msg.sender, "Only the original seller can provide proof");
// Set the difficulty of the relay based on the Bitcoin headers in the proof
testLightRelay.setDifficultyFromHeaders(proof.bitcoinHeaders);
// Validate the BTC transaction proof using the relay, in production a higher than 1 block confirmation should be used
BitcoinTx.validateProof(relay, 1, transaction, proof);
// Check if the BTC transaction output matches the expected amount and recipient
_checkBitcoinTxOutput(acceptedOrder.sellAmountBtc, acceptedOrder.btcBuyer, transaction);
// Transfer the locked USDT to the original seller
IERC20(usdtContractAddress).safeTransfer(acceptedOrder.btcSeller, acceptedOrder.buyAmount);
// Remove the order from the mapping since it has been successfully processed
delete btcSellOrders[id];
// Emit an event indicating the successful completion of the BTC to USDT swap
emit btcSuccessfullySendtoDestination(id);
}
/**
* @notice Places an ordinal sell order in the contract.
* @dev Emits an `ordinalSellOrderSuccessfullyPlaced` event upon successful placement.
* @param ordinalID The unique identifier for the ordinal.
* @param utxo Information about the Bitcoin UTXO associated with the ordinal.
* @param buyAmount The amount to be received in exchange for the ordinal.
* @dev Requirements:
* - `buyAmount` must be greater than 0.
* @dev Effects:
* - Creates a new ordinal sell order with the provided details.
*/
function placeOrdinalSellOrder(OrdinalId calldata ordinalID, BitcoinTx.UTXO calldata utxo, uint256 buyAmount)
public
{
require(buyAmount > 0, "Buying amount should be greater than 0");
uint256 id = nextOrdinalOrderId++;
ordinalSellOrders[id] = OrdinalSellOrder({
ordinalID: ordinalID,
buyAmount: buyAmount,
utxo: utxo,
ordinalSeller: msg.sender,
isOrderAccepted: false,
ordinalBuyer: BitcoinAddress({scriptPubKey: new bytes(0)})
});
emit ordinalSellOrderSuccessfullyPlaced(id, ordinalID, buyAmount);
}
/**
* @notice Accepts an ordinal sell order, providing the Bitcoin address for the buyer.
* @dev Transfers the corresponding currency from the buyer to the contract and updates the order details.
* @param id The unique identifier of the ordinal sell order.
* @param bitcoinAddress The Bitcoin address of the buyer to receive the ordinal.
* @dev Requirements:
* - The specified order must not have been accepted previously.
* - The buyer must transfer the required currency amount to this contract.
* @dev Effects:
* - "Locks" the selling token by transferring it to the contract.
* - Updates the ordinal sell order with the buyer's Bitcoin address and marks the order as accepted.
* @dev Emits an `ordinalSellOrderBtcSellOrderAccepted` event upon successful acceptance.
*/
function acceptOrdinalSellOrder(uint256 id, BitcoinAddress calldata bitcoinAddress) public {
OrdinalSellOrder storage placedOrder = ordinalSellOrders[id];
require(placedOrder.isOrderAccepted == false, "Order already accepted");
// "lock" sell token by transferring to contract
IERC20(usdtContractAddress).safeTransferFrom(msg.sender, address(this), placedOrder.buyAmount);
placedOrder.ordinalBuyer = bitcoinAddress;
placedOrder.isOrderAccepted = true;
emit ordinalSellOrderBtcSellOrderAccepted(id, bitcoinAddress);
}
/**
* @notice Completes an ordinal sell order by validating and processing the provided Bitcoin transaction proof.
* @dev This function is intended to be called by the original seller.
* @param id The unique identifier of the ordinal sell order.
* @param transaction Information about the Bitcoin transaction.
* @param proof Proof associated with the Bitcoin transaction.
* @dev Requirements:
* - The specified order must have been previously accepted.
* - The caller must be the original seller of the ordinal.
* - The Bitcoin transaction proof must be valid.
* - The BTC transaction input must spend the specified UTXO associated with the ordinal sell order.
* - The BTC transaction output must be to the buyer's address.
* @dev Effects:
* - Sets the relay difficulty based on the Bitcoin headers in the proof.
* - Validates the BTC transaction proof using the relay.
* - Ensures that the BTC transaction input spends the specified UTXO.
* - Checks the BTC transaction output to the buyer's address.
* - Transfers the locked USDT amount to the original seller.
* - Removes the ordinal sell order from storage after successful processing.
* @dev Emits an `ordinalSuccessfullySendtoDestination` event upon successful completion.
*/
function completeOrdinalSellOrder(uint256 id, BitcoinTx.Info calldata transaction, BitcoinTx.Proof calldata proof)
public
{
OrdinalSellOrder storage acceptedOrder = ordinalSellOrders[id];
// Ensure that the order has been accepted and the caller is the original seller
require(acceptedOrder.isOrderAccepted == true, "Order must be accepted");
require(acceptedOrder.ordinalSeller == msg.sender, "Only the original seller can provide proof");
// Set the relay difficulty based on the Bitcoin headers in the proof
testLightRelay.setDifficultyFromHeaders(proof.bitcoinHeaders);
// Validate the BTC transaction proof using the relay, in production a higher than 1 block confirmation should be used
BitcoinTx.validateProof(relay, 1, transaction, proof);
// Ensure that the BTC transaction input spends the specified UTXO associated with the ordinal sell order
BitcoinTx.ensureTxInputSpendsUtxo(transaction.inputVector, acceptedOrder.utxo);
// Check if the BTC transaction output is to the buyer's address
_checkBitcoinTxOutput(0, acceptedOrder.ordinalBuyer, transaction);
// ToDo: Check that the correct satoshis are being spent to the buyer's address if needed
// Transfer the locked USDT to the original seller
IERC20(usdtContractAddress).safeTransfer(acceptedOrder.ordinalSeller, acceptedOrder.buyAmount);
// Remove the ordinal sell order from storage as it has been successfully processed
delete ordinalSellOrders[id];
// Emit an event to indicate the successful completion of the ordinal sell order
emit ordinalSuccessfullySendtoDestination(id);
}
/**
* Checks output script pubkey (recipient address) and amount.
* Reverts if transaction amount is lower or bitcoin address is not found.
*
* @param expectedBtcAmount BTC amount requested in order.
* @param bitcoinAddress Recipient's bitcoin address.
* @param transaction Transaction fulfilling the order.
*/
//ToDo: Should we move this into the library.
function _checkBitcoinTxOutput(
uint256 expectedBtcAmount,
BitcoinAddress storage bitcoinAddress,
BitcoinTx.Info calldata transaction
) private view {
// Prefixes scriptpubkey with its size to match script output data.
bytes32 scriptPubKeyHash =
keccak256(abi.encodePacked(uint8(bitcoinAddress.scriptPubKey.length), bitcoinAddress.scriptPubKey));
uint256 txOutputValue = BitcoinTx
.processTxOutputs(transaction.outputVector, scriptPubKeyHash)
.value;
require(txOutputValue >= expectedBtcAmount, "Bitcoin transaction amount is lower than in accepted order.");
}
}
```
Also create a `TestLightRelay.sol` file for deploying your own bitcoin relay.
```solidity
pragma solidity 0.8.17;
import {BTCUtils} from "@bob-collective/bitcoin-spv/BTCUtils.sol";
import "@bob-collective/bob/relay/LightRelay.sol";
/**
* @title HelloBitcoin
* @dev contract allows swapping between BTC->USDT and Ordinal->USDT using the BTC relay on testnet.
* @custom:dev-run-script ./scripts/deploy_relay.ts
*/
contract TestLightRelay is LightRelay {
using BTCUtils for bytes;
using BTCUtils for uint256;
/// @notice Sets the current and previous difficulty based on the difficulty
/// inferred from the provided Bitcoin headers.
function setDifficultyFromHeaders(bytes memory bitcoinHeaders) external {
uint256 firstHeaderDiff = bitcoinHeaders.extractTarget().calculateDifficulty();
currentEpochDifficulty = firstHeaderDiff;
prevEpochDifficulty = firstHeaderDiff;
}
}
```
### Compile the Contract
To compile the contract run the following command:
```shell
forge build
```
In `Advanced Configurations` section of Solidity Compiler switch from `Compiler configuration` to `Use configuration file`.
To compile the contract, go to the `Solidity Compiler` section of the IDE, select and compile the `HelloBitcoin` smart contract.
You can also directly compile the `HelloBitcoin` smart contract by right-clicking on the `HelloBitcoin.sol` file and select compile.
In the same way `TestLightRelay.sol` contract should also be compiled.
### Deploy the HelloBitcoin Contract
To deploy the contract via the terminal, you'll need your private key. We recommend generating a separate key for development purposes.
:::tip
If you are using MetaMask, use this [guide](https://support.metamask.io/hc/en-us/articles/360015289632-How-to-export-an-account-s-private-key) to export your private key.
:::
To deploy the compiled smart contract on testnet we will use the `HelloBitcoin` script present under `scripts/HelloBitcoin.sol`:
```shell
export PRIVATE_KEY=0x
export USDT_ADDRESS=0xF58de5056b7057D74f957e75bFfe865F571c3fB6
export RPC_URL=https://testnet.rpc.gobob.xyz
export VERIFIER_URL=https://testnet-explorer.gobob.xyz/api?
forge script script/HelloBitcoin.sol --rpc-url=$RPC_URL --broadcast \
--verify --verifier blockscout --verifier-url=$VERIFIER_URL \
--priority-gas-price 1
```
The output in the terminal should look similar to this:
```shell
Script ran successfully.
...
✅ [Success]Hash: 0x7a1653e0a0673bd363c28ebd610eb643b29408087f29bf1565df81ded78d2f8b
Contract Address: 0x14F932d0184d4595A3d152ec13F64A36393701B7
Block: 4325242
Paid: 0.00551169309186155 ETH (1837231 gas * 3.00000005 gwei)
✅ [Success]Hash: 0x1d8edfa2be54524804a69507cc967adbdc34716404c43b0d27b9b2375aaf221c
Contract Address: 0x141eE0F02Df17bE850032D578CC4b3BF7d1c7f4F
Block: 4325242
Paid: 0.0082765501379425 ETH (2758850 gas * 3.00000005 gwei)
```
To deploy the compiled HelloBitcoin smart contract first open the MetaMask extension and make sure the wallet is connected to the BOB network.
Choose the Remix `ENVIRONMENT` and `Injected Provider - MetaMask`. Remix will deploy contract to connected network, i.e., BOB.
Select contract as `TestLightRelay`. Click `Deploy` and sign the transaction pop up message.
Copy the `TestLightRelay` contract address from the terminal this will be used as a constructor argument for `HelloBitcoin` contract.
Select contract as `HelloBitcoin`.
Add the `_RELAY` ie `TestLightRelay` address copied above.
Add the `_USDTCONTRACTADDRESS` address as `0xF58de5056b7057D74f957e75bFfe865F571c3fB6`.
:::tip
If you want, you can also modify the contract at a later stage and use [other ERC20 contracts already deployed on BOB Sepolia (Testnet)](/docs/reference/contracts)
:::
Click `Deploy` and sign the transaction pop up message.
The contract details will be displayed in the Remix terminal.
### Interact with the HelloBitcoin Contract
Checkout the [testnet explorer](https://testnet-explorer.gobob.xyz/) to get contract details using the transaction hash from the previous step.
Get the [ABI](https://docs.soliditylang.org/en/latest/abi-spec.html) of HelloBitcoin contract:
```shell
forge build --silent && jq '.abi' ./out/HelloBitcoin.sol/HelloBitcoin.json > hello_bitcoin_contract_abi.json
```
Get the [ABI](https://docs.soliditylang.org/en/latest/abi-spec.html) of Coin contract from remix IDE under `Solidity Compiler` section:
### Congratulations! You are done!
Congratulations! You have successfully deployed your first smart contract on BOB.
### Extra: Publish and verify the HelloBitcoin Contract
The deployment script provided above already handles contract verification.
You can find the contract source code in the "Code" tab, along with new "Read Contract" and "Write Contract" sub-tabs. You are now ready to interact with the contract directly on the explorer.
At this point, your smart contract is ready to be used, but we can go a step further to verify and publish the smart contract in the explorer. By doing this you will be able to interact with any existing read or write calls in the contract right on the explorer. To do so follow these steps:
1. Go to the Remix IDE. Check if the contract imports other contracts. If it does, check step 2. If it doesn't, simply copy the contract code into your clipboard and jump to step 3.
2. In case your contract imports other contract, you need to flatten your contract. To do that you just need right click your contract file in Remix IDE file explorer and copy the flattened code into your clipboard.
3. Head over to the [testnet explorer](https://testnet-explorer.gobob.xyz/) and search for your published contract page.
4. Click on the "Contract" tab and click on "Verify & Publish" button.
5. Click on the "Code" tab and click on "Verify & Publish" button.
6. Now you should be presented we a set of possibilities for verifying you published contract, but we will proceed with "Via flattened source code".
7. Fill the form with the specific information about the contract and how it was deployed. Make sure every field is correctly populated before submitting. Any incorrect field will lead to a failed verification. After submitting, the verification might take a couple of minutes.
8. Once submitted correctly, the contract source code should be visible in the "Code" tab, alongside with new "Read Contract" and "Write Contract". You are now ready to interact with the contract right on the explorer.
## Next Steps
BOB is built to make it easy to interact with Bitcoin.
### Join the Community
Join the [Telegram](https://t.me/+CyIcLW2nfaFlNDc1) to connect with the community and ask questions.
## References
- [HelloBitcoin contract code](https://github.com/bob-collective/StarterKit/blob/main/src/HelloBitcoin.sol)
- [Remix](https://remix.ethereum.org/)
- [Foundry](https://book.getfoundry.sh/)
---
## Local Development
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
# Local Development
## EVM and Bitcoin
### EVM Setup
If you are developing on the BOB network, you need to install a wallet and a development environment.
#### Install a wallet
- [Metamask](https://metamask.io/)
You can also use other EVM wallets. BOB has a special Snap though so that you can use MetaMask for both the BOB chain and Bitcoin.
#### Install a development environment
Quickstart:
```shell
# Install foundry
curl -L https://foundry.paradigm.xyz | bash
# Init a new project
forge init hello_bob
cd hello_bob
# Build the project
forge build
# Start a local chain
anvil
```
Check the docs for more information: [Foundry](https://book.getfoundry.sh/getting-started/installation).
Quickstart:
```shell
# Install hardhat
yarn add --dev hardhat
# Init a new project
npx hardhat init
```
Check the docs for more information: [Hardhat](https://hardhat.org/getting-started/).
### Bitcoin
#### Install
Install Bitcoin Core `25.0` or higher so that you have access to the `bitcoind` and `bitcoin-cli` commands:
- MacOS: `brew install bitcoin`
- Ubuntu: `sudo add-apt-repository ppa:bitcoin/bitcoin && sudo apt-get update && sudo apt-get install bitcoind`
- Arch: `yay bitcoin-core`
- Download a binary: https://bitcoin.org/en/download
#### Start Bitcoin Core
```shell
# Start a regtest node
bitcoind -regtest
# Create a wallet named Alice
bitcoin-cli -regtest createwallet alice
# Get a new address for Alice
ADDRESS=$(bitcoin-cli -regtest -rpcwallet=alice getnewaddress)
# Mine 101 blocks to the address
bitcoin-cli -regtest -rpcwallet=alice generatetoaddress 101 $ADDRESS
```
#### Wallet
You can use `bitcoin-cli` to manage the wallet. However, if you prefer a UI, you can use Bitcoin QT.
Start Bitcoin QT (for wallet functionality):
```shell
bitcoin-qt -regtest
```
## RPCs and APIs
### Esplora
Very useful for Bitcoin blockchain indexing and querying.
- Fork of electrs (Electrum Server in Rust)
- Indexes data using Bitcoin Core
- Provides REST API
The good:
- Can be run locally
API documentation: [Esplora](https://github.com/Blockstream/esplora/blob/master/API.md)
Quickstart:
```shell
git clone https://github.com/Blockstream/esplora && cd esplora
npm install
export API_URL=http://localhost:3000/ # or https://blockstream.info/api/ if you don't have a local API server
(see more config options below)
npm run dev-server
```
### Ord
If you are working with ordinals on a deeper level or in a local environment with Bitcoin regtest, this is a useful tool.
- Indexer, block-explorer and wallet
- Uses Bitcoin Core for signing and indexing
- Provides JSON-API
The good:
- Shows ordinals and inscriptions
- Can be run locally
The bad:
- Slow to index mainnet
Get started: https://docs.ordinals.com/
### UniSat
If you are working with ordinals or BRC20 tokens on Bitcoin testnet or mainnet, the hosted service is easier to use than using `ord`.
- Hosted service
- Provides REST API
The good:
- BRC20 indexing
- Swagger supports code-gen
- Additional APIs (inscription, swap, marketplace)
The bad:
- Only mainnet and testnet (hosted)
Get started: https://docs.unisat.io/dev/unisat-developer-service
## More Tools
### BOB SDK
- [Wallets](https://docs.gobob.xyz/gateway): Learn how to connect your app with Bitcoin wallets like UniSat, Leather, Xverse, and MetaMask.
- [Bitcoin Light Client](/docs/bob-chain/relay): Learn how to interact with Bitcoin by proving transaction inclusion on BOB.
- [Use tBTC, wBTC, or other ERC20 Tokens as Fee Tokens on BOB](/docs/deprecated/bridged-btc-gas-fee/): Learn how to use tBTC and wBTC as fee tokens on BOB.
### Collection of Bitcoin Tools
[Lopp Development Tool List](https://www.lopp.net/bitcoin-information/developer-tools.html)
---
## BOB Bitcoin MetaMask Snap
MetaMask Snaps allow us to add features and functionality to the standard MetaMask wallet.
The BOB Bitcoin Snap is a MetaMask Snap that allows you to use MetaMask to interact with Bitcoin on the BOB network.
## Features
Use MetaMask to:
- Send Bitcoin
- Receive Bitcoin
- Cache the extended public key
- Sign Bitcoin transactions
- Inscribe Ordinals (text and images) including BRC20s
- Send inscriptions (including BRC20s)
:::tip
Take a look at the [BTC Snap source code](https://github.com/bob-collective/btcsnap), which includes a demo React app you can try out locally.
:::
## Usage
### Connecting to the BOB BTC Snap
:::tip
To see how to connect to the BOB BTC Snap and call the available methods, take a look at the [utils.ts](https://github.com/bob-collective/demo-unified-assets-tracker/blob/1475ef915518d45103cd4581c3901ede216a6197/ui/src/utils/btcsnap.ts) file.
:::
```typescript
import { MetaMaskInpageProvider } from "@metamask/providers";
declare global {
interface Window {
ethereum: MetaMaskInpageProvider;
}
}
const { ethereum } = window;
const snapId = "npm:@gobob/btcsnap";
export async function checkConnection(): Promise {
const snaps = await ethereum.request({
method: "wallet_getSnaps",
});
const hasMySnap = Object.keys(snaps || []).includes(snapId);
return hasMySnap;
}
export async function connect(cb: (connected: boolean) => void) {
let connected = false;
try {
const result: any = await ethereum.request({
method: "wallet_requestSnaps",
params: {
[snapId]: {},
},
});
const hasError = !!result?.snaps?.[snapId]?.error;
connected = !hasError;
} finally {
cb(connected);
}
}
```
### Getting the extended public key
```typescript
export enum BitcoinNetwork {
Main = "mainnet",
Test = "testnet",
}
export enum BitcoinScriptType {
P2PKH = "P2PKH",
P2SH_P2WPKH = "P2SH-P2WPKH",
P2WPKH = "P2WPKH",
}
export interface ExtendedPublicKey {
xpub: string;
mfp: string;
}
export async function getExtendedPublicKey(
network: BitcoinNetwork,
scriptType: BitcoinScriptType,
): Promise {
const networkParams = network === BitcoinNetwork.Main ? "main" : "test";
try {
return (await ethereum.request({
method: "wallet_invokeSnap",
params: {
snapId,
request: {
method: "btc_getPublicExtendedKey",
params: {
network: networkParams,
scriptType,
},
},
},
})) as ExtendedPublicKey;
} catch (err: any) {
const error = new SnapError(
err?.message || "Get extended public key failed",
);
console.error(error);
throw error;
}
}
```
### Using the BOB BTC Snap in a React application
:::tip
Take a look at the [UI code in our demo application](https://github.com/bob-collective/demo-unified-assets-tracker/tree/1475ef915518d45103cd4581c3901ede216a6197/ui) to see how this hook can be used.
:::
```typescript
import { useCallback, useEffect, useState } from "react";
import { addressFromExtPubKey } from "../utils/btcsnap-signer";
import {
BitcoinNetwork,
BitcoinScriptType,
checkConnection,
connect,
getExtendedPublicKey,
} from "../utils/btcsnap-utils";
import { useLocalStorage, LocalStorageKey } from "./useLocalStorage";
import { useGetInscriptionIds } from "./useGetInscriptionIds";
import { useQueryClient } from "@tanstack/react-query";
import { BITCOIN_NETWORK } from "../utils/config";
const bitcoinNetwork =
BITCOIN_NETWORK === "mainnet" ? BitcoinNetwork.Main : BitcoinNetwork.Test;
const getDerivedBtcAddress = async () => {
const xpub = await getExtendedPublicKey(
bitcoinNetwork,
BitcoinScriptType.P2WPKH,
);
const bitcoinAddress = addressFromExtPubKey(xpub.xpub, bitcoinNetwork)!;
return {
bitcoinAddress,
};
};
const connectionCheck = async () => {
const isConnected = await checkConnection();
return isConnected;
};
const useBtcSnap = () => {
const [isConnected, setIsConnected] = useState(false);
const queryClient = useQueryClient();
const [bitcoinAddress, setBitcoinAddress, removeBitcoinAddress] =
useLocalStorage(LocalStorageKey.DERIVED_BTC_ADDRESS);
const { refetch } = useGetInscriptionIds(bitcoinAddress);
useEffect(() => {
if (!bitcoinAddress) return;
refetch();
}, [bitcoinAddress, refetch]);
const connectBtcSnap = useCallback(async () => {
connect(async (connected: boolean) => {
if (connected) {
const { bitcoinAddress } = await getDerivedBtcAddress();
setBitcoinAddress(bitcoinAddress);
}
});
// eslint-disable-next-line react-hooks/exhaustive-deps
}, [setBitcoinAddress]);
useEffect(() => {
const checkConnection = async () => {
const connected = await connectionCheck();
// This will reset BTC address if user has disconnected
if (!connected && bitcoinAddress) {
removeBitcoinAddress();
queryClient.removeQueries();
}
setIsConnected(connected);
};
checkConnection();
}, [
bitcoinAddress,
isConnected,
queryClient,
removeBitcoinAddress,
setBitcoinAddress,
]);
return { connectBtcSnap, bitcoinAddress, isConnected };
};
export { useBtcSnap };
```
---
## Give Users Free Transactions
## Sponsor Your Users' Transactions With Safe Gas Station
BOB believes that users deserve next-gen UX, including abstracting away the complexity of transaction fees from users. That's why we're partnered with the [Safe\{Core\} Gas Station Program](https://safe.global/gas-station) to sponsor up to $150,000 of your users' transaction fees.
## Spice Things Up With BOB Fusion
In addition to sponsoring your users' transaction fees, we would like to invite any projects joining the Safe\{Core\} Gas Station Program to be a part of [BOB Fusion](/docs/user-hub/bob-fusion). Check out the [BOB Fusion app](https://app.gobob.xyz/fusion) to see how we engage our community with weekly voting competitions, Spice harvesting bonuses, and links to our ecosystem of projects.
:::tip Join BOB Fusion today!
If free gas fees and Spice points to give your users sounds interesting to you, [contact us](https://forms.gle/EKYmrAhPsyiQ3ua57) to learn more and join the BOB Fusion campaign.
:::
## Resources
- [Apply to the Safe\{Core\} Gas Station Program](https://wn2n6ocviur.typeform.com/gasstationapp)
- [Learn more about Safe Modules and ERC-4337](https://docs.safe.global/advanced/erc-4337/4337-safe)
- [Check out the Safe SDK](https://docs.safe.global/advanced/erc-4337/guides/safe-sdk)
---
## What is BOB?
import styles from "./index.module.css";
# What is BOB?
BOB is building the Bank of Bitcoin, reimagining banking for the Bitcoin age. One platform for everything - swapping, saving, earning & borrowing - all on Bitcoin rails.
By fusing Bitcoin’s unmatched security with Ethereum’s versatility, BOB’s hybrid chain unlocks real utility for the world’s most important asset.
Swap BTC into any asset or deposit directly into DeFi on any chain with a single click, powered by Bitcoin intents. Save, lend and earn securely with new native Bitcoin vaults.
## Get Started in 3 Steps
📚
1. Learn About BOB
Discover how BOB's Hybrid Chain combines Bitcoin security with Ethereum innovation.
What is BOB?
🔗
2. Connect & Bridge
Connect your wallet and bridge assets from Bitcoin or Ethereum to BOB.
Connect Wallet
⚡
3. Make Transaction
Execute your first transaction and start earning yield with your Bitcoin.
First Transaction
## Choose Your Path
👤
Regular User
Bridge assets, stake Bitcoin, and use DeFi apps on BOB. Start earning yield with your BTC today.
User Hub
🔧
Developers & Integrators
Add native BTC integration to your app with our Gateway SDK. Build the future of Bitcoin DeFi.
Gateway SDK
🔐
BitVM Partner
Run BitVM nodes and participate in institutional partnerships. Help secure the Bitcoin network.
BitVM Network
---
## Connect Wallet & Bridge Assets
import AddToWallet from '@site/src/components/AddToWallet';
# Connect Wallet & Bridge Assets
Get started with BOB in just a few minutes by connecting your wallet and bridging your first assets.
## Step 1: Connect Your Wallet
BOB supports all major Ethereum wallets:
- **MetaMask** - Most popular browser wallet
- **WalletConnect** - Mobile wallet support
- **Hardware Wallets** - Ledger, Trezor, etc.
See our [Wallet Guide](/docs/user-hub/wallet-guide/) for detailed information.
## Step 2: Connect to BOB Network
1. Click "Add to Wallet"
2. Choose your wallet provider
3. Approve the connection and add the BOB network
See our [Networks Guide](/docs/user-hub/networks) for detailed information.
## Step 3: Bridge Assets to BOB
### From Ethereum
1. Visit [BOB Bridge](https://app.gobob.xyz/en?network=ethereum)
2. Connect your EVM wallet
3. Select assets to bridge
4. Follow the prompts to complete the transfer
:::info
BOB uses ETH as gas fees. Make sure to bridge ETH to BOB to make transactions.
See the full [Bridge from Ethereum to BOB](/docs/user-hub/onboard-to-bob/ethereum-bridge) guide for more details.
:::
### From Bitcoin
1. Visit [BOB Bridge](https://app.gobob.xyz/en?network=bitcoin)
2. Connect your EVM and Bitcoin wallets
3. Select BTC to bridge
4. Follow the prompts to complete the transfer
:::info
BOB uses ETH as gas fees. When bridging from Bitcoin, you don't need to have ETH on BOB. When you select the "Top Up Gas" option, you will get ETH to make further transactions on BOB.
See the full [Bridge from Bitcoin to BOB](/docs/user-hub/onboard-to-bob/bob-gateway) guide for more details.
:::
### From other networks or platforms
See the full [Bridge to BOB](/docs/user-hub/onboard-to-bob) guides.
## Step 4: Start Using BOB
After bridging, you can:
- **Stake Bitcoin** - Earn yield on your BTC
- **Use DeFi Apps** - Access the full DeFi ecosystem
- **Trade Assets** - Swap between BTC and other tokens
## Next Steps
- [Make Your First Transaction](./first-transaction.md)
- [Explore User Hub](../user-hub/)
- [Explore apps on BOB](https://app.gobob.xyz/en/apps)
## Need Help?
- **Discord Support**: [Join our Discord](https://discord.gg/gobob)
- **Telegram Support**: [Join our Telegram](https://t.me/+CyIcLW2nfaFlNDc1)
- **Documentation**: Explore our [documentation](/)
---
## Make Your First Transaction
Complete your first transaction on BOB to experience the power of Bitcoin-secured DeFi.
## Choose Your First Transaction
### Option 1: Stake Bitcoin
The most popular first transaction on BOB is staking Bitcoin to earn yield.
1. **Navigate to Staking**
- Go to [BOB Earn](https://app.gobob.xyz/en/earn)
2. **Select BTC Staking**
- Choose Bitcoin staking pool
- Review APY and terms
3. **Stake Your BTC**
- Enter amount to stake
- Confirm transaction
- Start earning yield
### Option 2: Swap Assets
Try swapping between BTC and other assets.
1. **Access Swap Interface**
- Go to [DEXs on BOB](https://app.gobob.xyz/en/apps?category=DEX)
- Select a DEX, e.g., [Uniswap v3 with Oku frontend](https://oku.trade/?inputChain=bob&inToken=0x05D032ac25d322df992303dCa074EE7392C117b9&outToken=0x4200000000000000000000000000000000000006)
2. **Select Trading Pair**
- Choose an input token
- Select desired output token
3. **Execute Swap**
- Review rates and fees
- Confirm transaction
- Receive swapped tokens
### Option 3: Use DeFi App
Explore the BOB ecosystem by using a DeFi application.
1. **Browse Apps**
- Visit [BOB App](https://app.gobob.xyz/en/apps)
- Explore featured applications
2. **Connect and Use**
- Go to the app you want to use
- Connect your wallet
- Follow app-specific instructions
## Transaction Tips
- **Gas Fees**: BOB has low gas fees compared to Ethereum mainnet
- **Confirmation Time**: Transactions are typically confirmed within seconds
## What's Next?
Now that you've made your first transaction, explore more:
- **[User Hub](../user-hub/)** - Learn about bridging, staking, and DeFi apps
- **[Gateway SDK](https://docs.gobob.xyz/gateway)** - For developers wanting to integrate BTC
- **[BitVM Network](../bitvm/)** - For institutional partners and node operators
- **[BOB Chain](../bob-chain/)** - For running full nodes and deploying smart contracts
---
## Quick Start
BOB is building the Bank of Bitcoin, reimagining banking for the Bitcoin age. One platform for everything - swapping, saving, earning & borrowing - all on Bitcoin rails.
## Quick Start Guide
Follow these steps to get started with BOB:
1. **[What is BOB?](./what-is-bob.md)** - 30-second overview of BOB
2. **[Connect Wallet & Bridge Assets](./connect-wallet)** - Set up your wallet and bridge your first assets
3. **[Make Your First Transaction](./first-transaction.md)** - Complete your first transaction on BOB
## Why Start Here?
By fusing Bitcoin's unmatched security with Ethereum's versatility, BOB's hybrid chain unlocks real utility for the world's most important asset.
This Quick Start guide will help you understand what makes BOB unique and get you up and running quickly.
## Ready to Begin?
Start with [What is BOB?](./what-is-bob.md) for a quick overview, or jump straight to [Connect Wallet & Bridge Assets](./connect-wallet) if you're ready to get started.
---
## What is BOB?(Quick-start)
## The Vision: The Bank of Bitcoin
BOB is building the Bank of Bitcoin - reimagining banking for the Bitcoin age. One platform for everything: swapping, saving, earning, and borrowing, all on Bitcoin rails.
Bitcoin is the world's most important financial asset, yet its utility has barely been unlocked. BOB exists to change that. By fusing Bitcoin's unmatched security with Ethereum's versatility, BOB's hybrid chain turns BTC into a fully productive asset.
The Problem: Users and institutions want to do more with their Bitcoin: swap, save, earn, and borrow - but today's options force trade-offs between security, usability, and trust. Projects and apps need liquidity in the world's most trusted asset, without compromising on Bitcoin's guarantees.
## The Solution: BOB - The Bank of Bitcoin
BOB is doing for Bitcoin what neobanks did for fiat money - and then taking it into the future. Swap BTC into any asset or deposit directly into DeFi on any chain with a single click, powered by Bitcoin intents. Save, lend, and earn securely with native Bitcoin vaults.
For Users: 1-click native BTC swaps, staking, DeFi deposits, and vaults - all accessible in a single transaction. Multi-chain BTC DeFi across 11+ major chains including Ethereum, Base, and BNB. Direct CEX deposits and hardware wallet support.
For Developers: BOB Gateway API and SDK bring frictionless Bitcoin interoperability and native BTC access to dapps.
**Key Innovation:** The first chain to achieve finality from both Ethereum and Bitcoin.
## The Technology: The BOB Stack
BOB is building the banking stack for Bitcoin. The hybrid chain is a ZK rollup on Ethereum, also secured by Bitcoin, combining the best of both networks into a single platform.
### Core Architecture
- **Bitcoin Security**: BTC on BOB is protected by Bitcoin's security model via [BitVM](https://blog.gobob.xyz/posts/what-is-bitvm)
- **Ethereum Compatibility**: Full EVM compatibility with ZK proofs
- **Hybrid Finality**: The first chain with finality secured by both Bitcoin and Ethereum networks.
- **Native BTC Integration**: 1-click native BTC swaps and DeFi deposits powered by Bitcoin intents, with instant swaps coming soon.
## Why build on BOB?
### 1-click Swap & Earn
- Best Bitcoin UX in the ecosystem - swap, stake, and earn with just 1 transaction
- Multi-chain BTC DeFi: 1-click native BTC swaps and DeFi deposits across 11+ major chains
- Direct CEX deposits and hardware wallet support via BOB Gateway API
- Instant BTC swaps coming soon
### BitVM / Bitcoin Security
- BOB co-authored the BitVM2 bridge design paper
- Member of the [BitVM Alliance](https://bitvm.org/)
- Launched [bitvm/acc](https://bitvm-acc.org/) to educate and recruit institutional partners
- BitVM live on testnet for institutional onboarding
- Secured by billions of dollars of staked BTC via BOB Finality Providers
### Ecosystem
- Best-in-class EVM and DeFi infrastructure based on the [OP stack](https://docs.optimism.io/stack/getting-started)
- 120+ projects and institutional partners building with BOB
- Tier 1 DeFi choosing BOB: Uniswap, Euler, Aave, LiFi, Chainlink, Babylon, Solv
- Institutions choosing BOB: Fireblocks, Anchorage Digital, Cobo, ForDeFi, and more
- Strong stablecoin infrastructure with USDC, USDT, Chainlink CCIP, LayerZero
## Next Steps
- [Connect Wallet & Bridge Assets](./connect-wallet)
- [Make Your First Transaction](./first-transaction.md)
---
## Audits
## BOB Mainnet
BOB is based on the OP Stack and relies on the extensive [security reviews](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/technical-documents/security-reviews) conducted for the OP Stack infrastructure by the Optimism Collective.
Our dispute game differs from the standard OP Stack implementation by using [Kailua](https://github.com/risc0/kailua), a hybrid zk rollup framework that enables validity proofs for dispute resolution and on-demand fast withdrawals. The Kailua framework has undergone multiple security audits:
### Veridise
- February 2025: Kailua Security Audit. [Report](veridise-kailua-20250217.pdf)
- May 2025: Kailua Security Audit. [Report](veridise-kailua-20250522.pdf)
- June 2025: Kailua Security Audit. [Report](veridise-kailua-20250616.pdf)
## BOB Token
- February 2025: BOB Token Audit. [Report](BobToken-Pashov-Audit-Report-Feb-2025.pdf)
- March 2025: BOB Staking Audit. [Report](BobStaking-security-review_2025-03-04.pdf)
- October 2025: BOB Token V2 Audit. [Report](BobTokenV2-Pashov-Audit-Report-Oct-2025.pdf)
- October 2025: BOB Staking Audit. [Report](BobStaking-security-review_2025-10-18.pdf)
## BOB Gateway
BOB's most novel product is our intent-based Bitcoin bridge, called "[BOB Gateway](/docs/user-hub/onboard-to-bob/bob-gateway/)." The reports below show the results of audits for every major release so far.
### Cure53
- April 2024: BOB Onramp Smart Contract Audit. [Report](BOB-02-WP2-report.pdf)
### Common Prefix
- April 2024: BOB Onramp Smart Contract Audit. [Report](Common-Prefix-Audit-Report-2024.pdf)
### Pashov
- April 2024: BOB Onramp Smart Contract Security Review. [Report](Pashov-Audit-Report-2024-v1.pdf)
- August 2024: BOB Gateway V2 Smart Contract Security Review. [Report](Pashov-Audit-Report-2024-v2.pdf)
- September 2024: BOB Gateway V3 Smart Contract Security Review. [Report](Pashov-Audit-Report-2024-v3.pdf)
- March 2025: BOB Gateway Offramp Registry Smart Contract Security Review. [Report](BOB-security-review_2025-03-17.pdf)
- August 2025: BOB Gateway Offramp Solver Security Audit. [Report](Pashov-Audit-Report-2025-offramp-solver.pdf)
## USDC Bridge
We contracted several auditing firms to evaluate BOB's implementation of the USDC bridge from Ethereum mainnet to BOB.
### Cure53
- April 2024: BOB Modified USDC Bridge Library. [Report](BOB-02-WP1-report.pdf)
### Pashov
- April 2024: BOB USDC Bridge Security Review. [Report](BOB-USDCBridge-security-review.pdf)
## FusionLock Contract
BOB's "Fusion Season One" campaign preceded our mainnet launch. Users had the option of depositing their tokens into a `FusionLock.sol` smart contract with the intention of bridging those assets to BOB mainnet once it went live. In preparation for that campaign, we contracted reviews of the FusionLock contract from several auditing firms.
### Ottersec
- March 2024: FusionLock Smart Contract Audit. [Report](FusionLock-Ottersec.pdf)
### Common Prefix
- March 2024: FusionLock Smart Contract Audit. [Report](FusionLock-Common_Prefix.pdf)
### Trail of Bits
- April 2024: FusionLock Smart Contract Security Review. [Report](FusionLock-Trail_of_Bits.pdf)
---
## BOB Token Reference
This page aggregates the information most partners need to integrate the BOB token across supported networks. The on-chain contracts themselves remain the canonical source of truth; always verify against the contract addresses linked below before deploying changes.
## Summary
- **Name:** BOB
- **Symbol:** `BOB`
- **Decimals:** `18`
- **Standard:** ERC-20 (OpenZeppelin implementation, no transfer fees or hooks)
- **Bridging:** Chainlink CCIP (lock/unlock on BOB, burn/mint on other chains)
- **Use cases:** Protocol reward token, liquidity incentives, gas subsidies, ecosystem alignment
## Deployments
| Network | Chain ID | Contract | Explorer |
| --- | --- | --- | --- |
| BOB Mainnet | `60808` (`0xED88`) | `0xb0bd54846a92b214c04a63b26ad7dc5e19a60808` | [explorer.gobob.xyz/address/0xb0bd...0808](https://explorer.gobob.xyz/address/0xb0bd54846a92b214c04a63b26ad7dc5e19a60808) |
| Ethereum Mainnet | `1` (`0x1`) | `0xC9746F73cC33a36c2cD55b8aEFD732586946Cedd` | [etherscan.io/address/0xC974...Cedd](https://etherscan.io/address/0xC9746F73cC33a36c2cD55b8aEFD732586946Cedd) |
| BNB Smart Chain | `56` (`0x38`) | `0x52B5fB4B0F6572B8C44d0251Cc224513ac5eB7E7` | [bscscan.com/address/0x52B5...B7E7](https://bscscan.com/address/0x52B5fB4B0F6572B8C44d0251Cc224513ac5eB7E7) |
All contracts are verified on their respective explorers. Always reference the full address (not a token symbol) when configuring integrations.
## Metadata & ABI
- `name() -> "BOB"`
- `symbol() -> "BOB"`
- `decimals() -> 18`
- `totalSupply()` returns 18-decimal units. Supply can change based on governance-controlled issuance.
- Standard ERC-20 events: `Transfer(address indexed from, address indexed to, uint256 value)` and `Approval(address indexed owner, address indexed spender, uint256 value)`.
- No custom callbacks are fired during transfers, so DeFi protocols can treat BOB like a vanilla ERC-20.
- ABI parity across every chain—only the deployment address and chain ID differ.
## Bridging
| Route | Purpose | Notes |
| --- | --- | --- |
| [CCIP Transporter](https://app.transporter.io/?token=BOB) | Canonical bridge for BOB between Ethereum ↔ BOB ↔ BSC and other CCIP-enabled domains | Uses Chainlink CCIP token pools. Provides attested, rate-limited transfers suitable for protocol treasury moves or end users. |
### CCIP Token Flow
- **BOB Mainnet:** CCIP locks/unlocks the existing L2 token when bridging in or out. Total BOB supply on BOB reflects supply across all chains.
- **Ethereum & BNB Smart Chain:** CCIP burns the source token and mints on the destination chain. On Ethereum and BSC, the total token supply is only the supply on that particular chain.
You can audit pool parameters, supply, and admin roles in the [Chainlink Token Manager dashboard](https://tokenmanager.chain.link/dashboard/ethereum-mainnet,0xc9746f73cc33a36c2cd55b8aefd732586946cedd).
### Integration Guidance
- Prefer CCIP for automated bridging flows, especially when you require deterministic settlement messages or per-transfer metadata.
- When monitoring bridges, watch for CCIP `MessageSent` / `MessageExecuted` events and the ERC-20 `Transfer` events emitted by the destination token.
- There is no secondary BOB-run liquidity bridge for BOB; CHAINLINK CCIP is the sole supported path for token portability today.
## Wallet & UI Integration Checklist
1. **Token metadata:** Symbol `BOB`, decimals `18`
2. **Add-to-wallet:** You can embed the `` component from `@site/src/components/AddBobToken` to let users add the token across supported chains.
3. **Logos:** Use the official SVG from the [brand assets](https://www.notion.so/build-on-bitcoin/Brand-Assets-2163a8aad3b48072afe8e134fc04e720/).
4. **Allowances:** Follow standard ERC-20 allowance flow.
## Security & Audits
- Smart contracts have been reviewed and [audit reports](/docs/reference/audits/) are available.
- Monitor [privileged roles](/docs/reference/privileged-roles) for information about controllers that can mint or pause bridge contracts.
---
## Bug Bounty Program
BOB maintains a comprehensive bug bounty program to help secure our protocol and protect our users. We have up to $250,000 in max payout available. For complete details and current information about our bug bounty program, please visit:
[BOB Bug Bounty Program →](https://r.xyz/bug-bounty/programs/bob)
## What You'll Find
Our bug bounty documentation covers:
### Program Structure
- Severity levels and payout ranges
- Programming languages and technologies
### Reward Categories
- Smart contract vulnerabilities
- Asset security
- Protocol functionality
### Guidelines & Rules
- Eligibility requirements
- Submission process
- Program scope and restrictions
- Testing requirements
### Asset Information
- In-scope contracts and systems
- Out-of-scope exclusions
## Getting Started
To participate in our bug bounty program or learn more about the specific requirements and rewards, please review the complete documentation at [our official bug bounty page](https://r.xyz/bug-bounty/programs/bob).
---
_Note: All details about rewards, scope, and guidelines are maintained on our official bug bounty page to ensure you always have access to the most current information._
---
## Contracts
## BOB Mainnet
### BOB Core Contracts (L2)
- [Light Relay](/docs/bob-chain/relay): [`0x9fe7ef727da3d79e0308ff43f31ea1d077ee9f41`](https://explorer.gobob.xyz/address/0x9fe7ef727da3d79e0308ff43f31ea1d077ee9f41)
- GatewayRegistry V2: [`0x37f330e667208633e1da1cf601d01f0ef8484306`](https://explorer.gobob.xyz/address/0x37f330e667208633e1da1cf601d01f0ef8484306)
- GatewayRegistry V3: [`0xAE6770a207E86FaE3b191564FA55ce7Bfee0Dde9`](https://explorer.gobob.xyz/address/0xAE6770a207E86FaE3b191564FA55ce7Bfee0Dde9)
### BOB Mainnet (L2)
- BaseFeeVault: [`0x4200000000000000000000000000000000000019`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000019)
- EAS: [`0x4200000000000000000000000000000000000021`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000021)
- EASSchemaRegistry: [`0x4200000000000000000000000000000000000020`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000020)
- GasPriceOracle: [`0x420000000000000000000000000000000000000F`](https://explorer.gobob.xyz/address/0x420000000000000000000000000000000000000F)
- L1Block: [`0x4200000000000000000000000000000000000015`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000015)
- L1FeeVault: [`0x420000000000000000000000000000000000001a`](https://explorer.gobob.xyz/address/0x420000000000000000000000000000000000001a)
- L2CrossDomainMessenger: [`0x4200000000000000000000000000000000000007`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000007)
- L2ERC721Bridge: [`0x4200000000000000000000000000000000000014`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000014)
- L2StandardBridge: [`0x4200000000000000000000000000000000000010`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000010)
- L2ToL1MessagePasser: [`0x4200000000000000000000000000000000000016`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000016)
- Multicall3: [`0xcA11bde05977b3631167028862bE2a173976CA11`](https://explorer.gobob.xyz/address/0xcA11bde05977b3631167028862bE2a173976CA11)
- OptimismMintableERC20Factory: [`0x4200000000000000000000000000000000000012`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000012)
- OptimismMintableERC721Factory: [`0x4200000000000000000000000000000000000017`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000017)
- ProxyAdmin: [`0x4200000000000000000000000000000000000018`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000018)
- SequencerFeeVault: [`0x4200000000000000000000000000000000000011`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000011)
- WETH9: [`0x4200000000000000000000000000000000000006`](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000006)
### Ethereum (L1)
:::info
These are OP Stack related contracts. If an API is preferred, here is the [Conduit API](https://api.conduit.xyz/file/v1/optimism/contracts/bob-mainnet-0).
:::
- AddressManager: [`0xF2dc77c697e892542cC53336178a78Bb313DFDC7`](https://etherscan.io/address/0xF2dc77c697e892542cC53336178a78Bb313DFDC7)
- AnchorStateRegistryImpl: [`0x7b465370bb7a333f99edd19599eb7fb1c2d3f8d2`](https://etherscan.io/address/0x7b465370bb7a333f99edd19599eb7fb1c2d3f8d2)
- AnchorStateRegistryProxy: [`0xeBA14d52F1b19cA65455E5ECaB72D2FfD9e43fEF`](https://etherscan.io/address/0xeBA14d52F1b19cA65455E5ECaB72D2FfD9e43fEF)
- DelayedWETHImpl: [`0x5e40b9231b86984b5150507046e354dbfbed3d9e`](https://etherscan.io/address/0x5e40b9231b86984b5150507046e354dbfbed3d9e)
- DelayedWETHPermissionedGameProxy: [`0x3a1D54496cf461fFc96d3b1a8A0B43B091ea3c13`](https://etherscan.io/address/0x3a1D54496cf461fFc96d3b1a8A0B43B091ea3c13)
- DisputeGameFactoryImpl: [`0x4bba758f006ef09402ef31724203f316ab74e4a0`](https://etherscan.io/address/0x4bba758f006ef09402ef31724203f316ab74e4a0)
- DisputeGameFactoryProxy: [`0x96123dbFC3253185B594c6a7472EE5A21E9B1079`](https://etherscan.io/address/0x96123dbFC3253185B594c6a7472EE5A21E9B1079)
- KailuaTreasury: [`0xE99AF5F4C60E06Beb3827F4ffdD06E88c55fB895`](https://etherscan.io/address/0xE99AF5F4C60E06Beb3827F4ffdD06E88c55fB895)
- L1CrossDomainMessengerImpl: [`0x5d5a095665886119693f0b41d8dfee78da033e8b`](https://etherscan.io/address/0x5d5a095665886119693f0b41d8dfee78da033e8b)
- L1CrossDomainMessengerProxy: [`0xE3d981643b806FB8030CDB677D6E60892E547EdA`](https://etherscan.io/address/0xE3d981643b806FB8030CDB677D6E60892E547EdA)
- L1ERC721BridgeImpl: [`0x7ae1d3bd877a4c5ca257404ce26be93a02c98013`](https://etherscan.io/address/0x7ae1d3bd877a4c5ca257404ce26be93a02c98013)
- L1ERC721BridgeProxy: [`0x5fF93263D5181b2A826f8c51d54BC0da2d20D50a`](https://etherscan.io/address/0x5fF93263D5181b2A826f8c51d54BC0da2d20D50a)
- L1StandardBridgeImpl: [`0x0b09ba359a106c9ea3b181cbc5f394570c7d2a7a`](https://etherscan.io/address/0x0b09ba359a106c9ea3b181cbc5f394570c7d2a7a)
- L1StandardBridgeProxy: [`0x3F6cE1b36e5120BBc59D0cFe8A5aC8b6464ac1f7`](https://etherscan.io/address/0x3F6cE1b36e5120BBc59D0cFe8A5aC8b6464ac1f7)
- MipsSingleton: [`0xf027f4a985560fb13324e943edf55ad6f1d15dc1`](https://etherscan.io/address/0xf027f4a985560fb13324e943edf55ad6f1d15dc1)
- OPCM: [`0xdfe652fb94eb26c0f343d1c0273bfee78596ee3c`](https://etherscan.io/address/0xdfe652fb94eb26c0f343d1c0273bfee78596ee3c)
- OptimismMintableERC20FactoryImpl: [`0x5493f4677a186f64805fe7317d6993ba4863988f`](https://etherscan.io/address/0x5493f4677a186f64805fe7317d6993ba4863988f)
- OptimismMintableERC20FactoryProxy: [`0x5557408ab14013ce9Dbb300dE0D87D386BB09cb6`](https://etherscan.io/address/0x5557408ab14013ce9Dbb300dE0D87D386BB09cb6)
- OptimismPortalImpl: [`0xb443da3e07052204a02d630a8933dac05a0d6fb4`](https://etherscan.io/address/0xb443da3e07052204a02d630a8933dac05a0d6fb4)
- OptimismPortalProxy: [`0x8AdeE124447435fE03e3CD24dF3f4cAE32E65a3E`](https://etherscan.io/address/0x8AdeE124447435fE03e3CD24dF3f4cAE32E65a3E)
- PermissionedDisputeGame: [`0xe3BD00F57B44E7aa4A6C212878427c85D638702A`](https://etherscan.io/address/0xe3BD00F57B44E7aa4A6C212878427c85D638702A)
- PreimageOracleSingleton: [`0x1fb8cdfc6831fc866ed9c51af8817da5c287add3`](https://etherscan.io/address/0x1fb8cdfc6831fc866ed9c51af8817da5c287add3)
- ProtocolVersionsImpl: [`0x37e15e4d6dffa9e5e320ee1ec036922e563cb76c`](https://etherscan.io/address/0x37e15e4d6dffa9e5e320ee1ec036922e563cb76c)
- ProtocolVersionsProxy: [`0x0dd8ed2f044fde13be5d28d51b29e87e22bd97d2`](https://etherscan.io/address/0x0dd8ed2f044fde13be5d28d51b29e87e22bd97d2)
- ProxyAdmin: [`0x0d9f416260598313Be6FDf6B010f2FbC34957Cd0`](https://etherscan.io/address/0x0d9f416260598313Be6FDf6B010f2FbC34957Cd0)
- RiscZeroVerifierRouter: [`0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319`](https://etherscan.io/address/0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319)
- SuperchainConfigImpl: [`0x4da82a327773965b8d4d85fa3db8249b387458e7`](https://etherscan.io/address/0x4da82a327773965b8d4d85fa3db8249b387458e7)
- SuperchainConfigProxy: [`0xe925205ad05d8d612ac205c4941ccd61fc965c46`](https://etherscan.io/address/0xe925205ad05d8d612ac205c4941ccd61fc965c46)
- SuperchainProxyAdmin: [`0xa70ddfb3e00fcfd083e64b200fe867104f703e1c`](https://etherscan.io/address/0xa70ddfb3e00fcfd083e64b200fe867104f703e1c)
- SystemConfigImpl: [`0x340f923e5c7cbb2171146f64169ec9d5a9ffe647`](https://etherscan.io/address/0x340f923e5c7cbb2171146f64169ec9d5a9ffe647)
- SystemConfigProxy: [`0xACB886b75D76d1c8d9248cFdDfA09b70C71c5393`](https://etherscan.io/address/0xACB886b75D76d1c8d9248cFdDfA09b70C71c5393)
## BOB Sepolia (Testnet)
### BOB Sepolia Core Contracts (L2)
- [TestLightRelay](/docs/bob-chain/relay): [`0x377d6993b848013991e3d8b3028db74ec6fdf03a`](https://bob-sepolia.explorer.gobob.xyz/address/0x377d6993b848013991e3d8b3028db74ec6fdf03a)
- GatewayRegistry V2: [`0x345f46fdd0adad44ba8e2a65ce6a7ba879f3404e`](https://bob-sepolia.explorer.gobob.xyz/address/0x345f46fdd0adad44ba8e2a65ce6a7ba879f3404e)
- GatewayRegistry V3: [`0xfDFed82309b14b7e3EDfc768Bb5EBF80dDcaFb3A`](https://bob-sepolia.explorer.gobob.xyz/address/0xfDFed82309b14b7e3EDfc768Bb5EBF80dDcaFb3A)
### BOB Sepolia (L2)
- BaseFeeVault: [`0x4200000000000000000000000000000000000019`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000019)
- EAS: [`0x4200000000000000000000000000000000000021`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000021)
- EASSchemaRegistry: [`0x4200000000000000000000000000000000000020`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000020)
- GasPriceOracle: [`0x420000000000000000000000000000000000000F`](https://bob-sepolia.explorer.gobob.xyz/address/0x420000000000000000000000000000000000000F)
- L1Block: [`0x4200000000000000000000000000000000000015`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000015)
- L1FeeVault: [`0x420000000000000000000000000000000000001a`](https://bob-sepolia.explorer.gobob.xyz/address/0x420000000000000000000000000000000000001a)
- L2CrossDomainMessenger: [`0x4200000000000000000000000000000000000007`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000007)
- L2ERC721Bridge: [`0x4200000000000000000000000000000000000014`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000014)
- L2StandardBridge: [`0x4200000000000000000000000000000000000010`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000010)
- L2ToL1MessagePasser: [`0x4200000000000000000000000000000000000016`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000016)
- OptimismMintableERC20Factory: [`0x4200000000000000000000000000000000000012`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000012)
- OptimismMintableERC721Factory: [`0x4200000000000000000000000000000000000017`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000017)
- ProxyAdmin: [`0x4200000000000000000000000000000000000018`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000018)
- SequencerFeeVault: [`0x4200000000000000000000000000000000000011`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000011)
- WETH9: [`0x4200000000000000000000000000000000000006`](https://bob-sepolia.explorer.gobob.xyz/address/0x4200000000000000000000000000000000000006)
### Ethereum Sepolia (L1)
:::info
These are OP Stack related contracts. If an API is preferred, here is the [Conduit API](https://api.conduit.xyz/file/v1/optimism/contracts/bob-sepolia-dm6uw0yhh3).
:::
- AddressManager: [`0x98Ba8b9cF38732db65c7E556617135A0E6669F57`](https://sepolia.etherscan.io/address/0x98Ba8b9cF38732db65c7E556617135A0E6669F57)
- AnchorStateRegistryImpl: [`0x7b465370bb7a333f99edd19599eb7fb1c2d3f8d2`](https://sepolia.etherscan.io/address/0x7b465370bb7a333f99edd19599eb7fb1c2d3f8d2)
- AnchorStateRegistryProxy: [`0x0e162344A1CA3a31c9455212d055bD3101D48880`](https://sepolia.etherscan.io/address/0x0e162344A1CA3a31c9455212d055bD3101D48880)
- DelayedWETHImpl: [`0x44efe3ecf916f756c02e09fe17fe2d9abc8d9d71`](https://sepolia.etherscan.io/address/0x44efe3ecf916f756c02e09fe17fe2d9abc8d9d71)
- DelayedWETHPermissionedGameProxy: [`0x7444d4470ED4320e4B84eE160351FBbcbCd4BB2a`](https://sepolia.etherscan.io/address/0x7444d4470ED4320e4B84eE160351FBbcbCd4BB2a)
- DisputeGameFactoryImpl: [`0x4bba758f006ef09402ef31724203f316ab74e4a0`](https://sepolia.etherscan.io/address/0x4bba758f006ef09402ef31724203f316ab74e4a0)
- DisputeGameFactoryProxy: [`0x7a25d06Af869d0A94f6effAfFa0A830EEBF1EcfB`](https://sepolia.etherscan.io/address/0x7a25d06Af869d0A94f6effAfFa0A830EEBF1EcfB)
- L1CrossDomainMessengerImpl: [`0x5d5a095665886119693f0b41d8dfee78da033e8b`](https://sepolia.etherscan.io/address/0x5d5a095665886119693f0b41d8dfee78da033e8b)
- L1CrossDomainMessengerProxy: [`0xB88164eE7669f1C736A55121160daB9c82b62d55`](https://sepolia.etherscan.io/address/0xB88164eE7669f1C736A55121160daB9c82b62d55)
- L1ERC721BridgeImpl: [`0x7ae1d3bd877a4c5ca257404ce26be93a02c98013`](https://sepolia.etherscan.io/address/0x7ae1d3bd877a4c5ca257404ce26be93a02c98013)
- L1ERC721BridgeProxy: [`0x70dee5e3723C76FC83238f62d2b3D4071533de69`](https://sepolia.etherscan.io/address/0x70dee5e3723C76FC83238f62d2b3D4071533de69)
- L1StandardBridgeImpl: [`0x0b09ba359a106c9ea3b181cbc5f394570c7d2a7a`](https://sepolia.etherscan.io/address/0x0b09ba359a106c9ea3b181cbc5f394570c7d2a7a)
- L1StandardBridgeProxy: [`0x75f48FE4DeAB3F9043EE995c3C84D6a2303D9a2F`](https://sepolia.etherscan.io/address/0x75f48FE4DeAB3F9043EE995c3C84D6a2303D9a2F)
- MipsSingleton: [`0x17c64e93846935dfbd281a5540a14d4cd67195f7`](https://sepolia.etherscan.io/address/0x17c64e93846935dfbd281a5540a14d4cd67195f7)
- OPCM: [`0xbfca47de47620ff1fcd3f2051125027d9b54847c`](https://sepolia.etherscan.io/address/0xbfca47de47620ff1fcd3f2051125027d9b54847c)
- OptimismMintableERC20FactoryImpl: [`0x5493f4677a186f64805fe7317d6993ba4863988f`](https://sepolia.etherscan.io/address/0x5493f4677a186f64805fe7317d6993ba4863988f)
- OptimismMintableERC20FactoryProxy: [`0x57e99fb38Da9E332D0D13A7223A7037DE041cF1d`](https://sepolia.etherscan.io/address/0x57e99fb38Da9E332D0D13A7223A7037DE041cF1d)
- OptimismPortalImpl: [`0x3b3505ae63b6cb180ba684cdfe76d71f6096a2bf`](https://sepolia.etherscan.io/address/0x3b3505ae63b6cb180ba684cdfe76d71f6096a2bf)
- OptimismPortalProxy: [`0xBAAf3BAfdbd660380938b27d21c31bB7D072a799`](https://sepolia.etherscan.io/address/0xBAAf3BAfdbd660380938b27d21c31bB7D072a799)
- PermissionedDisputeGame: [`0x5687b5950FC5604c7D4959bF09192C57D0d62891`](https://sepolia.etherscan.io/address/0x5687b5950FC5604c7D4959bF09192C57D0d62891)
- PreimageOracleSingleton: [`0xee74fd716edbfe6575ecc18b39f181b4de79fa7a`](https://sepolia.etherscan.io/address/0xee74fd716edbfe6575ecc18b39f181b4de79fa7a)
- ProtocolVersionsImpl: [`0x37e15e4d6dffa9e5e320ee1ec036922e563cb76c`](https://sepolia.etherscan.io/address/0x37e15e4d6dffa9e5e320ee1ec036922e563cb76c)
- ProtocolVersionsProxy: [`0xfdce12536a20b2736fd2f8bccc6285c08234c809`](https://sepolia.etherscan.io/address/0xfdce12536a20b2736fd2f8bccc6285c08234c809)
- ProxyAdmin: [`0xb2eBBa78eEbb4670CA357fAeA3C2B723cdf03221`](https://sepolia.etherscan.io/address/0xb2eBBa78eEbb4670CA357fAeA3C2B723cdf03221)
- SuperchainConfigImpl: [`0x4da82a327773965b8d4d85fa3db8249b387458e7`](https://sepolia.etherscan.io/address/0x4da82a327773965b8d4d85fa3db8249b387458e7)
- SuperchainConfigProxy: [`0x70675e148b5f88fffaeac70bc6c5369f3273bef3`](https://sepolia.etherscan.io/address/0x70675e148b5f88fffaeac70bc6c5369f3273bef3)
- SuperchainProxyAdmin: [`0xa58898f7f706c208410232a8fbf70699cd0ef9a0`](https://sepolia.etherscan.io/address/0xa58898f7f706c208410232a8fbf70699cd0ef9a0)
- SystemConfigImpl: [`0x340f923e5c7cbb2171146f64169ec9d5a9ffe647`](https://sepolia.etherscan.io/address/0x340f923e5c7cbb2171146f64169ec9d5a9ffe647)
- SystemConfigProxy: [`0x3974436Fa4BB4Deb5A04ace51A704B10FF5A1f25`](https://sepolia.etherscan.io/address/0x3974436Fa4BB4Deb5A04ace51A704B10FF5A1f25)
---
## Founder Resources
Whether you're a Bitcoin native looking to leverage EVM capabilities or an Ethereum builder ready to tap into Bitcoin's potential, BOB provides the infrastructure, capital, and ecosystem you need to succeed.
BOB offers founders:
- **Funding Opportunities**: Access grants, including our DeFi Incentive Campaign with 750,000 $OP tokens
- **Accelerator Programs**: Join programs like the IOSG Kickstarter offering up to $100K in funding
- **BTC Shark Tank**: Pitch your project to leading investors at major crypto hubs worldwide
- **Networking**: Connect with our extensive VC and Angel investor networks
- **Technical Support**: Get the tools and infrastructure needed to build on BOB
:::tip Ready to Explore More?
For detailed information about these opportunities and how to apply, visit our [Founder Resources page](https://build-on-bitcoin.notion.site/founder-resources).
:::
---
## Governance: Whitelisted Delegates
For information about BOB's governance and whitelisted delegates, please refer to our governance documentation:
**[Governance: Whitelisted Delegates](https://docs.google.com/document/d/1AQBQAkImZDBi-mFFZgMRoEyENDiqL8DF5F4Dx_7urPs/edit?usp=sharing)**
---
## Reference
Technical reference for BOB Chain, BitVM, and Gateway SDK.
## Contents
- **[Audits](./audits/)**: Security audits and reports
- **[Contracts](./contracts/)**: Smart contract addresses and ABIs
- **[Token Registry](./token-registry/)**: Official token registry
- **[Tools](/docs/tools/)**: Developer and user tools
- **[Bug Bounty](./bug-bounty.md)**: Security program details
- **[Privileged Roles](./privileged-roles.md)**: Role-based permissions
- **[Research](./research.md)**: Technical research and whitepapers
## Network Information
### BOB Mainnet
- **Chain ID**: 60808
- **RPC URL**: https://rpc.gobob.xyz/
- **Block Explorer**: https://explorer.gobob.xyz/
- **Currency**: ETH
### BOB Sepolia (Testnet)
- **Chain ID**: 808813
- **RPC URL**: https://bob-sepolia.rpc.gobob.xyz
- **Block Explorer**: https://sepolia-explorer.gobob.xyz/
- **Currency**: ETH
## Official Resources
- **Homepage**: https://gobob.xyz
- **App**: https://app.gobob.xyz
- **Blog**: https://blog.gobob.xyz
- **GitHub**: https://github.com/bob-collective
- **Discord**: https://discord.gg/gobob
---
## Privileged Roles in BOB Mainnet
BOB uses the [OP Stack](https://docs.optimism.io/stack/getting-started) as its foundation and has upgraded to a [hybrid zk rollup](/docs/bob-chain/hybrid-chain) powered by Kailua, which enables validity proofs for dispute resolution and on-demand fast withdrawals.
OP Stack chains still include "privileged" roles that allow certain addresses to carry out specific actions. Read this page to understand these roles, why they exist, and what risks they pose.
For independent reviews of BOB's security and decentralization status, see:
- [L2Beat](https://l2beat.com/scaling/projects/bob) - Comprehensive analysis of L2 scaling solutions
- [Bitcoin Layers](https://www.bitcoinlayers.org/layers/bob) - Bitcoin-focused layer analysis
## L1 Proxy Admin
The L1 Proxy Admin is an address that can be used to upgrade most BOB system contracts.
### Risks
- Compromised L1 Proxy Admin could upgrade contracts to malicious versions.
- Compromised L1 Proxy Admin could remove or lock ETH or tokens in the Standard Bridge.
- Compromised L1 Proxy Admin could fail to mitigate a risk as described on this page.
### Mitigations
- L1 Proxy Admin owner is a 4-of-6 [multisig](https://etherscan.io/address/0xC91482A96e9c2A104d9298D1980eCCf8C4dc764E#readProxyContract).
### Address
- **Ethereum**: [`0x0d9f416260598313Be6FDf6B010f2FbC34957Cd0`](https://etherscan.io/address/0x0d9f416260598313Be6FDf6B010f2FbC34957Cd0)
## L2 Proxy Admin
The L2 Proxy Admin is an address that can be used to upgrade most BOB system contracts on L2.
### Risks
- Compromised L2 Proxy Admin could upgrade contracts to malicious versions.
- Compromised L2 Proxy Admin could remove or lock ETH or tokens in the Standard Bridge.
- Compromised L2 Proxy Admin could fail to mitigate a risk as described on this page.
### Mitigations
- L2 Proxy Admin is a 4-of-6 [multisig](https://explorer.gobob.xyz/address/0x432c1fe0a868c8eeec2c73f59743f88fb07b561b).
### Address
- **BOB**: [`0xaCdBaAC6707c7e28ac1A15007f22Aac1188910d7`](https://explorer.gobob.xyz/address/0xaCdBaAC6707c7e28ac1A15007f22Aac1188910d7?tab=read_proxy)
## System Config Owner
The System Config Owner is an address that can be used to change the values within the [`SystemConfig`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/SystemConfig.sol) contract on Ethereum.
### Risks
- Compromised System Config Owner could cause a temporary network outage.
- Compromised System Config Owner could cause users to be overcharged for transactions.
### Mitigations
- System Config Owner is a 4-of-6 [multisig](https://etherscan.io/address/0xC91482A96e9c2A104d9298D1980eCCf8C4dc764E#readProxyContract).
- System Config Owner can be replaced by the [L1 Proxy Admin](#l1-proxy-admin).
### Address
- **Ethereum**: [0xaa0a1efd35d6578ea6b5704dbc2c40b36a55b590](https://etherscan.io/address/0xaa0a1efd35d6578ea6b5704dbc2c40b36a55b590#code)
## Batcher
### Description
The Batcher is a software service that submits batches of transactions to Ethereum on behalf of the current BOB Sequencer.
BOB nodes will look for transactions from this address to find new batches of L2 transactions to process.
### Risks
- Batcher address is typically a hot wallet.
- Compromised batcher address can cause L2 reorgs or sequencer outages.
### Mitigations
- Compromised batcher address cannot publish invalid transactions.
- Compromised batcher address can be replaced by the [L1 Proxy Admin](#l1-proxy-admin).
### Address
- **Ethereum**: [`0x08f9f14ff43e112b18c96f0986f28cb1878f1d11`](https://etherscan.io/address/0x08f9f14ff43e112b18c96f0986f28cb1878f1d11)
## Proposer
### Description
The Proposer is a software service that submits proposals about the state of BOB to the `DisputeGameFactory` contract on Ethereum, which spawns a new `KailuaGame` contract for each proposal in which disputes can be resolved if necessary. BOB operates in [Kailua's vanguard mode](https://boundless-xyz.github.io/kailua/parameters.html?highlight=vanguard#vanguard-advantage), where the BOB proposer has priority to submit proposals. If no proposal is made by the BOB proposer within 30 days, then any user can submit their own proposal.
Proposals can be finalized in multiple ways:
- After 4 days if there is no challenge
- Instantly when a challenge is resolved through a validity proof
- Instantly when a proposal is submitted with a validity proof
Proposer addresses are typically "hot wallets" as they must be available to frequently sign and publish new state proposals.
### Risks
- Proposer address is typically a hot wallet.
- Compromised proposer address could propose invalid state proposals.
- Invalid state proposals can be used to execute invalid withdrawals if not challenged.
### Mitigations
- Compromised proposer address can be replaced by the [L1 Proxy Admin](#l1-proxy-admin).
- Invalid state proposals can be challenged by anyone with 0.5 ETH collateral.
- Validity proofs provide mathematical certainty during disputes.
### Address
- **Ethereum**: [`0x7cB1022D30b9860C36b243E7B181A1d46f618C69`](https://etherscan.io/address/0x7cB1022D30b9860C36b243E7B181A1d46f618C69)
## Challenger
### Description
In BOB's Kailua-powered system, anyone can challenge invalid state proposals submitted by the [Proposer](#proposer) role. Challenges require a collateral deposit of 0.5 ETH. When a challenge is initiated, the dispute is resolved through validity proofs that provide mathematical certainty about the correctness of the state transition.
Successful challengers are rewarded, while unsuccessful challengers forfeit their collateral. This permissionless challenging mechanism ensures the security of the hybrid zk rollup system.
### Risks
- Economic barrier (0.5 ETH) may limit the number of potential challengers.
- If no one challenges invalid proposals within the challenge period, invalid withdrawals could be executed.
### Mitigations
- Low collateral requirement (0.5 ETH) makes challenging accessible to many participants.
- Validity proofs provide cryptographic certainty in dispute resolution.
- Anyone can participate in challenging, not limited to specific addresses.
- Economic incentives reward successful challengers.
### Address
- **Anyone** can challenge by depositing 0.5 ETH collateral
## Guardian
### Description
The Guardian is an address that can be used to pause withdrawals from BOB.
This is a backup safety mechanism that allows for a temporary halt in the event of a security concern.
The Guardian role cannot pause specific withdrawals and can only pause all withdrawals.
### Risks
- Compromised guardian could pause withdrawals indefinitely.
### Mitigations
- Compromised guardian address can be replaced by the [L1 Proxy Admin](#l1-proxy-admin).
- Withdrawals can be unpaused by replaced guardian address.
- Guardian is a 4-of-6 [multisig](https://etherscan.io/address/0xC91482A96e9c2A104d9298D1980eCCf8C4dc764E#readProxyContract).
### Address
- **Ethereum**: [`0xC91482A96e9c2A104d9298D1980eCCf8C4dc764E`](https://etherscan.io/address/0xC91482A96e9c2A104d9298D1980eCCf8C4dc764E#readProxyContract)
## ERC20 Contract Upgrade Proxy
### Description
The ERC20 Contract Upgrade Proxy is an address that can be used to upgrade four ERC20 contracts on BOB to new versions: USDC, tBTC, wstETH, and STONE. This is a temporary measure:
- USDC: The ERC20 is upgradable to allow Circle to take over the contract to enable native minting and redeeming on BOB.
- tBTC: The ERC20 is upgradable to allow Threshold governance to take over the contract to enable native minting and redeeming on BOB.
- wstETH: The ERC20 is upgradable to allow Lido governance to take over the contract to control the contract from the Ethereum side.
All other ERC20 contracts on BOB are not upgradable by this proxy.
### Risks
- Compromised ERC20 Contract Upgrade Proxy could upgrade contracts to malicious versions.
### Mitigations
- USDC and wstETH Contract Upgrade Proxy is a 3-of-5 [multisig](https://explorer.gobob.xyz/address/0xAE554F69fEd747006BF48481A6629921c3cD2Ba5).
- tBTC Contract Upgrade Proxy is a 3-of-5 [multisig](https://explorer.gobob.xyz/address/0x694DeC29F197c76eb13d4Cc549cE38A1e06Cd24C).
## BOB Token Admin Multisig
### Description
The BOB token contracts on BOB, Ethereum, and BNB Smart Chain share a single admin multisig at `0x71083c7F1dCa054E3D96c833Eb38500aA6881Db9`. Today it operates as a 2-of-4 multisig with an upgrade plan to move to a 3-of-4 threshold.
This multisig owns each BOB token proxy contract and can:
- Upgrade implementation logic
- Mint or burn supply
- Configure Chainlink CCIP bridge parameters (adding chains, adjusting rate limits, pausing flows)
### Risks
- A compromised multisig could mint unlimited BOB, impose malicious upgrades, or block all transfers/bridging by altering CCIP parameters.
### Mitigations
- Multisig threshold (moving to 3-of-4) distributes key custody across independent signers.
- CCIP rate-limit changes and new chain listings follow internal change-management reviews before execution.
### Address
- **BOB / Ethereum / BSC:** [`0x71083c7F1dCa054E3D96c833Eb38500aA6881Db9`](https://explorer.gobob.xyz/address/0x71083c7F1dCa054E3D96c833Eb38500aA6881Db9)
---
## Research at BOB
Technological advantage stems from persistent and rigorous research.
Founded by ex-Imperial College London PhDs, we are dedicated to contribute to cutting-edge research in the areas of blockchain interoperability, security, and crypto-economics.
Our team members have co-authored over 30 scientific publications in collaboration with leading universities and research centres around the globe, resulting in more than 1,000 citations.
## Latest Research Papers
### Bitcoin Vaults Liquidation Engine
Read abstract
We present a novel trust-minimized liquidation engine for Bitcoin vaults that enable native BTC as collateral for lending and stablecoins on DeFi chains like Ethereum, Base, BOB, Solana, and others. Our solution addresses limitations in BitVM-style Bitcoin vaults, where liquidations take several days to process, the entire BTC amount must be liquidated, and the liquidator set is static and predefined. The Bitcoin Vault Liquidation Engine restores atomic liquidations with an open liquidator set as used by lending protocols today. The liquidation engine maintains trust minimization for the depositor: the depositor needs to trust the Bitcoin and DeFi chain consensus, as well as the correct implementation of the DeFi protocol and the Bitcoin vault. The depositor can (1) enforce withdrawal of their BTC via a proof powered by BitVM on Bitcoin without having to trust bridge operators, and (2) receive exact BTC from their deposit UTXO, offsetting concerns around receiving BTC from unknown third parties.
- **Harz D**
- BOB Research, October 2025
### BitVM Status Report
Read abstract
BitVM2 represents a significant advancement in Bitcoin's programmability, enabling arbitrary program execution through optimistic computation without requiring consensus changes. We present a comprehensive analysis of BitVM2's improvements over its predecessor, highlighting its reduction to just three on-chain transactions for dispute resolution and introduction of permissionless challenging. We detail the roles and incentive structures of the BitVM ecosystem participants and evaluate various approaches to Bitcoin L2s, providing a practical roadmap for implementing BitVM in production environments. Our analysis demonstrates that while current technological limitations prevent immediate deployment of certain L2 models, BitVM2 enables practical and secure implementations of Bitcoin bridges with minimal trust assumptions.
- **Zamyatin A, Harz D**
- Pre-print, 2025
### BOB: The Hybrid Chain
中文版 | 한국어
Read abstract
BOB is a new type of Bitcoin-secured blockchain: a Hybrid Chain. Hybrid Chains inherit security from Bitcoin, as the most secure and decentralized network. Bitcoin security is then used to create trustminimized bridges to Bitcoin, Ethereum, and other L1s. As a result, the Hybrid Chain does not rely on third-party bridges for interoperability and solves the problem of fragmented BTC multi-chain liquidity.
- **Zamyatin A, Harz D**
- Pre-print, 2024
### [BitVM2: Bridging Bitcoin to Second Layers](https://bitvm.org/bitvm_bridge.pdf)
Read abstract
BitVM2 is a novel paradigm that enables arbitrary program execution in Bitcoin, thereby combining Turing-complete expressiveness with the security of Bitcoin consensus. At its core, BitVM2 leverages optimistic computation, assuming operators are honest unless proven otherwise by challengers through fraud proofs, and SNARK proof verification scripts, which are split into sub-programs that are executed within Bitcoin transactions. As a result, BitVM2 ensures program correctness with just three on-chain transactions. BitVM2 significantly improves over prior BitVM designs by enabling, for the first time, permissionless challenging and by reducing the complexity and number of on-chain transactions required to resolve disputes. Our construction requires no consensus changes to Bitcoin. BitVM2 enables the design of an entirely new class of applications in Bitcoin. We showcase that by presenting BitVM Bridge, a protocol that enhances prior Bitcoin bridges by reducing trust assumptions for the safety of deposits from an honest majority (t-of-n) to existential honesty (1-of-n) during setup. To guarantee liveness, we only require one active rational operator (while the others can be malicious). Any user can act as challenger, facilitating permissionless verification of the protocol.
- Linus R, Aumayr L, **Zamyatin A**, Pelosi A, Avarikioti Z, Meffei M
- Pre-print, 2024
### [OptiMine: Optimistically Sequenced Merged Mining for Rollups and Sidechains](https://gobob.xyz/optimine)
Read abstract
We coin the hybrid consensus technique “Optimistically Sequenced Merged Mining”. The technique enables any sidechain or rollup connected to an L1 chain to receive Proof-of-Work security from Bitcoin Miners. Rollups and sidechains retain fast block production and reduce the trust in centralized Sequencers and block-producing nodes.
- The BOB Collective
- Pre-print, 2024
## Previous Research Work
Our team has been actively contributing to cutting-edge research in the blockchain space over the past 9 years.
A lot of the concepts developed by our team during their previous research careers find their way into BOB's products. Some of the most recent and relevant works of our team members are outlined below:
### [XCC: Theft-Resilient and Collateral-Optimized Cryptocurrency-Backed Assets](https://docs.interlay.io/_assets/papers/XCC_paper.pdf)
Read abstract
The need for cross-blockchain interoperability is higher than ever. Today, there exists a plethora of blockchain-based cryptocurrencies, with varying levels of adoption and diverse niche use cases, and yet communication across blockchains is still in its infancy. Despite the vast potential for novel applications in an interoperable ecosystem, cross-chain tools and protocols are few and often limited.
Cross-chain communication requires a trusted third party, as the Fair Exchange problem is reducible to it. However, the decentralised consensus of blockchains can be used as a source of trust, and financial incentives can achieve security. XCLAIM uses these principles to enable collateralised cryptocurrency-backed assets (CbAs) to be created and used. However, full collateralization is inefficient, and to protect against exchange rate fluctuations overcollateralization is necessary. This is a significant barrier to scaling, and as a result, in practice, most systems still employ a centralised architecture.
In this work, we introduce XCC, an extension to the XCLAIM framework which allows for a significant reduction in collateral required. By making use of periodic, timelocked commitments on the backing blockchain, XCC decouples locked collateral from issued CbAs, allowing fractional collateralization without loss of security. We instantiate XCC between Bitcoin and Ethereum to showcase practical feasibility. XCC is compatible with the majority of existing blockchains without modification.
- Bugnet T, **Zamyatin A**
- Pre-print, 2022
- In collaboration with Imperial College London
### [SoK: Communication Across Distributed Ledgers](https://eprint.iacr.org/2019/1128.pdf)
Read abstract
Since the inception of Bitcoin, a plethora of distributed ledgers differing in design and purpose has been created. While by design, blockchains provide no means to securely communicate with external systems, numerous attempts towards trustless cross-chain communication have been proposed over the years. Today, cross-chain communication (CCC) plays a fundamental role in cryptocurrency exchanges, scalability efforts via sharding, extension of existing systems through sidechains, and bootstrapping of new blockchains. Unfortunately, existing proposals are designed ad-hoc for specific use-cases, making it hard to gain confidence in their correctness and composability.
We provide the first systematic exposition of cross-chain communication protocols. We formalize the underlying research problem and show that CCC is impossible without a trusted third party, contrary to common beliefs in the blockchain community. With this result in mind, we develop a framework to design new and evaluate existing CCC protocols, focusing on the inherent trust assumptions thereof, and derive a classification covering the field of cross-chain communication to date. We conclude by discussing open challenges for CCC research and the implications of interoperability on the security and privacy of blockchains.
- **Zamyatin A**, Al-Bassam M, Zindros D, Kokoris-Kogias E, Moreno-Sanchez P, Kiayias A, Knottenbelt WJ
- Financial Cryptography and Data Security 2021
- In collaboration with Imperial College London, UCL, IOHK, EPFL, TU Vienna, University of Athens, University of Edinburgh
### [TxChain: Efficient Cryptocurrency Light Clients via Contingent Transaction Aggregation](https://eprint.iacr.org/2020/580.pdf)
Read abstract
Cryptocurrency light- or simplified payment verification (SPV) clients allow nodes with limited resources to efficiently verify execution of payments. Instead of downloading the entire blockchain, only block headers and selected transactions are stored. Still, the storage and bandwidth cost, linear in blockchain size, remain non-negligible, especially for smart contracts and mobile devices: as of April 2020, these amount to 50 MB in Bitcoin and 5 GB in Ethereum.
Recently, two improved sublinear light clients were proposed: to validate the blockchain, NIPoPoWs and FlyClient only download a polylogarithmic number of block headers, sampled at random. The actual verification of payments, however, remains costly: for each verified transaction, the corresponding block must too be downloaded. This yields NIPoPoWs and FlyClient only effective under low transaction volumes.
We present TxChain, a novel mechanism to maintain efficiency of light clients even under high transaction volumes. Specifically, we introduce the concept of contingent transaction aggregation, where proving inclusion of a single contingent transaction implicitly proves that n other transactions exist in the blockchain. To verify n payments, TxChain requires only a single transaction in the best (n≤c), and n/c+logc(n) transactions in the worst case (n>c). We deploy TxChain on Bitcoin without consensus changes and implement a soft fork for Ethereum. To demonstrate effectiveness in the cross-chain setting, we implement TxChain as a smart contract on Ethereum to efficiently verify Bitcoin payments.
- **Zamyatin A**, Avarikioti Z, Perez D, Knottenbelt WJ,
- 4th International Workshop on Cryptocurrencies and Blockchain Technology - CBT 2020
- In collaboration with Imperial College London and ETH Zurich
### [Promise: Leveraging Future Gains for Collateral Reduction](https://eprint.iacr.org/2020/532.pdf)
Read abstract
Collateral employed in cryptoeconomic protocols protects against the misbehavior of economically rational agents, compensating honest users for damages and punishing misbehaving parties. The introduction of collateral, however, carries three disadvantages: (i) requiring agents to lock up a substantial amount of collateral can be an entry barrier, limiting the set of candidates to wealthy agents; (ii) affected agents incur ongoing opportunity costs as the collateral cannot be utilized elsewhere; and (iii) users wishing to interact with an agent on a frequent basis (e.g., with a service provider to facilitate second-layer payments), have to ensure the correctness of each interaction individually instead of subscribing to a service period in which interactions are secured by the underlying collateral.
We present Promise, a subscription mechanism to decrease the initial capital requirements of economically rational service providers in cryptoeconomic protocols. The mechanism leverages future income (such as service fees) prepaid by users to reduce the collateral actively locked up by service providers, while sustaining secure operation of the protocol. Promise is applicable in the context of multiple service providers competing for users. We provide a model for evaluating its effectiveness and argue its security. Demonstrating Promise's applicability, we discuss how Promise can be integrated into a cross-chain interoperability protocol, XCLAIM, and a second-layer scaling protocol, NOCUST. Last, we present an implementation of the protocol on Ethereum showing that all functions of the protocol can be implemented in constant time complexity and Promise only adds USD 0.05 for a setup per user and service provider and USD 0.01 per service delivery during the subscription period.
- **Harz D**, Gudgeon L, Khalil R, **Zamyatin A**
affiliations: Imperial College London
- International Conference on Mathematical Research for Blockchain Economy 2020
- In collaboration with Imperial College London
### [XCLAIM: Trustless, Interoperable Cryptocurrency-Backed Assets](https://eprint.iacr.org/2018/643.pdf)
Read abstract
Building trustless cross-blockchain trading protocols is challenging. Centralized exchanges thus remain the preferred route to execute transfers across blockchains. However, these services require trust and therefore undermine the very nature of the blockchains on which they operate. To overcome this, several decentralized exchanges have recently emerged which offer support for atomic cross-chain swaps (ACCS). ACCS enable the trustless exchange of cryptocurrencies across blockchains, and are the only known mechanism to do so. However, ACCS suffer significant limitations; they are slow, inefficient and costly, meaning that they are rarely used in practice.
We present XCLAIM: the first generic framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets (CbAs). XCLAIM offers protocols for issuing, transferring, swapping and redeeming CbAs securely in a non-interactive manner on existing blockchains. We instantiate XCLAIM between Bitcoin and Ethereum and evaluate our implementation; it costs less than USD 0.50 to issue an arbitrary amount of Bitcoin-backed tokens on Ethereum. We show XCLAIM is not only faster, but also significantly cheaper than atomic cross-chain swaps. Finally, XCLAIM is compatible with the majority of existing blockchains without modification, and enables several novel cryptocurrency applications, such as cross-chain payment channels and efficient multi-party swaps.
- **Zamyatin A**, **Harz D**, Lind J, Panayiotou P, Arthur G, Knottenbelt WJ
- IEEE Symposium on Security and Privacy (S&P)
- In collaboration with Imperial College London, SBA Research
### [SoK: Decentralized Finance (DeFi)](https://arxiv.org/abs/2101.08778)
Read abstract
Decentralized Finance (DeFi), a blockchain powered peer-to-peer financial system, is mushrooming. One and a half years ago the total value locked in DeFi systems was approximately 700m USD, now, as of September 2021, it stands at around 100bn USD. The frenetic evolution of the ecosystem has created challenges in understanding the basic principles of these systems and their security risks. In this Systematization of Knowledge (SoK) we delineate the DeFi ecosystem along the following axes: its primitives, its operational protocol types and its security. We provide a distinction between technical security, which has a healthy literature, and economic security, which is largely unexplored, connecting the latter with new models and thereby synthesizing insights from computer science, economics and finance. Finally, we outline the open research challenges in the ecosystem across these security types.
- Werner S, Perez D, Gudgeon L, Klages-Mundt A, **Harz D**, Knottenbelt WJ
- In collaboration with Imperial College London, Cornell University
### [Stablecoins 2.0: Economic Foundations and Risk-based Models](https://arxiv.org/pdf/2006.12388.pdf)
Read abstract
Stablecoins are one of the most widely capitalized type of cryptocurrency. However, their risks vary significantly according to their design and are often poorly understood. We seek to provide a sound foundation for stablecoin theory, with a risk-based functional characterization of the economic structure of stablecoins. First, we match existing economic models to the disparate set of custodial systems. Next, we characterize the unique risks that emerge in non-custodial stablecoins and develop a model framework that unifies existing models from economics and computer science. We further discuss how this modeling framework is applicable to a wide array of cryptoeconomic systems, including cross-chain protocols, collateralized lending, and decentralized exchanges. These unique risks yield unanswered research questions that will form the crux of research in decentralized finance going forward.
- Klages-Mundt A, **Harz D**, Gudgeon L, Liu J, Minca A
- ACM conference on Advances in Financial Technologies (AFT’20)
- In collaboration with Cornell University, Imperial College London
### [The Decentralized Financial Crisis](https://arxiv.org/pdf/2002.08099.pdf)
Read abstract
The Global Financial Crisis of 2008, caused by the accumulation of excessive financial risk, inspired Satoshi Nakamoto to create Bitcoin. Now, more than ten years later, Decentralized Finance (DeFi), a peer-to-peer financial paradigm which leverages blockchain-based smart contracts to ensure its integrity and security, contains over 702m USD of capital as of April 15th, 2020. As this ecosystem develops, it is at risk of the very sort of financial meltdown it is supposed to be preventing. In this paper we explore how design weaknesses and price fluctuations in DeFi protocols could lead to a DeFi crisis. We focus on DeFi lending protocols as they currently constitute most of the DeFi ecosystem with a 76% market share by capital as of April 15th, 2020.
First, we demonstrate the feasibility of attacking Maker's governance design to take full control of the protocol, the largest DeFi protocol by market share, which would have allowed the theft of 0.5bn USD of collateral and the minting of an unlimited supply of DAI tokens. In doing so, we present a novel strategy utilizing so-called flash loans that would have in principle allowed the execution of the governance attack in just two transactions and without the need to lock any assets. Approximately two weeks after we disclosed the attack details, Maker modified the governance parameters mitigating the attack vectors. Second, we turn to a central component of financial risk in DeFi lending protocols. Inspired by stress-testing as performed by central banks, we develop a stress-testing framework for a stylized DeFi lending protocol, focusing our attention on the impact of a drying-up of liquidity on protocol solvency. Based on our parameters, we find that with sufficiently illiquidity a lending protocol with a total debt of 400m USD could become undercollateralized within 19 days.
- Gudgeon L, Perez D, **Harz D**, Livshits B, Gervais A
- 2020 Crypto Valley Conference on Blockchain Technology (CVCBT)
- In collaboration with Imperial College London
### [Commit-Chains: Secure, Scalable Off-Chain Payments](https://eprint.iacr.org/2018/642.pdf)
Read abstract
Current permissionless blockchains suffer from scalability limitations. To scale without changing the underlying blockchain, one avenue is to lock funds into blockchain smart-contracts (collateral) and enact transactions outside, or off- the blockchain, via accountable peer-to-peer messages. Disputes among peers are resolved with appropriate collateral redistribution on the blockchain. In this work we lay the foundations for commit-chains, a novel off-chain scaling solution for existing blockchains where an untrusted and non-custodial operator commits the state of its user account balances via constant-sized, periodic checkpoints. Users dispute operator misbehavior via a smart contract. The commit-chain paradigm enables for the first time that off-chain users can receive payments while being offline. Moreover, locked funds can be managed efficiently at constant communication costs, alleviating collateral fragmentation.
We instantiate two account-based commit-chain constructions: NOCUST, based on a cost-effective challenge-response dispute mechanism; and NOCUST-ZKP, which provides provably correct operation via zkSNARKs. These constructions offer a trade-off between correctness, verification, and efficiency while both are practical and ensure key properties such as balance safety; that is, no honest user loses coins. We implemented both constructions on a smart contract enabled blockchain. Our evaluation demonstrates that NOCUST's operational costs in terms of computation and communication scale logarithmically in the number of users and transactions, and allow very efficient lightweight clients (a user involved in e.g. 100 daily transactions only needs to store a constant 46 kb of data, allowing secure payments even on mobile devices). NOCUST is operational in production since March 2019.
- Khalil R, **Zamyatin A**, Felley G, Moreno-Sanchez P, Gervais A
- In collaboration with Imperial College London, TU Wien, Liquidity Network
### [Pay To Win: Cheap, Crowdfundable, Cross-chain Algorithmic Incentive Manipulation Attacks on PoW Cryptocurrencies](https://eprint.iacr.org/2019/775.pdf)
Read abstract
In this paper we extend the attack landscape of bribing attacks on cryptocurrencies by presenting a new method, which we call Pay-To-Win (P2W). To the best of our knowledge, it is the first approach capable of facilitating double-spend collusion across different blockchains. Moreover, our technique can also be used to specifically incentivize transaction exclusion or (re)ordering. For our construction we rely on smart contracts to render the payment and receipt of bribes trustless for the briber as well as the bribee. Attacks using our approach are operated and financed out-of-band i.e., on a funding cryptocurrency, while the consequences are induced in a different target cryptocurrency. Hereby, the main requirement is that smart contracts on the funding cryptocurrency are able to verify consensus rules of the target. For a concrete instantiation of our P2W method, we choose Bitcoin as a target and Ethereum as a funding cryptocurrency. Our P2W method is designed in a way that reimburses collaborators even in the case of an unsuccessful attack. Interestingly, this actually renders our approach approximately one order of magnitude cheaper than comparable bribing techniques (e.g., the whale attack). We demonstrate the technical feasibility of P2W attacks through publishing all relevant artifacts of this paper, ranging from calculations of success probabilities to a fully functional proof-of-concept implementation, consisting of an Ethereum smart contract and a Python client.
- Judmayer A, Stifter N, **Zamyatin A**, Tsabary I, Eyal I, Gazi P, Meiklejohn S, Weippl E
- In collaboration with SBA Research, TU Wien, Imperial College London, Technion, IC3, IOHK, and UCL
---
## Token Registry
import tokenListData from '@gobob/tokenlist/tokenlist.json';
# Token Registry
Various ERC-20 tokens originally deployed to Ethereum also have corresponding "bridged" representations on BOB Mainnet.
:::info Do Your Own Research
Tokens listed on this page are provided for convenience only.
The presence of a token on this page does not imply any endorsement of the token or its minter.
:::
## BOB Mainnet
export const TokenTable = () => {
// Sort tokens alphabetically by name
const tokenList = tokenListData.tokens;
const bobTokens = tokenList.filter(token => token.chainId === 60808);
const mainnetTokens = tokenList.filter(token => token.chainId === 1);
const mainnetTokensMapping = mainnetTokens.reduce((acc, token) => {
acc[token.extensions.tokenId] = token;
return acc;
}, {});
const sortedTokens = bobTokens.toSorted((a, b) => a.name.localeCompare(b.name));
const formatAddress = (address) => {
return `${address.slice(0, 6)}...${address.slice(-4)}`;
};
return (
Name
Symbol
L1 Token
L2 Token
Bridge L1
Bridge L2
{sortedTokens.map((token, index) => {
const bobBridgeAddress = token.extensions?.bridge?.["1"];
const mainnetToken = mainnetTokensMapping[token.extensions.tokenId];
const mainnetBridgeAddress = mainnetToken?.extensions?.bridge?.["60808"];
// L1 Token
let l1Token = 'L2 Native Token';
if (mainnetBridgeAddress && mainnetToken?.address) {
const shortL1 = formatAddress(mainnetToken?.address);
l1Token = (
{shortL1}
);
} else if (token.address === '0x0000000000000000000000000000000000000000') {
l1Token = 'Native Asset';
}
// L2 Token
const l2Token = token.address === '0x0000000000000000000000000000000000000000' ? (
'Native Asset'
) : (
{formatAddress(token.address)}
);
// Bridge addresses
let bridgeL1 = 'N/A';
let bridgeL2 = 'N/A';
if (mainnetBridgeAddress) {
const shortBridgeL1 = formatAddress(mainnetBridgeAddress);
bridgeL1 = (
{shortBridgeL1}
);
}
if (bobBridgeAddress) {
const shortBridgeL2 = formatAddress(bobBridgeAddress);
bridgeL2 = (
{shortBridgeL2}
);
}
return (
{token.name}
{token.symbol}
{l1Token}
{l2Token}
{bridgeL1}
{bridgeL2}
);
})}
);
};
## Bridge Information
### Standard Bridge
- **L1:** [0x3F6c...1f7](https://etherscan.io/address/0x3F6cE1b36e5120BBc59D0cFe8A5aC8b6464ac1f7)
- **L2:** [0x4200...0010](https://explorer.gobob.xyz/address/0x4200000000000000000000000000000000000010)
### USDC Bridge
- **L1:** [0x450D...aCBb](https://etherscan.io/address/0x450D55a4B4136805B0e5A6BB59377c71FC4FaCBb)
- **L2:** [0xe497...cE90](https://explorer.gobob.xyz/address/0xe497788F8Fcc30B773C9A181a0FFE2e60645cE90)
### wstETH Bridge
- **L1:** [0x091d...5B72](https://etherscan.io/address/0x091dF5E1284E49fA682407096aD34cfD42B95B72)
- **L2:** [0xd155...c4d1](https://explorer.gobob.xyz/address/0xd1559523374D93972E0F7fE1AA98642754f5c4d1)
### Chainlink CCIP
Cross-chain interoperability protocol for select tokens like SolvBTC, xSolvBTC, and uniBTC.
## TokenList Integration
This token registry is automatically generated from our **[tokenlist.json](https://raw.githubusercontent.com/bob-collective/bob/master/tokenlist/tokenlist.json)** which follows the [Uniswap Token List Standard](https://tokenlists.org/) with bridge extensions.
**Total Tokens:** {tokenListData.tokens.length}
### Bridge Extensions
Each bridged token includes bridge information in its `extensions.bridge` field:
```json
{
"name": "Wrapped BTC",
"address": "0x0555E30da8f98308EdB960aa94C0Db47230d2B9c",
"symbol": "WBTC",
"decimals": 8,
"chainId": 60808,
"logoURI": "https://...",
"extensions": {
"bridge": {
"1": "0x2260fac5e5542a773aa44fbcfedf7c193bc2c599",
}
}
}
```
### Usage Examples
```javascript
// Fetch the tokenlist
const response = await fetch(
'https://raw.githubusercontent.com/bob-collective/bob/master/tokenlist/tokenlist.json',
);
const tokenList = await response.json();
// Find WBTC token info
const wbtc = tokenList.tokens.find((token) => token.symbol === 'WBTC');
console.log(wbtc.address); // L2 WBTC address
// Get bridge information
const bridgeInfo = wbtc.extensions?.bridgeInfo?.['1'];
console.log(bridgeInfo.tokenAddress); // L1 WBTC address
console.log(bridgeInfo.destBridgeAddress); // L1 bridge address
console.log(bridgeInfo.originBridgeAddress); // L2 bridge address
```
---
## Account Abstraction
BOB supports multiple account abstraction solutions, including the latest EIP-7702 standard introduced with Ethereum's Pectra upgrade. This enables enhanced user experiences with gasless transactions, batch operations, and seamless wallet integrations.
## EIP-7702 Support
With the latest OP stack update, BOB now supports [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), a groundbreaking Ethereum standard that enables externally owned accounts (EOAs) to execute smart contract functionality temporarily. This provides [superior UX](https://blog.thirdweb.com/eip-7702/) compared to traditional account abstraction methods.
### Key Benefits
EIP-7702 on BOB enables:
- **Batch Transactions**: Execute multiple operations in a single atomic transaction (token approvals, swaps, transfers)
- **Gas Sponsorship**: Allow third parties to pay gas fees for your transactions
- **Temporary Delegation**: Grant scoped permissions without exposing private keys
- **Enhanced Security**: Trustless execution without requiring smart contract deployment
- **Backward Compatibility**: Full compatibility with existing ERC-4337 infrastructure
### How It Works
EIP-7702 introduces a new transaction type (0x04) that allows EOAs to:
1. Create an authorization list specifying which smart contract to delegate execution to
2. Temporarily execute smart contract logic from their own address
3. Return to normal EOA behavior after transaction completion
### Implementation on BOB
BOB's EIP-7702 implementation provides:
- **Native Support**: Integrated into BOB's OP stack upgrade
- **Bitcoin Wallet Integration**: Use EIP-7702 features with Bitcoin wallets through BOB Gateway
- **DeFi Protocol Support**: Enhanced interactions with lending, staking, and trading protocols
- **Cross-Chain Operations**: Seamless integration with BOB's interoperability layer
### Getting Started
To use EIP-7702 on BOB:
1. **Connect a Compatible Wallet**: Use any EOA wallet (MetaMask, Rabby, etc.)
2. **Interact with DApps**: Look for applications offering batch operations or sponsored transactions
3. **Bitcoin Integration**: Use BOB Gateway to control EVM operations from Bitcoin wallets
:::info EIP-7702 Resources
For technical implementation details and code examples:
- [EIP-7702 Official Specification](https://eips.ethereum.org/EIPS/eip-7702)
- [QuickNode Implementation Guide](https://www.quicknode.com/guides/ethereum-development/smart-contracts/eip-7702-smart-accounts)
- [Thirdweb EIP-7702 Guide](https://blog.thirdweb.com/eip-7702/)
:::
## Safe Wallet
[Safe Wallet](https://safe.gobob.xyz/welcome) (formerly known as Gnosis Safe multisig) is a smart contract wallet. Featuring 130+ ecosystem apps and the ability to create your own modules and guard, Safe is the most trusted decentralized custody protocol and collective asset management platform.
## BTC Connect
Made by [Particle Network](https://particle.network/), BTC Connect enables users to control ERC-4337 smart accounts (i.e. smart contract wallets) on EVM-chains with their native Bitcoin wallets (e.g. UniSat). Interactions with products deployed on BOB can be conducted via Bitcoin wallet signatures using their pre-built modal. Learn more in their [docs](https://docs.particle.network/developers/btc-connect).
---
## Block Explorers
## Blockscout
[Blockscout](https://www.blockscout.com/) is a comprehensive blockchain explorer for BOB that provides detailed information about transactions, blocks, tokens, and smart contracts. It offers a user-friendly interface for tracking on-chain activity and verifying contract deployments.
**Features**
- Transaction tracking and verification
- Block information and statistics
- Token transfers and balances
- Smart contract verification
- Gas price tracking
- Network statistics
**Supported Networks**
- [BOB Mainnet](https://explorer.gobob.xyz/)
- [BOB Sepolia (Testnet)](ttps://bob-sepolia.explorer.gobob.xyz/)
## OKX Explorer
[OKX Explorer](https://web3.okx.com/explorer) provides a powerful interface for exploring the BOB blockchain, offering real-time data and analytics for transactions, blocks, and network activity.
**Features**
- Real-time transaction monitoring
- Network statistics and metrics
- Token tracking and analytics
- Block information
- Gas price monitoring
- Active address tracking
**Supported Networks**
- [BOB Mainnet](https://web3.okx.com/explorer/bob)
## Tenderly
[Tenderly](https://tenderly.co/) is a comprehensive blockchain development platform that provides advanced debugging, monitoring, and analytics tools for BOB developers.
**Features**
- Transaction debugging and simulation
- Smart contract monitoring
- Gas profiling and optimization
- Real-time alerts and notifications
- Detailed transaction traces
- Contract verification
**Supported Networks**
- [BOB Mainnet](https://dashboard.tenderly.co/public/bob)
---
## Cross-chain
## Chainlink CCIP
BOB has chosen Chainlink’s [Cross-Chain Interoperability Protocol (CCIP)](https://chain.link/cross-chain) as its canonical bridge solution. CCIP will complement BOB’s [trust-minimized BitVM bridge to Bitcoin](https://blog.gobob.xyz/posts/bob-announces-trust-minimized-bitcoin-bridge-prototype-powered-by-bitvm) and native bridge to Ethereum, supporting BOB’s mission to position Bitcoin as the backbone of DeFi.
This means asset issuers looking to expand their token cross-chain can benefit from CCIP. This applies both to assets issued natively on BOB that want to expand to other chains, as well as native tokens on other chains looking to bridge into the BOB ecosystem.
Chainlink CCIP enables developers to build secure cross-chain apps that can transfer tokens, send messages, and initiate actions across blockchains. Through the [Cross-Chain Token (CCT)](https://blog.chain.link/ccip-v-1-5-upgrade/) standard, CCIP enables token developers to integrate new and existing tokens with CCIP in a self-serve manner in minutes. CCTs support self-serve deployments, full control and ownership for developers, enhanced programmability, and zero-slippage transfers. CCIP is built with [defense-in-depth security](https://blog.chain.link/ccip-security-features/) and is powered by Chainlink oracle networks—a proven standard with a track record of securing tens of billions of dollars and enabling over $18 trillion in onchain transaction value.
A selection of bridging apps powered by CCIP:
- [BOB Bridge](https://app.gobob.xyz/bridge)—Native bridging from Ethereum mainnet, including CCT-powered tokens.
- [Transporter](https://www.transporter.io/)—an intuitive bridging app built in association with the Chainlink Foundation.
- [XSwap](https://xswap.link/)—a cross-chain swaps protocol powered by Chainlink CCIP.
- [Interport](https://interport.fi/)—a comprehensive cross-chain hub powered by Chainlink CCIP.
Key CCIP developer tools:
- [CCIP official documentation](https://docs.chain.link/ccip)—start adopting CCIP into your cross-chain application.
- [CCIP Token Manager](https://tokenmanager.chain.link/)—an intuitive front-end web interface for the deployment of new and management of existing CCTs by their developers, including no-code guided deployments and configuration tools.
- [CCIP SDK](https://docs.chain.link/ccip/ccip-javascript-sdk)—a software development kit that streamlines the process of integrating CCIP, allowing developers to use JavaScript to create a token transfer frontend dApp.
If you require technical advice or wish to consult on your project's implementation, please contact a CCIP expert through Chainlink’s [CCIP contact form](https://chain.link/ccip-contact).
#### Supported Networks
- [BOB Mainnet](https://docs.chain.link/ccip/directory/mainnet/chain/bitcoin-mainnet-bob-1)
- [BOB Sepolia](https://docs.chain.link/ccip/directory/testnet/chain/bitcoin-testnet-sepolia-bob-1)
## Hyperlane
[Hyperlane](https://hyperlane.xyz/) is a permissionless interoperability protocol for cross-chain communication. It enables message passing and asset transfers across different chains without relying on centralized intermediaries or requiring any permissions.
See [Hyperlane's docs](https://docs.hyperlane.xyz/docs/intro) to learn how you can integrate their protocol. Their [GitHub](https://github.com/hyperlane-xyz) and [Discord](https://discord.com/invite/hyperlane) are available as well.
#### Supported Networks
- [BOB Mainnet](https://docs.hyperlane.xyz/docs/reference/domains)
## LayerZero
LayerZero is a technology that enables applications to move data across blockchains, uniquely supporting censorship-resistant messages and permissionless development through immutable smart contracts. Projects on BOB can connect to 35+ supported blockchains using LayerZero's contracts.
Visit [LayerZero's documentation](https://docs.layerzero.network/v2) to learn more about their supported chains, data schema, omnichain fungible tokens (OFTs), and other useful guides. Their [GitHub repository](https://github.com/LayerZero-Labs) and [Discord](https://discord-layerzero.netlify.app/discord) are also wonderful resources for getting started.
#### Supported Networks
- [BOB Mainnet](https://docs.layerzero.network/v2/developers/evm/technical-reference/deployed-contracts#bob)
- [BOB Testnet](https://docs.layerzero.network/v2/developers/evm/technical-reference/deployed-contracts#bob-testnet)
:::warning BOB Testnet is not BOB Sepolia
For historical reasons, the smart contracts in the link above point to our previous testnet, "BOB Testnet". While it has been replaced by our newer testnet, "BOB Sepolia", the LayerZero contracts remain live on BOB Testnet.
:::
---
## Data Indexers
## Goldsky
[Goldsky](https://goldsky.com/) is a data indexer for web3 builders, offering high-performance subgraph hosting and realtime data replication pipelines.
Their [subgraphs](https://goldsky.com/products/subgraphs) are fully spec-compliant with every subgraph on The Graph’s hosted and decentralized networks. Smart APIs automatically create a subgraph from any smart contract ABI, so you don’t have to.
[Mirror](https://goldsky.com/products/mirror) streams live crypto data to your backend database, giving you more control & flexibility than traditional APIs.
**Supported Networks**
- BOB Mainnet
- BOB Sepolia (Testnet)
## SQD
[SQD](https://sqd.dev/) is a decentralized hyper-scalable data platform optimized for providing efficient, permissionless access to large volumes of data. It currently serves historical on-chain data, including event logs, transaction receipts, traces, and per-transaction state diffs. SQD offers a powerful toolkit for creating custom data extraction and processing pipelines, achieving an indexing speed of up to 150k blocks per second.
To get started, visit the [documentation](https://docs.sqd.dev/) or see [EVM examples](https://github.com/subsquid-labs/squid-evm-examples) of what you can build with SQD.
**Supported Networks**
- BOB Mainnet
## Sim IDX
[Sim IDX](https://sim.dune.com/) is a blockchain indexing framework centered around a Solidity listener contract that runs in an instrumented EVM. Developers define their data requirements using Solidity in a listener contract, specifying triggers for on-chain events or function calls. The framework then handles the entire indexing pipeline, from efficient historical backfilling to real-time data ingestion. The resulting data is stored in a dedicated PostgreSQL instance, with a schema derived directly from the events defined in the listener contract.
The Sim IDX framework provides a complete development environment, including a CLI for project management, a managed database, and a serverless API layer using Cloudflare Workers, Hono, and Drizzle.
To get started, visit the [developer docs](https://docs.sim.dune.com/idx).
**Supported Networks**
- BOB Mainnet
- Ethereum
- Base
- Unichain
- World
- Zora
- Ink
- Soneium
- Mode
- Sepolia
- Base Sepolia
---
## Developer Tools
## Tenderly
[Tenderly](https://tenderly.co/) is a comprehensive blockchain development platform that provides a suite of tools for building, testing, and monitoring applications on BOB.
### Virtual TestNets
Tenderly's Virtual TestNets provide a flexible, zero-setup development environment that replaces traditional testnets.
**Features**
- Fork any EVM chain
- Complete mainnet data and state syncing
- Built-in private and public explorers
- Unlimited faucet for native and ERC-20 tokens
- Team collaboration tools
### Transaction Simulator
Preview transaction outcomes before sending them on-chain for a risk-free development experience.
**Features**
- Simulate any transaction with complete control
- Preview exact transaction outcomes
- Test complex scenarios
- Validate contract interactions
- Gas estimation and optimization
### Debugging Tools
Advanced debugging tools for smart contract development and testing.
**Features**
- Granular smart contract debugging
- Full stack traces and human-readable errors
- Gas profiling and optimization
- Contract state inspection
- Event monitoring and analysis
### Monitoring
Real-time monitoring and alerting for on-chain events and contract interactions.
**Features**
- Real-time alerts and notifications
- Custom webhook integrations
- Contract state monitoring
- Transaction monitoring
- Gas price tracking
- Error detection and reporting
**Supported Networks**
- BOB Mainnet
- BOB Sepolia (Testnet)
---
## Builder Tools
BOB is fully EVM compatible and built on the OP Stack, making it easy for Ethereum developers to deploy and use their favorite tools on BOB. Below you'll find a curated list of tools and services that help you build, test, and deploy on BOB.
:::info **Are you a team offering builder tools and have deployed them to BOB?**
Create a PR to add your tool to this page and help the BOB builder community grow!
:::
## Available Tools
- [Account Abstraction](./account-abstraction.md)
- [Block Explorers](./block-explorers.md)
- [Cross-Chain](./cross-chain.md)
- [Data Indexers](./data-indexers.md)
- [Developer Tools](./developer-tools.md)
- [Node Providers](./node-providers.md)
- [Onboarding](./onboarding.md)
- [Oracles](./oracles.md)
- [Rust zkVM](./rust-zkvm.md)
- [Social Login](./social-login.md)
---
## Node Providers
## Conduit
Follow [Conduit's guide](https://docs.conduit.xyz/guides/run-a-node/op-stack-node) to run your own BOB node. Search "BOB" on their [Browse rollups page](https://app.conduit.xyz/browse-networks) and click "Run a node" to get started.
**Supported Networks**
- BOB Mainnet
## Tenderly
[Tenderly Node](https://tenderly.co/web3-gateway) provides a fast and reliable hosted node solution with a built-in suite of developer tooling and infrastructure building blocks covering your whole development lifecycle. Develop, test, deploy, and monitor your app on BOB with their [free and paid plans](https://tenderly.co/pricing).
**Supported Networks**
- [BOB Mainnet](https://bob.gateway.tenderly.co)
## dRPC
[dRPC](https://drpc.org/?utm_source=docs&utm_medium=bob) provides geo-distributed and auto-scalable RPC nodes that enhances security, reliability, and cost-efficiency for Web3 companies of all sizes. dRPC also supports Websockets.
**Supported Networks**
- [BOB Mainnet](https://drpc.org/chainlist/bob?utm_source=docs&utm_medium=bob)
- [BOB Sepolia](https://drpc.org/chainlist/bob?utm_source=docs&utm_medium=bob#bob-testnet) (Testnet)
---
## Onboarding
## thirdweb
[**Universal Bridge**](https://thirdweb.com/connect/universal-bridge) is a comprehensive Web3 payment solution to help you monetize any app or game.
With Universal Bridge, your users can **onramp, bridge, and swap** on any EVM chain — with any EVM token or fiat — thanks to its **automatic cross-chain routing**.
Plus, developers can **earn from day one** using the **fee-sharing mechanism** and **easy implementation**.
**Supported Networks**
- [BOB Mainnet](https://thirdweb.com/bridge?chainId=60808)
### Universal Bridge Features
- Let users pay for assets in any EVM token on BOB right in your app
- Automatic cross-chain routing for seamless transactions
- Earn from day one with fee-sharing mechanism
- Access ready-made UI component for easy implementation
[Learn more in the full documentation on thirdweb’s Universal Bridge](https://portal.thirdweb.com/connect/pay/overview)
### Get Started with thirdweb Universal Bridge
[How to get started with Universal Bridge](https://portal.thirdweb.com/connect/pay/get-started)
### See Universal Bridge in Action
Want to see how Universal Bridge works? Check it out under the hood
```jsx
import { createThirdwebClient } from "thirdweb";
import { PayEmbed } from "thirdweb/react";
import { createWallet } from "thirdweb/wallets";
import { defineChain } from "thirdweb";
const client = createThirdwebClient({
clientId: "....",
});
function Example() {
return (
);
}
```
[**See how the Buy Crypto flow works in the playground**](https://playground.thirdweb.com/connect/pay)
## Banxa
[Banxa](https://banxa.com) is a payment service provider that allows users to buy and sell cryptocurrencies using fiat currencies. Banxa provides an easy-to-integrate solution for applications looking to offer fiat on-ramps to their users.
You can access Banxa's checkout system for BOB via this link:
[https://checkout.banxa.com/?coinType=ETH&fiatType=EUR&blockchain=BOB](https://checkout.banxa.com/?coinType=ETH&fiatType=EUR&blockchain=BOB)
Banxa supports multiple cryptocurrencies and blockchain networks. For BOB specifically, the following tokens are supported:
- ETH (Ethereum)
- USDC (USD Coin)
For a complete list of all supported cryptocurrencies and blockchains, visit [Banxa's documentation](https://docs.banxa.com/docs/available-cryptocurrencies-and-blockchains).
To integrate Banxa into your BOB application, follow the [integration tutorial](https://docs.banxa.com/docs/tutorial). The process typically involves setting up a partner account, implementing the API or iframe checkout solution, configuring webhooks for order status updates, and testing before going live
---
## Oracles
## Acurast
[Acurast](https://acurast.com/) is a zero-trust application platform with universal interoperability.
Acurast provides [Chainlink-compatible Price Feeds](https://docs.acurast.com/integrations/evm/#chainlink-compatible-price-feeds) on BOB. See their guide on how to integrate with Acurast and the deployed price feeds.
## API3
The [API3 Market](https://market.api3.org/bob) provides access to 200+ price feeds on [BOB Mainnet](https://market.api3.org/bob) and [Testnet](https://market.api3.org/bob-sepolia-testnet). The price feeds operate as a native push oracle and can be activated instantly via the Market UI.
The price feeds are delivered by an aggregate of [first-party oracles](https://old-docs.api3.org/airnode/v0.10/#designed-for-first-party-oracles) using signed data and support [OEV recapture](https://docs.api3.org/oev-searchers/in-depth/oev-searching.html).
Unlike traditional data feeds, reading [API3 price feeds](https://docs.api3.org/guides/dapis/) enables dApps to auction off the right to update the price feeds to searcher bots which facilitates more efficient liquidation processes for users and LPs of DeFi money markets. The OEV recaptured is returned to the dApp.
Check out these guides on how to:
- [Use dAPIs on the Market](https://docs.api3.org/guides/dapis/subscribing-to-dapis/)
- [Read a dAPI](https://docs.api3.org/guides/dapis/read-a-dapi/)
## RedStone
[RedStone](https://redstone.finance/) is a modular Oracle providing Pull and Push model on BOB.
1. You can use multiple Push (RedStone Classic) feeds including BTC, ETH, STONE, USDT, USDC, wstETH following the [addresses in the docs](https://docs.redstone.finance/docs/smart-contract-devs/price-feeds).
2. Integrate versatile Pull (RedStone Core) feeds with low-latency and innovative design of attaching signed data packages in transaction call-data by [following these steps](https://docs.redstone.finance/docs/smart-contract-devs/get-started/redstone-core).
**Supported Networks**
- BOB Mainnet: [0x2d484E029b8Ae5cA6335DAe11fC726B232bE87D1](https://explorer.gobob.xyz/address/0x2d484E029b8Ae5cA6335DAe11fC726B232bE87D1) STONE, USDC, USDT, BTC, ETH, wstETH multi-price feed
## DIA
[DIA](https://www.diadata.org/) provides [price feeds](https://www.diadata.org/app/price/) for 20,000+ assets on BOB.
See [this guide](https://docs.diadata.org/introduction/intro-to-dia-oracles/access-the-oracle) to learn how to use DIA price feeds. Learn more about DIA’s [data sourcing](https://docs.diadata.org/introduction/dia-technical-structure/data-sourcing) and [data computation](https://docs.diadata.org/introduction/dia-technical-structure/data-computation) architecture.
Here is an example of how to access a price value on DIA oracles:
1. Access your custom oracle smart contract on BOB.
2. Call `getValue(pair_name)` with `pair_name` being the full pair name such as `BTC/USD`. You can use the "Read" section on the explorer to execute this call.
3. The response of the call contains two values:
- The current asset price in USD with a fix-comma notation of 8 decimals.
- The UNIX timestamp of the last oracle update.
DIA has [oracle integration samples](https://docs.diadata.org/products/token-price-feeds/access-the-oracle) in Solidity and Vyper. For assistance, connect with the DIA team directly on [Discord](https://discord.gg/ZvGjVY5uvs) or [Telegram](https://t.me/diadata_org).
**Assets (BOB Mainnet)**
- WBTC/USD: [0x6Ae049df8FC215aC1A5f5226B220E51301FE7e3D](https://explorer.gobob.xyz/address/0x6Ae049df8FC215aC1A5f5226B220E51301FE7e3D)
- tBTC/USD: [0x7F1AD8fBb80A262cE5987439d2F4B52f1a426f55](https://explorer.gobob.xyz/address/0x7F1AD8fBb80A262cE5987439d2F4B52f1a426f55)
- USDC/USD: [0x13B6052B34c6A9Fe0419E5154826a1CB858f3181](https://explorer.gobob.xyz/address/0x13B6052B34c6A9Fe0419E5154826a1CB858f3181)
- USDT/USD: [0xF67Ce8007810e8e87B3871B104366b105a71bB55](https://explorer.gobob.xyz/address/0xF67Ce8007810e8e87B3871B104366b105a71bB55)
- ETH/USD: [0x27abC874f709fbc7b2af4153e875cf52C701725E](https://explorer.gobob.xyz/address/0x27abC874f709fbc7b2af4153e875cf52C701725E)
- wstETH/USD: [0xa6aEdd027Bc91569617c26EEB6146A2b9148788a](https://explorer.gobob.xyz/address/0xa6aEdd027Bc91569617c26EEB6146A2b9148788a)
- eSOV/USD: [0x3844E091e4058c7B8D96b3eCb676d0B40d1941d2](https://explorer.gobob.xyz/address/0x3844E091e4058c7B8D96b3eCb676d0B40d1941d2)
**Supported Networks**
- BOB Mainnet: [0x4d24e7c1cf0ed63bc8c6cb5a795af31fd8127c6b](https://explorer.gobob.xyz/address/0x4d24E7c1cF0ed63bc8c6cB5a795af31FD8127C6B)
## Tellor
[Tellor](https://tellor.io/) is a versatile oracle protocol that can provide any data type permissionlessly, with crypto-economic liveness and security.
To use Tellor data see their [integration guide](https://docs.tellor.io/tellor/getting-data/solidity-integration) and BOB related [contracts](https://docs.tellor.io/tellor/the-basics/contracts-reference#bob).
**Supported Networks**
BOB Mainnet:
- Token: [0x665060707c3Ea3c31b3eaBaD7F409072446E1D50](https://explorer.gobob.xyz/address/0x665060707c3Ea3c31b3eaBaD7F409072446E1D50)
- Oracle: [0x896419Ed2E0dC848a1f7d2814F4e5Df4b9B9bFcc](https://explorer.gobob.xyz/address/0x896419Ed2E0dC848a1f7d2814F4e5Df4b9B9bFcc)
- Governance: [0xC866DB9021fe81856fF6c5B3E3514BF9D1593D81](https://explorer.gobob.xyz/address/0xC866DB9021fe81856fF6c5B3E3514BF9D1593D81)
- Autopay: [0x9EA18BFDB50E9bb4A18F9d3Df7804E398F8fE0dc](https://explorer.gobob.xyz/address/0x9EA18BFDB50E9bb4A18F9d3Df7804E398F8fE0dc)
BOB Testnet:
- Token/Playground: [0x896419Ed2E0dC848a1f7d2814F4e5Df4b9B9bFcc](https://bob-sepolia.explorer.gobob.xyz/address/0x896419Ed2E0dC848a1f7d2814F4e5Df4b9B9bFcc)
- Oracle: [0xC866DB9021fe81856fF6c5B3E3514BF9D1593D81](https://bob-sepolia.explorer.gobob.xyz/address/0xC866DB9021fe81856fF6c5B3E3514BF9D1593D81)
- Governance: [0x6684E5DdbEe1b97E10847468cB5f4e38f3aB83FE](https://bob-sepolia.explorer.gobob.xyz/address/0x6684E5DdbEe1b97E10847468cB5f4e38f3aB83FE)
- Autopay: [0x89e44099f5E80484dcF48995080481214b9c2D7c](https://bob-sepolia.explorer.gobob.xyz/address/0x89e44099f5E80484dcF48995080481214b9c2D7c)
- QueryDataStorage: [0x9EA18BFDB50E9bb4A18F9d3Df7804E398F8fE0dc](https://bob-sepolia.explorer.gobob.xyz/address/0x9EA18BFDB50E9bb4A18F9d3Df7804E398F8fE0dc)
---
## Rust zkVM
## RISC Zero
The [RISC Zero zero-knowledge virtual machine](https://dev.risczero.com/api/zkvm/) (zkVM) lets you prove correct execution of arbitrary Rust code in your Ethereum contract. [For example](https://dev.risczero.com/api/blockchain-integration/bonsai-on-eth), any smart contract can call the RISC Zero Verifier contract to trustlessly verify that the zk proof of the off-chain computation is valid. While you can generate proofs on your own hardware, you can also use their [Bonsai API and SDK](https://dev.risczero.com/api/generating-proofs/remote-proving) to generate them.
**Supported Networks**
- BOB Mainnet
- BOB Sepolia (Testnet)
## zkVM Taproot Address Ownership Proofs
This demo uses [zkVM](https://dev.risczero.com/zkvm/) to prove ownership of a Bitcoin taproot address. A user submits a Bitcoin private key to zkVM, which will derive the public key and submit it to BOB Sepolia (Testnet). Because of the zero-knowledge (zk) part of zkVM, no information regarding the private key gets published. The proof is generated by [Bonsai](https://dev.risczero.com/bonsai/) and verified on-chain.
:::info Example Code
The code of the demo can be found in [this repository](https://github.com/bob-collective/demo-zkvm-taproot-address/).
:::
## Limitations, Notes and Warnings
This demo is a demonstration of the technical possibilities rather than something to use in production. In production, other approaches are more suitable, such as signing a message with the private key, and having zkVM check that signed message using the public key.
:::warning
It is important to note that while zkVM does not leak information about the private key, the private key _is_ received by the Bonsai API, which means that you have to trust this service to not steal your keys. As such, it is not recommended to use this demo on production accounts and generate a new throwaway key for trying this demo.
:::
Finally, taproot addresses are pretty flexible - the spending condition can be either pubkey-based (like P2PK) or script-based (like P2SH). This demo only works for taproot addresses of the former type. Specifically is written to work only with Bitcoin-core wallets, where wallets and addresses are created using the `ord` tool.
## Demo
### Prerequisites
This demo has the following prerequisites:
- [bitcoin-core](https://bitcoin.org/en/bitcoin-core/) version 23 or higher. Tests were done with version 25.
- [ord](https://github.com/ordinals/ord) for address and wallet generation.
- [risc0 dependencies](https://github.com/risc0/bonsai-foundry-template) for the zkVM program compilation.
- a [Bonsai API key](https://dev.risczero.com/bonsai/quickstart). The commands below will use `$API_KEY` - substitute this for your key.
### Running the Demo
To execute the demo, perform the following steps:
#### 1. Account Creation and Funding
Create a new Ethereum account using e.g. MetaMask, and [bridge some Sepolia ETH to BOB Sepolia](https://puff-bob-jznbxtoq7h.testnets.rollbridge.app/) - after funding your account using a [Sepolia faucet](https://sepolia-faucet.pk910.de/), if necessary. The private key of this account will be used in the commands below (substitute the `DEPLOYER_PRIVATE_KEY` variable).
#### 2. Deploy the Contracts
Deploy the necessary contracts (the Bonsai relay, verifier, and the TaprootRegister):
```bash
forge script script/Deploy.s.sol --rpc-url https://l2-fluffy-bob-7mjgi9pmtg.t.conduit.xyz --broadcast --verify --verifier blockscout --verifier-url 'https://explorerl2-fluffy-bob-7mjgi9pmtg.t.conduit.xyz/api?'
```
After running the command above, look for output like this:
```
== Logs ==
Deployed RiscZeroGroth16Verifier to [...]
Deployed BonsaiRelay to [...]
Image ID for taproot-derive is [...]
Deployed TaprootRegister to [...]
```
The commands below will use the `$BONSAI_RELAY` and `$TAPROOT_REGISTER` values - substitute those for the addresses logged above.
#### 3. Start the Relayer
Start a relayer client (and leave it running in the background):
```bash
BONSAI_API_URL=https://api.bonsai.xyz/ BONSAI_API_KEY=$API_KEY cargo run --bin bonsai-ethereum-relay-cli -- run --relay-address $BONSAI_RELAY --eth-node wss://l2-fluffy-bob-7mjgi9pmtg.t.conduit.xyz --eth-chain-id 901 --private-key $DEPLOYER_PRIVATE_KEY
```
#### 4. Start Bitcoin Core
Start a regtest Bitcoin daemon:
```bash
bitcoind -regtest -server -rpcuser=rpcuser -rpcpassword=rpcpassword -fallbackfee=0.0002 -blockfilterindex -txindex=1 -prune=0 -blockversion=4
```
#### 5. Create an Ordinals Wallet
Create an ordinals wallet:
```bash
ord --regtest --bitcoin-rpc-pass rpcpassword --bitcoin-rpc-user rpcuser wallet create
```
#### 6. Create a Taproot Address
Create a new taproot address:
```bash
ord --regtest --bitcoin-rpc-pass rpcpassword --bitcoin-rpc-user rpcuser wallet receive
```
#### 7. Prove Ownership of the Address
Now finally, initiate the proving of an address:
```bash
cargo run --bin taproot-prover -- --address 0000000000000000000000000000000000000001 --taproot-address $TAPROOT_ADDRESS_FROM_PREVIOUS_STEP --bonsai-api-key=$API_KEY
```
The command above, if it runs successfully, will initiate the generation of a zk-proof on the Bonsai server, and after completion (which can take a couple of minutes), it will submit it to BOB Sepolia (Testnet) for verification. After waiting a couple of minutes, you will be able to see the result in the explorer. Go to [the explorer](https://bob-sepolia.explorer.gobob.xyz) and search for the previously logged `$TAPROOT_REGISTER` address. Go to the "Internal Transactions", click the latest transaction, and click "Logs". You should see an `OwnershipProven` event, showing your Ethereum and taproot address.
## Diving into the Code
The guest program running inside the zkVM can be found in [methods/guest/src/main.rs](https://github.com/bob-collective/demo-zkvm-taproot-address/blob/main/methods/guest/src/main.rs) and [methods/guest/src/lib.rs](https://github.com/bob-collective/demo-zkvm-taproot-address/blob/main/methods/guest/src/lib.rs). This code takes the private key of the taproot address and a public EVM address (both encoded using the Ethereum ABI), and outputs the derived the bech32m address. The EVM address is passed through unprocessed. Note that in production you wouldn't want to do this, since you'd assume that the host is an untrusted component.
The code for extracting the private key associated with an address can be found in [taproot-prover/src/main.rs](https://github.com/bob-collective/demo-zkvm-taproot-address/blob/main/taproot-prover/src/main.rs). Note that this is not very straightforward, since with descriptor wallets the RPC commands for directly dumping private addresses do not work.
---
## Social Login
## Arcana Wallet
The [Arcana Network](https://arcana.network) SDKs enable web3 developers to use [social login](https://docs.arcana.network/concepts/social-login) to quickly onboard new users.
Authenticated users can instantly access the embedded, non-custodial [Arcana wallet](https://docs.arcana.network/concepts/anwallet/) from within the app to sign blockchain transactions.
Developers can leverage the [built-in gasless feature](https://docs.arcana.network/quick-start/gasless-standalone-quick-start) to sponsor gas fees for allowlisted blockchain transactions. The gasless transactions can be enabled for Arcana Wallet and third-party, browser-based wallets.
Developers need to follow these steps for integration:
1. **Register the app** with the [Arcana Developer Dashboard](https://dashboard.arcana.network/), and copy the unique client identifier for the app.
2. **Configure Auth SDK usage** via the dashboard, specify social login options, wallet user experience settings, gasless transaction settings, etc.
3. **Install the Arcana Auth SDK and use the client identifier to integrate the app**. Initialize the `AuthProvider`, then add a single line code to onboard users by calling the `connect()` method and enabling the plug-and-play login UI. After a successful user login, _Arcana wallet will automatically display within the app context_, enabling the user to sign blockchain transactions instantly.
:::note
Arcana wallet supports [JSON/RPC calls and web3 wallet operations](https://docs.arcana.network/web-sdk/auth-usage-guide#arcana-wallet-operations).
:::
## References
- [Social login Providers](https://docs.arcana.network/state-of-the-arcana-auth#app-login)
- [Blockchain networks](https://docs.arcana.network/state-of-the-arcana-auth#supported-blockchains)
- [Browsers](https://docs.arcana.network/state-of-the-arcana-auth#supported-browsers)
- [Supported App Types](https://docs.arcana.network/sdk-installation)
- [SDK Reference Guides](https://docs.arcana.network/dev-resources/sdk-ref/)
---
## BOB Fusion
## What is BOB Fusion?
BOB Fusion is the official points program of BOB, where users can harvest BOB Spice (points) based on their on-chain activity on the BOB mainnet. BOB Spice (points) represent your contribution to the BOB ecosystem - today and in the future. Season 3, the final season is now live.
:::info BOB Fusion App
Checkout the information on the official [BOB Fusion app](https://app.gobob.xyz/fusion?tab=info) for more details.
:::
:::tip Add your project to Fusion
Building on BOB? [Contact us](https://forms.gle/EKYmrAhPsyiQ3ua57) to join the Fusion campaign after you deploy on BOB.
:::
## Season 3 (Live)
Season 3 is the final season of the BOB Fusion program, bringing in new ways to harvest Spice.
- Deposit into BOB apps (special multipliers for BTC LSTs and DeFi apps).
- Vote for your favorite projects.
- Invite your friends to join Fusion.
- Complete quest campaigns.
- Join special events.
### Stacking BOB Partner Points
Most of BOB's dApp partners, like Solv, Bedrock, and FBTC, have introduced points programs. Users can also collect Babylon points by using partner LSTs on BOB. Season 3 enables triple harvesting across different partners, allowing you to stack points alongside Spice. Explore the dApps and choose your favorites. DYOR!
## Season 2 (Ended)
Season 2 ended on 25/09/2024 with more ways to harvest Spice based on on-chain activity. The on-chain TVL grew up to $135M with 153k+ users and 60+ projects launched across DeFi, NFTs, and more.
## Season 1 (Ended)
Season 1 started on 27/03/2024 and ended with the BOB mainnet launch on 1st May 2024. During Season 1, users harvested Spice by locking in whitelisted assets with different multipliers. The on-chain TVL for Season 1 reached a whopping USD 300 million in just four weeks.
## FAQs
### What is the gas token on BOB?
ETH. BOB fees are low, similar to OP chain fees. Learn more at [l2fees.info](https://l2fees.info/)
### My assets are on an exchange. How can I contribute?
Withdraw your assets as well as sufficient ETH for gas fees from a centralized exchange to the Ethereum network or any supported L2 like Arbitrum, Optimism, Base, etc.
If you're a Coinbase user, withdrawing to the base network is free & then you can bridge your assets to BOB for low gas fees.
Use the [BOB bridge](https://app.gobob.xyz/bridge) or any other listed bridge providers to bridge your assets to the BOB network.
### What happens to my Season 1 & 2 points?
Season 1 and 2 points are being counted separately from Season 3 points. They can be found on the dashboard under Season 3 points.
### I have deployed capital into some dApps but they're not distributing Spice very regularly
Please note some dApps plan to distribute Spice retroactively at some point in the future, so if you have used the dApp during that snapshot time, you will get your Spice, albeit the distribution timelines depend on the dApps.
If you are unhappy about a dApp's Spice distribution, your best options are to either voice your concerns to that dApp or look for other opportunities in the BOB Fusion campaign.
### What happens to the referrals I made in Season 1 & 2?
Your referral bonus will continue into Season 3 if your Season 1 & 2 invites (& their invites) also participate & harvest Spice into Season 3. Your invite code will remain the same in Season 3 so you can invite more people as well for bonus Spice.
### Is there a distinction between how much Spice I can earn with different dApps as an LP?
Yes! More risk and effort = more Spice.
Example: DEXes harvest more than lending.
There will be regular calls to action for specific assets or pools that can get bonuses.
### What's the maximum amount of Spice for the Fusion campaign?
There is no limit. The more TVL and activity, the more Spice distribution. Stay active in the ecosystem, to defend and grow your position.
---
## User Hub
Welcome to BOB's User Hub - your gateway to Bitcoin-secured DeFi. Bridge assets, earn yield, and explore the ecosystem.
## Bridge Assets
**Bridge to BOB** - The easiest way to get started with Bitcoin-secured DeFi.
### Supported Networks
- **Ethereum**: ETH, USDC, USDT, DAI, and more ERC-20 tokens
- **Bitcoin**: Native BTC with 1-transaction onboarding
- **Other Networks**: Major L1s and L2s
### How to Bridge
1. Visit [app.gobob.xyz](https://app.gobob.xyz/en)
2. Connect your wallet
3. Select source network and asset
4. Confirm transaction
:::info
Find more information on [how to bridge to BOB](/docs/user-hub/onboard-to-bob/).
:::
## Staking & Earning
**Stake BTC** - Earn yield on your Bitcoin while securing the network.
### Staking Options
- **BTC Staking**: Earn yield on native Bitcoin
- **Liquidity Mining**: Provide liquidity to earn rewards
- **Validator Staking**: Run a node and earn fees
### Staking live on BOB
- [BOB Earn](https://app.gobob.xyz/en/earn)
- [Explore the ecosystem](https://app.gobob.xyz/en/apps)
## DeFi Apps on BOB
**Explore the Ecosystem** - Access a growing suite of DeFi applications.
### Available Apps
- **DEXs**: Trade assets with low fees
- **Lending**: Borrow against your assets
- **Yield Farming**: Maximize your returns
- **NFTs**: Digital collectibles and art
### Getting Started
1. Bridge your assets to BOB
2. Connect to your preferred DeFi app
3. Start earning and trading
### DeFi apps live on BOB
- [Explore the ecosystem](https://app.gobob.xyz/en/apss)
---
## Networks
## BOB Mainnet
BOB Mainnet is the production network where real value is at stake. Use this network for:
- Deploying production applications
- Trading with real assets
- Participating in DeFi protocols
- Staking BTC
### Network Details
- **Chain ID**: `60808`
- **RPC URL**: `https://rpc.gobob.xyz/`
- **Block Explorer**: `https://explorer.gobob.xyz/`
- **Currency Symbol and Gas Token**: `ETH`
### Alternative RPC URLs
If the main RPC URL is not working, try these alternatives:
- `https://bob.gateway.tenderly.co`
- `https://bob.drpc.org`
## BOB Sepolia (Testnet)
BOB Sepolia is the test network where you can experiment without risking real assets. Use this network for:
- Testing smart contracts
- Developing applications
- Learning how to use BOB
- Testing integrations
### Network Details
- **Chain ID**: `808813`
- **RPC URL**: `https://bob-sepolia.rpc.gobob.xyz`
- **Block Explorer**: `https://bob-sepolia.explorer.gobob.xyz/`
- **Currency Symbol and Gas Token**: `Sepolia ETH`
### Getting Testnet ETH
To get testnet ETH for BOB Sepolia:
1. Get Sepolia ETH from a faucet:
- [Alchemy Sepolia Faucet](https://sepoliafaucet.com/)
- [Infura Sepolia Faucet](https://www.infura.io/faucet/sepolia)
- [PoW Faucet](https://sepolia-faucet.pk910.de/)
2. Bridge your Sepolia ETH to BOB Sepolia using the [BOB Bridge](https://bob-sepolia.gobob.xyz/bridge)
### Getting Signet BTC
1. Get Signet BTC from a faucet:
- [Signet Faucet](https://signetfaucet.com/)
2. Bridge your Signet BTC to BOB Sepolia using the [BOB Bridge](https://bob-sepolia.gobob.xyz/bridge)
---
## Bridge with Binance Web3 Wallet
## Task: Bridge from Bitcoin to BOB
[BOB Gateway](https://app.gobob.xyz) lets you stake, swap, or lend your BTC from a single, unified interface so you can put your bitcoin to work earning yield faster than ever before.
We are partnering with Binance Web3 Wallet to offer this task to their users.
When you're done, you can complete [other Binance Web3 Wallet tasks](#more-tasks-on-bob) on BOB.
## Prerequisites
To complete this task you will need
- At least 0.0001 BTC on the Bitcoin Network in any wallet
- Binance Web3 Wallet (even if you have never used an EVM chain before)
That's it! You do not need any tokens on any EVM chain, including BOB. The Binance Web3 Wallet comes with an EVM address. You will have an option to receive ETH, the fee token on BOB, if you don't have any yet.
## Step-by-step Guide
1. Open your Binance Web3 Wallet app.
1. Tap "Wallets".
1. Tap "Web3".
1. Tap "Discover".
1. Tap the URL box.
1. Type `app.gobob.xyz` and press "return".
1. Tap "Connect Wallet".
1. Tap "Connect your EVM Wallet (Mandatory)".
1. Tap "Binance Web3 Wallet".
1. Tap "Connect your Bitcoin Wallet (Optional)".
1. Tap "Binance Web3 Wallet" or whatever wallet you use to hold your Bitcoin.
1. This is what the Connect Wallet screen looks like after connecting both EVM and Bitcoin wallets. If you are using a different Bitcoin wallet, your wallet icon may look different.
1. Change networks by tapping "Ethereum".
1. Tap "Bitcoin".
1. Type in the amount of BTC you will bridge. The minimum amount is 0.0001 BTC.
1. Tap "Bridge Asset".
1. A confirmation screen will appear, immediately followed by the next step.
1. Tap "Confirm".
1. Scroll down to see the Activity section, which shows the progress of your transaction.
1. After a few Bitcoin blocks your BTC will be finalised on BOB. You can verify the bridging is complete with the Activity section on the right of the page or by checking your WBTC balance on BOB.
## More Tasks on BOB
You can get even more Spice points by completing these other tasks on BOB.
1. Solv: Mint at least 0.0001 Solvbtc and deposit to xSolvBTC on BOB.
1. Bedrock: Mint uniBTC greater than 0.0001 on BOB.
1. Pell: Deposit at least 0.0001 xSolvBTC or uniBTC into Pell on BOB.
We will add links to these tasks soon.
If you have any questions, please reach out to us on [Discord](https://discord.gg/gobob) or [Telegram](https://t.me/+CyIcLW2nfaFlNDc1). Welcome to the Bitcoin Renaissance on BOB!
---
## Bridge from Bitcoin to BOB
[BOB Gateway](https://docs.gobob.xyz/gateway) lets you stake, swap, or lend your bitcoin from a single, unified interface so you can put your bitcoin to work earning yield faster than ever before.
It's built on a trustless, RFQ-based cross-chain swap protocol that connects professional LPs with users through a seamless swapping experience. Essentially, LPs handle the complexities of bridging and staking on behalf of users in exchange for a fee.
:::tip Interested in providing liquidity?
If you are interested in being an LP for the BOB Gateway bridge, please send us an email at `gateway@gobob.xyz`.
:::
All you need is a Bitcoin wallet with some BTC to send and an EVM-compatible wallet to receive your Bitcoin LST/LRT or wrapped Bitcoin on BOB. We'll even send you some ETH to cover the fees of your first few transactions on BOB.
:::tip Want to add BOB Gateway to your dapp?
Check out our guide to see how you can [integrate BOB Gateway into your dapp](https://docs.gobob.xyz/gateway).
:::
## Video Tutorial
## Step-by-Step Guide
1. Open the [BOB Gateway website](https://bob-fusion-git-feat-external-bridges-interlay.vercel.app/bridge?type=deposit).
2. Select the Bitcoin network by clicking "Ethereum" and then selecting "Bitcoin" from the list.
3. Click `Connect Wallet` in the top-right corner.
3. Click `Connect your EVM Wallet (Mandatory)`.
4. Choose your EVM wallet provider. In this example we'll use MetaMask.
:::tip Choosing your EVM address
You will receive your wrapped Bitcoin at the EVM address you connect at this step.
:::
5. Click `Wallet` in the top-right corner again to connect your Bitcoin wallet.
6. Click `Connect your Bitcoin Wallet (Optional)`.
7. Select your Bitcoin wallet provider. In this example we'll use Leather.
8. Type the amount of BTC that you would like to bridge from Bitcoin to BOB.
9. Click "Bridge Asset," then Confirm the transaction in your wallet.
10. That's it! After a few Bitcoin blocks your BTC will be finalized on BOB. You can verify the bridging is complete with the Activity section on the right of the page or by opening your EVM wallet and seeing that your balance of wrapped BTC on BOB has increased.
If you have any questions, please reach out to us on [Discord](https://discord.gg/gobob) or [Telegram](https://t.me/+CyIcLW2nfaFlNDc1). Welcome to the Bitcoin Renaissance on BOB!
---
## Bridge from Ethereum to BOB
The [BOB Bridge](https://app.gobob.xyz/bridge) allows you to move ETH between Ethereum and BOB.
## Step-by-step Guide
1. Open the [BOB Bridge website](https://app.gobob.xyz/bridge).
2. Click `Connect Wallet` in the top-right corner.
3. Click `Connect your EVM Wallet (Mandatory)`.
4. Choose your EVM wallet. In this example we’ll use MetaMask.
5. You will receive a few pop-up messages to connect your wallet, including this message to “Sign-In.” Your wallet may look different. The URI displayed for you will be `https://app.gobob.xyz`.
6. Make sure you are on the “Deposit” tab and have “Ethereum” selected.
:::tip
You may choose to use a “3rd Party” bridge. Each of these buttons will direct you to that bridge’s website. For the rest of this guide we’ll use the “BOB Bridge.”
:::
7. You may choose between bridging ETH (“Ether”) or a variety of ERC-20 tokens such as WBTC, DAI, wstETH, and others.
8. Type the amount of that token that you would like to bridge from Ethereum to BOB.
9. Click “Bridge Asset,” then Confirm the transaction in your wallet. Make sure you have enough ETH to pay the gas fee for the transaction. 🥲
10. That’s it! After ~3 minutes your tokens will be bridged to BOB. You can verify the bridging is complete with the Activity section on the right or by clicking “Withdraw” and seeing that your token balance on BOB has increased.
If you have any questions, please reach out to us on [Discord](https://discord.gg/gobob) or [Telegram](https://t.me/+CyIcLW2nfaFlNDc1). Welcome to BOB!
---
## Guides: Bridge to BOB
There are several ways to bridge tokens to and from BOB, depending on which network and token you're interested in moving. Here is an overview of your options.
| Where Your Tokens Are | How to Move Your Tokens to BOB |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Centralized Exchanges (e.g. Coinbase, Binance, OKX) | Bridge to Base, then [bridge from Base to BOB](https://app.gobob.xyz/bridge) |
| Bitcoin | [Use the BOB Gateway](https://app.gobob.xyz/bridge) |
| Bitcoin Layer 2s | [Use one of our trusted bridges](https://app.gobob.xyz/bridge) |
| Ethereum | [Use one of our trusted bridges](https://app.gobob.xyz/bridge) |
| Ethereum Layer 2s | [Use one of our trusted bridges](https://app.gobob.xyz/bridge) |
| Other EVM-compatible Networks | [Use one of our trusted bridges](https://app.gobob.xyz/bridge) |
| Solana | [Meson](https://meson.fi/), [Orbiter Finance](https://www.orbiter.finance/), or [Owlto Finance](https://owlto.finance/bridge) |
| Non-EVM-compatible Networks (Tron, Starknet, Aptos, Sui) | [Meson](https://meson.fi/) |
---
## Guide: Stake BTC
## One-Click BTC Staking
[BOB Earn](https://app.gobob.xyz/stake?type=stake&stakeWith=solv-solvbtcbbn) is a new 1-click Bitcoin staking portal and [BOB Gateway](https://docs.gobob.xyz/gateway) for Bitcoin liquid staking. Harvest BOB Spice points in the final season of BOB Fusion by using BOB Earn and exploring the growing Bitcoin staking ecosystem on BOB.
It's built on a trustless, RFQ-based cross-chain swap protocol that connects professional LPs with users through a seamless swapping experience. LPs handle the complexities of bridging and staking on behalf of users in exchange for a fee.
All you need is a Bitcoin wallet with some BTC to send and an EVM-compatible wallet to receive your Bitcoin LST on BOB. We'll even send you some ETH to cover the fees of your first few transactions on BOB.
## Choose Your Wallet Setup
### Standard Setup
If you're using a regular Bitcoin wallet and EVM wallet, follow the [Standard Guide](#standard-guide) below.
### Ledger Hardware Wallet Setup
If you're using a Ledger hardware wallet, follow the [Ledger Guide](#ledger-guide) below.
## Standard Guide
1. Open the [BOB Earn website](https://app.gobob.xyz/stake?type=stake&stakeWith=solv-solvbtcbbn).
1. Click `Connect Wallet` in the top-right corner.
2. Click `Connect your EVM Wallet (Mandatory)`.
3. Choose your EVM wallet provider.
:::tip Choosing your EVM address
You will receive your assets at the EVM address you connect at this step.
:::
4. Click `Wallet` in the top-right corner again to connect your Bitcoin wallet.
5. Click `Connect your Bitcoin Wallet (Optional)`.
6. Select your Bitcoin wallet provider.
7. Type the amount of BTC that you would like to stake.
8. Click the "Stake with" box to open a menu of staking options.
9. Choose a BTC yield source.
10. Toggle on "Top-up Gas" to convert a small amount of your BTC to ETH for transaction fees on BOB. You must do this if your EVM wallet has no ETH to make sure you can transact on BOB. If you already have ETH on BOB, this is optional.
11. Click "Stake", then Confirm the transaction in your wallet.
12. Click "Close".
:::tip You're done!
The next steps are optional and show how to monitor the progress of your transaction.
:::
13. Click "Bridge".
14. Look in the "Activity" box to see the status of your transaction. After a few Bitcoin blocks your BTC will be finalized on BOB. You can also verify the bridging is complete by opening your EVM wallet and seeing that your balance of wrapped BTC on BOB has increased.
## Ledger Guide
### Prerequisites
To complete this task you will need:
- A Ledger Hardware wallet with BTC on the Bitcoin network
That's it! You do not need any tokens on any EVM chain, including BOB. If you don't have an Ethereum or EVM address yet, this guide will show you how to create one in Ledger Live.
### Part One: Set Up Accounts
1. [Download the XVerse wallet](https://www.xverse.app/ledger-hardware-wallet-support). This will allow you to connect your Ledger's BTC account to the BOB Stake app.
2. [Connect your Ledger device to the XVerse wallet](https://support.xverse.app/hc/en-us/articles/17819233917965-How-to-Connect-Your-Ledger-Device-to-Xverse).
3. Create an EVM account for your Ledger device. This is sometimes also called an Ethereum address. We recommend these options:
- Ledger Live: [Create an EVM account in Ledger Live](https://support.ledger.com/article/360009576554-zd)
- MetaMask: [Connect your Ledger to MetaMask](https://support.ledger.com/article/4404366864657-zd)
- Rabby: [Set up and use Rabby wallet to access your Ledger Ethereum (ETH) account](https://support.ledger.com/article/4409801559569-zd)
### Part Two: Stake
1. [Open the BOB Earn page](https://app.gobob.xyz/en/stake).
2. Click `Connect Wallet` in the top-right corner of the page.
3. Select BTC, then select XVerse.
4. Select your Ledger account and click `Connect` in the XVerse window that pops open.
5. Click your Bitcoin address in the top-right corner of the page.
6. Click `Connect EVM Wallet` in the sidebar that opens.
7. Choose your EVM account to connect. It will depend on the wallet software you chose in [Part One](#part-one-set-up-accounts). The next few steps will show how to connect to Ledger Live's Ethereum account with WalletConnect.
8. Click `Ledger Live`.
9. Click the EVM address you would like to use, then click `Connect`.
10. Back on the BOB Stake page, click the icon of two arrows to close the wallet drawer.
11. Follow steps 7-14 from the [Standard Guide](#standard-guide) to complete your staking.
## Contact Us
If you have any questions, please reach out to us on [Discord](https://discord.gg/gobob) or [Telegram](https://t.me/+CyIcLW2nfaFlNDc1). Welcome to the Bitcoin Renaissance on BOB!
---
## FAQ & Troubleshooting
## Do I need a new wallet for BOB?
- **No!** Your existing Ethereum wallet (MetaMask, Rabby, Safe, or Ledger address) works on BOB.
- The only exception is Safe - you need to create a new Safe on the BOB network: https://safe.gobob.xyz/
## What if my wallet's RPC isn't working?
- Try the **Tenderly public RPC**:
- https://bob-sepolia.explorer.gobob.xyz/
## Can I use a custodian like Fireblocks or Anchorage?
- Yes! BOB supports institutional-grade custody solutions.
## What's the best wallet for beginners?
- **MetaMask** is the most popular and user-friendly option
- **Rabby** offers enhanced security features while maintaining ease of use
## What's the most secure wallet option?
- **Hardware wallets** (Ledger or Trezor) provide the highest security
- **Multi-signature wallets** (Safe) are ideal for teams and large holdings
## Can I use multiple wallets with BOB?
- Yes! You can use multiple wallets simultaneously
- Each wallet will have its own address and balance
- You can switch between wallets in the BOB interface
## How do I recover my wallet if I lose access?
- Use your recovery phrase (also called seed phrase)
- Never share your recovery phrase with anyone
- Store it securely offline
- Consider using a hardware wallet for better security
## MetaMask fees are too high. How can I reduce them?
Sometimes MetaMask can have issues with estimating the correct gas fees. Gas fee settings in MetaMask consist of three parts:
- **Max Base Fee**: The base fee amount you will pay for the transaction. This will not be refunded if set too high. If it is set too low, the sequencer might take a long time to include transaction.
- **Max Priority Fee**: The amount of gas you are willing to pay per unit of gas as a priority to get the transaction included before others. This will not be refunded if set too high. If it is set too low, the sequencer might take a long time to include the transaction.
- **Gas Limit**: The maximum amount of gas you are willing to spend on a transaction. If this is set too high, it will be refunded. The transaction will fail if it is set too low, and the fees paid are lost.
You can reduce the gas fees by following [the steps from the MetaMask documentation](https://support.metamask.io/transactions-and-gas/gas-fees/how-to-customize-gas-settings/):
1. When making a transaction using MetaMask, click the "Pen" icon next to the estimated fee to edit the gas usage.
2. In the "Advanced Gas Controls" window, you can adjust the "Gas Limit" and "Max Priority Fee" to reduce the gas fees. You can either set one of the suggested gas options like "Low", "Market", or "Aggressive". If these options still seem expensive, or you can manually set the gas limit and max priority fee via the "Advanced" tab.
3. In the "Advanced" tab, you can manually set the "Max base fee", "Priority Fee", and "Gas limit" to reduce the gas fees.
- For "Max base fee" and "Priority fee", check the current gas prices on the [BOB explorer](https://explorer.gobob.xyz/gas-tracker). In this example, the base fee is 0.2 Gwei, and the priority fee is 0 Gwei.
- Set the "Max base fee" and "Priority fee" to the desired values. In this example, the base fee is 0.2 Gwei, and the priority fee is 0 Gwei.
- Ideally, don't adjust the "Gas limit" unless you are sure about the amount of gas required for the transaction. The only reason to adjust the gas limit is if MetaMask underestimates the gas required to send a transaction, which might happen if you interact with an unverified smart contract. **If you set the gas limit too low, the transaction will fail with an out-of-gas error, and you will lose the fees paid.**
:::tip
Gas fees change based on the BOB network utilization. If you consistently face issues with MetaMask, you might want to consider switching to other wallets such as Rainbow or Rabby.
:::
## I can't connect to the BOB network. How can I change the RPC node?
If you are unable to connect to the BOB network, you can try changing the RPC node in your wallet. Here is an example how to change the RPC node in MetaMask:
1. Open the wallet settings.
2. Go to the "Networks" tab and select the BOB Network to change RPC nodes.
We recommend using the following network settings:
- **Network Name**: BOB Mainnet
- **New RPC URL**: https://bob-mainnet.public.blastapi.io
- **Chain ID**: 60808
- **Symbol**: ETH
- **Block Explorer URL**: https://explorer.gobob.xyz
---
## Wallets
import AddToWallet from '@site/src/components/AddToWallet';
import AddBobToken from '@site/src/components/AddBobToken';
# Wallets
This guide lists EVM-compatible wallets that are supported on the BOB network. Any EVM wallet supports the BOB network and this list is not complete but serves as a good guide for a few wallets you might find useful.
Each wallet is categorized by type and includes setup instructions and key features.
## Connecting to BOB
### Automatic Connection (Recommended)
Use the "Add to Wallet" button below to automatically add BOB to your wallet:
### Manual Connection
1. Open your wallet settings
2. Add network with these details:
- Network Name: `BOB Mainnet` or `BOB Sepolia`
- Chain ID: `60808` (Mainnet) or `808813` (Sepolia)
- Currency Symbol: `ETH`
- RPC URL: See network details above
- Block Explorer: See network details above
## Add the BOB Token
Use the buttons below to add the official BOB token (18 decimals) on each supported network. The component will switch your wallet to the right chain, add it if needed, and register the token contract automatically.
### Token Addresses
| Network | Contract | Explorer |
| --- | --- | --- |
| BOB | `0xb0bd54846a92b214c04a63b26ad7dc5e19a60808` | [BOB Explorer](https://explorer.gobob.xyz/address/0xb0bd54846a92b214c04a63b26ad7dc5e19a60808) |
| Ethereum | `0xC9746F73cC33a36c2cD55b8aEFD732586946Cedd` | [Etherscan](https://etherscan.io/address/0xC9746F73cC33a36c2cD55b8aEFD732586946Cedd) |
| BNB Smart Chain | `0x52B5fB4B0F6572B8C44d0251Cc224513ac5eB7E7` | [BscScan](https://bscscan.com/address/0x52B5fB4B0F6572B8C44d0251Cc224513ac5eB7E7) |
BOB uses Chainlink CCIP to bridge liquidity between these deployments. You can move the token with:
- [CCIP Transporter](https://app.transporter.io/?token=BOB)
- [BOB Gateway Bridge](https://app.gobob.xyz/en/bridge)
## Browser Wallets
### MetaMask
- **Type**: Browser Extension
- **Security**: Medium (password + recovery phrase)
- **Setup**: [Install MetaMask](https://metamask.io/)
- **BOB Support**: Full support, works with all BOB features
### Rabby Wallet
- **Type**: Browser Extension
- **Security**: Medium (password + recovery phrase)
- **Setup**: [Install Rabby](https://rabby.io/)
- **BOB Support**: Full support, works with all BOB features
### Rainbow
- **Type**: Browser Extension
- **Security**: Medium (password + recovery phrase)
- **Setup**: [Install Rainbow](https://rainbow.me/)
- **BOB Support**: Full support, works with all BOB features
### Coinbase Wallet
- **Type**: Browser Extension & Mobile App
- **Security**: Medium (password + recovery phrase)
- **Setup**: [Install Coinbase Wallet](https://www.coinbase.com/wallet)
- **BOB Support**: Full support, works with all BOB features
## Mobile Wallets
### OKX Wallet
- **Type**: Mobile App
- **Security**: Medium (password + recovery phrase)
- **Setup**: [Download OKX](https://www.okx.com/web3)
- **BOB Support**: Full support, works with all BOB features
### Binance Wallet
- **Type**: Mobile App
- **Security**: Medium (password + recovery phrase)
- **Setup**: [Download Binance](https://www.binance.com/en/wallet)
- **BOB Support**: Full support, works with all BOB features
## Hardware Wallets
### Ledger
- **Type**: Hardware Device
- **Security**: High (private keys never leave device)
- **Setup**: [Get Ledger](https://www.ledger.com/)
- **BOB Support**: Full support, works with all BOB features
### Trezor
- **Type**: Hardware Device
- **Security**: High (private keys never leave device)
- **Setup**: [Get Trezor](https://trezor.io/)
- **BOB Support**: Full support, works with all BOB features
## Institutional Wallets
### Fireblocks
- **Type**: Enterprise Platform
- **Security**: High (institutional-grade security)
- **Setup**: [Contact Fireblocks](https://www.fireblocks.com/)
- **BOB Support**: Full support, works with all BOB features
## Multi-Signature Wallets
### Safe (formerly Gnosis Safe)
- **Type**: Smart Contract Wallet
- **Security**: High (requires multiple approvals)
- **Setup**: [Create Safe Account](https://safe.gobob.xyz/welcome/accounts)
- **BOB Support**: Full support, works with all BOB features