# Bitcoin Appchains (L3)

Citrea lets you deploy **Bitcoin Appchains (L3s)**: application-specific OP Stack chains that **settle to Citrea**, while using a modular **Data Availability (DA)** layer like **Celestia** or **Avail**.

From an architecture point of view:

* **Bitcoin** is the base layer.
* **Citrea (L2)** is a rollup on Bitcoin (zkEVM).
* **Your Appchain (L3)** is an OP Stack chain that treats **Citrea as its settlement layer**, and uses **Celestia/Avail for DA**.

***

### Why an L3 ₿appchain?

An L3 is useful when you want **dedicated blockspace** and **predictable execution** for a single application (or app ecosystem), without competing for fees with everything else.

Some easy benefits from an infra perspective are as follows:

* **Dedicated blockspace**: your app’s throughput/fees are isolated from other apps.
* **Custom chain parameters**: block time, gas limits, sequencing policy, etc.
* **Lower DA costs**: batch data goes to a DA network (Avail/Celestia) instead of being fully posted on the settlement layer.
* **EVM + Ethereum tooling**: standard JSON-RPC, op-geth/op-node, Foundry, etc.

{% hint style="info" %}
Note: Citrea does not support EIP-4844 blobs at the moment. Therefore using an external DA layer keeps data costs and throughput more flexible.
{% endhint %}

***

### How an L3 works on Citrea

At a high level, an OP Stack L3 has the usual OP Stack components — except it settles to **Citrea**, and uses **Alt-DA mode** for data availability.

```
Users
  |
  | (JSON-RPC)
  v
L3 execution (op-geth)  <----- engine API ----->  L3 rollup node (op-node)
  |                                               |
  | produces blocks                               | derives chain by reading:
  v                                               |  - Citrea commitments
op-batcher                                        |  - DA data (Celestia/Avail)
  |
  | uploads batch data
  v
DA Server  --->  DA Layer (Celestia or Avail)
  |
  | submits DA commitment tx to Citrea
  v
Citrea (settlement + OP Stack contracts for the L3)
  ^
  | proposes outputs
  v
op-proposer
```

#### What each component does

* `op-geth`: Executes L3 transactions and serves the L3 JSON-RPC.
* `op-node`: Derives the canonical L3 chain by combining:
  * commitments on **Citrea**, and
  * batch data retrieved from the **DA layer**.
* `op-batcher`: Compresses L3 blocks into batches and publishes them.
* `DA Server (sidecar)`: The adapter between OP Stack and the DA network.
* `op-proposer`: Submits L3 output roots to Citrea (settlement/bridging logic).

***

### Data Availability via OP Stack Alt-DA mode

These ₿appchains use **Alt-DA mode** in the OP Stack:

1. The batcher **uploads** compressed batch data to the DA layer (via the DA Server).
2. The batcher **posts a commitment** on Citrea that points to that data.
3. Any node can follow Citrea, then use the DA Server to fetch the underlying batch data and fully derive the L3 chain.

{% hint style="info" %}
Note: Alt-DA mode is a beta OP Stack feature. The “generic commitment / DA-server” flow adds additional trust assumptions compared to posting all batch data directly on the settlement layer.
{% endhint %}

Both Celestia and Avail are DA networks designed to keep large volumes of transaction data available at lower cost than typical settlement layers.

#### Avail DA

* You run an **Avail DA Server** sidecar and publish data under an **AppID**.
* Avail’s model includes **light clients performing DAS**, with availability verification built around commitments/proofs (e.g., KZG-based designs).

#### Celestia DA

* You run a **Celestia Light Node** and a **Celestia DA Server** sidecar.
* Celestia is built around **Data Availability Sampling (DAS)** and **Namespaced Merkle Trees (NMTs)**.

***

### Transaction lifecycle (end-to-end)

1. A user sends a transaction to your **L3 RPC**.
2. The **sequencer** orders transactions and executes them in **op-geth**.
3. **op-batcher** collects L3 blocks and compresses them into batches.
4. Batch data is posted to **Celestia/Avail** via the **DA Server**.
5. A **DA commitment** is submitted to **Citrea**.
6. **op-node** derives the L3 state by reading Citrea + pulling batch data from the DA layer.
7. **op-proposer** periodically posts output roots to Citrea.

***

### Security model and tradeoffs

An L3 ₿appchain inherits different guarantees from different layers:

* **Settlement**: anchored to **Citrea** (and Citrea anchors to Bitcoin).
* **Execution correctness**: enforced by OP Stack rules and the L3 derivation pipeline.
* **Data availability**: depends on the selected DA layer **and** the Alt-DA publication/retrieval path.

If you are deploying an L3 beyond experimentation, you should add operational monitoring for:

* batch publication to DA,
* DA retrieval health,
* consistency between Citrea commitments and DA data.

***

For the remainder of this section we provide example deployments of ₿appchains.

If you want to learn more or build one from a business perspective, feel free to reach us at [https://origins.citrea.xyz](https://origins.citrea.xyz/).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.citrea.xyz/developer-documentation/bitcoin-appchain.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.