Transactions

Sei supports EVM transactions, allowing compatibility with Ethereum-based tools and contracts. Transactions are signed messages originating from an externally owned account (EOA) that trigger state changes on the blockchain.

Transaction Lifecycle

Stage	Description
1. Creation	A transaction is created by an EOA, specifying the recipient, value, gas parameters, and other fields.
2. Signing	The transaction is signed with the sender’s private key to create a valid signature.
3. Submission	The signed transaction is submitted to the network through an RPC endpoint.
4. Mempool	The transaction enters the mempool (transaction pool) where it awaits inclusion in a block.
5. Execution	When selected by a validator, the transaction is executed in the EVM, causing state changes.
6. Validation	The transaction and its state changes are validated by the consensus mechanism.
7. Confirmation	Once validated, the transaction is included in a block and confirmed on-chain.
8. Finality	On Sei, transactions achieve immediate finality once included in a block.

Unlike other EVM chains where you need to wait for multiple confirmations, Sei’s consensus mechanism provides immediate transaction finality. Once a transaction is included in a block, it cannot be reversed.

Gas Mechanics

Gas is a unit of computational work in the EVM that helps prevent spam and allocate resources efficiently:

Term	Description
Gas Limit	The maximum amount of gas the transaction may consume, set by the sender.
Base Fee	The minimum gas price required to be included in a block. On Sei, the base fee is not burned — all fees go to validators.
Priority Fee	An additional fee (tip) paid to validators for faster inclusion.
Gas Price	In legacy transactions, the price per unit of gas the sender is willing to pay.
Effective Gas Price	The actual price paid per unit of gas (base fee + priority fee in EIP-1559).

Gas Requirements for Common Operations:

Simple SEI transfer: 21,000 gas
ERC-20 transfer: ~45,000 gas
Contract deployment: Varies based on contract size and complexity
Always estimate gas before sending transactions using eth_estimateGas

Transaction Structure

EVM transactions in Sei follow the Ethereum transaction format with standard properties:

Transaction Properties
Transaction Types
Example Request
Example Response

Property	Description
`from`	The address of the sender who will sign the transaction. This must be an externally-owned account (EOA) as contract accounts cannot send transactions.
`to`	The receiving address. If this is an EOA, the transaction transfers value. If a contract address, the transaction executes the contract code. If empty or null, the transaction creates a new contract.
`signature`	The cryptographic signature generated when the sender’s private key signs the transaction. This confirms the sender has authorized the transaction and includes the v, r, and s components.
`nonce`	A sequentially incrementing counter that indicates the transaction number from the account. This prevents replay attacks and ensures transaction ordering.
`data`	The input data (also called ‘input’ or ‘calldata’) for contract execution. For simple transfers, this is usually empty. For contract interactions, this contains the function selector and encoded arguments.
`value`	Amount of SEI to transfer from sender to recipient (denominated in WEI, where 1 SEI equals 1e+18 WEI).
`gasLimit`	The maximum amount of gas units that can be consumed by the transaction. Often referred to as ‘gas’ in transaction objects.
`maxPriorityFeePerGas`	The maximum price of the consumed gas to be included as a tip to the validator (denominated in WEI). Used in EIP-1559 transactions.
`maxFeePerGas`	The maximum fee per unit of gas willing to be paid for the transaction (inclusive of baseFeePerGas and maxPriorityFeePerGas). Used in EIP-1559 transactions.
`gasPrice`	The price per unit of gas the sender is willing to pay (denominated in WEI). Used in legacy transactions.
`chainId`	The chain identifier number. Prevents transaction reuse across different chains.
`accessList`	A list of addresses and storage keys that the transaction plans to access. Used in EIP-2930 and EIP-1559 transactions to reduce gas costs for accessing specified addresses and storage slots.
`type`	The transaction type: 0 for legacy (pre-EIP-2718), 1 for EIP-2930 access list transactions, and 2 for EIP-1559 fee market transactions.
`hash`	The transaction hash, a unique identifier for the transaction generated after signing.

Legacy Transactions (Type 0)

Pre-EIP-1559 transaction format that specifies a single gasPrice.

{
  "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
  "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
  "gas": "0x55555",
  "gasPrice": "0x1234",
  "value": "0x1234",
  "data": "0xabcd",
  "nonce": "0x0"
}

Access List Transactions (Type 1, EIP-2930)

Transactions with an optional access list of addresses and storage keys to reduce gas costs.

{
  "type": "0x1",
  "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
  "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
  "gas": "0x55555",
  "gasPrice": "0x1234",
  "value": "0x1234",
  "data": "0xabcd",
  "nonce": "0x0",
  "accessList": [
    {
      "address": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
      "storageKeys": [
        "0x0000000000000000000000000000000000000000000000000000000000000000"
      ]
    }
  ]
}

Fee Market Transactions (Type 2, EIP-1559)

Transaction format that supports dynamic base fees with a priority fee tip to validators.

{
  "type": "0x2",
  "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
  "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
  "gas": "0x55555",
  "maxFeePerGas": "0x1234",
  "maxPriorityFeePerGas": "0x1234",
  "value": "0x1234",
  "data": "0xabcd",
  "nonce": "0x0",
  "accessList": []
}

Example Request: Sending an EIP-1559 Transaction

{
  "jsonrpc": "2.0",
  "method": "eth_sendTransaction",
  "params": [
    {
      "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
      "gas": "0x55555",
      "maxFeePerGas": "0x1234",
      "maxPriorityFeePerGas": "0x1234",
      "value": "0x1234",
      "data": "0xabcd",
      "nonce": "0x0"
    }
  ],
  "id": 2
}

JavaScript example with web3.js

Public RPC endpoints such as https://evm-rpc.sei-apis.com do not manage or unlock accounts, so eth_getAccounts and eth_sendTransaction are not available. Sign transactions locally with a private key and broadcast the raw transaction instead.

// Example using web3.js v4 to sign and broadcast a transaction.
// Public RPC endpoints do not manage accounts, so sign locally with a private key.
const { Web3 } = require('web3');
const web3 = new Web3('https://evm-rpc.sei-apis.com');

// Load your account from a private key. Never hard-code keys — read from an env var.
const account = web3.eth.accounts.privateKeyToAccount(process.env.PRIVATE_KEY);

async function sendTransaction() {
  // Current nonce for the sender
  const nonce = await web3.eth.getTransactionCount(account.address);

  // Use the latest base fee to set EIP-1559 fees
  const block = await web3.eth.getBlock('latest');
  const maxPriorityFeePerGas = web3.utils.toWei('1', 'gwei');
  const maxFeePerGas = (BigInt(block.baseFeePerGas) + BigInt(maxPriorityFeePerGas)).toString();

  const tx = {
    from: account.address,
    to: '0x07a565b7ed7d7a678680a4c162885bedbb695fe0',
    value: web3.utils.toWei('0.1', 'ether'),
    gas: 21000, // Gas limit for a simple transfer
    maxFeePerGas,
    maxPriorityFeePerGas,
    nonce,
    chainId: 1329 // pacific-1 mainnet (use 1328 for atlantic-2 testnet)
  };

  // Sign locally, then broadcast the raw transaction
  const signed = await web3.eth.accounts.signTransaction(tx, process.env.PRIVATE_KEY);
  const receipt = await web3.eth.sendSignedTransaction(signed.rawTransaction);
  console.log('Transaction receipt:', receipt);
}

sendTransaction().catch(console.error);

`eth_sendTransaction`

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
}

`eth_getTransactionByHash`

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "blockHash": "0x5d15649e25d8e7c60b5a1cb3612b6b45dceaa3c774f438d4d5b4e1e1b2db634a",
    "blockNumber": "0x92a",
    "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
    "gas": "0x55555",
    "gasPrice": "0x1234",
    "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e",
    "input": "0xabcd",
    "nonce": "0x0",
    "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
    "transactionIndex": "0x1",
    "value": "0x1234",
    "type": "0x2",
    "accessList": [],
    "chainId": "0x1",
    "maxFeePerGas": "0x1234",
    "maxPriorityFeePerGas": "0x1234",
    "v": "0x0",
    "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
    "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663"
  }
}

Transaction receipt

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "transactionHash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e",
    "transactionIndex": "0x1",
    "blockHash": "0x5d15649e25d8e7c60b5a1cb3612b6b45dceaa3c774f438d4d5b4e1e1b2db634a",
    "blockNumber": "0x92a",
    "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
    "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
    "cumulativeGasUsed": "0xd190",
    "gasUsed": "0x5208",
    "contractAddress": null,
    "logs": [],
    "status": "0x1",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "effectiveGasPrice": "0x77359400",
    "type": "0x2"
  }
}

Transaction Guidelines

Transaction Best Practices:

Set appropriate gas parameters: Use network conditions to estimate optimal values for maxFeePerGas and maxPriorityFeePerGas.
Manage nonces carefully: Track and increment nonces correctly to avoid transaction failures.
Use typed transactions: Prefer EIP-1559 transactions (type 2) for more predictable fees.
Implement proper error handling: Account for potential transaction failures and revert reasons.
Verify recipient addresses: Always double-check destination addresses, as transactions cannot be reversed.

Common Issue	Cause	Solution
Transaction Underpriced	Gas price or priority fee too low	Increase `maxFeePerGas` and `maxPriorityFeePerGas`
Nonce Too Low	Using a nonce that’s already been used	Query current nonce with `getTransactionCount`
Out of Gas	Gas limit too low for the operation	Use `eth_estimateGas` to set appropriate limit
Contract Execution Failed	Contract function reverted	Test with `eth_call` before sending transaction

Transaction Validation

Before an EVM transaction is accepted, Sei performs strict semantic validation of its fields, enforced since v6.5.0. If you construct and sign transactions manually, make sure they are well-formed to avoid rejection.

The canonical field-level reference (signature-value byte caps and zero-padding rules, access-list entries, EIP-7702 authorization lists) lives in Transaction Types.
Envelope-level restrictions (no Cosmos wrapper fields, canonical protobuf encoding, whole-block rejection on decode failure) are covered in Differences with Ethereum.

Receipts for nonce-bumping failed transactions

Some EVM transactions pass basic validation and bump the sender’s nonce, yet still fail during state transition — for example, a transaction whose gas limit clears the intrinsic-gas check but falls short of the EIP-7623 floor-data-gas requirement (which can occur in normal operation after Pectra). Because these transactions bump the nonce, they are considered to have happened and therefore produce a receipt. For such failures, Sei writes a synthetic status=0 (failed) receipt at the end of the block. The receipt reports a gasUsed of 0 and an effectiveGasPrice of 0, and carries a VmError describing the state-transition reason. eth_getTransactionReceipt returns this failed-tx receipt instead of null. The VmError is stored on Sei’s internal receipt record and is not included in the eth_getTransactionReceipt JSON response; retrieve it with the non-standard eth_getVMError method.

Previously, a nonce-bumping transaction that failed during state transition could return null from eth_getTransactionReceipt indefinitely, causing clients that poll for a receipt to hang. Clients should now expect a status=0 receipt for these transactions and treat it as a normal failed-transaction result.

Additional Resources

RPC Reference

Complete documentation of Sei’s EVM RPC endpoints for transaction creation and monitoring

Gas & Fees

Learn more about gas calculation, fee estimation, and cost optimization on Sei

Accounts

Understanding Externally Owned Accounts and Contract Accounts on Sei

Overview

Essentials

seid CLI

Frontend Development

Smart Contracts

sei-js Library

Videos

Ecosystem Tutorials

Reference

Hardware Wallets

Transaction Lifecycle

Gas Mechanics

Transaction Structure

Legacy Transactions (Type 0)

Access List Transactions (Type 1, EIP-2930)

Fee Market Transactions (Type 2, EIP-1559)

Example Request: Sending an EIP-1559 Transaction

JavaScript example with web3.js

`eth_sendTransaction`

`eth_getTransactionByHash`

Transaction receipt

Transaction Guidelines

Transaction Validation

Receipts for nonce-bumping failed transactions

Additional Resources

RPC Reference

Gas & Fees

Accounts

​Transaction Lifecycle

​Gas Mechanics

​Transaction Structure

​Legacy Transactions (Type 0)

​Access List Transactions (Type 1, EIP-2930)

​Fee Market Transactions (Type 2, EIP-1559)

​Example Request: Sending an EIP-1559 Transaction

​JavaScript example with web3.js

​eth_sendTransaction

​eth_getTransactionByHash

​Transaction receipt

​Transaction Guidelines

​Transaction Validation

​Receipts for nonce-bumping failed transactions

​Additional Resources

RPC Reference

Gas & Fees

Accounts

Transaction Lifecycle

Gas Mechanics

Transaction Structure

Legacy Transactions (Type 0)

Access List Transactions (Type 1, EIP-2930)

Fee Market Transactions (Type 2, EIP-1559)

Example Request: Sending an EIP-1559 Transaction

JavaScript example with web3.js

`eth_sendTransaction`

`eth_getTransactionByHash`

Transaction receipt

Transaction Guidelines

Transaction Validation

Receipts for nonce-bumping failed transactions

Additional Resources