EthereumTransaction lets you execute a raw, RLP-encoded EVM transaction (type 0, 1, 2, or 4) on the Hedera network. This enables developers familiar with EVM tooling to leverage their existing knowledge and infrastructure when interacting with the Hedera Smart Contract Service (HSCS).
Supported transaction types
Access Lists (EIP-2930)
Type 1 and Type 2 transactions accept an optionalaccess_list, a list of {address, storageKeys[]} tuples that the EVM “warms up” before execution. Slots and addresses on the list are charged at the warm rate (100 gas) on first touch instead of the cold rate (2,100 for storage, 2,600 for accounts).
- Cross-contract calls where the EVM doesn’t already know about the target address. Listing it converts a 2,600-gas cold
CALLinto a 100-gas warm one. - Reads of storage slots in another contract (a token balance lookup, a registry probe). Listing the slot converts a 2,100-gas cold
SLOADinto a 100-gas warm one.
- Slots in the contract that owns the transaction’s
toaddress are warm anyway (the contract’s own storage is pre-warmed). - Speculative listings of slots that never get read. You still pay the access-list overhead (
2,400per address +1,900per slot) without recouping the cold-access discount.
Example: hand-built Type 1 transaction (ethers v6)
JavaScript
EthereumTransaction directly by passing the raw signed RLP bytes as ethereumData.
Example: Type 2 with access list (viem)
JavaScript
Tip: Most JSON-RPC providers expose eth_createAccessList; call it against a simulated transaction to get a near-optimal access list before signing.
Hedera specifics
A few things to know before you rely on access lists on Hedera:- The warm/cold discount is honored. Hedera applies the same EIP-2929/2930 gas accounting as Ethereum, so listed addresses and slots are charged at the warm rate on first touch. The exact cold/warm opcode costs are in the gas schedule.
access_listalso rides on Type 4 transactions. The EIP-7702 payload carries bothaccess_listandauthorization_list, so you can pre-warm storage and set EOA code delegation in a single transaction. See EOA Code Delegation.- Access-list bytes count toward the EIP-7623 calldata floor. A large speculative access list increases
callDatasize and can push a low-execution transaction into the calldata floor; list only slots you’ll actually touch. - Submitting via the SDK. Pass the raw signed RLP (Type 1 or Type 2) as
ethereumDataon anEthereumTransaction; Hedera preserves the access list during execution. No Hedera-native field mirrorsaccess_list; it lives entirely inside the RLP payload.
Handling Large callData Payloads
HIP-1086 introduced support for jumbo Ethereum transactions, allowingethereumData to directly include callData up to 24KB for contract creation and 128KB for contract calls. This removes the need to use callDataFileId for many large payloads. The rest of the protobuf wrapper (signatures, node account ID, etc.) must still fit within 2KB.
Gas Calculation for callData
The gas cost for thecallData in jumbo EthereumTransaction is calculated as:
gasLimit (in the RLP-encoded transaction) and maxGasAllowance (in the wrapper) are set high enough.
📣 For detailed gas and fee calculation, refer to the Gas and Fees page.
Quick reference: Jumbo vs Standard Transactions
📣 See HIP-1086 and the Gas and Fees page for complete technical details.
Transaction Signing Requirements
The transaction must be signed by the key of the fee-paying account. ForEthereumTransaction, this is:
- The account with the ECDSA alias derived from the public key in
ethereumData, if sufficient gas and fees are authorized. - If the authorized fee from the Ethereum sender is insufficient, the payer of the transaction is charged up to the
maxGasAllowance. - For jumbo transactions, ensure the payer’s key is included and
maxGasAllowanceis set high enough to cover potential gas and fees.
Transaction Fees
The total transaction cost includes:- Base transaction fee
- Gas for
callData, (calculated as:4 × zero bytes + 16 × non-zero bytes) - Execution gas determined by EVM smart contract logic