Gas model and fee token explanation.
In Buburuza, gas fees are paid in the native token BUBU, which aligns economic incentives across users, sequencers, validators, and enterprise participants. The gas model is designed to reflect both the costs of execution on Buburuza (L3) and the costs of anchoring data onto an underlying base layer (L2 settlement). This ensures the network remains financially sustainable while keeping fees predictable and fair.
Here’s a detailed breakdown of how it works:
Components of the Fee
The total fee a user pays (in BUBU) is composed of two main parts:
Rollup / Execution Fee (L3 component) This corresponds to the computational, storage, and state-change costs incurred by executing the transaction within Buburuza.
Each EVM opcode (e.g.
SLOAD,CALL, arithmetic ops) has a gas cost (just like in Ethereum).Additional costs arise from writing to state, accessing storage, executing precompiles, and internal rollup-specific overhead.
This fee is essentially
GasUsed_L3 × GasPrice_L3.
Settlement / Data Fee (L2 anchoring component) Since batches of transactions (or transaction data) must eventually be posted to a base layer (L2) for final settlement and security, there is a cost associated with the calldata posted or data committed on L2.
The cost is a function of the size (in compressed bytes) of the data committed, and the current data-price on L2 (i.e. how much cost per byte on that base chain).
That L2 cost is then converted (or “translated”) into an equivalent gas cost on Buburuza so the user pays up front in BUBU.
This ensures that the sequencer or batch poster who submits that data on L2 is reimbursed fairly.
Thus:
Total Fee (in BUBU) = (GasUsed_L3 × GasPrice_L3) + (L2_Data_Cost converted to BUBU-equivalent)How L2 Data Cost is Incorporated (Buffering)
Because the system must pack both components into a single “gas limit × gas price” format (to preserve compatibility with wallets and tooling), the L2 data cost is incorporated via a buffer or adjustment in the effective “gas limit” that the user sees.
Conceptually:
Let P = GasPrice_L3 (in BUBU per gas unit).
Let L2Gas = GasUsed_L3 (from executing on Buburuza).
Let L2Cost = (size_in_bytes × L2_price_per_byte).
Then we compute a buffer B as:
This B is expressed in “gas units” so that P × B yields the L2 cost in BUBU.
Therefore, the gas limit submitted is:
And the transaction fee computed is:
Dynamic Pricing & Adjustments
Adjustment of L2 Price per Byte The system dynamically adjusts the “per-byte price” for L2 data to reflect network congestion, L2 gas market conditions, and the cost borne by batch submitters. This ensures that fees justice the actual cost of settlement.
Refund / Overpayment Buffer If the actual cost when the batch is posted ends up lower than estimated, excess can be refunded or credited.
Minimum Base Fee & Floors A minimum allowable gas price may exist to ensure that sequencers / operators always receive enough compensation.
Prioritization & Tips Optionally, users can include a “priority tip” in BUBU to signal urgency. The sequencer can choose to prioritize higher-tip transactions, especially under high load.
Last updated