Hedera's EVM Equivalence Goals and Exceptions

Hedera aims to achieve Ethereum Virtual Machine (EVM) equivalence to enhance the programmability and adoption of the network. This page outlines Hedera's EVM equivalence goals and highlights the key differences and exceptions between Hedera and Ethereum.

Hedera's EVM Equivalence Goals

Hedera's EVM equivalence strategy is designed to empower developers by facilitating the execution of EVM smart contracts more rapidly and cost-effectively while ensuring seamless integration of Hedera’s native services. The key goals include:

Robust Application Programmability

Hedera aims to enable a wider range of application programmability without sacrificing its unique value. This means allowing developers to build a diverse range of applications on the Hedera network, from decentralized finance (DeFi) applications to supply chain solutions, while still benefiting from the unique features of Hedera, such as its speed, security, and fairness.

Seamless Integration

Hedera plans to integrate its native services with the EVM seamlessly. This will allow developers to execute smart contracts more rapidly and cost-effectively. It will also make it easier for developers to use Hedera's services, as they can use the same tools and languages they are already familiar with from the Ethereum ecosystem.

Leverage Existing Expertise

Hedera's strategy involves leveraging the HyperLedger Besu EVM client, which allows developers to capitalize on their existing Solidity expertise. This means that developers already familiar with Solidity and the EVM can easily transition to developing on Hedera, taking advantage of its unique strengths such as faster transactions, low and fixed fees, fair transaction ordering, immediate finality, and heightened security.

Smooth Transition

Hedera aims to provide a seamless transition for developers already working with EVM-based platforms. This means making it easy for developers to move their existing applications, smart contracts, and other digital assets to the Hedera network. This goal aims to encourage the adoption of the Hedera network by reducing the barriers to entry for developers.

Support for EVM Tools

Hedera plans to support familiar EVM tools, libraries, and environments. This includes providing support for popular development environments like Truffle and HardHat, as well as libraries like Web3js and EthersJS. The network also supports tools like MetaMask, The Graph, and Remix. This goal is to make it easier for developers to build on Hedera, as they can use the same tools they are already familiar with from the Ethereum ecosystem.

Community Engagement

Hedera encourages developers to contribute to its EVM development and join the community discussions in the official Hedera Discord. This goal aims to foster a vibrant and engaged developer community, which is crucial for the long-term success and sustainability of the Hedera network.

🔔 Detailed blog post of Hedera's EVM Equivalence strategy.

Key Differences and Exceptions between Hedera and Ethereum

While Hedera strives for EVM equivalence, it's important to recognize certain unique aspects and fundamental differences in its network architecture and operations, such as the handling of state data structures, hashing algorithms, and the management of accounts and transactions. These distinctions in network behaviors are intentional design choices made to align with EVM standards, thereby achieving EVM compatibility. This approach ensures that while Hedera aligns closely with Ethereum, it also maintains its distinctive features and optimization.

Network Differences


Network State Data Structure

Virtual Merkle Tree

Merkle Patricia Trie

Hashing Algorithm



Accounts and Authorizations Differences


Authorization Signatures

Used for transaction authorization outside of smart contracts

Typically used within smart contracts

Special System Accounts

Available with unique properties

Not available

Non-ECDSA Accounts

Non-ECDSA accounts (such as ED or multi-key) are supported by Hedera and

ECDSA accounts are fully compatible

ECDSA accounts are supported by Ethereum and non-ECDSA accounts are not supported/compatible

Account Deletion


Not possible

Contract Accounts Differences


Data Return on Static Calls

Data retrieval must be done through the relay

Data returned directly

Gas Fees

Charges at least 80% of gas fees regardless of transaction outcome

Gas fees depend on transaction outcome but typically 100% of the gas fees are charged and the unused portion is credited back

Contract Lifecycle

Contract entities can expire, rent fees may apply

No expiration or rent fees

Transactions and Queries Differences


Transaction Size Limit


No limit

Transaction Throttling

Transactions may be throttled by gas limits

Transactions pending until future submission

Query Costs

Not free, can use mirror node for free queries

Free read-only calls


Mempools available

RPC Endpoint Differences


RPC Block Requests (e.g., eth_getBlockByHash* & eth_getBlockByNumber )

Return zero 32bytes hexadecimal value for the stateRoot

Returns the stateRoot hexadecimal value of the final state trie of the block

Note: Hedera Consensus and mirror nodes do not provide Ethereum RPC API endpoints.

Tokens and Fee Differences


Native Tokens

Supports native tokens in addition to ERC-20 and ERC-721 token standards

All ERC token standards but primarily ERC-20 and ERC-721 tokens.

Fee Structure

Complex with two different gas prices

Single gas price

Token Association**

No concept of token association

**Note: Token Association only applies to native HTS tokens and does not affect ERC-20/721 tokens.

Keys and Other Differences


Keys for Token Functionality

Keys control access to token functionality (KYC, FREEZE, WIPE, supply, fee, and PAUSE)

No equivalent native functionality

Precheck Failures

Typically single failure reason


Requires communication with both consensus and mirror nodes

Direct communication with nodes

HBAR Decimal Precision

Consistent 18 point decimal precision

Last updated