Besu-based execution
Hedera’s smart contract service embeds Hyperledger Besu, the same EVM implementation used across the Ethereum ecosystem, as its execution layer. Contracts compile to standard EVM bytecode, and opcodes behave as they do on Ethereum. Hedera tracks Ethereum’s hard forks; for the current Besu version and the exact supported hard fork, see Deploying, which is the source of truth for that detail. Because execution is standard Besu:- Solidity and Vyper contracts deploy unchanged.
- Existing ABIs, libraries, and audited contract patterns carry over.
- EVM tools talk to Hedera through the JSON-RPC relay, which translates standard Ethereum JSON-RPC calls into Hedera transactions and queries.
Consensus and settlement
On most EVM chains, one layer both orders transactions and executes them, and a block producer decides ordering. On Hedera these responsibilities are separate:- Consensus - Consensus nodes run the Hashgraph algorithm to agree on the order and timestamp of every transaction. This is aBFT (asynchronous Byzantine fault tolerant) and produces a fair, deterministic order with no block producer choosing what goes where.
- Settlement and execution - Once order is fixed, each node executes the transaction against network state. Smart contract calls run in Besu at this stage, and the resulting state changes are applied identically on every node.
The account model
Every actor on Hedera is a Hedera account with an ID in the form0.0.<num> (for example, 0.0.1234). EVM tooling expects a 20-byte hex address, so each account also has an EVM address. There are two ways an account gets one:
For EVM-oriented applications, create accounts with an ECDSA key and set the EVM Address from Public Key at creation. This gives native compatibility with EVM wallets, JSON-RPC tooling, and smart contract interactions.
When a contract or tool references an address that has never transacted, Hedera can create the account automatically the first time value arrives. This table is a summary; for the full account and address model see Accounts, and for how it differs from Ethereum see Accounts and Keys. The native-account view is in Auto Account Creation.
Gas and fees
Contract execution is metered in gas, exactly as on Ethereum, so gas estimation andgasLimit work the way your tools expect. Two things differ:
- Pricing is in USD, paid in HBAR - The network prices gas against a USD target and converts to HBAR at the current exchange rate, rather than through a fee market auction. Costs stay predictable under load.
- HBAR uses different decimal precision than ETH - HBAR has 8 decimals natively, but the JSON-RPC relay presents balances and values to EVM tools in 18-decimal
wei-style units. This conversion is the most common source of surprise when porting scripts. See HBAR Decimals.
Finality
Hedera finality is absolute, not probabilistic. Once a transaction receives its consensus timestamp, it is final and cannot be reorganized out of history. There is no confirmation count to wait for.
Because finality is reached in seconds and never reverses, application logic that would normally wait for N confirmations can act on a transaction as soon as it has a consensus timestamp.
Where to go next
Why Hedera for EVM Developers
The value proposition compared to other EVM chains.
EVM Differences
Every behavior that differs from L1 Ethereum, in detail.
Smart Contracts on Hedera
The core-concepts view of the smart contract service.
Quickstart
Deploy your first contract on testnet.