Skip to main content

Transaction types

Sei supports most Ethereum transaction types. The one notable exception is blob transactions.

Supported types

Set code (EIP-7702) auth list requirement

Type 4 (EIP-7702) SetCode transactions must include a non-empty authorization list. If the auth list is empty or nil, validation rejects the transaction with the error auth list cannot be empty. Each authorization entry must also carry a valid (non-nil) chain ID. If you construct SetCode transactions directly, make sure that at least one authorization is present before you submit the transaction.

Access list and auth list entry validation

Since v6.5.0, ValidateBasic applies stricter semantic validation to EVM transactions. It rejects malformed transactions that older node versions accepted. Access list entries (type 1 and type 2): Validation checks each access list tuple for well-formed hex encoding. Every address must be a canonical hex address of the correct length. Every storage key must be a canonical hex hash of the correct length. Validation rejects entries with wrong-length or non-hex values. Auth list entries (type 4): Validation checks each authorization entry for a canonical hex address and well-formed signature values. This check is in addition to the non-empty auth list and non-nil chain ID requirements above. Signature values: The transaction-level v, r, and s values must each fit in 32 bytes. In auth list entries (type 4), v is limited to 1 byte, and r and s are limited to 32 bytes. In both cases, values must not be zero-padded: a multi-byte value must not have leading zero bytes. Validation rejects zero-padded signature encodings. This section is the canonical reference for field-level EVM transaction validation on Sei. Differences with Ethereum covers the envelope-level restrictions: Cosmos wrapper fields, canonical protobuf encoding, and whole-block rejection on decode failure.

Not supported

Blob transactions

Sei runs the Pectra hardfork without blob transaction support. If you try to send a type 3 transaction, Sei rejects it at the RPC level. If you port code from Ethereum that uses blob transactions (for example, for rollup data availability), that code path does not apply to Sei.

Sending transactions

Standard library defaults work correctly. viem, wagmi, and ethers all default to type 2 (EIP-1559) transactions on chains that support EIP-1559, and Sei does.