Skip to main content
An 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

Important

Hedera interprets HBAR decimals differently depending on the context:
  • The lowest denomination of HBAR when used within a the value field in the EthereumTransaction is weibars meaning with 18 decimals
  • The lowest denomination of hbar when used within data or the Hedera EVM is tinybars meaning with 8 decimals.
  • Gas Price information is in weibars denomination.

    Reference: HIP-410

Access Lists (EIP-2930)

Type 1 and Type 2 transactions accept an optional access_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).
When access lists save gas:
  • Cross-contract calls where the EVM doesn’t already know about the target address. Listing it converts a 2,600-gas cold CALL into 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 SLOAD into a 100-gas warm one.
When they don’t save gas:
  • Slots in the contract that owns the transaction’s to address 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,400 per address + 1,900 per slot) without recouping the cold-access discount.

Example: hand-built Type 1 transaction (ethers v6)

JavaScript
The same payload can be submitted via 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_list also rides on Type 4 transactions. The EIP-7702 payload carries both access_list and authorization_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 callData size 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 ethereumData on an EthereumTransaction; Hedera preserves the access list during execution. No Hedera-native field mirrors access_list; it lives entirely inside the RLP payload.

Handling Large callData Payloads

HIP-1086 introduced support for jumbo Ethereum transactions, allowing ethereumData 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 the callData in jumbo EthereumTransaction is calculated as:
This is added to base gas and execution gas. Developers must ensure both 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. For EthereumTransaction, 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 maxGasAllowance is 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
📣 See the transaction and query fees table and the smart contracts gas and fees page for details.