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
Priority Fee	Optional tip to incentivize inclusion	PriorityFeeVault
L1 Fee	Data availability cost for state changes	L1FeeVault

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.

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.

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.

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 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.

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.

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 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

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.

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.

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.

Fee Distribution

All collected fees flow to dedicated Fee Vault system contracts:

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) are exempt from fees. These transactions originate from the system signer and perform essential network functions without charging the network itself.