HIP-1341 brings the execution-layer features of Ethereum’s Pectra upgrade to the Hedera Smart Contract Service, and they have been live on Hedera Mainnet since Release 77 in September 2026. Smart contracts on Hedera now run on the Prague EVM, with native BLS12-381 cryptography, Ethereum-aligned calldata pricing, and full gas accounting for access lists. Most contracts keep working with no changes. Developers who hardcode gas limits for data-heavy transactions or deploy very large contracts should review the Action Required section below.
Motivation
Native BLS12-381 Cryptography (EIP-2537)
Ethereum activated its Pectra hard fork in May 2025, and Solidity compilers, Foundry, and other EVM tooling now target the Prague EVM that Pectra introduced. Developers expect a contract that works on Ethereum to behave the same way on any EVM network they deploy to. HIP-1341 reviews each of the twelve EIPs in Pectra and adopts the ones that apply to Hedera’s execution layer, so gas costs, precompiles, and transaction behavior stay Ethereum-aligned. EIPs that cover blobs, validators, or the consensus layer do not apply to Hedera’s architecture and are documented as out of scope. This follows the same approach Hedera took for the Cancun upgrade (see HIP-865 and HIP-866).
What’s New in Release 77
BLS12-381 is a pairing-friendly elliptic curve. Ethereum’s validators use it to sign blocks, and many zero-knowledge proof systems are built on it. Its signatures can be aggregated, so thousands of signatures can be checked as one. EIP-2537 adds seven precompiles for BLS12-381 operations. A precompile is a built-in contract at a fixed address that runs native code inside the EVM client instead of interpreted bytecode. HIP-1341 notes that these operations can be written in Solidity, but “the gas costs are prohibitive.” As precompiles, they run at fixed, published gas prices.
Hedera exposes all seven at the same addresses and gas costs as Ethereum:
- 0x0b G1ADD: adds two G1 points. Input 256 bytes. 375 gas
- 0x0c G1MSM: multi-scalar multiplication on G1. Input 160 × k bytes for k pairs. k × 12,000 × discount ÷ 1,000 gas, where the discount factor falls as k grows and is capped at 519 for k above 128
- 0x0d G2ADD: adds two G2 points. Input 512 bytes. 600 gas
- 0x0e G2MSM: multi-scalar multiplication on G2. Input 288 × k bytes. k × 22,500 × discount ÷ 1,000 gas, with the discount capped at 524 for k above 128
- 0x0f PAIRING_CHECK: checks a product of pairings. Input 384 × k bytes. 32,600 × k + 37,700 gas (a two-pair check costs 102,900 gas)
- 0x10 MAP_FP_TO_G1: maps a field element to a G1 point. Input 64 bytes. 5,500 gas
- 0x11 MAP_FP2_TO_G2: maps a field element to a G2 point. Input 128 bytes. 23,800 gas
Solidity has no built-in wrapper for these precompiles, so contracts call them with a low-level staticcall:
// Adds two BLS12-381 G1 points using the EIP-2537 precompile at 0x0b.
function g1Add(bytes memory input) internal view returns (bytes memory) {
require(input.length == 256, "G1ADD expects 256 bytes");
(bool ok, bytes memory result) = address(0x0b).staticcall(input);
require(ok && result.length == 128, "G1ADD failed");
return result;
}
Why it matters: BLS12-381 verification on-chain is the foundation for Ethereum light clients, cross-chain bridges, staking and restaking protocols, verifiable randomness beacons such as drand, and zk proof verifiers. These can now run natively on Hedera with the same contracts and gas assumptions used on Ethereum.
Calldata Gas Floor (EIP-7623)
Calldata is the input data sent with a contract call or deployment. EIP-7623 sets a minimum gas charge based on how much calldata a transaction carries. Ethereum introduced it to limit block size. HIP-1341 adopts it on Hedera for equivalence: “Although the limit to maximum block size and block gas limit do not directly apply to Hiero, for EVM equivalence, Hiero will also adopt these gas costs.”
Calldata is measured in tokens, and the transaction pays whichever is higher, the standard cost or the floor:
tokens_in_calldata = zero_bytes + 4 × non_zero_bytes
standard = 21,000 + 4 × tokens_in_calldata + execution gas (after refunds)
floor = 21,000 + 10 × tokens_in_calldata
gas used = max(standard, floor)
The standard cost also includes contract-creation and access-list charges where they apply. For example, a call carrying 1,000 non-zero bytes with very little execution has a standard cost of 37,000 gas and a floor of 61,000 gas. It is charged 61,000. A call that does meaningful computation already exceeds the floor, so its cost stays the same.
The floor applies to every EVM entry point on Hedera: EthereumTransaction, ContractCall, and ContractCreate. A transaction’s gas limit must cover the floor, or the transaction fails with INSUFFICIENT_GAS. The Hiero JSON-RPC Relay applies the same check before submission, and eth_estimateGas results already include the floor. Unused gas is still fully refunded. See Gas and Fees for the full breakdown.
Why it matters: Gas estimates and cost models built for post-Pectra Ethereum carry over to Hedera without adjustment.
Access List Gas Accounting (EIP-2930)
An access list is an optional field in Type 1 and Type 2 Ethereum transactions. It declares up front which contract addresses and storage slots the transaction will touch. Release 77 applies the full gas rules from EIP-2930 to these lists:
- Each listed address: 2,400 gas, added to the transaction’s intrinsic cost
- Each listed storage key: 1,900 gas, added to the transaction’s intrinsic cost
- Pre-warming: listed entries are marked “warm,” so the first access costs 100 gas instead of the cold rate (2,600 for an account, 2,100 for a storage read)
Each listed entry that the transaction actually uses saves about 100 gas. An entry that is never used adds its full cost, so accurate lists matter. The JSON-RPC Relay does not support eth_createAccessList (it returns error -32601), so access lists are built manually or with client-side tooling. See Access Lists (EIP-2930) for a full example.
Why it matters: Transactions that include access lists are now priced the same way as on Ethereum, so existing tooling and gas optimizations behave as expected.
Initcode Size Limit (EIP-3860)
Release 77 also enforces the initcode limit from EIP-3860. Initcode is the bytecode that runs once to deploy a contract. It is capped at 49,152 bytes. A deployment over the limit fails with CONTRACT_SIZE_LIMIT_EXCEEDED. A CREATE or CREATE2 from inside a contract fails with CODE_TOO_LARGE. The JSON-RPC Relay checks the same limit before submission.
Token and Schedule Facade Bytecode
Hedera token and schedule addresses expose a Solidity interface, called a facade, that forwards calls to the Hedera Token Service and Hedera Schedule Service system contracts. With the Prague EVM, these facades are represented as delegation indicators, the same format EIP-7702 defines. For example, eth_getCode on a token address now returns 0xef0100 followed by the address of the Hedera Token Service system contract (0x167). Direct calls to token and schedule facades work as before, but tools or contracts that inspect bytecode at these addresses will see the new format.
What Is Not Included
EIP-7702 lets an externally owned account (EOA) delegate its execution to smart contract code. This enables batched transactions, sponsored gas, and other smart-account features. On Hedera it is specified in HIP-1340. The functionality ships in Release 77 but is not yet enabled. Type 4 (set-code) transactions are not accepted: the JSON-RPC Relay rejects them with error -32611, and eth_getCode on an EOA continues to return empty code. Enabling HIP-1340 will be announced separately.
The remaining Pectra EIPs do not apply to Hedera’s architecture:
- Blobs (EIP-7691, EIP-7840): Hedera does not support blob transactions (HIP-866)
- Validator and beacon-chain mechanics (EIP-6110, EIP-7002, EIP-7251, EIP-7685): Hedera’s consensus has no Ethereum validators or beacon chain
- Consensus-layer changes (EIP-2935, EIP-7549): these relate to Ethereum’s consensus layer, so Hedera keeps its own block-hash handling
- EIP-7642: an informational networking change
Action Required
Not affected: most contract calls, where execution cost already exceeds the calldata floor; contracts that do not use access lists; and applications that use native Hedera services through the SDKs. No SDK upgrade is required for these changes. Contracts compiled for Cancun or Prague deploy as before.
Affected: developers with hardcoded gas limits on data-heavy transactions, very large deployments, access-list users, and tools that read facade bytecode. Steps:
- Check gas limits on calldata-heavy transactions. Make sure the gas limit is at least 21,000 + 10 × tokens_in_calldata. Gas limits taken from eth_estimateGas already include the floor.
- Check initcode size for large deployments. Contracts deployed through the File Service or jumbo Ethereum transactions must have initcode of 49,152 bytes or less.
- Review access lists. Include only addresses and storage slots the transaction actually uses, and make sure the gas limit covers 2,400 gas per address and 1,900 gas per storage key.
- Update bytecode checks on token and schedule addresses. Tools that compare bytecode at these addresses should expect the 0xef0100 delegation-indicator format.
- Set evmVersion explicitly. Hedera runs the Prague EVM. Solidity 0.8.31 and later compile for the newer Osaka EVM by default, so set evmVersion to prague (or earlier) in Hardhat, Foundry, or solc settings.
What This Means for EVM Developers
Release 77 keeps Hedera’s EVM in step with Ethereum’s execution layer. Contracts, gas estimates, and tooling configured for Prague behave the same on Hedera, and cryptographic workloads that depend on BLS12-381 can now run natively. Combined with Hedera’s fast finality and low, predictable fees, this opens Hedera to bridge, light-client, and zk-verification projects that need BLS12-381 support.
FAQ
Do existing contracts need to be redeployed? No. Deployed contracts keep working. Re-test transactions with large calldata and low computation if they use hardcoded gas limits, since the calldata floor can raise their gas usage.
Will gas costs go up? Only for transactions that carry a lot of calldata relative to the computation they perform. Access lists add cost for each listed entry and save gas on each entry the transaction actually uses. Most contract calls see no change.
Can Type 4 (EIP-7702) transactions be sent to Hedera? Not yet. EIP-7702 support is specified in HIP-1340 and is not enabled. Type 4 transactions are rejected until it is.
Does the calldata floor apply to native Hedera contract transactions? Yes. It applies to ContractCall and ContractCreate as well as EthereumTransaction.
Next Steps
Full technical details are in the Hedera documentation, including the precompile table, the calldata floor formula, supported Ethereum transaction types, and Cancun-to-Pectra migration notes:
- Deploying Smart Contracts: Pectra Hard Fork: precompile table, past hard forks, and what changed from Cancun to Pectra
- Gas and Fees: Calldata Floor: the floor formula and worked examples
- HIP-1341: Support for Ethereum Pectra Release
- HIP-1340: EOA Code Delegation (EIP-7702)
- Release 77 Notes: the full list of changes in Release 77
Test Pectra features on Hedera Testnet before taking them to mainnet, and bring questions to the developer community on Discord.
