What Is Citrea? Bitcoin Layer 2
Bitcoin is famously hard to change, and that is the point. If you want programmable smart contracts with Bitcoin-grade settlement, you either compromise on trust, or you invent new ways to prove complex computation inside Bitcoin’s intentionally minimal environment. Citrea is built for the second path. It is a Bitcoin Layer 2 rollup that provides an EVM-compatible smart contract platform, uses Bitcoin for data availability and settlement, and relies on ZK-STARK validity proofs that are enforced on Bitcoin through BitVM-style optimistic verification.
TL;DR
Citrea is a Type 2 zkEVM rollup anchored to Bitcoin. It targets high EVM compatibility so Ethereum developers can deploy contracts with minimal rewrites, while still making practical engineering choices that improve proving performance. It uses a zkVM backend (RISC Zero) so full EVM execution becomes provable, which is the technical core of “Ethereum-like programmability, Bitcoin-like settlement.” It also positions this design as a way to bring existing EVM tooling, audits, and composability into a Bitcoin-anchored environment without asking Bitcoin to change its consensus rules.
What is Citrea, exactly?
Citrea is a Layer 2 rollup for Bitcoin that provides a general smart contract platform secured by Bitcoin’s blockchain. It batches transactions on an off-chain execution layer (the Citrea zkEVM), generates a succinct validity proof, and posts that proof and minimal state data to Bitcoin L1. The design goal is EVM-compatible execution with Bitcoin used for data availability and settlement, without requiring any Bitcoin consensus change.
Two design decisions define the project’s identity.
zkEVM rollup types, and why Citrea picked Type 2
Citrea aligns with Vitalik Buterin’s zkEVM taxonomy to make the trade-offs legible. Type 1 is fully Ethereum-equivalent and expensive to prove. Type 2 targets EVM equivalence with small engineering differences for proof practicality. Type 4 compiles from high-level languages into ZK-friendly VMs and breaks low-level equivalence.
Citrea positions itself as Type 2: it keeps the EVM mental model, but is willing to make limited changes that make proving feasible at real-world throughput. That choice matters because it lets Citrea import Ethereum’s tooling, audits, and contract composability into a Bitcoin-anchored environment, which is the fastest known path to a non-toy ecosystem.
Architecture
Citrea’s pipeline is a rollup pipeline, but with Bitcoin where you would normally expect Ethereum. Users submit transactions to the Citrea execution layer. The zkEVM executes them off-chain, then a validity proof (a ZK-STARK) is generated for the batch, and the proof plus minimal state data is inscribed onto Bitcoin.
Bitcoin as data availability
A core pillar is using Bitcoin L1 for data availability rather than an external committee. Every batch outputs a state diff that is published on Bitcoin along with the proof material, so any node can reconstruct the current Citrea state by reading Bitcoin blocks. This is explicitly positioned as Bitcoin-equivalent data availability, in contrast to validium approaches that introduce trust in a data committee or off-chain DA provider.
Bitcoin as settlement and finality
Citrea uses Bitcoin not only as a data store but as the ultimate arbiter of state. Each rollup batch is associated with a validity proof, and settlement occurs when the batch commitments are posted on Bitcoin and sufficiently confirmed. This design also creates an alignment effect: Citrea’s activity pays Bitcoin miner fees via data and commitment postings, contributing to Bitcoin’s fee market over time.
BitVM and Clementine
Bitcoin's minimal design does not let programmers openly write all kinds of programs, dApps, and contracts. However, a smart group of cryptographers and Zero-Knowledge engineers came up with ideas to help Bitcoin verifying correctness of execution of some programs.
BitVM, as used by Citrea
The core verification challenge is that Bitcoin script cannot directly verify a full STARK proof in one go due to size and expressiveness limits. Citrea addresses this with BitVM, a technique for achieving Turing-complete computations inside Bitcoin’s constraints by using an optimistic, challenge-based verification game. The operational result is simple but profound: correctness is enforced through dispute resolution, and Bitcoin remains the final court of appeal.
This produces a security posture that is closer to “trust Bitcoin and watchfulness” than “trust the operator.” As long as an invalid proof would be caught by at least one honest party, the system remains secure, and Bitcoin remains the ultimate enforcement layer for the rollup’s commitments.
Clementine: the two-way peg
Clementine is Citrea’s bridge design for moving BTC into Citrea as cBTC and redeeming cBTC back to BTC. It is designed as a trust-minimized peg with no multisig federation, secured under the assumption that at least one honest watcher will challenge invalid withdrawals. The important nuance is that Clementine is optimistic today because Bitcoin cannot natively verify the STARK proof directly, which introduces a dispute window and therefore a withdrawal delay in the worst case.
That trade-off is deliberate. Compared to prior sidechains such as Liquid and RSK that rely on federated multisigs, Clementine aims to make Bitcoin itself enforce peg rules via dispute resolution, reducing the trust surface area for the core custody bridge.
Security model
Citrea’s target is Bitcoin-equivalent security across validity, data availability, reorg resistance, and censorship resistance. Validity is provided by ZK-STARK proofs, with optimistic enforcement on Bitcoin via BitVM challenges and an honest-watchtower assumption. Data availability is provided by publishing all essential data onto Bitcoin, so anyone can reconstruct state by scanning Bitcoin blocks. Reorg resistance is inherited from Bitcoin’s finality assumptions. Citrea anchors rollup blocks to specific Bitcoin blocks, and after typical Bitcoin confirmation depth, reverting a finalized rollup batch becomes extremely unlikely because it requires a deep Bitcoin reorg. Censorship resistance is addressed by forced inclusion. A forced transaction envelope can be posted to Bitcoin that the rollup circuit must include in the next state, preventing a sequencer from permanently censoring a determined user. An escape-hatch style flow is also part of the safety story, enabling users to recover by leaning back toward Bitcoin when liveness assumptions break.
Funding and team
Citrea is developed by Chainway Labs, with Orkun Mahir Kılıç named as CEO and co-founder. Chainway Labs has raised $16.7M total. This includes a $2.7M seed round led by Galaxy Digital, and a $14M Series A led by Founders Fund, described as Founders Fund’s first Bitcoin ecosystem investment, plus other investors such as Delphi Ventures, Maven11 Capital, and Mirana Ventures, and angels like Erik Voorhees and Balaji Srinivasan. There has been no public token sale described for Citrea, with funding framed as private equity investment into Chainway Labs.
Token design: cBTC versus a governance token
On Citrea, the primary asset is cBTC, positioned as a 1:1 representation of BTC on the rollup. It acts as the native currency for gas fees and as the bridged BTC representation, but it is not positioned as a governance or fundraising token.
A separate governance or utility token is often discussed as a future possibility around mainnet, particularly for decentralizing sequencers and provers over time. Early-user distribution via testnet quests and NFT campaigns is a common pattern in the space, but the key analytical point is that governance decentralization and gas economics are distinct problems from “BTC representation,” so cBTC and a governance token serve different roles even if both exist.
Ecosystem: ₿apps and early integrations
Citrea’s early ecosystem is framed around a growing set of “₿apps” on testnet. Highlighted examples include Crest (self-custodial Bitcoin trading), Nectra (Bitcoin-backed stablecoin and lending), Satsuma (Bitcoin-first AMM DEX), and Garden Finance (a trustless bridge and atomic swap service connecting Citrea to other chains).
Key integrations include atomic swap infrastructure between Citrea and the Lightning Network (Citrex), wallet compatibility with MetaMask and a push toward support from Bitcoin wallets like Xverse, and BitVM Alliance collaboration with projects such as ZeroSync and Alpen. The ecosystem story here is less about “many apps today” and more about “the base rails exist for BTC-native liquidity, swaps, and stablecoin primitives.”
Fees: making Bitcoin-grade settlement affordable
Citrea’s fee mechanism is designed to cover both the cost of Layer 2 execution and the expense of posting data and proofs to Bitcoin, while keeping fees reasonable by amortizing Bitcoin costs across many transactions.
The fee model follows an Ethereum-like structure with a base fee and a priority fee, plus a dedicated L1 component that reflects Bitcoin posting costs. Fee accounting is implemented through three vault contracts, BaseFeeVault, PriorityFeeVault, and L1FeeVault, which provides a clean separation of what users pay for execution versus what they pay for settlement anchoring.
The L1 fee and why diff size matters
Posting to Bitcoin costs sats, so bytes matter. Citrea charges users according to how much their transaction contributes to the batch’s Bitcoin footprint, which makes the L1 fee behave like a “data fee” rather than a pure compute fee. A dedicated endpoint (eth_estimateDiffSize) is part of the developer story, giving integrators a way to estimate how a transaction will affect the state diff and therefore the Bitcoin cost component.
High Bitcoin fees and the amortization strategy
Bitcoin congestion is the obvious constraint for any Bitcoin-anchored rollup. Citrea’s central mitigation is batching: bundling many transactions into one Bitcoin transaction and dividing a small subset of Bitcoin block space among orders of magnitude more L2 transactions. The design also leans on compressed data posting and dynamic fee calibration so the L1 portion tracks Bitcoin fee rates rather than forcing the sequencer to subsidize miners during spikes.
Scalability levers also exist on the roadmap. Volition is described as a future option where some users can opt into off-chain data availability for lower fees at the cost of introducing a new trust assumption. Lightning integration is described as a complementary path for frequent small payments, making the broader BTC execution stack more flexible across payment and smart contract use-cases.
Gas token economics
Citrea uses cBTC for gas, which ties transaction fees to BTC’s value. That makes UX simple because BTC is the native economic unit of the ecosystem, but it also means real-world fee affordability can swing with BTC price moves. Over time, this creates pressure for careful parameter tuning and potentially governance around fee calibration, especially if the network wants stable “dollars-per-transaction” experience during volatile cycles.
Roadmap and future research
Citrea’s roadmap focuses on decentralizing key roles and expanding execution flexibility.
Sequencer decentralization is a post-mainnet goal to remove a single point of failure for liveness and ordering. Multi-prover support is described as adding proof-system diversity by enabling a second prover (SP1) alongside RISC Zero, reducing the risk of a single proof-system flaw becoming a systemic failure mode.
Multi-VM support is described as a modular zkVM direction that could add WebAssembly and potentially other VMs over time, enabling languages like Rust alongside Solidity. Trustless atomic swaps and deeper Lightning integration are highlighted as active areas, and volition remains the longer-term lever for fee-sensitive workloads that can accept a different DA trust profile.
Conclusion
Citrea’s thesis is that Bitcoin can be a programmable settlement layer without changing Bitcoin consensus. The architecture is specific: a Type 2 zkEVM for developer compatibility, ZK-STARK proofs for validity, Bitcoin postings for data availability and settlement, and BitVM challenge mechanisms to make correctness enforceable inside Bitcoin’s current constraints.
The core trade-off is explicit. Validity is optimistically enforced today, which introduces a watchtower assumption and dispute-window style withdrawal finality. If you accept that trade, you get a rollup model where the bridge is designed to avoid federated multisigs and where the rollup’s truth is anchored into Bitcoin itself.
Resources and further readings
Frequently asked questions
Check out most commonly asked questions, addressed based on community needs. Can't find what you are looking for?
Contact us, our friendly support helps!
How does Citrea really differ from other Bitcoin Layer 2 solutions in terms of security and design?
Most Bitcoin Layer 2s today either rely on federated multisigs, separate validator sets, or their own consensus tokens, which means users ultimately lean on some off-chain group rather than Bitcoin itself for final security. Citrea’s design is explicitly rollup-first: it executes transactions in an EVM-compatible environment, proves them with ZK-STARKs (via a zkVM built on RISC Zero), and posts compact state diffs plus proofs directly to Bitcoin, treating Bitcoin as both data availability and settlement. Because Bitcoin Script can’t natively verify these proofs, Citrea uses a BitVM-style optimistic challenge game, where any honest watcher can dispute an invalid state and enforce correctness on-chain. That shifts the trust model toward “Bitcoin + at least one honest verifier” instead of “trust a fixed federation,” while still accepting the usual rollup trade-off of a dispute window and monitoring requirement. From a design perspective, that makes Citrea feel closer to an Ethereum-style validity rollup anchored to Bitcoin than to a classic sidechain or custodial bridge.
Is Citrea mainnet live, and what does its current performance and fee profile look like?
Yes. Citrea mainnet is live and positioned as a production Bitcoin application layer, after earlier testnet phases that focused on the zkEVM pipeline and the Clementine bridge. According to the docs, the network currently targets a 2-second block time with a ~10 million gas limit, offering a more Ethereum-like UX on top of Bitcoin’s settlement guarantees. Fees are split conceptually into L2 execution costs (denominated in cBTC) and an L1 data component that reflects how much a transaction contributes to the state diff posted on Bitcoin, so real fees scale with Bitcoin blockspace prices rather than being fixed. In practice this means users should expect fees materially lower than direct Bitcoin transactions when batches are full, but still sensitive to BTC mempool spikes. Over time, batching efficiency, compression, and potential DA options like volition are intended to keep L2 fees acceptable even when Bitcoin itself becomes expensive, while still preserving the “Bitcoin as source of truth” story for the canonical rollup state.
How can developers start deploying smart contracts on Citrea, and what tooling is supported?
From a developer’s point of view, Citrea behaves like a familiar EVM chain that just happens to settle onto Bitcoin. The docs emphasize full EVM compatibility and describe deployment as “as easy as changing the RPC endpoint,” with guides for configuring Hardhat, Remix, and OpenZeppelin Wizard to point at Citrea’s endpoints. You fund a wallet with cBTC (bridged BTC) via the official Bridge Hub, add Citrea Mainnet or Testnet to any standard EVM wallet like MetaMask, and then deploy Solidity contracts just as you would on an Ethereum testnet. Full nodes expose a JSON-RPC surface that’s explicitly compatible with Ethereum tools, so explorers, indexers, and bots can integrate with minimal changes. That combination, Type 2 zkEVM semantics, cBTC gas, and drop-in support for existing EVM tooling, is what makes Citrea attractive for teams who want Bitcoin settlement without relearning an entirely new VM or ecosystem stack.
