GigaHierz · Oct 8, 2026 · Oct 6, 2026 · Oct 6, 2026 · Oct 8, 2026
@@ -11,7 +11,7 @@ Check out the ["The Great Celo Halvening – Proposed Tokenomics in the Era of C
 
 The Carbon Offsetting Fund represents Celo's commitment to environmental sustainability by making the platform's infrastructure **carbon-negative**. The fund automatically transfers resources every epoch to partner organizations that use these assets for verified carbon offsetting projects.
 
-## How the Carbon Offsetting Fund Receives Assets
+## How the Carbon Offsetting Fund receives assets
 
 - **Epoch rewards**: the Carbon Offsetting Fund receives 0.1% of epoch rewards, adjustable via governance and distributed automatically at each epoch.
-- **Transaction fees**: the Carbon Offsetting Fund receives 10% of transaction fees, adjustable via governance.
+- **Transaction fees**: the Carbon Offsetting Fund receives the share of transaction fees that Celo governance sets in the FeeHandler; see [Transaction fees](/operate/specification/transaction-fees#feehandler) for the current split.
@@ -30,23 +30,9 @@ used to pay gas fees are controlled via governance and the list of tokens allowe
 FeeCurrencyDirectory.sol. Fee abstraction on Celo works with EOAs. No paymaster required! Learn all
 about [fee abstraction](/build/fee-abstraction/overview).
 
-## Transaction Fee Allocation Post-L2 Transition
+## Transaction fee allocation
 
-With the shift to L2, the allocation of transaction fees has been restructured to support the network's evolving operational needs:
-
-- [**Carbon Offset Fund**](/learn/protocol/epoch-rewards/carbon-offsetting-fund): 10% of transaction fees continue to support the carbon offset fund, maintaining Celo's environmental commitment. This adjustment reflects the network's reduced carbon footprint following the L2 upgrade.
-
-- **Network Operations**: The remaining 90% of transaction fees are allocated to essential network operations, including:
-
-  - **Data Availability**: Ensuring that transaction data is accessible and secure.
-
-  - **Layer 1 Fees**: Covering costs associated with interactions between Celo's L2 and the Ethereum mainnet.
-
-  - **Sequencer and Batcher Operations**: Supporting the infrastructure that orders and batches transactions on the network.
-
-  - **Revenue Sharing with the OP-Stack**: Complying with the Superchain Ecosystem requirements, which involve sharing revenue with the OP-Stack.
-
-This reallocation ensures that transaction fees are utilized effectively to maintain network sustainability and operational efficiency in the L2 environment.
+Celo governance sets how the FeeHandler splits collected fees; see [Transaction fees](/operate/specification/transaction-fees#feehandler) for the current split.
 
 ## Conclusion
 

@@ -14,7 +14,7 @@ The Celo L2 network has the following chain properties:
 - Block gas target: 6,000,000 gas (see EIP-1559 elasticity multiplier)
 - EIP-1559 elasticity multiplier: 5
 - EIP-1559 denominator: 400
-- EIP-1559 floor: 25 Gwei
+- Minimum base fee: 200 Gwei ([Jovian](/operate/specification/upgrades/jovian) `minBaseFee`)
 
 ### Parameters
 
@@ -31,14 +31,14 @@ L1 and L2 contract addresses are listed in the documentation.
 
 ## Celo Sepolia testnet
 
-The Celo Sepolia testnet has the same chain properties as Celo Mainnet:
+The Celo Sepolia testnet has the same chain properties as Celo Mainnet, except for a lower minimum base fee:
 
 - Block period: 1 second
 - Block gas limit: 30,000,000 gas
 - Block gas target: 6,000,000 gas (see EIP-1559 elasticity multiplier)
 - EIP-1559 elasticity multiplier: 5
 - EIP-1559 denominator: 400
-- EIP-1559 floor: 25 Gwei
+- Minimum base fee: 50 Gwei ([Jovian](/operate/specification/upgrades/jovian) `minBaseFee`)
 
 ### Contract addresses
 
@@ -53,13 +53,18 @@ L1 and L2 contract addresses are listed in the documentation.
 | Config                            | Celo        | OP     |
 |-----------------------------------|-------------|--------|
 | `maxSequencerDrift`               | 2892        | 1800   |
-| `sequencerWindowSize`             | 3600        | 3600   |
-| `channelTimeout`                  | 300         | 300    |
-| `finalizationPeriodSeconds`       | 12          | 12     |
+| `sequencerWindowSize`             | 7200        | 3600   |
+| `channelTimeout`                  | 50          | 50     |
+| `finalizationPeriodSeconds`       | 604800      | 604800 |
 | `enableGovernance`                | `false`     | `true` |
-| `eip1559Denominator`              | 400         | 50     |
-| `eip1559DenominatorCanyon`        | 400         | 250    |
-| `eip1559Elasticity`               | 5           | 6      |
-| `eip1559BaseFeeFloor`             | 25000000000 | -      |
-| `gasPriceOracleBaseFeeScalar`     | 0           | 1368   |
-| `gasPriceOracleBlobBaseFeeScalar` | 0           | 810949 |
+| `eip1559Denominator`              | 400         | -      |
+| `eip1559DenominatorCanyon`        | 400         | -      |
+| `eip1559Elasticity`               | 5           | -      |
+| `gasPriceOracleBaseFeeScalar`     | 0           | -      |
+| `gasPriceOracleBlobBaseFeeScalar` | 0           | -      |
+
+`channelTimeout` and `maxSequencerDrift` show the values in force. The Granite and Fjord upgrades made them protocol constants: 50 L1 blocks for `channelTimeout`, and 1800 seconds for `maxSequencerDrift`, which Celo's op-node raises by 1092 seconds to 2892 because the sequencer waits for L1 finality. The older configured values (`channel_timeout` 300 in Celo's `rollup.json`, and `maxSequencerDrift` 600 in OP's deploy config) no longer apply.
+
+OP Mainnet can change its EIP-1559 and gas price oracle values in its `SystemConfig` contract, so the OP column leaves them out. OP Mainnet's configuration and `SystemConfig` address are in the [Superchain Registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml).
+
+The minimum base fee is not part of this config. It is the `minBaseFee` value in the L1 `SystemConfig` contract, encoded in every L2 block header; see [Transaction fees](/operate/specification/transaction-fees#base-fee-floor).
@@ -25,4 +25,4 @@ ERC20 tokens can be bridged the same way as in the unmodified OP Stack, see [Bri
 
 ## Using Bridged Tokens as Fee Abstraction
 
-The `OptimismMintableERC20` (used to represent ERC20 tokens from L1 on L2) supports the [`IFeeCurrency`](https://github.com/celo-org/fee-currency-example/blob/master/src/IFeeCurrency.sol) interface, which is a requirement to use them as a Fee Abstraction token. Before a new `OptimismMintableERC20` instance can actually be used as Fee Abstraction, it still has to be added to the `FeeCurrencyDirectory` (`0x71FFbD48E34bdD5a87c3c683E866dc63b8B2a685`) by Celo governance. This is currently only the case for `WETH`.
+The `OptimismMintableERC20` (used to represent ERC20 tokens from L1 on L2) supports the [`IFeeCurrency`](https://github.com/celo-org/fee-currency-example/blob/master/src/IFeeCurrency.sol) interface, which is a requirement to use them as a Fee Abstraction token. Before a new `OptimismMintableERC20` instance can actually be used as Fee Abstraction, it still has to be added to the [`FeeCurrencyDirectory`](/build/tools/contracts/core-contracts#celo-mainnet) by Celo governance. This is currently only the case for `WETH`.
@@ -22,15 +22,14 @@ The [Isthmus](/operate/specification/upgrades/isthmus) upgrade also introduces a
 
 If you are coming from Ethereum, not having L1 data and operator fees is what you are used to, and you will feel right at home on Celo.
 
-## Base Fee Floor
+## Base fee floor
 
-Celo follows the usual [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) rules to determine a block's base fee with on modification: The base fee can't fall below a certain limit, the base fee floor. This prevents the chain to be spammed with unimportant transactions that will make the chain state grow rapidly and make future scaling harder. The floor is set sufficiently low to still keep average transactions below 0.01 USD.
+Celo follows the usual [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) rules to determine a block's base fee with one modification: the base fee can't fall below a certain limit, the base fee floor. This prevents the chain from being spammed with unimportant transactions that will make the chain state grow rapidly and make future scaling harder. The floor is set low enough to keep fees below $0.01 for a typical transaction.
 
-The base fee floor is set in the `eip1559BaseFeeFloor` rollup configuration variable and is denominated in native CELO token. If Fee Abstraction is used to pay in other tokens, the base fee is converted to the token's value at the current exchange rate.
+The base fee floor is the `minBaseFee` value introduced by the [Jovian upgrade](/operate/specification/upgrades/jovian). It is set in the L1 `SystemConfig` contract and encoded in the `extraData` field of every L2 block header, next to the EIP-1559 denominator and elasticity: bytes 9 to 16 hold the floor in wei as a big-endian `u64`. The current value for each network is listed on [Deployments](/operate/specification/deployments). The floor is denominated in native CELO token. If Fee Abstraction is used to pay in other tokens, the base fee is converted to the token's value at the current exchange rate.
 
 ## FeeHandler
 
-All base fees are sent to the FeeHandler contract, which is responsible for deciding what to eventually do with the fees. The final behavior for Celo L2 mainnet has not been confirmed yet (as of 2024-11-15). On Celo L1, the FeeHandler:
+All base fees are sent to the [FeeHandler](/build/tools/contracts/core-contracts#celo-mainnet) contract, which decides what to do with the fees. Celo governance sets how the FeeHandler splits them between burning, carbon offsetting and other beneficiaries. On Celo Mainnet the burn fraction and the carbon fraction are both 0, and a single other beneficiary, registered under the name `cLabs`, receives 100% of the fees. On Celo Sepolia the FeeHandler has the same address but a different split: the burn fraction is 20% and the carbon fraction is 80%, with no other beneficiaries, as returned by `getBurnFraction()` and `getCarbonFraction()`.
 
-- burns 80% of the fees (after converting non-CELO fees to CELO)
-- sends 20% of the fees to carbon offsetting projects as part of the Ultragreen Money initiative.
+To read the current split, call `getBurnFraction()`, `getCarbonFraction()`, `getOtherBeneficiariesAddresses()` and `getOtherBeneficiariesInfo(address)` on the FeeHandler. Fractions are fixed-point values where `10^24` is 100%.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -25,4 +25,4 @@ ERC20 tokens can be bridged the same way as in the unmodified OP Stack, see [Bri

		## Using Bridged Tokens as Fee Abstraction

		The `OptimismMintableERC20` (used to represent ERC20 tokens from L1 on L2) supports the [`IFeeCurrency`](https://github.com/celo-org/fee-currency-example/blob/master/src/IFeeCurrency.sol) interface, which is a requirement to use them as a Fee Abstraction token. Before a new `OptimismMintableERC20` instance can actually be used as Fee Abstraction, it still has to be added to the `FeeCurrencyDirectory` (`0x71FFbD48E34bdD5a87c3c683E866dc63b8B2a685`) by Celo governance. This is currently only the case for `WETH`.
		The `OptimismMintableERC20` (used to represent ERC20 tokens from L1 on L2) supports the [`IFeeCurrency`](https://github.com/celo-org/fee-currency-example/blob/master/src/IFeeCurrency.sol) interface, which is a requirement to use them as a Fee Abstraction token. Before a new `OptimismMintableERC20` instance can actually be used as Fee Abstraction, it still has to be added to the [`FeeCurrencyDirectory`](/build/tools/contracts/core-contracts#celo-mainnet) by Celo governance. This is currently only the case for `WETH`.