Search
Search for projects by name
BOB
Badges
About
BOB (Build on Bitcoin) is an OP Stack rollup that aims to natively support the Bitcoin stack. The current implementation supports a variety of canonical and external bridging for BTC-related assets and a tBTC-v2 LightRelay smart contract for verifying... Bitcoin transaction proofs through their blocks' headers on the L2.
Badges
About
BOB (Build on Bitcoin) is an OP Stack rollup that aims to natively support the Bitcoin stack. The current implementation supports a variety of canonical and external bridging for BTC-related assets and a tBTC-v2 LightRelay smart contract for verifying... Bitcoin transaction proofs through their blocks' headers on the L2.
2024 Aug 02 — 2025 Aug 01
The section shows the operating costs that L2s pay to Ethereum.
2024 Aug 02 — 2025 Aug 01
This section shows the amount of data the project has posted to its respective Data Availability (DA) layer.
2024 Aug 02 — 2025 Aug 01
This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.
2025 Jul 03 — Aug 02
Proof System Intervention
2025 Jul 17th
A state root proposal is manually resolved after changing the finalization config.
OP Kailua Upgrade
2025 Jul 17th
BOB returns to the rollup section by using a hybrid zk fault proof system.
Funds can be stolen if
- a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL),
- the validity proof cryptography is broken or implemented incorrectly,
- no challenger checks the published stat,
- the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route selector.
Funds can be frozen if
MEV can be extracted if
Fraud proofs allow actors watching the chain to prove that the state is incorrect. Single round proofs (1R) prove the validity of a state proposal, only requiring a single transaction to resolve. A fault proof eliminates a state proposal by proving that any intermediate state transition in the proposal results in a different state root. For either, a ZK proof is used.
All of the data needed for proof construction is published on Ethereum L1.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
The primary whitelisted proposer has an optimistic advantage, letting them win by default if no conflicting proposals are made. This privilege is dropped after 30d of inactivity, and anyone can leverage the source available zk prover to prove a fault or a conflicting valid proposal to win against the privileged proposer and/or supply a bond and make a counter proposal at any time.
BOB is a All data required for proofs is published on chain
All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.
- Derivation: Batch submission - OP Mainnet specs
- BatchInbox - address
- OptimismPortal2.sol - source code, depositTransaction function
Ethereum
Proposers submit state roots as children of any (possibly unresolved) previous state root proposal, by calling the propose() function in the KailuaTreasury. A parent state root can have multiple conflicting children, composing a tournament. Each proposer requires to lock a bond, currently set to 0.5 ETH, that can be slashed if any proposal made by them is proven incorrect via a fault proof or a conflicting validity proof. The bond can be withdrawn once the proposer has no more pending proposals that need to be resolved and was not eliminated.
Proposals consist of a state root and a reference to their parent and implicitly challenge any sibling proposals who have the same parent. A proposal asserts that the proposed state root constitutes a valid state transition from the parent’s state root. To offer efficient zk fault proofs, each proposal must include 3600 intermediate state commitments, each spanning 6 L2 blocks.
Proposals target sequential tournament epochs of currently 3600 * 6 L2 blocks. A tournament with a resolved parent tournament, a single child- and no conflicting sibling proposals can be resolved after 3d.
The Vanguard is a privileged actor who can always make the first child proposal on a parent state root. They can, in the worst case, delay each tournament for up to 30d by not making this first proposal. Sibling proposals made after the Vanguard’s initial one or after the 30d vanguardAdvantage in each tournament are permissionless.
Any conflicting sibling proposals within a tournament that are made within the 3d challenge period of a proposal they are challenging, delay resolving the tournament until sufficient ZK proofs are published to leave one single tournament survivor.
In the tree of proposed state roots, each parent node can have multiple children. These children are indirectly challenging each other in a tournament, which can only be resolved if but a single child survives. A state root can be resolved if it is the only remaining proposal due to any combination of the following elimination methods:
- the proposal’s challenge period of 3d has ended before a conflicting proposal was made
- the proposal is proven correct with a full validity proof (invalidates all conflicting proposals)
- a conflicting sibling proposal is proven faulty
Proving any of the 3600 intermediate state commitments in a proposal faulty invalidates the entire proposal. Proving a proposal valid invalidates all conflicting siblings. Pruning of a tournament’s children happens strictly chronologically, which guarantees that the first faulty proposal of a given proposer is always pruned first. When pruned, an invalid proposal leads to the elimination of its proposer, which invalidates all their subsequent proposals, slashes their bond, and disallows future proposals by the same address. A slashed bond is transferred to an address chosen by the prover who caused the slashing.
A single remaining child in a tournament can be ‘resolved’ and will be finalized and usable for withdrawals after an execution delay of 1d (time for the Guardian to manually blacklist malicious state roots).
Validity proofs and fault proofs both must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
The Kailua state validation system is primarily optimistically resolved, so no validity proofs are required in the happy case. But two different zk proofs on unresolved state roots are possible and permissionless: The proveValidity() function proves a state root proposal’s full validity, automatically invalidating all conflicting sibling proposals. proveOutputFault() allows any actor to eliminate a state root proposal for which they can prove that any of the 3600 intermediate state transitions in the proposal are not correct. Both are zk proofs of validity, although one is used as an efficient fault proof to invalidate a single conflicting state transition.
Funds can be stolen if the validity proof cryptography is broken or implemented incorrectly.
Funds can be stolen if no challenger checks the published state
Funds can be stolen if the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route selector.
Funds can be frozen if a verifier needed for a given proof is paused by its permissioned owner.
The system has a centralized operator
The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can force any transaction
Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.
Regular exits
The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 1d. Withdrawal inclusion can be proven before state root settlement, but a 1d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.
Forced messaging
If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.
EVM compatible smart contracts are supported
OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.
Ethereum
Roles:
Allowed to pause withdrawals. In op stack systems with a proof system, the Guardian can also blacklist dispute games and set the respected game type (permissioned / permissionless).
Allowed to commit transactions from the current layer to the host chain.
Actors:
A Multisig with 4/6 threshold.
- Can upgrade with no delay
- DelayedWETH ProxyAdmin
- L1StandardBridge ProxyAdmin
- OptimismMintableERC20Factory ProxyAdmin
- L1ERC721Bridge ProxyAdmin
- OptimismPortal2 ProxyAdmin
- DisputeGameFactory ProxyAdmin
- SystemConfig ProxyAdmin
- L1CrossDomainMessenger ProxyAdmin
- SuperchainConfig ProxyAdmin
- AnchorStateRegistry ProxyAdmin
- Can interact with DelayedWETH
- can pull funds from the contract in case of emergency
- Can interact with SystemConfig
- Can interact with AddressManager
- set and change address mappings ProxyAdmin
- A Guardian - acting directly
- Can interact with KailuaTreasury
- propose new state roots before anyone else, giving a first-mover advantage on the optimistic clock
- Can interact with TimelockController
- cancel queued transactions
- execute transactions that are ready
- manage all access control roles with 3d delay TimelockController with 3d delay
- propose transactions
- Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
- Can interact with RiscZeroVerifierRouter
- add/remove verifiers and the selectors they are mapped to with 3d delay TimelockController with 3d delay
Ethereum
The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the KailuaGame.
- Roles:
- admin: ProxyAdmin; ultimately Bob Multisig 1
- This contract stores the following tokens: ETH.
The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them.
- Roles:
- admin: ProxyAdmin; ultimately Bob Multisig 1
This is NOT the shared SuperchainConfig contract of the OP stack Superchain but rather a local fork. It manages the PAUSED_SLOT, a boolean value indicating whether the local chain is paused, and GUARDIAN_SLOT, the address of the guardian which can pause and unpause the system.
- Roles:
- admin: ProxyAdmin; ultimately Bob Multisig 1
- guardian: Bob Multisig 1
The main entry point to deposit ERC20 tokens from host chain to this chain.
- Roles:
- admin: ProxyAdmin; ultimately Bob Multisig 1
- This contract can store any token.
Used to bridge ERC-721 tokens from host chain to this chain.
- Roles:
- admin: ProxyAdmin; ultimately Bob Multisig 1
Sends messages from host chain to this chain, and relays messages back onto host chain. In the event that a message sent from host chain to this chain is rejected for exceeding this chain’s epoch gas limit, it can be resubmitted via this contract’s replay function.
- Roles:
- admin: ProxyAdmin; ultimately Bob Multisig 1
Escrow for custom external tokens that use the canonical bridge for messaging but are governed externally.
- This contract stores the following tokens: wstETH.
A timelock with access control. The current minimum delay is 3d.
- Roles:
- canceller: EOA 3
- defaultAdmin: TimelockController; ultimately EOA 3
- executor: EOA 3
- proposer: EOA 3
- Roles:
- owner: Bob Multisig 1
The PreimageOracle contract is used to load the required data from L1 for a dispute game.
Contract designed to hold the bonded ETH for each game. It is designed as a wrapper around WETH to allow an owner to function as a backstop if a game would incorrectly distribute funds.
- Roles:
- admin: ProxyAdmin; ultimately Bob Multisig 1
- owner: Bob Multisig 1
A helper contract that generates OptimismMintableERC20 contracts on the network it’s deployed to. OptimismMintableERC20 is a standard extension of the base ERC20 token contract designed to allow the L1StandardBridge contracts to mint and burn tokens. This makes it possible to use an OptimismMintableERC20 as this chain’s representation of a token on the host chain, or vice-versa.
- Roles:
- admin: ProxyAdmin; ultimately Bob Multisig 1
Entrypoint for state root proposals. Manages bonds (currently 0.5 ETH) and tournaments for the OP Kailua state validation system, wrapping the OP stack native DisputeGameFactory. The current vanguard advantage is defined here as 30d.
- Roles:
- vanguard: EOA 2
A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (TimelockController).
- Roles:
- owner: TimelockController; ultimately EOA 3
- Roles:
- owner: Bob Multisig 1
Verifier contract for RISC Zero Groth16 proofs (version 2.2.0).
Implementation of the KailuaGame with type 1337. Based on this implementation, new KailuaGames are created with every new state root proposal.
Same as FaultDisputeGame, but only two permissioned addresses are designated as proposer and challenger.
Contains the latest confirmed state root that can be used as a starting point in a dispute game.
- Roles:
- admin: ProxyAdmin; ultimately Bob Multisig 1
The MIPS contract is used to execute the final step of the dispute game which objectively determines the winner of the dispute.
Value Secured is calculated based on these smart contracts and tokens:
Main entry point for users depositing ERC20 token that do not require custom gateway.
Main entry point for users depositing ETH.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).