Unveiling Clementine 🍊-Citrea's BitVM Based Trust-Minimized Two-Way Peg Program

Today we introduce Clementine 🍊, Citrea's BitVM based trust-minimized two-way peg program. Through this blog post we explain the core components of Clementine and how it works. You can find the work-in-progress implementation here.

The core components of Clementine are:

• Light Client Proof (of Bitcoin and Citrea)
• Zero-Knowledge Proof (ZKP) Verifier in BitVM

Light Client Proof

Our light client proof is a recursive ZKP. It simply aggregates Citrea proofs over Bitcoin through inclusion and soundness proofs, resulting in a single succinct proof for Citrea and Bitcoin light client. The proof outputs multiple identifiers on Citrea and Bitcoin, most importantly "Citrea Withdrawal Merkle Root" and "Last Scanned Bitcoin Blockhash".

Peg-in and Peg-outs

Clementine, based on BitVM, only allows static size of UTXOs to peg-in and out. For simplicity, let's assume it is exactly 1 BTC.

Peg-in

To make a peg-in, user locks 1 BTC into a UTXO that is only spendable by;

• N+1 of N+1 multisig (N - 1 verifiers, the bridge operator and user)
• User after 200 blocks

After locking the UTXO, the user sends the signature of the transaction (image below) to the verifiers.

Once the transaction is finalized on Bitcoin, funds are moved into a new N-of-N multisig, the user can mint its pegged BTC by showing a SPV proof to the smart contract on Citrea. The transaction includes an EVM address to identify the user on Citrea.

Peg-out

To initiate a withdrawal, a user must transfer 1 BTC to a smart contract on Citrea, accompanied with a Bitcoin address. This address is recorded as a new leaf in the "Withdrawal Merkle Tree", then the 1 BTC is burned on Citrea. For the purposes of this discussion, it can be assumed, without loss of generality, that each Bitcoin address is unique. Thus, any transfer of 1 BTC to the given Bitcoin address on the Bitcoin network will result in a valid withdrawal.

Connector Source UTXO

Clementine makes sure that if the bridge operator tries to claim more BTC than it covered for withdrawals, it will lose access to the bridge funds forever.

Connector Source UTXO is what the operator will have to use to claim from Clementine. In order to gain access to the Connector Source UTXO, operator must act honest - meaning:

• It front covered all the withdrawals
• It inscribed enough preimages such that it can only claim the same amount of BTC of withdrawals.

Connector UTXO Trees are trees of UTXOs that are used by the operator to prove that it can claim the amount of BTC for the withdrawals it covers.

Each Connector Source UTXO is opened to a binary tree where each leaf is pre-signed with each deposit for the operator to take. In addition, each node in this tree has a spending path with the knowledge of a preimage, or with a 7 days timelock and operators signature.

This means that the operator can confirm how many leaf UTXOs can be opened, thus how much bridge funds can be claimed, by publicly revealing some preimages.

Two-Way Peg Program

Defining the Timeline

• Light client cut-off: The block height where the BitVM commits to check withdrawals
• Commit period: Operator's given time to satisfy the remaining withdrawals and inscribe preimages
• K-deep assumption: A period to make sure the last Bitcoin block is finalized. Since a verifier can start a challenge with the latest blocks' PoW, operator should not be able to make a private fork with a different blockhash
• BitVM challenge response period: The period where verifiers challenge the operator and the interactive verification game takes place, if required. At the end of the period, there are only two possible results:
  • connector source UTXO(s) becomes spendable by the operator, allowing the operator to claim the amount of BTC it covered during withdrawals
  • connector source UTXO(s) is burnt alongside BitVM response UTXO, revoking operators' access to the bridge funds

The light client cut-off happens every 6 months and perpetually continues at the same interval.

The Logic

In Clementine, the operator is responsible for covering every single withdrawal once the proof including the withdrawal is finalized on Bitcoin. After each period, the operator commits the amount of bridge funds it will claim from Clementine by revealing log2(n) number of preimages on Bitcoin. This amount equals to the sum of the front covered withdrawals since the previous checkpoint. 

Committing the amount of bridge funds operator will claim
For efficiency purposes, the operator must be able to commit how much bridge funds it will claim from Clementine. This number must be the same with the number of withdrawals that it front covered.

Our binary transaction tree enables this commitment architecture. Every UTXO in this tree has two spending paths:

• Operator spends after 7 days
• Anyone can spend with the preimage of the given hash

Every transaction output has a random preimage that only the operator knows. If the operator reveals the preimage for a UTXO, that branch of the transaction tree can be burnt by anyone. Since every Clementine deposit is pre-signed with the leaf UTXOs for the operator to claim, the operator cannot take those funds in the current period anymore.

For a binary tree that has M leaves, by revealing log(M) preimages, the operator can commit how much bridge funds it will claim.

Guarding the Peg

At least one honest verifier should initiate a challenge at the end of the commit period if;

• The operator tries to claim more BTC than it front covered
• The operator fails to cover any withdrawal before the checkpoint

Verifiers begin a challenge by providing the Bitcoin block header and total proof of work up to the checkpoint.

If the operator's total PoW significantly exceeds the verifier's PoW, the operator wins.

If the verifier's PoW is sufficient, indicating that the verifier started the challenge with a correct block height, the operator now must prove:

• It satisfied all the withdrawals
• It revealed preimages such that it matches the number of satisfied withdrawals

As a result, the operator provides a ZK proof that proves the following:

• Bitcoin + Citrea Light Client Proof,
• Bitcoin SPV (Simplified Payment Verification) Proofs of Withdrawals,
• Bitcoin SPV Proofs of Revealed Preimages.

If the operator's proof fails, the verifier can now burn the connector source UTXO, meaning the operator loses access to the bridge funds forever.

Conclusion

Citrea, through Clementine, enables the first trust-minimized two-way peg mechanism, secured by ZK proofs and BitVM. As long as the single verifier in the BitVM setup is honest, Clementine remains secure. This represents a significant improvement over existing solutions, such as open and closed federations. Clementine's design, coupled with Citrea’s trustless light client, minimizes trust requirements for Citrea's two-way peg without necessitating a soft fork.

You can find the work-in-progress implementation here. Please note that neither Clementine nor Citrea is live today. Both implementations are work-in-progress. Clementine is being built on the work-in-progress, open source BitVM implementation.

Ekrem Bal
Chief Scientist, Chainway Labs

Join the community and follow us on X to be an early adopter. Don’t miss out on any updates from Citrea!

• Join Discord
• Follow Twitter | X