Skip to main content

BOB Gateway: Bitcoin Intents

Introduction​

Bitcoin users can easily onboard to the BOB Hybrid L2 without previously holding any Ethereum assets. This page explains the structure of BOB Gateway, an intent-based bridge that coordinates peer-to-peer swaps between users and liquidity providers (LPs).

Cross-chain transfers are secured by verifying Bitcoin transaction proofs with an on-chain light client, avoiding the need for an oracle. Optional intents, such as staking, lending, and swapping a small amount of ETH for transaction fees can all be accomplished while only requiring a single Bitcoin transaction from the user.

Next Steps for Gateway​

We are interested in working closely with builders looking to connect their smart contracts as new strategies for BOB Gateway users.

These are some of the features we're working on for Gateway's next upgrade, with new ideas being added frequently.

  • "Unwrap" your wrapped BTC on BOB by withdrawing back to BTC on Bitcoin mainnet
  • "Unstake" your BTC LST/LRT back to BTC on Bitcoin mainnet
  • Swapping from BTC to any ERC20 through a DEX (already possible, not fully implemented yet)
Integrate BOB Gateway Into your App

See our Builder Guide to learn more about our SDK and extending BOB Gateway's functionality to bring Bitcoiners one transaction away from your use-case.

How Gateway Works​

  1. Liquidity providers (LPs) temporarily lock wrapped Bitcoin (WBTC or tBTC) in escrow smart contracts on BOB.
  2. A user makes a request to the off-chain relayer to reserve some of the available liquidity.
  3. The user sends BTC to the liquidity provider's Bitcoin address. A hash of the user's order is included in the OP_RETURN of their transaction, including data such as the recipient's EVM address on BOB.
  4. The relayer trustlessly verifies the user's Bitcoin transaction by submitting a Merkle proof to an on-chain Light Client, granting the relayer permission to withdraw the LP's wrapped Bitcoin without needing to use an oracle.
  5. Gateway sends the LP's wrapped Bitcoin to the user's EVM address. If the user requested a Bitcoin LST/LRT, that token is minted using the LP's wrapped Bitcoin before it is sent to the user.

Architecture​

architecture

User Flow​

  1. A user requests to swap BTC for wrapped BTC (e.g. WBTC, tBTC, or FBTC) or staked BTC (e.g. SolvBTC.BBN, uniBTC)
  2. The user gets a "quote" of which Gateway smart contract is an available route (i.e. which LP they can swap with)
  3. The user creates an "order" with the relayer to reserve the LP's liquidity
  4. The user creates a Bitcoin transaction, updating the order with their txid
  5. The relayer monitors the Bitcoin chain and sends the LP's wrapped BTC to the user after the txid seen on Bitcoin. Specifically, the relayer submits a Merkle proof of the Bitcoin tx to an on-chain light client for trustless verification of the user's intent.

Liquidity Provider (LP) Flow​

  1. An LP asks the relayer to deploy a new Gateway contract, which functions as an escrow for their funds. This is permissioned at the moment because BOB pays the transaction fees.
  2. The LP deposits wrapped Bitcoin (e.g. WBTC, tBTC, FBTC) in their Gateway contract.
  3. The LP can only withdraw their funds or update their swap fees after a delay so that the relayer has time to finish open orders. The relayer will not accept new orders during this delay until reset.