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 errorauth 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.