Skip to content
LitVM AcademyStart
All modules
ZK Seal badge, locked

Module 04 of 07

BitcoinOS and the Grail Bridge

How a 300 byte proof and a single honest verifier move real LTC onto an EVM chain without a custodian.

12 min read, then 10 questions

Bridges are where crypto loses money. Billions of dollars have been stolen from them, almost always because the bridge held custody of user funds behind a multisig, and the multisig failed. The Grail bridge is interesting because it removes custody from the design entirely.

Why bridges keep failing

A typical bridge works like this: you send LTC to an address controlled by the bridge operator, the operator observes the deposit, and the operator mints a wrapped token on the destination chain. To get your LTC back, you burn the wrapped token and the operator releases the original.

Every step past the first depends on the operator behaving. If the keys leak, the funds leave. If the operators collude, the funds leave. If the operators disappear, the wrapped token becomes worthless while the LTC sits in an address nobody can open.

Multisig reduces this risk without removing it. A five of nine multisig still fails if five parties are compromised or collude, and the assumption is an honest majority: security holds only while most signers are honest.

What BitcoinOS is

BitcoinOS, usually shortened to BOS, is an operating system for UTXO blockchains. It combines zero knowledge proofs, multiparty computation, and related cryptography to bring programmability to chains that were never designed for it, without changing those chains.

Its credential is concrete. In July 2024, at Bitcoin block 853626, BitcoinOS verified a zero knowledge proof on Bitcoin mainnet for the first time, with no soft fork, no hard fork, and no new opcode. Everything ran on the script system Bitcoin already had.

BOS is being adapted for Litecoin, which is an easier target in two ways: 2.5 minute blocks confirm deposits faster, and the Scrypt mining base is more widely distributed.

BitSNARK: verifying proofs on a chain that cannot verify proofs

The verification protocol at the core of BOS is BitSNARK. It is the piece that makes everything else possible.

The problem it solves: a UTXO script system cannot run a SNARK verifier. There is no elliptic curve pairing opcode, no loop, no arbitrary computation.

The solution is to reframe verification as a dispute. Rather than asking Litecoin to verify the proof, BitSNARK encodes the verification as a set of pre-signed transactions and a challenge-response game. If the prover is honest, nothing happens on chain beyond the ordinary path. If the prover lies, a verifier challenges, and the two walk through a deterministic sequence that ends with Litecoin script adjudicating one small step that it can evaluate.

The resulting properties:

PropertyValue
Proof sizeRoughly 300 bytes
Bridge transactions per blockUp to 40
Litecoin protocol change requiredNone
Security model1 of n honest verifiers
Challenge typeDeterministic, fraud-proof style

The Grail bridge, step by step

Grail is the bridge built on BitSNARK. It moves LTC between the Litecoin mainchain and LitVM.

Depositing

  1. 01

    Lock LTC in a Taproot address

    You send LTC to a Taproot output whose spending conditions are fixed by the bridge protocol. No individual holds a key that can move it unilaterally.

  2. 02

    BitcoinOS generates a ZK-SNARK proof

    The proof attests that a specific amount of LTC was locked at a specific output, verifiable against Litecoin's chain state.

  3. 03

    zkLTC is minted on LitVM

    The rollup mints zkLTC to your address at a one to one ratio against the locked LTC.

Withdrawing

  1. 01

    Burn zkLTC on LitVM

    You destroy the zkLTC, which produces a claim on the corresponding locked LTC.

  2. 02

    The proof is verified on Litecoin

    The burn is proven against the Litecoin chain through the BitSNARK protocol.

  3. 03

    LTC is released

    The Taproot output unlocks and the LTC returns to your control on the mainchain.

At no point does a third party hold your funds. The LTC sits in a locked output whose release is governed by proof verification, not by anyone's discretion.

zkLTC compared with wrapped tokens

Traditional wrapped LTC

  • Custody: a third party custodian holds the asset
  • Trust: you trust the custodian
  • Verification: off-chain attestation, often a periodic report
  • Counterparty risk: high
  • Redemption: depends on the custodian staying solvent and willing

zkLTC via Grail

  • Custody: none, funds sit in a protocol-locked output
  • Trust: you trust mathematics and one honest verifier
  • Verification: on-chain proof
  • Counterparty risk: minimal
  • Redemption: guaranteed by the protocol

The distinction is not cosmetic. Wrapped assets have failed repeatedly because the custodian was the single point of failure. Removing the custodian removes that failure mode rather than mitigating it.

What Litecoin brings to BOS

Adapting BOS from Bitcoin to Litecoin is not a straight port. Three properties change the calculus:

  • 2.5 minute blocks. Deposit confirmations arrive four times faster than on Bitcoin, which materially improves bridge latency.
  • Scrypt consensus. A broader mining distribution means fewer concentration concerns around the chain securing the locked funds.
  • MWEB. MimbleWimble Extension Blocks are on the roadmap as an optional privacy layer for bridged assets. Litecoin already ships the privacy primitive; the bridge can use it.

What comes next from BOS

Two capabilities matter for where LitVM is heading:

  • MerkleMesh. Infrastructure for anchoring rollups directly to Litecoin. This is the machinery that phase two and phase three of the settlement migration depend on.
  • Charms. BOS-native programmable tokens on UTXO chains, joining Ordinals, Runes, and LTC-20 in the set of Litecoin-native assets LitVM plans to support.

There is also a longer term ambition: bridging native BTC into LitVM through the same Grail infrastructure, letting Bitcoin participate in Litecoin-secured DeFi without touching Bitcoin's base layer.

What to remember

  • 01Most bridge failures come from custody: an operator or multisig holds the funds and eventually fails.
  • 02BitcoinOS verified a ZK proof on Bitcoin mainnet in July 2024 at block 853626, with no fork required.
  • 03BitSNARK makes proof verification possible on UTXO chains by turning it into a deterministic challenge game.
  • 04The proof is roughly 300 bytes and allows up to 40 bridge transactions per block.
  • 05Security is 1 of n: a single honest verifier is enough, unlike a multisig which needs an honest majority.
  • 06Deposits lock LTC in a Taproot output and mint zkLTC one to one; withdrawals burn zkLTC and unlock the original LTC.
  • 07Litecoin's faster blocks, wider mining distribution, and MWEB privacy make it a good fit for BOS.

Primary sources

Ready for the ZK Seal?

Ten questions on this module. Answer 8 correctly and the badge unlocks. You can retake it as often as you like.

Take the quiz