Skip to main content
Hedera’s EVM-compatible environment lets you deploy Solidity smart contracts using Hardhat, Foundry, or Remix and connect with standard Ethereum tooling. Hedera’s architecture introduces differences in account models, key management, token handling, and JSON-RPC behavior that affect how you build and migrate from Ethereum. This guide is for:
  • EVM developers migrating to Hedera: Understand key differences in Hedera’s architecture, tokenomics, and tooling, including ED25519 key management and native system contracts (introduced in HIP-632).
  • Hedera-native developers adding smart contract functionality: Learn how EVM contracts interact with Hedera’s native services (HTS, HCS, HFS) and how to bridge both worlds.

​
High-Level Differences: Hedera vs. Ethereum

​
Jumbo Ethereum Transactions

Hedera supports jumbo Ethereum transactions (introduced in HIP-1086), allowing larger callData payloads to be included directly in the ethereumData field of EthereumTransaction. This aligns Hedera’s EVM behavior more closely with Ethereum’s, enabling seamless deployment of complex contracts. 📣 To learn more, including size limits, gas calculation, and limitations, see the Ethereum Transaction SDK documentation.

​
Pectra Compatibility

Hedera adopts the applicable EIPs from Ethereum’s Pectra upgrade under HIP-1341, so Ethereum tooling that targets Pectra (Prague EVM execution layer) works on Hedera with no special handling:

​
Type 4 transactions and smart accounts

Type 4 transactions enable smart-account patterns (transaction batching, sponsored gas, session keys, privilege de-escalation) without migrating funds to a new contract wallet. The EOA’s address, balance, NFTs, and tokens stay put; only the execution is delegated to a contract’s code running in the EOA’s storage frame. Two important Hedera-specific behaviors apply:
  1. HAS precedence. When an EOA has a code delegation set, calls whose 4-byte selector matches a Hedera Account Service facade function (hbarAllowance, hbarApprove, setUnlimitedAutomaticAssociations) are routed to HAS and take precedence over the user’s delegation.
  2. Account-type applicability. Only ECDSA accounts with a public-key-derived alias can configure delegation via Type 4 transactions (same rule as for submitting any Ethereum transaction). ED25519 accounts and ECDSA accounts with a long-zero alias must use the native HAPI path (CryptoCreate / CryptoUpdate).
📣 See the full feature page: EOA Code Delegation.

​
EVM Developers: What Changes on Hedera

The following topics cover the most common differences when coming from Ethereum:

​
Hedera-Native Developers: Adding Smart Contracts

If you’re already building with Hedera’s native services and want to add EVM smart contract functionality, see Hedera-Native Developers Adding Smart Contracts.

​
Additional Resources