Citrea: An Engine That Puts Bitcoin to Work for Institutional Capital

Key Takeaways

• Bitcoin is the largest cryptocurrency and the most thoroughly tested asset, yet it is also the least utilized. The arrival of spot ETFs has opened a path for institutions to hold Bitcoin, but the path to putting that Bitcoin to productive use remains closed. The constraint stems not from a lack of yield or products, but from a structural problem: every attempt to use Bitcoin requires trusting some specific party.
• Citrea positions itself as the first zero-knowledge rollup (zk-rollup) on Bitcoin, relying on Bitcoin for both data availability and settlement. The core idea is to build a programmable execution layer on top of Bitcoin without altering Bitcoin's consensus rules.
• Citrea's utilization strategy rests on three pillars. The first is Clementine, a trust-minimized bridge based on BitVM2 that transfers Bitcoin into cBTC under a 1-of-N trust assumption. The second is ctUSD, a regulation-aligned stablecoin issued by Moonpay, backed by M0's infrastructure, and collateralized 1:1 with short-term U.S. Treasuries and cash. The third is CTR, a token that coordinates capital flows within the Bitcoin economy, aligning capital deployment through vote-escrow staking, a dual treasury, and over $50 million in institutional commitments for its ecosystem liquidity.

1. The Silent Asset, Bitcoin

In the mid-20th century, vaults at central banks around the world held enormous quantities of gold. Gold functioned as a store of value that retained its worth through political upheaval and currency fluctuations, yet it generated no cash flow of any kind. Gold sat in the contradictory position of being the safest asset and the laziest one at the same time.

The attempt to unlock this unproductiveness took shape as the gold lending market that formed around the London bullion market (LBMA) during the 1980s and 1990s. Central banks could earn returns on their gold without selling it: they lent the gold to bullion banks like JP Morgan or HSBC and collected lease fees. The bullion banks then lent that gold on to mining companies and jewelers, and the mining companies built a structure where they could borrow gold that had not yet been mined, sell it in advance to raise funds, and repay later with gold they would produce.

The problem was that as the chain grew longer, the risk layered on top grew with it. In September 1999, when major European central banks announced the Washington Agreement restricting gold sales and lending, the gold price rose roughly 20 percent in about two weeks, and mining companies that had pre-sold their gold suddenly faced massive paper losses and margin calls. As counterparty risk piled up at every link in the lease chain, it became clear that gold lent out once and repeatedly re-collateralized had created claims in the market far larger than the actual physical gold. The gold lending market left behind a lesson: when a store-of-value asset is put to work, the chain of trust grows longer, and as the chain extends, trust inevitably erodes.

Bitcoin stands in much the same place. Since the SEC approved spot Bitcoin ETFs in January 2024, institutional Bitcoin holdings have grown rapidly. Spot ETFs alone now manage over $100 billion in assets, and when corporate treasuries and institutional custody are added, the total reaches hundreds of billions of dollars. Bitcoin has earned its place as digital gold, but like gold before it, it sits as an idle asset that produces no cash flow.

Attempts to put Bitcoin to use have continued for years, but most ran into the same wall the gold lending market faced. The biggest question was how far to compromise the trust assumptions in order to make a store-of-value asset productive. Every time Bitcoin's utilization was on the table, the same question returned: how much trust must be surrendered? The history of Bitcoin utilization has been a search for a compromise between two extremes: handing the entire asset over to a single party, or handing it to no one at all.

I previously argued in The Expansion of the Bitcoin Ecosystem is Inevitable that technologies like BitVM2, zkVM, and OP_CAT are gradually resolving Bitcoin's trust and bridge problems. At that time, however, much of what I proposed remained in the future tense, framed as "someday this will be possible." Citrea matters because it has moved that future tense into the present. By implementing the same technologies on a live mainnet, it has offered a working answer to the long-standing challenge of putting Bitcoin to work without surrendering trust.

Citrea is a project that attempts to shift the compromise point in one direction. Rather than extending the chain of trust, it rebuilds the utilization infrastructure into a form that the Bitcoin network itself can verify. This article examines how Citrea is establishing itself as institutional capital's infrastructure for Bitcoin utilization, looking at its structure and significance at the implementation level wherever possible.

2. The Price Paid to Use Bitcoin

2.1 Why Bitcoin Cannot Be Used As Is

The first wall blocking Bitcoin's utilization lies in Bitcoin's own design. Bitcoin's scripting language was deliberately kept simple for security and ease of verification, and that simplicity came back as a constraint: it cannot accommodate complex financial logic. Bitcoin script has no loops, cannot maintain state, and lacks covenants that bind how a particular output should be spent later. With those constraints, it cannot implement complex programs in the way Ethereum's general-purpose smart contracts do. That is why decentralized exchanges, lending protocols, and stablecoins cannot simply be deployed on Bitcoin as they are.

As a result, anyone holding Bitcoin who wants to use it has had to move outside Bitcoin, and every detour leading away from Bitcoin has carried a common cost: giving up Bitcoin's greatest asset, its trustlessness.

2.2 The Detours of Bitcoin Utilization and the Cost of Trust

Until now, there have been roughly four detours for using Bitcoin, and each paid the same price in a different form.

• The first is centralized custodial lending desks. Users hand their Bitcoin over to a company and either borrow dollars against it or earn interest, and at one point this was the most widely used route. Even today, institutional desks like Coinbase and Galaxy Digital, along with specialized desks like Nexo, form one pillar of the Bitcoin-backed lending market. But this model carries counterparty risk because the return of deposited Bitcoin depends entirely on the company's creditworthiness. The cascading bankruptcies of Celsius and BlockFi in 2022, in which depositors lost control of their assets at these desks, brought this risk into full view.
• The second is wrapped Bitcoin. The leading example, WBTC, lets users deposit Bitcoin with a custodian and receive a 1:1 token on Ethereum that can be used in DeFi. This gave Bitcoin programmability, but it also requires trust in the custodian. WBTC's structure has BitGo holding the underlying Bitcoin, and when risks surrounding a change in the custody arrangement surfaced in 2024, many DeFi protocols rapidly reduced their reliance on WBTC. What users actually trusted was not Bitcoin's inherent security but the custodian's operational competence and integrity.
• The third is sidechains. Long-running efforts like Stacks and Rootstock tried to build independent blockchains that use Bitcoin as their asset. But sidechains have their own consensus and validator sets, and the bridges connecting Bitcoin to them generally rely on multisigs or federated signing. Rootstock's peg system assumes the honesty of a majority of signers, and Stacks's sBTC likewise requires an honest majority for safety. Within the Bitcoin community, there has been persistent criticism that many projects calling themselves Bitcoin L2s were really sidechains with trusted bridges.
• The fourth is the Lightning Network. Lightning is one of the solutions that best preserves Bitcoin's trustlessness, but its strength is concentrated in payments, and extending it to general-purpose smart contracts is difficult. On top of that, operational complexity such as channel opening, liquidity management, and securing inbound liquidity proved to be a serious barrier for ordinary users. The result was a familiar irony: many Lightning wallet services ultimately reverted to centralized custodial models.

All four paths worked by giving up some portion of Bitcoin's trustlessness. They either entrusted the asset to a specific party or required trust in a separate set of validators, neither of which institutions found acceptable.

2.3 What Institutions Require

For Bitcoin operations to function safely at the level of institutional finance, three conditions, drawn from the failures of the existing detours, must be met.

1. Trust-minimized custody and transfer: The full process of sending Bitcoin to an execution environment and bringing it back must keep the asset safe without trusting any specific company or multisig group. Even in the extreme case where the entire bridge operator vanishes, users must be able to recover their Bitcoin independently and safely.
2. A regulation-compliant unit of stable value: Lending, trading, and settlement cannot run smoothly on Bitcoin alone given its volatility. A stable, dollar-denominated asset must accompany it, and that asset must be issued within a clear regulatory perimeter so that institutions can use it with confidence.
3. Economic mechanisms for capital coordination: Even with excellent infrastructure, an ecosystem will not come alive without capital to supply initial liquidity and incentives that direct that capital efficiently.

Citrea's architecture maps to these three conditions one for one. Trust-minimized custody is handled by the Clementine bridge, the regulation-aligned unit of value is ctUSD, and capital coordination falls to the CTR token. Holding all of these elements together so that they can function as a whole is Citrea's execution layer itself.

3. Citrea: The First Bitcoin-Based Zero-Knowledge Rollup

3.1 What Sets Citrea Apart: A BitVM-Based zk-Rollup Implementation

Source: Citrea

Citrea presents itself as the first zk-rollup to settle to the Bitcoin network through zero-knowledge proofs. More specifically, it classifies itself as a Type 2 zkEVM, meaning a zero-knowledge proof-based execution environment that embeds the proof circuit within the execution layer while behaving almost identically to the existing Ethereum Virtual Machine (EVM). As a result, Solidity contracts that run on Ethereum can be deployed on Citrea with little to no modification. For institutions, this translates into an operational benefit: they can reuse the verified Ethereum codebase and audit materials directly, without dedicating separate engineering resources to a new execution environment.

The unit of all activity on Citrea is cBTC. cBTC is Citrea's native asset and gas token, representing Bitcoin 1:1, and every transaction on Citrea pays its fee in cBTC. Rather than taking the form of an ERC-20, cBTC is issued as the native token of the Citrea protocol itself.

Ordering transactions and building blocks is handled, as in typical rollups, by a party called the sequencer. The sequencer gathers transactions from Citrea's mempool roughly every two seconds, builds a block, executes the transactions in an EVM environment, computes a new state root, and signs it immediately.

To fully understand Citrea's structure, it helps to first cover BitVM. BitVM is a technique proposed by Robin Linus in 2023. It is a workaround that enables the verification of heavy computations such as zero-knowledge proofs on Bitcoin without changing Bitcoin's consensus rules. Normally, no computation runs on Bitcoin at all. Only when someone disputes a result does the contested piece actually execute on Bitcoin script to determine who was right. The detailed mechanics will be covered later.

The way Citrea uses BitVM is what sets it apart from other Bitcoin L2s. Citrea introduced and implemented a unique BitVM bridge infrastructure to optimize BitVM2 to overcome Bitcoin's severe scripting restrictions and capital bottlenecks to verify proofs. Citrea's BitVM implementation, as detailed in its Clementine whitepaper, solves the critical issue of Bitcoin chain fork selection by utilizing a novel Bitcoin Light Client design that aggregates succinct Header Chain Proofs into a single BitVM proof. It also radically improves operator capital efficiency by leveraging non-standard Bitcoin transactions to process hundreds of concurrent withdrawals under a single collateral commitment, ensuring that disproving just one fraudulent withdrawal stops the entire malicious process. Citrea uses Bitcoin for both data availability and settlement, which means not just the basis for verification but also the storage and ordering of transaction data are entrusted to Bitcoin. This means the basis for finality, the area institutional capital watches most closely, rests not on a separate consensus set but on the Bitcoin network itself, allowing the safety assumptions of capital operations to align with Bitcoin's security budget.

3.2 Putting the Proof in a Form Bitcoin Can Read

Citrea implements its system so that the validity of its entire execution history can be securely settled by Bitcoin without requiring the base layer to process individual transactions. While Citrea publishes compact state differences directly to Bitcoin for data availability, Bitcoin’s native scripting language cannot inherently read or verify zero-knowledge proofs. To bridge this gap, Citrea compresses thousands of offchain transactions into a succinct cryptographic validity proof, essentially a mathematical receipt. Because Bitcoin cannot natively evaluate this receipt, Citrea leverages BitVM2 to establish an optimistic challenge framework onchain. Bitcoin only steps in to execute specific verification scripts if a Watchtower disputes a state transition. Consequently, Citrea’s core engineering decisions focus not just on generating this receipt, but on optimizing its structure so that any potential onchain dispute fits seamlessly within Bitcoin's rigid script and resource limitations.

3.2.1 Two Proofs

The most important point in understanding Citrea's architecture is the generation of two distinct types of cryptographic proofs: the Batch Proof and the Light Client Proof (LCP).

• The first proof concerns state changes inside Citrea. It proves which user sent which transaction, how the state of which contract was updated as a result, and what value Citrea's overall state root finally changed to. In effect, it provides the cryptographic foundation to verify on Bitcoin that the execution inside Citrea was valid.
• The second proof concerns Bitcoin itself. The Light Client Prover tracks Bitcoin block headers to verify Citrea block follows Bitcoin’s proof-of-work rules while simultaneously verifying the Citrea sequencer commitments and batch proofs published to Bitcoin's data availability layer. It contains the entire history of Citrea as one single succinct proof, proving to external entities, specifically Citrea’s BitVM bridge, that a given Citrea L2 state root is canonical and valid.

Unlike Ethereum-based rollups, Citrea needs the second proof separately because Bitcoin itself does not verify its own block headers for external use. Bitcoin verifies incoming transactions and includes them in blocks, but it does not issue any externally usable certificate that "this section of the chain is valid." Yet for the Clementine bridge to work, the Clementine bridge scripts (operating via BitVM) must be able to judge whether the Bitcoin transaction promised by the operator really lies within Bitcoin's honest chain. Since these BitVM scripts cannot re-verify the entire Bitcoin chain onchain, the system pulls in the validity of the Bitcoin chain in pre-compressed zero-knowledge proof form.

3.2.2 Two Provers

To produce these cryptographic artifacts, Citrea runs two specialized proving nodes: the Batch Prover and the Light Client Prover.

• The Batch Prover proves state transitions inside Citrea. When the Citrea sequencer bundles a set of L2 blocks into a single batch, the Batch Prover takes that batch and re-executes all the transactions inside it on a zkVM based on RISC Zero. Through re-execution, it confirms that the transition from the pre-state root to the post-state root is legitimate, and converts that fact into a zero-knowledge proof through the Batch Proof Circuit. The Batch Prover is paired with an L1 Syncer and an L2 Syncer: the L2 Syncer fetches the blocks built by the sequencer, while the L1 Syncer fetches the record on Bitcoin to confirm whether those blocks were actually committed. Only when the order the sequencer committed to Bitcoin matches the order the Batch Prover saw is the proof recognized as honest.
• The Light Client Prover proves the validity of the Bitcoin chain that Citrea references. It takes Bitcoin block headers and verifies whether proof-of-work was performed correctly, whether the difficulty adjustment rules were followed, and which chain has the most accumulated proof-of-work while simultaneously validating the Citrea batch commitments published within those blocks. That result is passed through the Light Client Circuit to generate a zero-knowledge proof, using an interesting technique. The Light Client Prover proves the validity of one block, then takes that proof as input to prove validity up to the next block, then uses that result as input to prove yet another block, in what is called a recursive proof. No matter how long the Bitcoin chain grows, holding only the most recent proof is enough to retain the fact that the entire Bitcoin chain up to that point is valid, in compressed form. This final proof is called the Light Client Proof (LCP), and the Clementine bridge covered in the next chapter uses it as the core basis for judging the operator's claims.

As a result, Citrea's safety rests on two intertwining lines of verification. The Batch Prover certifies that what happened inside Citrea was honest, while the Light Client Prover certifies which Bitcoin chain Citrea has accepted as truth from the outside world. Both proofs must pass for one round of Citrea to complete, and forging only one is not enough to deceive the system as a whole.

Source: Citrea

3.2.3 Where the Two Proofs End Up

The two proofs are created in different places, but the final step of compressing them into a form Bitcoin can read is the same. Both provers ultimately run on RISC Zero's zkVM at the final stage, producing STARK proofs that are recursively compressed into Groth16 SNARKs. A zkVM can be likened to a kind of proof-issuing machine that converts the execution of a general program into a zero-knowledge proof. Citrea runs an Ethereum-equivalent execution environment inside the Batch Prover circuit, while the Light Client Prover circuit executes Bitcoin chain verification logic alongside it within the broader network architecture.

Here a wall appears immediately. The receipt a zkVM issues is around 200 KB in size, which is far too large for Bitcoin to handle. So Citrea takes the roughly 200 KB STARK receipt and wraps it through recursive proving into a Groth16 proof of about 192 bytes. Groth16 offers the smallest proof size and fastest verification time among known zero-knowledge proof systems, meaning its verifier is small enough for BitVM2, the only workaround for verifying proofs on Bitcoin, to handle.

These two compressed proofs interact sequentially. The Batch Prover's proof is inscribed back into Bitcoin, permanently anchoring it on the L1 layer for Data Availability. The Light Client Prover then scans the Bitcoin chain, ingesting these published Batch Proofs along with Bitcoin's block headers to produce the consolidated Light Client Proof. This proof is delivered to the Clementine bridge, where it serves as the basis for judging whether the Bitcoin transaction promised by the bridge operator actually appears on the Bitcoin chain.

This structure foreshadows where the cryptographic verification logic of the Clementine challenge game, covered in Chapter 4, come from. The Clementine Bridge Circuit evaluates facts about the Bitcoin chain based on the LCP produced by the Light Client Prover, and this judgment is possible only because Citrea has recursively proven the validity of the Bitcoin chain itself. Citrea's proof structure and Clementine's bridge architecture can be seen as designs derived from the same structural decision.

3.2.4 Outsourcing to a Proof Market

Generating proofs is a computationally heavy task. Since both provers must produce heavy zero-knowledge proofs, having a single party handle this would quickly become a bottleneck. Citrea takes the approach of outsourcing this burden to a proof market called Boundless. In Boundless, GPU provers participate via a Proof of Verifiable Work (PoVW) mechanism, locking staked collateral to execute the work, with their stake slashed if they fail to deliver valid proofs within the requested slot. By distributing the heavy computation into a competitive market open to anyone, rather than concentrating it in one place, Citrea ensures that proof generation does not become a bottleneck even if its transaction volume grows by thousands of times. For institutions, this means that the throughput ceiling no longer depends on a single operator's willingness to invest in infrastructure, providing a foundation where large capital inflows do not lead to structural settlement delays.

A design that does not rely on a single proof system for soundness is also in progress. Citrea currently runs only one proof system based on RISC Zero, but the codebase is already prepared to incorporate Succinct's SP1 to establish a multi-prover architecture. Hardware-based verification such as SGX has also been left as a remaining task.

Source: Citrea

A final point worth noting is that Groth16 requires a separate trusted setup ceremony for each circuit. In this procedure, several participants combine their own randomly generated values to produce public parameters. As long as just one of them honestly discards their random value, no one can forge a fake proof. Citrea has conducted its Risc0-to-BitVM trusted setup ceremony with 63 participants, including RISC Zero, Nethermind, and StarkWare.

3.3 What Citrea Writes to Bitcoin, and How

What Citrea leaves on Bitcoin is not a copy of every transaction but a summary of the changes. Instead of recording who sent how much to whom, it records only the differences in what balance each account ended up with after the transactions and how the state of each contract was updated. Along with these come a single state root representing the latest overall state and a zero-knowledge proof guaranteeing that the changes are legitimate. These three pieces are tucked into a Bitcoin transaction.

Source: Citrea

The recording method itself involves some workarounds. Bitcoin was not originally designed for arbitrary data storage, but Citrea borrows the Taproot-based inscription technique that became widely known after 2023, which allows packing up to roughly 397 KB of data into a single transaction. Just before inscribing, Citrea optimizes the data using stateful compression to index storage keys, compresses it once more with a compression algorithm called Brotli, and if the limit is exceeded, it splits the data into several pieces and submits an additional transaction that ties those pieces together. As a result, anyone running a Bitcoin node can reconstruct Citrea's entire state from scratch using only the inscriptions on Bitcoin. For institutions, this goes beyond simple data availability and amounts to something close to a right to exit from the operator. Even if the Citrea operator disappears or its infrastructure halts, anyone with a Bitcoin full node can independently reconstruct the state of their assets.

Leaving data on Bitcoin naturally has a cost. Citrea's transaction fees are split into two layers: one is the ordinary gas cost for executing the transaction inside Citrea, and the other is the L1 fee, charged in proportion to the size of the diff that the transaction leaves on Bitcoin.

Source: Citrea

Interestingly, Citrea calculates the size of these diffs differently depending on the item. If an ordinary user's account balance changes, only 32 percent of the original size is charged; if a slot in a contract's internal storage changes, it is 66 percent. However, if it is a brand-new account appearing for the first time, a one-time extra byte charge applies to establish its stateful compression index. Rather than publishing full 20-byte addresses directly to the Data Availability (DA) layer, Citrea assigns each new address a compact 8-byte index (u64) and pushes this relationship to the DA layer just once. Subsequent operations can then reference the account by its short index, allowing frequent operations like balance changes to merge seamlessly during state diff computation and drastically lowering long-term data costs for the user.

The process by which a single transaction gets confirmed on Citrea unfolds across three stages with different levels of guarantee. In the first stage, Confirmed, the sequencer builds a block and signs it immediately, returning a result to the user within seconds. However, since this stage is not yet inscribed on Bitcoin, it can in principle be reversed. In the second stage, Finalized, the sequencer records on Bitcoin a commitment binding the order of transactions, and after six Bitcoin blocks are produced, the transaction order is fixed. In the third stage, Proven, the receipt produced in the previous section, the ZK proof, is permanently inscribed on Bitcoin, establishing an irrefutable, Bitcoin-backed certificate of correctness verified by full nodes. From an institutional operations perspective, these three stages are not just technical detail but a device that explicitly exposes the tradeoff between capital turnover speed and settlement guarantee level. Using this staged finality, short-term trades can be recycled at the Confirmed stage while large settlements wait until the Finalized or Proven stage, enabling differentiated operations.

4. The Clementine Bridge: Implementing a Trust-Minimized Bitcoin Bridge

4.1 BitVM: What It Means to Verify Proofs on Bitcoin

Source: bitvm.org

Clementine is the bridge that underpins the two-way peg between Bitcoin and Citrea, and at its foundation lies BitVM, the technology briefly touched on in Chapter 3. Understanding exactly what BitVM is and how it works is essential to grasping how Clementine reduces trust.

BitVM is a technique proposed by Robin Linus in 2023. It is a workaround that allows the verification of arbitrarily complex computations on Bitcoin without changing Bitcoin's consensus rules, and it rests on two basic tools.

The first tool is a device that mimics the covenant mechanism that Bitcoin lacks. On chains like Ethereum, once funds enter a contract, they can be locked through smart contracts so that they only exit when predefined conditions are met. Bitcoin script cannot implement such functionality, so it is difficult to force funds to move only along specific rules. Clementine tries to fill this gap with signatures. Multiple signers come together to form an N-of-N multisig and use MuSig2 to pre-sign the transaction paths for each deposit. Once this process is complete, funds can only exit through the pre-signed paths. To pull funds out through any other path, the signers would have to collectively sign an invalid state. If even one of several signers honestly refuses to sign outside the protocol rules, that becomes impossible. In short, safety is guaranteed not by the honesty of a majority but by the honesty of a single party.

The second tool is a device for proving falsehoods. When someone commits to a value on Bitcoin, they attach a cryptographic hash commitment bound to that value within a Taproot script. This commitment has the property that it binds the operator to a single deterministic computational state. The principle is simple: the operator commits to the inputs and outputs of a function using hashes. If the same commitment is evaluated with conflicting values, or if the math doesn't add up and this contradiction can be detected through Bitcoin script to seize the signer's collateral.

On top of these two tools, BitVM makes it possible to perform the heavy computation of zero-knowledge proof verification on Bitcoin. BitVM is based on optimistic verification. If the Groth16 receipt verifier that Citrea produces were ported directly to Bitcoin script, it would reach about 3 GB in size, while Bitcoin's block size limit is only 4 MB, meaning the verifier could not fit in a single block. So BitVM chops the verifier into chunks and has the operator commit to all intermediate results of each chunk via hash commitments. According to the whitepaper's example, about 960 chunks are generated per peg-out, and the operator submits these to Bitcoin through an assert transaction. Normally no computation runs on the Bitcoin network, but if a dispute occurs, a watchtower can permissionlessly execute a single 'disprove' transaction containing the exact contested chunk on Bitcoin to resolve the issue.

BitVM has evolved quickly. The first version, BitVM1, was designed for only two parties and required up to dozens of onchain transactions to resolve a dispute. Its successor, BitVM2, expanded to permissionless verification that anyone can challenge and shortened the dispute resolution period from 40 weeks to between two and three weeks. Clementine is a BitVM2-family bridge, and the announced BitVM3 is expected to move verification execution entirely offchain, significantly reducing costs. Citrea has also been designed with BitVM3 compatibility in mind.

4.2 How the Clementine Bridge Works

Source: Citrea

To understand how the Clementine bridge operates, the fastest path is to follow, in chronological order, how assets flow from Bitcoin into Citrea and back out to Bitcoin. First, the five types of actors involved in the operation of the Clementine bridge can be defined as follows.

• Users: Parties that initiate peg-ins and peg-outs.
• Signers: A committee of N members. They emulate covenants through pre-signing and are responsible for moving funds into the vault during peg-ins and directly remitting funds during optimistic peg-outs.
• Operators: Rational actors who deposit collateral of around 2 BTC and, on peg-out, pay the user from their own funds first before recovering the amount in the next round.
• Watchtowers: Monitors that watch both Bitcoin and Citrea, submitting header proofs of the Bitcoin chain they have observed when disputes arise.
• Challengers: Permissionless entities who can force operators to prove their claims by initiating a Challenge transaction. Anyone with enough capital to cover Bitcoin transaction fees can become a challenger.

In the sections that follow, we examine how these actors interlock when BTC moves between the Bitcoin network and Citrea, divided into three flows: peg-in, peg-out, and the challenge game.

4.2.1 Peg-In: BTC → cBTC

Source: Citrea

When a user deposits a fixed amount of Bitcoin into Clementine, the funds are first sent to a temporary Taproot deposit address, and then a subsequent transaction moves them into a vault protected by the 1-of-N assumption. On the current mainnet, the peg-in unit is fixed at 10 BTC. This vault is locked by covenant emulation so that funds can only exit along pre-signed paths. The Bitcoin address the user sends funds to is effectively a Taproot output bound by two conditions: one is a bridge path co-signed by the signer committee with the user's Citrea address inscribed in it, and the other is a refund path that lets the user reclaim the funds with their own key after 200 blocks (about 33 hours).

So even if the signer committee fails to move the funds into the vault, the user can recover their funds with their own key alone after a set period. On the normal path, the MoveToVault transaction, pre-signed by the signers during the deposit setup stage, is submitted to the Bitcoin network by the operator. Once this transaction is confirmed on Bitcoin for at least six blocks and Citrea's Bitcoin light client contract verifies the deposit and the recipient address, an equivalent amount of cBTC is issued inside Citrea. For the user, the process from Bitcoin deposit to cBTC receipt typically takes around one hour. Issuing cBTC without an actual Bitcoin deposit is naturally blocked through this process.

4.2.2 Peg-Out: cBTC → BTC

Source: Citrea

Peg-outs follow either a normal optimistic path or an operator path, depending on the signers' behavior.

• Optimistic path: When a user burns cBTC inside Citrea to request a withdrawal, the first path Clementine tries is a shortcut in which neither operators nor the challenge game appear. If all signers are online, they directly co-sign the user's withdrawal transaction and remit BTC straight to the user. The user can withdraw within one or two Bitcoin blocks, and under normal conditions most withdrawals are completed on this path.
• Operator path: If a signer fails to respond for about 12 hours or more, the optimistic payout cannot proceed, and an operator steps in. The operator pays the user the Bitcoin owed to them from their own funds first. The user still receives the funds within one or two Bitcoin blocks on this path, and the operator then begins the process of recovering the amount they pre-paid from the bridge vault in the next round. To begin the recovery, the operator submits a KickOff transaction to Bitcoin to claim reimbursement, initiating the challenge window. After a roughly 1.5-day challenge timeout window in which no one raises a dispute, the operator unlocks the funds with a NoChallenge transaction and receives the reimbursement in the next round. The normal flow ends here.

One point worth noting about the peg-out structure is that since the operator handles the pre-payment from their own funds, the size of withdrawal an operator can process is limited by the available capital that operator holds. This means that the thicker the operator pool, the larger the total volume of withdrawals that can be processed simultaneously.

4.2.3 The Challenge Game

When someone raises a question about an operator's recovery process, the challenge game unfolds. The party in the challenger position is the challenger, who is a permissionless monitor, not limited to identified participants but open to anyone willing to put up capital. When a challenger challenges the operator's claim, another set of monitors called watchtowers then present the state of the Bitcoin network as they have observed it. Watchtowers, like operators, are identified participants. They follow the Bitcoin chain on their own nodes and verify whether the block hash the operator committed to actually appears in that chain by submitting a succinct Header Chain Proof of the heaviest canonical chain. Once this fork selection proof is established, there is no back-and-forth interactive disclosure or reliance on Winternitz signatures. Instead, because Clementine uses a non-interactive BitVM2 architecture, any fraudulent claim can be exposed and penalized in a single step.

If even one chunk among these revealed intermediate results contains an error, a challenger can run that single chunk directly on Bitcoin to refute the operator's claim. If the refutation succeeds, the operator's collateral is seized in full and they are permanently expelled from the bridge.

The judgment of the challenge game is backed by two kinds of zero-knowledge circuits. One is the Header Chain Circuit (the Bitcoin Light Client) that mathematically guarantees through a zero-knowledge proof that the Bitcoin chain seen by the watchtower is valid and represents the true heaviest proof-of-work chain. The other is the bridge circuit, which comprehensively verifies the operator's entire claim. It proves in a single shot that the operator presented the Bitcoin chain with the most accumulated proof-of-work, that the chain contains the block they committed to, that the block contains the transaction in which they actually paid the user, and that the corresponding cBTC burn and withdrawal actually occurred on Citrea.

4.3 Collateral and Punishment Mechanisms

The way Clementine enforces honesty through structure rather than trust is most visible in its collateral design. Operators can only participate in the bridge after depositing about 2 BTC in collateral, and a single successful refutation is enough to cost them the entire collateral and permanently remove them from the bridge. Within a game shaped so that honest operators cannot be refuted and dishonest operators can be refuted and punished by anyone, the safety of assets comes not from trust in the operator but from the structure that ensures fraud is always caught and punished. For institutional capital, this is the most important shift. Counterparty risk in conventional custodial or multisig bridges has been managed by due diligence on the operator's credit and operational competence. In Clementine's structure, that risk is replaced by something enforced through game theory. In other words, the basis of safety becomes not who the operator is, but what they stand to lose if they cheat.

One point worth noting is that the time axis along which this collateral and punishment operate is separate from the time axis along which users receive their funds. Users receive funds in minutes on the optimistic path, and within one or two Bitcoin blocks even on the operator path. By contrast, an operator getting reimbursed for the funds they pre-paid from the bridge typically takes one to two weeks, combining the roughly 1.5-day challenge window with the payoff round that follows. Within a round, there are also devices such as timelocks to safely handle the exit of an operator from the set, and deterministic single-round challenge scripts. These function as safety margins that create the time needed to detect and refute even a single operator's attempt at fraud.

That the bridge's collateral can remain small is a particularly interesting point. Normally, processing a large number of withdrawals through a bridge would require massive capital tied up as operator collateral. According to a calculation example shown in the Clementine whitepaper, processing about 100,000 withdrawals over 12 years would require around 250 BTC in capital under conventional designs. Clementine, however, reuses the same collateral every round (about two weeks). To build its pre-signed connector trees without liquidity bloat, it leverages spendable Taproot outputs optimized at the bare minimum dust limit. Furthermore, while the architecture was originally designed to bypass old policy limits by wrapping state data into Taproot envelopes, the relaxation of Bitcoin’s OP_RETURN constraints allows the protocol to anchor its data commitments directly and cleanly onchain. This lowers the this capital requirement to around 2 BTC. That is a reduction of roughly 125 times, dramatically lowering the entry barrier for operators and allowing more parties to participate in bridge operations. As the operator pool grows thicker, the N in the 1-of-N assumption grows with it, and so does the bridge's safety margin. This capital efficiency therefore goes beyond mere cost reduction and strengthens the security model itself.

4.4 Remaining Trust Assumptions and the Decentralization Roadmap

The Citrea and Clementine structures examined so far reduce trust as far as Bitcoin utilization infrastructure has been able to, but they have not reached full trustlessness. The Citrea team also states this explicitly and has indicated that, through the post-mainnet roadmap, the remaining trust assumptions will be reduced further along two dimensions: first, the decentralization of Citrea chain operations, and second, the reduction of trust assumptions in the Clementine bridge.

4.4.1 Decentralization of Chain Operations

Rollups have always carried questions about decentralization due to their structure. A rollup's structure fundamentally consists of a sequencer that orders transactions to build blocks and a verification mechanism that checks the integrity of those blocks. In optimistic rollups, the verification comes through a challenge game and challengers based on a re-execution mechanism. In zero-knowledge rollups, there is a prover that generates zero-knowledge proofs and a verification circuit on chain that checks the integrity of those proofs. In most rollups, the sequencer, prover, and challenger roles are all filled by parties related to the operator, leaving centralization issues such as transaction censorship or deliberate processing delays.

Citrea at the mainnet stage sits at the starting point of this familiar path. The sequencer that orders transactions and builds blocks, and the prover that issues proofs for those blocks, are both currently operated as a single party by the Citrea Foundation (or Chainway Labs). However, this single operation does not imply arbitrary authority. Because every state transition is verified with a zero-knowledge proof and full nodes re-verify the proof, the moment the sequencer produces an incorrect result, that result cannot pass Bitcoin's verification. The maximum power the sequencer can wield is limited to selecting and ordering transactions and slowing down processing. Violating correctness, diverting funds, or arbitrarily freezing assets is structurally impossible. Even if the sequencer deliberately omits a transaction, the moment the next sequencer commitment is inscribed on Bitcoin, that order is permanently fixed, making any later tampering impossible.

There is, however, still some room for transaction censorship, so Citrea has placed on its roadmap the introduction of a force inclusion mechanism, as implemented in advanced Ethereum rollups like Arbitrum and Optimism. This is a feature that, when a user submits a transaction directly to Bitcoin, requires Citrea nodes to process it. Once activated, users will be able to take a Bitcoin-based detour regardless of the sequencer's cooperation. In addition, the Citrea team has explicitly listed the introduction of multiple provers and a decentralized sequencer as key tasks for after mainnet. Once these stages are complete, the trust minimization Citrea claims will reach a more fully realized form in the operational dimension as well.

On the operational side, as with other rollups, a Security Council made up of five members is also active. Citrea's Security Council operates under a 3-of-5 multisig, and Citrea has stated that a majority of the council is composed of external parties independent of the development team, Chainway Labs. The council holds key authority over core contracts, including changes to Clementine's funds usage paths, rotation of the signer set, emergency system halts, and upgrades to the Citrea bridge contract, the light client contract, and the fee vault contract.

4.4.2 Trust Assumptions of the Clementine Bridge

For Clementine to reach full trustlessness, an upgrade to Bitcoin itself appears necessary. If opcodes that significantly improve the implementation flexibility of Bitcoin script, such as OP_CAT, were added, it might become possible to implement a trustless bridge without a signer set. But such soft forks must go through Bitcoin's social consensus and have no firm timeline. BitVM can be seen as a transitional means for this period, and as use cases like Citrea expand, it could also lead to upgrades to the Bitcoin network itself.

At the current point in time, the security of the Clementine bridge can be summarized along two lines.

First, the mainnet signer set is not an anonymous majority but rests on a 1-of-10 assumption composed of 10 publicly identified infrastructure companies: Chainway Labs, Galaxy, Coinsummer, Omakase, Nansen, Nethermind, Laminated Labs, Hashkey Cloud, Finoa, and Luxor. Since the Clementine bridge operates under a 1-of-N assumption, safety can be guaranteed as long as even one of these acts honestly. For institutions, this means that counterparty assessment is distributed across the combined credit of N parties rather than the single credit of one, and the decision to put Bitcoin holdings to use does not have to be tied to the operational risk of a single company. This is a decisive break from existing custodial detours.

One point worth noting is that a single institution can serve in multiple roles at once. This is a design choice that concentrates the 1-of-N honest assumption among parties with clear economic incentives. The institutions listed above can serve as signers, watchtowers, and challengers all at the same time. For institutions, this means that counterparty assessment is distributed across the combined credit of N parties rather than the single credit of one. Citrea also has expanding the signer set on its roadmap, so as the population grows, the safety margin is expected to thicken further.

Source: Clementine Whitepaper

Second, the security of Clementine's light client is based on economic safety. According to the Clementine whitepaper, even if an attacker were to privately mobilize 45 percent of Bitcoin's hash rate for about two weeks, the probability of a successful attack would remain at around 0.5 percent. Reducing the share to 44 percent drops the probability sharply to about 0.02 percent. These are conservative conditions even compared to Bitcoin's 51 percent assumption.

5. A Dollar Aligned with Regulation: ctUSD

5.1 A Bitcoin-Based Stablecoin

Source: Citrea

Being able to move Bitcoin in a trust-minimized way does not mean utilization happens automatically. For lending, trading, and settlement to flow smoothly, Bitcoin alone, with its daily price swings, is not enough. A stable, dollar-pegged asset must come paired with it. The cycle of taking Bitcoin as collateral and borrowing dollars, buying and selling Bitcoin against dollars, and settling the result back in dollars all requires a unit of value with controlled volatility, available anywhere.

For institutions to use it, however, stability alone is not enough for this dollar asset. It must sit within a clear regulatory framework, and its issuance, redemption, and reserve management must be transparently administered. Citrea's second pillar, ctUSD, is a stablecoin designed precisely to meet these requirements.

5.2 The Structure of ctUSD

ctUSD is an asset issued by MoonPay and supported by M0's stablecoin infrastructure. M0 is a kind of shared infrastructure that helps multiple issuers create stablecoins under their own names, with a base token called $M at its center. $M is a token overcollateralized by safe assets such as short-term U.S. Treasuries, and issuers approved by M0 can use $M as a basis to create their own branded stablecoins on audited templates. Issuers exchange their stablecoins for $M at 1:1 through a counter called SwapFacility. Thanks to this structure, even if the issuer disappears, users holding the stablecoin can still recover value through $M's underlying collateral. ctUSD is one of the extensions issued on top of this structure, collateralized 1:1 with short-term U.S. Treasuries and cash, and the reserves are managed separately for the benefit of token holders rather than as MoonPay's own assets.

On the regulatory side, ctUSD has been designed to align with the guidelines of the U.S. stablecoin regulation bill, the GENIUS Act. The issuer, MoonPay, holds multiple regulatory credentials, including a New York BitLicense and trust charter, U.S. money transmitter licenses, European MiCA authorization, and FCA registration in the U.K. It also has compliance controls that can freeze or block specific addresses when legally required.

Another characteristic of ctUSD is that it is issued natively on Citrea from the start. Rather than bringing in an asset that was first issued on another chain through a bridge, Citrea itself becomes the place of issuance. The same principle is applied to both Bitcoin and the dollar: minimize what needs to be bridged in, and accept only assets routed through the most trust-minimized paths possible.

5.3 Implications for Institutions

The role ctUSD plays in the context of institutional utilization is clear. It is the banking rail connecting Bitcoin collateral on chain with the fiat currency system off chain. It connects directly to MoonPay's base of over 30 million verified users, and through MoonPay's subsidiary Iron, virtual accounts (vIBAN) are issued, so a flow is already in place where bank transfers from users automatically convert to ctUSD. Support for use through payment instruments such as Visa, Mastercard, Apple Pay, Google Pay, and PayPal has also been extended, broadening the points of contact with existing financial infrastructure. The moment the asset Bitcoin (cBTC) and the stable unit of value the dollar (ctUSD) come together on a single chain, institutional-grade activities such as Bitcoin-collateralized lending, trading, and structured products can finally operate on the same rail.

6. The Engine That Coordinates Bitcoin's Utilization: CTR

Even with a trust-minimized Bitcoin bridge and a regulation-aligned dollar in place, Bitcoin does not automatically get used. Even if the Citrea chain itself is well designed, without bringing the liquidity within the Bitcoin network into Citrea, it remains nothing more than well-designed infrastructure.

Citrea aims at this problem through its own token, CTR. Citrea seeks to use CTR as a tool for jointly deciding where capital on top of Bitcoin should flow. If an ordinary governance token only decides the operating policies of a protocol, CTR goes one step further and influences the deployment of capital itself.

6.1 CTR and xCTR

Source: Citrea

Citrea's token design centers on a non-transferable token called xCTR, which users receive when they stake CTR. xCTR follows a modified vote-escrow model, in which governance influence scales dynamically with a user's total xCTR balance. In addition to governance influence, xCTR also serves as the basis for receiving rewards. Initially it is exchanged with CTR at 1:1, but over time, as rewards flow in, the exchange ratio rises beyond 1:1. In other words, xCTR received from the same amount of CTR will return more CTR over time, and the difference becomes the reward the staker receives.

However, simply staking CTR and holding xCTR only generates base emissions and automated unstaking penalty rewards. For xCTR to receive multiplied network rewards, the holder must actually participate in governance voting. Stakes that maintain their position without voting miss out on these significant emission multipliers. This is a design that ties capital to decision-making, ensuring that simply holding the token does not grant influence and that only staking and actively participating in decisions is disproportionately rewarded.

Similar conditions apply to unstaking. To withdraw CTR immediately, a penalty of about 50 percent is applied, which decreases to zero over about 90 days. This penalty is not burned but is distributed proportionally to the remaining stakers, encouraging capital that is committed to the ecosystem to lead governance rather than capital chasing short-term returns.

The governance influence gathered this way translates into actual capital deployment through an automated device called the gauge. When xCTR holders concentrate votes on a particular liquidity pool, the liquidity incentives flowing from the governance treasury are directed toward that pool. In other words, where liquidity should be placed more thickly is decided by token holder votes. The gauge works as a self-adjusting mechanism in which the market itself decides the direction of incentives. When liquidity concentrates in a particular pool, the incentives for that pool are naturally adjusted, and in the opposite case, the market finds its way back to a more efficient equilibrium.

Another supporting device is the dual treasury. In terms of governance, Citrea has separated two kinds of funds. One is the governance treasury, controlled by xCTR holders. The other is the foundation treasury, managed by the Citrea Foundation. The governance treasury is used for market-aligned activities such as liquidity incentives through gauges, committee selection and rewards, and the selection and compensation of infrastructure providers. The foundation treasury is set aside for longer-horizon work such as research, grants, and operations, and is explicitly restricted from being used for ongoing liquidity emissions. If the foundation wishes to run a liquidity program, it must request approval from governance with clear goals and KPIs. Control over short-term capital flows is placed in token governance rather than in a centralized entity. For institutional capital, this separation means that the incentives affecting the liquidity they supply are under the control of token governance rather than the foundation's discretionary decisions, making the sustainability of capital deployment predictable in advance.

6.2 Combination with Institutional Liquidity

The most concrete expression of CTR's coordination role appears in the institutional liquidity program. Citrea has announced that it has secured over $50 million in liquidity commitments from asset managers including Galaxy Digital. This capital is supplied not in dollars but in Citrea's native assets, cBTC and ctUSD, and is deployed across lending markets such as Morpho and Zentra, decentralized exchanges, and cBTC-based yield products.

A scenario can help illustrate how this mechanism would actually work. Suppose an asset manager supplies cBTC and ctUSD liquidity to Morpho's Bitcoin-collateralized lending market, and xCTR holders direct gauge votes to concentrate incentives on that market. As liquidity deepens, borrowing rates naturally fall, and lower rates in turn attract more demand for Bitcoin-collateralized loans. The supply of capital, the decisions of governance, and the applications running on top of them all align in the same direction through a single token. For institutions, this means that the liquidity they supply does not disperse arbitrarily, but flows into areas where demand is being formed through token governance. CTR plays the role of pulling capital and participants together toward a single goal: putting Bitcoin to work.

7. Closing

Bitcoin has long held the position of being the safest store of value among cryptocurrencies. But the fact that an asset is safe enough also means that it is lazy enough, and to combine the two properties of safety and productivity, the asset has had to be entrusted to someone whose credit could be borrowed. The history of Bitcoin utilization has been the history of detours built around accepting these terms.

Citrea matters because these long-standing terms are no longer the only option. A rollup structure that uses Bitcoin as the basis for data and settlement, a pipeline that compresses zero-knowledge proofs into a form Bitcoin can verify, a bridge operating on a 1-of-N assumption built on BitVM, a dollar issued within regulation, and a token coordinating capital flows: the result of combining all of these can be condensed into a single sentence. For the first time, a path has opened in which Bitcoin can be put to use while surrendering almost none of its trustlessness.

The more interesting question is what change this path will bring to the asset Bitcoin itself. Over the past 15 years, the position Bitcoin has occupied has been digital gold: an asset that stores value while enduring price swings, a reference point for measuring the value of all other crypto assets, a hedge against inflation and currency fluctuations. All of these are roles within the realm of holding, and the stability that holding brings has shaped Bitcoin's identity.

The picture Citrea presents is one in which Bitcoin moves beyond an asset of holding into an asset of operation. A cycle in which Bitcoin is taken as collateral to borrow other assets, those assets trade in the market, and the results of those trades settle back into Bitcoin all runs on a single chain, borrowing Bitcoin's security as is. Just as gold expanded its meaning by moving from a simple store of value into the underlying asset of lending and derivative markets, Bitcoin too may now be on the verge of a transition from digital gold to digital capital.