R&D for Clementine v2: Eliminating Collateral and Liquidity Requirements with Garbled Circuits and TOOP

Citrea Team

04 Jun 2025 • 6 min read

Introduction

Today, we’re introducing our approach to improving Clementine using Garbled Circuits and Transfer of Ownership Protocol (TOOP) by constructing a SNARK verifier circuit with logic gates. We're also announcing the open-sourcing of this garbled SNARK verifier to help accelerate research into Bitcoin bridges that don't require trust, collateral, or liquidity constraints.

The first version of Clementine offered a trust-minimized Bitcoin bridge to Citrea using BitVM2. While still in the research phase, our proposed Clementine v2 replaces BitVM2 with the garbled snark verifier and combined with TOOP, it eliminates two key limitations of the original design:

Operators had to lock large amounts of collateral to prove they wouldn’t act maliciously. We significantly lowered the amount of collateral needed with our latest paper, but the design still had required some amount of collateral.
They also had to pre-pay withdrawals, providing liquidity to users upfront and getting reimbursed later.

These design constraints limited scalability and discouraged decentralized participation.

With Clementine v2, we eliminate both.

Garbled Circuits remove the need for operator collateral.
TOOP, designed by Fairgate Labs, removes the need for operator liquidity.

Together, they turn Clementine into a lighter, cheaper, and more accessible bridge, without compromising trust-minimization or security.

Citrea mainnet is locked in for deployment with Clementine v1 (BitVM2-based). However, our team has started a separate effort towards Clementine v2 for the first upgrade after mainnet launch.

Garbled Circuits: A Drop-in Replacement for BitVM2

From BitVM2 to Garbled Circuits

BitVM2 relied on large script-based challenge games and bonded operators. Garbled Circuits offer a cleaner alternative.

Our exploration of this direction was heavily inspired by Delbrag paper by Jeremy Rubin, which introduced the idea of using garbled circuits for making fraud proofs on Bitcoin substantially more efficient at the cost of increased out-of-band information exchange. Their framing of off-chain circuit evaluation led us to develop a SNARK verifier using binary gates and apply it as a drop-in replacement for BitVM2’s on-chain logic.

Instead of executing SNARK verification on-chain, we represent the SNARK verifier as a binary circuit composed of logic gates. This circuit is then garbled by the operator during setup, encrypted in such a way that only a correct proof can be evaluated.

Each gate output can be decrypted only with the correct combination of input preimages (e.g., for AND, P1_A & P1_B yields P1_AB). The final output is 1 if the SNARK is valid, and 0 if not.

This allows for:

Fully off-chain computation
A compact dispute model: All the chain needs is a hash of the output preimage and a simple hash comparison.

Eliminating Expensive Transactions

This model drastically reduces the cost of challenge-response logic:

Disprove transactions are now a single hashing script, representing an approximately 100,000x improvement compared to the previous 4MB BitVM2 transaction.
Assert transactions drop from 1.3MB to 80kB.
No collateral is needed to “prove honesty.”

Enabling This with Watchtowers

Clementine already includes a watchtower-based light client. Since the network is permissioned, we can create a dedicated garbled circuit setup between each operator and each watchtower.

Think of this as a graph:

Each edge represents a unique Garbled Circuit (GC) circuit between an operator and a watchtower.
If an operator cheats, any honest watchtower can challenge them and remove them from the operator set.
If a watchtower cheats, the operator responds with a valid SNARK output and keeps operating.

This ensures security with a simple 1-of-N honest assumption — and makes bonded collateral obsolete.

A Closer Look: How Garbled Circuits Work in Clementine

At a lower level, here’s how we’re adapting garbled circuits specifically for SNARK verification:

We compile the Groth16 verifier into a boolean circuit of AND and XOR gates.
Each wire in the circuit is assigned two random preimages: one for logical 0 and one for 1. For example:
- Input A: P0_A, P1_A
- Input B: P0_B, P1_B
Each gate output (e.g. AB) has encrypted entries, each decryptable only by the correct combination of input preimages:
- For AND:
  - P0_AB can be decrypted from pairs (P0_A & P0_B, P0_A & P1_B, P1_A & P0_B)
  - P1_AB can be decrypted only from the pair: P1_A & P1_B

This gives us a garbled SNARK verifier circuit that returns:

1 if the proof is valid
0 if it is invalid

The circuit is evaluated off-chain, and only the final result, a preimage representing the verifier output, is published.

On-chain logic then hashes it and checks it against the committed GC root hash.

Currently, proving correctness of the GC takes ~14 days, but we’re working on reducing that.

This model:

Removes the need for large, expensive script-based disputes
Turns disprove transactions into simple hash checks
Makes assert transactions small (~20k vbytes, down from +1.3mb)

Why This Only Works in Clementine

Using garbled circuits only at setup time, without recomputing them for each deposit, is only possible thanks to Clementine’s round-based design.

Each round represents a discrete window of operation. A user’s reimbursement can only be processed if the next round is successfully opened. If malicious behavior is detected in the current round (e.g. an invalid proof or forged reimbursement), the system halts, preventing the next round from opening.

This acts as a built-in circuit breaker:

No need to repeat GC construction or evaluation per transaction
Fraud halts progression and blocks further withdrawals from the malicious operator

This architecture is key to making GC-based proof enforcement both efficient and secure.

TOOP: Transfer of Ownership Protocol

While garbled circuits solve the dispute/collateral problem, TOOP (by Fairgate Labs) solves the liquidity problem. In Clementine v1, operators had to fund user withdrawals upfront, locking BTC with the promise of getting it reimbursed later.

TOOP eliminates this.

How It Works

Because Clementine v2 pushes all heavy computation, like SNARK verification via garbled circuits, into the one-time bridge setup phase, the runtime logic becomes minimal. This simplification also extends to signature collection. With no dynamic computation required during withdrawals, it becomes much easier to integrate the Transfer of Ownership Protocol securely and efficiently.

At setup time:
- Each of the N operators generates a keypair.They pre-sign reimbursement transactions for every subset of the operator set.
- These are linked to output scripts on Bitcoin, known as reimbursement connectors.
At withdrawal time:
- Operators encrypt and send their private keys to the user.
- The user selects a preferred subset of signers and confirms it via a transaction on Bitcoin.
- One of the selected operators sends a kickoff transaction finalizing the reimbursement route.

This way:

Operators never have to post liquidity.
Users control their exit.
The Bitcoin transaction reflects exactly what the user selected.
Any deviation (e.g. operator sending a kickoff with the wrong subset) is provable as fraud.

Honest Operator Responsibilities

Maintain GC circuits with all watchtowers.
Generate all reimbursement signatures during setup.
On withdrawal, send encrypted keys to the user.
Finalize kickoff and reimbursement logic only after user’s preferences are confirmed.

What This Means for Users and Operators

Clementine v2 doesn’t just change the underlying protocol, it also simplifies how people interact with the system in practice.

For Operators

Running a bridge operator no longer requires locking up capital or managing liquidity. With garbled circuits, your only setup responsibility is generating a single circuit per round and maintaining connections with watchtowers. If you behave honestly, the system works passively. If challenged unfairly, you’re protected by the ability to prove correctness. If you’re dishonest, you’re simply removed, no need for slashing mechanisms or complex economic penalties.

This makes operating the bridge accessible to a wider set of participants and lowers the barrier to decentralization.

For End Users

Using Clementine v2 feels like using any other bridge, but under the hood, you’re getting significantly stronger guarantees.

Thanks to the Transfer of Ownership Protocol, you control your withdrawal path. You choose which operators will enable your exit, and that preference is enforced on Bitcoin. No operator ever touches your funds or needs to prepay you. And if anything goes wrong, any watchtower can halt the system and prevent theft before it happens.

The result is a system that’s cheaper, safer, and more transparent, without requiring users to expect operators to have liquidity.

Try It Out and Build With Us

We’ve open-sourced a toy implementation of our GC verifier circuit for Groth16, called garbled-snark-verifier. It’s meant to help others build, experiment, and improve.

We believe the future of Bitcoin bridges doesn’t require trust, collateral, or liquidity constraints.

Clementine v2 is our step in that direction.

Acknowledgments
We’ve begun R&D efforts for Clementine v2 after reading the Delbrag paper by Jeremy Rubin and realized the idea aligns well with our current design. The same goes for TOOP by Fairgate Labs. We thank both parties for their innovations and insightful discussions.

We’re also aware of parallel efforts on Garbled Circuits, such as DV-SNARKs, led by Alpen Labs researchers Liam Eagen and Aaron Feickert. We appreciate their openness in exchanging ideas and discussions.