Gas Pricing FAQ
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?
Use RPC suggestions directly:
eth_gasPrice or eth_feeHistory for base fee (includes 10% buffer)
eth_maxPriorityFeePerGas for priority fee (usually 1 wei)
Optional adjustments:
Some projects add 2% additional slippage for extra safety
This is generally not necessary on Sonic
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
Hex Conversion Issues Ensure proper hex to decimal conversion (0xcce416600 = 55,000,000,000 wei, not 54,816,600,000)
Use Suggested Values Don't use raw block base fee; use RPC-suggested values that include buffers
Minimum Tip Is Fine Don't increase priority fee unless you specifically need priority during high load
Check Transaction Type Ensure you're setting the correct fields for Type 1 vs Type 2 transactions
Last updated