# Fee Model

Citrea implements a hybrid fee model that combines Ethereum's EIP-1559 mechanism with a novel L1 data availability fee. This dual approach ensures users pay for both L2 execution and the cost of posting state changes to Bitcoin.

## Fee Components

Every transaction on Citrea incurs three types of fees:

| Component        | Description                              | Destination                                                                                     |
| ---------------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Base Fee**     | EIP-1559 base fee for L2 execution       | [BaseFeeVault](https://docs.citrea.xyz/developer-documentation/system-contracts/fee-vaults)     |
| **Priority Fee** | Optional tip to incentivize inclusion    | [PriorityFeeVault](https://docs.citrea.xyz/developer-documentation/system-contracts/fee-vaults) |
| **L1 Fee**       | Data availability cost for state changes | [L1FeeVault](https://docs.citrea.xyz/developer-documentation/system-contracts/fee-vaults)       |

The total transaction cost is:

```
Total Fee = (base_fee_per_gas + priority_fee_per_gas) × gas_used + L1_fee
```

## Base Fee (EIP-1559)

Citrea uses Ethereum's EIP-1559 fee mechanism with the following parameters:

| Parameter                   | Value                      |
| --------------------------- | -------------------------- |
| Block gas limit             | 10,000,000                 |
| Minimum base fee            | 0.001 gwei (1,000,000 wei) |
| Elasticity multiplier       | 2                          |
| Base fee change denominator | 8                          |

The base fee adjusts dynamically based on network congestion. When blocks are more than 50% full, the base fee increases; when blocks are less than 50% full, it decreases. This mechanism helps maintain predictable transaction inclusion while preventing spam.

{% hint style="info" %}
The minimum base fee ensures a floor price for transactions even during periods of low network activity. This prevents potential spam attacks that could occur with near-zero fees.
{% endhint %}

## L1 Data Availability Fee

The L1 fee is Citrea's unique mechanism for charging users for the Bitcoin data availability cost. When you execute a transaction, any state changes (storage modifications, balance updates, contract deployments) must eventually be posted to Bitcoin as part of a [batch proof](https://docs.citrea.xyz/essentials/architecture-and-transaction-lifecycle#5-batch-proof-generation-submission).

### How L1 Fee is Calculated

```
L1_fee = l1_fee_rate × diff_size
```

Where:

* **l1\_fee\_rate**: Current cost in wei per byte, derived from Bitcoin fee rates
* **diff\_size**: `(uncompressed_diff × 0.48) + 2` — the compressed state diff size plus 2 bytes overhead that are always posted even when no transactions take place

### State Diff Size Calculation

The state diff represents all changes your transaction makes to the blockchain state. Citrea calculates this based on the [`calc_diff_size` function](https://github.com/chainwayxyz/citrea/blob/main/crates/evm/src/evm/handler.rs#L430) and works as follows:

| Change Type             | Raw Size                     | Charged % |
| ----------------------- | ---------------------------- | --------- |
| Account info (EOA)      | 53 bytes (41 value + 12 key) | 32%       |
| Account info (Contract) | 85 bytes (73 value + 12 key) | 32%       |
| Storage slot change     | 68 bytes (36 key + 32 value) | 66%       |
| New account index       | 32 bytes (24 key + 8 value)  | 100%      |

The "Charged %" column indicates what fraction of the raw size users pay. For example, account changes are charged at 32% of their raw size, meaning users effectively receive a 68% discount.

**Why discounts exist:** When multiple transactions in the same batch modify identical accounts or storage slots, their state diffs merge during batch proof creation. Historical data from Ethereum shows that approximately 68% of account changes and 34% of storage changes merge with other transactions. The charged percentages reflect these merging ratios, ensuring users collectively pay fair prices without overcharging individuals.

The final uncompressed diff size is calculated as:

```
uncompressed_diff = (account_bytes × 0.32) + (storage_bytes × 0.66) + new_account_index_bytes
```

Where `account_bytes` is the sum of raw byte sizes for all changed accounts, `storage_bytes` is the sum for all changed storage slots, and `new_account_index_bytes` covers first-time account indexing.

{% hint style="info" %}
A 48% Brotli compression ratio is then applied to all state diff calculations, reflecting the average compression achieved when posting data to Bitcoin. The final compressed size adds a 2-byte overhead per transaction.
{% endhint %}

### Example: Simple cBTC Transfer

A simple cBTC transfer between two existing EOAs modifies two accounts (sender and receiver):

* Both accounts: (53 + 53) bytes × 32% = 33 bytes
* After 48% compression: 33 × 0.48 ≈ 15 bytes
* Plus overhead: 15 + 2 = **17 bytes**

If the recipient is a **new address** (first time receiving), add a 32-byte account index:

* Account changes: 33 bytes (after discount)
* New account index: 32 bytes (no discount)
* Total uncompressed: 65 bytes
* After 48% compression: 65 × 0.48 ≈ 31 bytes
* Plus overhead: 31 + 2 = **33 bytes**

At an L1 fee rate of 5 sat/vByte (12.5 gwei/byte), these transfers cost approximately 212 gwei and 412 gwei respectively.

### L1 Fee Rate Source

The L1 fee rate is dynamically derived from Bitcoin's current fee market and is determined by the sequencer:

1. The sequencer fetches the current Bitcoin fee rate (in sat/vByte)
2. The rate is converted to wei/byte using: `1 sat/vByte = 2,500,000,000 wei/byte`
3. A maximum cap (default: 15 sat/vByte) prevents excessive charges during Bitcoin fee spikes

The conversion factor derives from: 1 satoshi = 10^10 wei (since 1 BTC = 10^8 sat and 1 cBTC = 10^18 wei), divided by 4 to account for Bitcoin's SegWit witness discount where witness data has 1/4 the weight of regular data.

This direct linkage means L1 fees on Citrea fluctuate with Bitcoin network congestion. Each block stores the current `l1FeeRate` (in wei/byte) in its header, which is calculated as:

```
l1_fee_rate = min(btc_fee_rate × multiplier, max_rate) × 2.5×10^9  (wei/byte)
```

The final L1 fee for a transaction is then: `l1_fee = l1_fee_rate × diff_size`

## Fee Estimation

Citrea provides a dedicated RPC method [`eth_estimateDiffSize`](https://docs.citrea.xyz/developer-documentation/rpc-documentation/citrea-rpc-documentation#eth_estimatediffsize) for estimating L1 data costs:

| Field        | Description                        |
| ------------ | ---------------------------------- |
| `gas`        | Estimated gas consumption          |
| `l1DiffSize` | Estimated state diff size in bytes |

The standard `eth_estimateGas` method returns an effective gas value that includes L1 costs:

```
effective_gas = gas_used + ceil(l1_fee / base_fee)
```

This allows standard Ethereum wallets to display meaningful cost estimates by expressing the L1 fee as equivalent gas units. The L1 fee itself can be calculated as:

```
l1_fee = l1DiffSize × current_l1_fee_rate
```

where `current_l1_fee_rate` is available in block headers via the `l1FeeRate` field.

After a transaction executes, its receipt includes an `l1DiffSize` field showing the actual state diff size that was charged.

## Typical Transaction Costs

The following table shows estimated costs for common transaction types at a Bitcoin fee rate of 5 sat/vByte (\~$100K BTC). These costs are indicatives and can vary between ERC-20 transfers and DeFi interactions. They are based on typical transaction patterns observed on Citrea's testnet. Actual costs vary with Bitcoin network congestion.

| Transaction Type                     | Gas       | Base Fee | L1 Diff Size | L1 Fee  | Total       |
| ------------------------------------ | --------- | -------- | ------------ | ------- | ----------- |
| cBTC Transfer (existing recipient)   | \~21,000  | \~$0.002 | \~17 bytes   | \~$0.02 | **\~$0.02** |
| cBTC Transfer (new recipient)        | \~21,000  | \~$0.002 | \~33 bytes   | \~$0.04 | **\~$0.04** |
| ERC-20 Transfer                      | \~65,000  | \~$0.006 | \~20 bytes   | \~$0.02 | **\~$0.03** |
| Token Approval                       | \~50,000  | \~$0.005 | \~30 bytes   | \~$0.04 | **\~$0.04** |
| DEX Swap                             | \~180,000 | \~$0.02  | \~70 bytes   | \~$0.09 | **\~$0.11** |
| DeFi Interaction (lending/borrowing) | \~300,000 | \~$0.03  | \~120 bytes  | \~$0.15 | **\~$0.18** |
| Simple Contract Deployment           | \~700,000 | \~$0.07  | \~40 bytes   | \~$0.05 | **\~$0.12** |

{% hint style="info" %}
Base fees scale with gas consumption, while L1 fees scale with state changes. A complex DeFi transaction that modifies many storage slots will have higher L1 fees than a simple transfer, even if gas consumption is similar.
{% endhint %}

### Bitcoin Fee Rate Impact

Since L1 fees derive directly from Bitcoin's fee market, costs fluctuate with Bitcoin network congestion. The following shows how a simple cBTC transfer (to existing address) varies across fee rates:

| Bitcoin Fee Rate       | L1 Fee Rate (wei/byte) | L1 Fee   | Total Tx Cost |
| ---------------------- | ---------------------- | -------- | ------------- |
| 1 sat/vByte            | 2.5 gwei/byte          | \~$0.004 | \~$0.01       |
| 5 sat/vByte            | 12.5 gwei/byte         | \~$0.02  | \~$0.02       |
| 10 sat/vByte           | 25 gwei/byte           | \~$0.04  | \~$0.04       |
| 15 sat/vByte (max cap) | 37.5 gwei/byte         | \~$0.06  | \~$0.07       |

The maximum L1 fee rate cap (default: 15 sat/vByte) protects users from extreme costs during Bitcoin fee spikes. Historical data shows Bitcoin fees typically range from 1-10 sat/vByte during normal conditions, with periodic spikes during high-demand periods.

{% hint style="warning" %}
During Bitcoin congestion events, fees can spike significantly. The sequencer caps the L1 fee rate to prevent excessive user charges, but this means the protocol may operate at reduced margins during these periods.
{% endhint %}

## Fee Distribution

All collected fees flow to dedicated [Fee Vault system contracts](https://docs.citrea.xyz/developer-documentation/system-contracts/fee-vaults):

| Vault            | Address                                      | Source                    |
| ---------------- | -------------------------------------------- | ------------------------- |
| BaseFeeVault     | `0x3100000000000000000000000000000000000003` | EIP-1559 base fees        |
| L1FeeVault       | `0x3100000000000000000000000000000000000004` | L1 data availability fees |
| PriorityFeeVault | `0x3100000000000000000000000000000000000005` | Priority tips             |

These vaults accumulate fees until withdrawn to configured recipient addresses. The separation enables transparent accounting of L2 operational costs versus L1 data availability costs.

## Reverted Transactions

Even if a transaction reverts or fails during execution, it still incurs L1 fees for the minimal state changes it causes. These include:

* The sender's nonce increment
* Balance reductions for gas fees

The L1 diff size for a failed transaction is significantly smaller than a successful one, but it is never zero. This ensures users cannot spam the network with intentionally failing transactions without cost.

## Transactions That Cannot Pay L1 Fees

Since the exact state diff size cannot be determined until a transaction executes, the sequencer must run the transaction first to calculate the required L1 fee. If during execution the sequencer determines that the sender lacks sufficient cBTC to pay the computed L1 fees, the transaction is not reverted—it is completely removed as if it was never executed. Importantly, the user pays no fees in this case, including no gas fees or L1 fees.

This design prevents situations where transactions consume gas to compute state diffs but then fail to pay the resulting L1 fees.

## Optimizing Transaction Costs

To minimize fees on Citrea:

1. **Batch operations**: Combine multiple state changes into fewer transactions when possible
2. **Avoid unnecessary storage writes**: Each storage slot modification incurs L1 costs
3. **Use efficient data structures**: Minimize the number of storage slots your contracts use
4. **Time transactions wisely**: L1 fees fluctuate with Bitcoin network congestion
5. **Set appropriate priority fees**: During low congestion, minimal priority fees suffice

## System Transactions

Certain protocol-level operations ([system transactions](https://docs.citrea.xyz/developer-documentation/system-contracts#system-transactions)) are exempt from fees. These transactions originate from the system signer and perform essential network functions without charging the network itself.