Gas and fees

Sei supports both legacy and EIP-1559 transactions. However, the fee model differs from Ethereum in three ways that affect how you estimate and set gas.

Legacy gas price floor

Legacy transactions (type 0) on Sei must meet a minimum gas price set by on-chain governance. Governance proposals can change this floor, so do not hard-code a specific value. To read the current minimum, use eth_gasPrice:

import { createPublicClient, http } from 'viem';
import { sei } from 'viem/chains';

const client = createPublicClient({ chain: sei, transport: http() });
const gasPrice = await client.getGasPrice();

import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://evm-rpc.sei-apis.com');
const feeData = await provider.getFeeData();
const gasPrice = feeData.gasPrice;

EIP-1559 fee model

Sei supports EIP-1559 transactions (type 2), but it does not burn the base fee. All fees go to validators. On Ethereum, part of the fee is burned. This does not affect how you construct or send transactions. maxFeePerGas and maxPriorityFeePerGas work as expected. It matters only if your application models token supply or shows fee-burn information to users.

const fees = await client.estimateFeesPerGas();
// fees.maxFeePerGas and fees.maxPriorityFeePerGas are usable as-is

const feeData = await provider.getFeeData();
// feeData.maxFeePerGas and feeData.maxPriorityFeePerGas are usable as-is

Effective gas price on receipts

For dynamic-fee (type 2) transactions, the effectiveGasPrice field of the transaction receipt reports the actual price charged, not the fee cap. That price is min(baseFee + maxPriorityFeePerGas, maxFeePerGas). This matches standard EIP-1559 semantics. Clients such as ethers and Hardhat therefore see the same effectiveGasPrice behavior that they expect from Ethereum. In practice, when your priority tip plus the base fee stays below maxFeePerGas, the receipt reports baseFee + maxPriorityFeePerGas, not maxFeePerGas. To compute what a transaction paid, use the receipt’s effectiveGasPrice, not maxFeePerGas.

SSTORE cost

On Sei, governance can adjust the gas cost of SSTORE (a write to contract storage). The current cost is 72,000 gas on both Sei Mainnet and Sei Testnet. For details, see Differences with Ethereum. Treat this number as the current value, not a constant. Do not hard-code storage write estimates in your application. Always use eth_estimateGas for any transaction that writes to storage:

const gas = await client.estimateGas({
  account,
  to: contractAddress,
  data: encodedCalldata,
});

// Add a buffer for governance changes during high-activity periods
const gasWithBuffer = (gas * 120n) / 100n; // 20% buffer

const gas = await provider.estimateGas({
  from: signer.address,
  to: contractAddress,
  data: encodedCalldata,
});

Estimate the absolute storage-write cost with a live eth_estimateGas call against a Sei RPC. A Foundry forge test --gas-report --fork-url <sei rpc> report forks the chain state, but it runs the standard EVM gas schedule of revm. It therefore shows SSTORE at the Ethereum cost (approximately 22,100) instead of the Sei cost (approximately 72,000). Use the report for relative profiling of your own logic.

Precompile calldata decode cost

Sei’s dynamic-gas precompiles (such as bank, wasmd, oracle, ibc, json, distribution, pointer, pointerview, addr, and p256) now charge gas for ABI-decoding a call’s calldata before the arguments are decoded. The charge covers a length-proportional scan of the input plus the cost of copying any string payloads the decoder would materialize — a cost that can be significantly larger than the raw calldata length when a single string is referenced by many array or tuple slots. The json, p256, and pointerview precompiles use this dynamic gas model as well. Their metering works as follows:

json — charges 100 gas per byte of the JSON payload being parsed, consumed against the call’s gas meter.
pointerview — self-meters based on the state reads performed during pointer lookups, rather than a flat charge.
p256 — charges a fixed 3,450 gas verification cost, matching RIP-7212’s P256VERIFY. Because this flat charge is levied outside the verification’s panic recovery, a call that forwards too little gas to cover it fails the transaction with an out-of-gas error rather than reverting the call.

Two consequences for callers:

A precompile call that forwards too little gas to cover the decode is reverted before the precompile runs, instead of being decoded for free.
Overall gas used for dynamic-gas precompile calls has increased slightly, since the decode is now metered.

Because this charge depends on the exact shape and size of your calldata, do not hard-code gas limits for precompile calls. Always size them with a live eth_estimateGas call against a Sei RPC:

const gas = await client.estimateGas({
  account,
  to: precompileAddress,
  data: encodedCalldata,
});

// Add a buffer for safety during high-activity periods
const gasWithBuffer = (gas * 120n) / 100n; // 20% buffer

const gas = await provider.estimateGas({
  from: signer.address,
  to: precompileAddress,
  data: encodedCalldata,
});

Summary

Behavior	Ethereum	Sei
Legacy gas floor	Protocol minimum	Governance-set, can change
Base fee	Burned	Paid to validators
SSTORE cost	Fixed by EIP	Governance-adjustable
`estimateGas`	Always correct to use	Required. Do not hard-code storage costs.

Overview

Essentials

seid CLI

Frontend Development

Smart Contracts

sei-js Library

Videos

Ecosystem Tutorials

Reference

Hardware Wallets

Gas and Fees

Gas and fees

Legacy gas price floor

EIP-1559 fee model

Effective gas price on receipts

SSTORE cost

Precompile calldata decode cost

Summary

​Gas and fees

​Legacy gas price floor

​EIP-1559 fee model

​Effective gas price on receipts

​SSTORE cost

​Precompile calldata decode cost

​Summary

Gas and fees

Legacy gas price floor

EIP-1559 fee model

Effective gas price on receipts

SSTORE cost

Precompile calldata decode cost

Summary