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 (burnt by the protocol). |
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). |
- 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
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 simply 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. |
Transaction Guidelines
Set appropriate gas parameters: Use network conditions to estimate optimal values for
maxFeePerGas
andmaxPriorityFeePerGas
.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 |