Gas Pricing

Gas and Fees

• Fee Model Sonic uses a Base Fee + Priority Fee model similar to Ethereum's EIP-1559.

• Fee Distribution Unlike Ethereum, the Base Fee is not burned. Instead, 90% of all transaction fees are sent to the FeeM treasury for developers and 10% are distributed to validators.

• Gas Power Each validator has a "gas power" budget that refills over time, based on their stake. This prevents any single validator from congesting the network. If a validator runs out of gas power, they may temporarily be unable to emit events containing large transactions, resulting in a Not enough gas power to emit event warning.

Gas Estimation (eth_estimateGas)

While eth_estimateGas is fully supported, its estimates can sometimes be inaccurate for complex transactions whose gas usage depends on the current on-chain state.

• The Problem The state of the chain can change between the time of gas estimation and the time of transaction execution. For contracts like a UniswapV3Pool, a change in the pool's state can alter the execution path and, consequently, the gas required.

• The Symptom This can lead to random out of gas transaction reversions.

• The Solution For transactions with state-dependent gas costs, it is best practice to add a buffer (e.g., 20-30%) to the estimated gas limit to ensure successful execution. Unused gas is refunded.

Frequently Asked Questions

Why does eth_maxPriorityFeePerGas sometimes return 0x1 (1 wei) while other times it returns larger values?

This is expected behavior on Sonic. The value 0x1 (1 wei) is the correct minimum gas tip estimation. Unlike Ethereum where users compete for block space, Sonic has much higher throughput, so there's usually no competition. The method returns the minimum tip needed for inclusion in a block. It only returns higher values when the network experiences higher load, which is rare on Sonic.

Isn't 1 wei too low? Gas tips are usually in GWei magnitude on other chains.

While it may seem unusually low compared to Ethereum, 1 wei is sufficient on Sonic because:

• Sonic has significantly higher throughput than Ethereum

• There's rarely competition for block space

• Transactions are included so quickly that tipping for priority is usually irrelevant

• The method name is somewhat misleading - it returns an estimate for inclusion, not a maximum you can set

What's the difference between the block base fee and the fee returned by eth_feeHistory?

• Block base fee: Usually at it’s current minimum of 50 GWei (0xbebc200 in hex) on Sonic

• eth_feeHistory and/or eth_gasPrice: Returns 55 GWei (0xcce416600 in hex), which is base fee + 10% buffer

• The 10% buffer is added to prevent transaction rejection due to potential price fluctuations

• This buffer ensures transactions won't be rejected as "underpriced"

Why are my transactions being rejected as "underpriced"?

This typically happens when you use the raw block base fee (50 GWei) without adding a buffer. To avoid this:

• Use eth_feeHistory which already includes a 10% buffer (55 GWei)

• Or use eth_gasPrice which also returns the buffered value

• If calculating the gas fee cap manually, add at least 6% to 10% buffer to the base fee

• The transaction pool requires at least 5% buffer above the base fee to accept transactions

How should I calculate gas fees for Sonic transactions?

For Type 1 transactions:

• Gas Price = Base Fee + >5% Buffer (10% recommended) + Priority Fee

• Example: 55,000,000,000 + 1 = 55,000,000,001 wei (0xcce416601)

For Type 2 (EIP-1559) transactions:

• maxFeePerGas (GasFeeCap) = Base Fee + Priority Fee = 55 GWei + 1 wei

• maxPriorityFeePerGas (GasTipCap) = 1 wei

Why doesn't the base fee change dynamically on Sonic?

The base fee on Sonic is configured with a minimum of 50 GWei and doesn't change because:

• Network bandwidth is nowhere near saturated

• The algorithm only increases fees when network gas budget spendage exceeds 50%

• Sonic has a much larger gas budget to spend

• The minimum prevents the price from dropping to dust levels, which could enable attacks

Why does gasUsedRatio show 99% if the network isn't congested?

This is due to how Sonic builds blocks:

• Blocks are fitted to transactions, not pre-allocated

• Unlike Ethereum's EIP-1559 premise, this doesn't indicate congestion

• The high ratio doesn't trigger base fee increases because the network has ample capacity

• This is a quirk of Sonic's block construction method, not an indicator of network load

What's the recommended approach for gas pricing on Sonic?

1. Use RPC suggestions directly:

   • eth_gasPrice or eth_feeHistory for base fee (includes 10% buffer)

   • eth_maxPriorityFeePerGas for priority fee (usually 1 wei)

2. Optional adjustments:

   • Some projects add 2% additional slippage for extra safety

   • This is generally not necessary on Sonic

3. Key points to remember:

   • All RPC values are in wei, not GWei

   • Don't convert or modify the hex values returned by RPC

   • The suggested values already include appropriate buffers

Why does Sonic add a 10% buffer to gas price suggestions?

The buffer exists because:

• Validators reject transactions with less than 2% buffer above the previous block's base price

• The transaction pool requires 5% buffer to accept and advertise transactions

• Sonic's asynchronous consensus creates a pipeline of potential blocks 3 frames wide

• The buffer ensures transactions won't be rejected during this multi-block resolution process

• It's safer to suggest a fee cap with buffer than to require clients to calculate adjustments

• Remember that maxFeePerGas is the maximal gas fee you accept, not the fee you pay

Common Troubleshooting Tips

1. Hex Conversion Issues Ensure proper hex to decimal conversion (0xcce416600 = 55,000,000,000 wei, not 54,816,600,000)

2. Use Suggested Values Don't use raw block base fee; use RPC-suggested values that include buffers

3. Minimum Tip Is Fine Don't increase priority fee unless you specifically need priority during high load

4. Check Transaction Type Ensure you're setting the correct fields for Type 1 vs Type 2 transactions