Clementine

  • Name: Clementine
  • URL: https://docs.citrea.xyz/essentials/clementine-trust-minimized-bitcoin-bridge
  • Category: Bitcoin bridge / tokenized-BTC control plane / BitVM-based two-way peg
  • Tags: bitcoin-ecosystem
  • Summary: Clementine is worth indexing separately from Citrea because it is not just a feature page for the parent rollup; it is a distinct bridge-control system with its own operator roles, payout flow, dispute process, and contract surface. The official docs make five roles explicit — users, signers, operators, watchtowers, and challengers — and show that the bridge’s core mechanism is not merely BitVM bridge security, but a combination of covenant-emulating signer precommitments, operator-fronted withdrawals, watchtower-published chain proofs, challenger-triggered disputes, and Citrea-side bridge/light-client verification contracts. That makes Clementine a strong comparison point for tokenized-BTC systems because it separates fast withdrawal liquidity, vault control, and fraud-challenge enforcement more clearly than most bridge overviews do.
  • What it does:
    • Moves BTC into Citrea as cBTC and back out again through a two-way peg that combines Bitcoin-side Taproot transactions with Citrea-side bridge and light-client contracts
    • Uses signers to pre-sign allowed spend paths so deposits move into a vault only along approved routes, effectively emulating covenant-like restrictions
    • Lets operators front BTC to users for withdrawals, then seek later reimbursement from the bridge vault through a challengeable claim process
    • Uses watchtowers to publish compact Bitcoin header-chain proofs and challengers to force operators into BitVM-based proof games when reimbursement claims look fraudulent
    • Exposes a concrete onchain control plane on Citrea, where the bridge contract validates deposits via the Bitcoin light client, mints cBTC, and records withdrawal intents
    • Ships implementation and operator-facing tooling through the open-source Clementine repository and Clementine CLI docs
  • Key claims:
    • The official docs say Clementine reduces peg-out trust to 1-of-N honesty, with one honest signer constraining spend paths, one honest watchtower able to block a wrong-chain claim, and one rational challenger able to force a malicious operator into a losing dispute.
    • The docs say the current bridge UX is built around 10 BTC denomination flows, including a 10 BTC deposit/withdrawal CLI path and a 240-sat payout anchor used by safeWithdraw.
    • The bridge docs and contract docs show that cBTC minting is not a generic message-bridge event; Citrea’s bridge contract verifies Bitcoin deposits through an onchain light client before minting, and queues withdrawal UTXOs on the way out.
    • The economics section says operators post a slashable bond of roughly 2 BTC and that one bond can back an entire payoff round, with any proven fraud slashing the bond and voiding that round’s reimbursements.
    • The role docs explicitly note that these roles can overlap in practice, with mainnet relations roughly Operators ⊆ Signers ⊆ Watchtowers ⊆ Challenger ⊆ Users, which is analytically important because the implementation may be less role-separated than the conceptual diagrams suggest.
    • The implementation notes say the deployed version differs from the whitepaper in at least one deliberate way: the watchtower circuit is simplified relative to the paper, without changing the claimed core security model.
    • The strongest reusable insight is that Clementine decomposes a Bitcoin peg into three distinct layers that many bridge descriptions blur together: signer-constrained vault control, operator-funded withdrawal liquidity, and watchtower/challenger-enforced reimbursement disputes.
  • Whitepaper: Clementine has an official whitepaper at https://citrea.xyz/clementine_whitepaper.pdf, but the most readable primary sources for this pass were the Citrea docs, contract docs, CLI docs, and the public Clementine repository. See ../whitepapers/clementine-primary-sources-2026-05-13.md.
  • Sources:

Internal linkages