Circuit Architecture
The circuit system consists of three primary components that work together to verify peg-out operations:- Header Chain Circuit - Verifies Bitcoin block header chain continuity and proof-of-work
- Work Only Circuit - Extracts and compresses accumulated proof-of-work data
- Bridge Circuit - Orchestrates all verifications for secure peg-out operations
How Circuits Enable Trust Minimization
Traditional Bitcoin bridges require trusted intermediaries to validate cross-chain operations. Clementine eliminates this trust assumption by using zero-knowledge proofs to cryptographically verify:- Bitcoin Chain State: Operators must prove they’re following the canonical Bitcoin chain with the most accumulated work
- Transaction Inclusion: Payout transactions are cryptographically verified to exist in specific Bitcoin blocks
- Watchtower Challenges: Independent watchtowers can challenge operators by submitting competing proofs
- L2 State Consistency: Bridge operations are verified against Citrea’s rollup state
BitVM2 Integration
The circuits integrate with BitVM2 to enable verification on Bitcoin without requiring protocol changes:Off-Chain Execution
The Operator executes circuits off-chain and generates zero-knowledge proofs (Groth16 format)
On-Chain Commitment
The Operator commits proof results on-chain via the KickOff transaction using Winternitz One-Time Signatures (WOTS)
Challenge Period
Challengers can verify the proof computation and initiate disputes if errors are detected
Dissection Game
BitVM2 facilitates a binary search process to identify the exact computational step in dispute
Proof Systems
Clementine uses two complementary proof systems:RISC Zero zkVM
The primary proof system for circuit execution:- Recursive Proofs: Header chain proofs can verify previous proofs, enabling verification of arbitrarily long chains
- Method IDs: Each circuit has a unique identifier ensuring proof compatibility across network types (mainnet, testnet, regtest)
- Network-Specific Builds: Circuits are compiled with network-specific constants for proper validation
Groth16 Proofs
Used for compact on-chain verification:- Compressed Format: 128-byte proofs enable efficient Bitcoin Script verification
- Watchtower Commitments: Watchtowers submit Groth16 proofs of their work-only circuit outputs
- Verification Keys: Pre-computed verification keys are embedded in Bitcoin Script for on-chain validation
Technical: Groth16 Proof Structure
Technical: Groth16 Proof Structure
Groth16 proofs consist of three elliptic curve points:
- Point A: Proof element verifying witness computation
- Point B: Proof element (G2 curve point) for pairing check
- Point C: Proof element ensuring constraint satisfaction
Circuit Data Flow
Network Configuration
Circuits adapt their verification logic based on the Bitcoin network:Mainnet
Standard Bitcoin difficulty rules with 2-week adjustment periods
Testnet4
Emergency difficulty reduction after 20-minute block gaps
Signet
Custom 10-second block time with adjusted difficulty parameters
Regtest
Minimal difficulty for local testing, no difficulty adjustments
BITCOIN_NETWORK environment variable.
Key Files
The circuit implementation is organized across several directories:risc0-circuits/- RISC Zero guest programs and build configurationbridge-circuit/- Bridge circuit implementationheader-chain/- Header chain verificationwork-only/- Work extraction circuit
circuits-lib/- Shared circuit logic and utilitiessrc/bridge_circuit/- Bridge verification logicsrc/header_chain/- Bitcoin header validationsrc/work_only/- Work conversion utilities
Next Steps
Header Chain
Learn about Bitcoin header chain verification
Work Only
Understand proof-of-work extraction
Bridge Circuit
Explore the complete bridge verification logic