Deploying Solidity on Hedera: what changes when you port from Ethereum

Hedera's smart contract service runs the EVM, so Solidity source, compilers and most libraries carry over. Teams keep Hardhat or Foundry for builds and tests and keep Ethers.js, viem or Web3.js in their applications, reaching the network through the Hedera JSON-RPC relay, which accepts Ethereum-style requests and turns them into Hedera transactions. Standard ERC-20 and ERC-721 contracts deploy and behave as written.

The relay implements a subset of the Ethereum JSON-RPC methods, some of which return fixed values for compatibility, and historical state, logs and transaction details come from mirror nodes rather than from block state roots¹. Tooling that relies on less common methods, or on debug tracing, is worth checking in the first week of a port.

A ported ERC-20 contract keeps working as a contract-managed token. The alternative is to issue the token natively on the Hedera Token Service and use it from Solidity: each HTS token answers standard ERC-20 or ERC-721 calls at its own address⁷, and the token service system contract at a reserved address offers operations such as minting and association⁸. The trade-offs between the two models belong to the Hedera Token Service design.

Either way, the receiving side differs from Ethereum. An account or contract must be associated with an HTS token before it can hold it. Accounts created automatically from an EVM address or public key now default to unlimited automatic associations, while accounts created explicitly default to none⁵, so a contract that pays tokens out should expect some transfers to fail and report them clearly.

System-contract calls also signal failure differently. Token-service functions return a response code alongside their result⁸. Check it on every call and revert explicitly when it is not SUCCESS, instead of assuming a failed call reverts by itself.

Hedera sets its fees in US dollars and converts them to HBAR, which keeps the cost of a given operation predictable when the HBAR price moves. HIP-1249 removed the earlier minimum charge on unused gas, so a transaction now pays for gas actually used, and network throughput is throttled by operations per second rather than gas per second; per-transaction limits remain, for example 15 million gas⁶.

Set gas limits from usage measured on testnet with headroom, not from Ethereum estimates, because system-contract calls are priced differently from ordinary opcodes. Deployments or calls with unusually large call data may need Hedera-specific handling, such as the jumbo transactions introduced by HIP-1086³.

Hedera has no public mempool for bots to watch: transactions go to consensus nodes and are ordered by consensus timestamp. That removes the familiar pattern of a searcher seeing a pending swap and paying to be placed ahead of it. It does not make ordering irrelevant, so keep slippage limits, deadlines and commit-reveal schemes wherever outcomes depend on order.

Indexers need adjusting too. The relay presents each record file as a block, so block numbers and timestamps exist but follow Hedera's cadence, and historical events are read from mirror-node contract logs. Code that uses block numbers as a clock, or a block value as a source of randomness, should move to timestamps and to the PRNG system contract respectively⁸.