Skip to content
Blockchain Posts

protocol

IoTeX activates v2.4.0 Yap hard fork tonight, pulls in four Pectra EIPs

IoTeX mainnet hard-forks at block 48,985,561 (~23:52 UTC on June 7). v2.4.0 'Yap' ships EIP-7702 account abstraction, EIP-7623 calldata repricing, EIP-2935 and EIP-2537.

by 4 min read
protocoliotexethereuminfrastructure

IoTeX activates its v2.4.0 mainnet upgrade, code-named Yap, tonight at block height 48,985,561 — an ETA of Sun, 07 Jun 2026 23:52:19 UTC per the release notes. The upgrade is mandatory for every node type (Delegate, Fullnode, API). The primary source is the GitHub release iotex-core v2.4.0.

What's in the fork

Yap is a two-part fork: an EVM upgrade that pulls in four EIPs from Ethereum's Pectra package, and a staking-layer change that adds a candidate exit queue. The combination ships under IIP-60 and the EVM module rollout.

IoTeX v2.4.0 (Yap)
- Tag:          v2.4.0
- Activation:   block 48,985,561 (ETA 2026-06-07 23:52:19 UTC)
- Mandatory:    yes — Delegate, Fullnode, API nodes
- IIP:          IIP-60 (Pectra EVM upgrade)

Included EIPs
- EIP-7702  Set EOA Account Code  (tx type 0x04)
- EIP-7623  Increase Calldata Cost (TX_COST_FLOOR_PER_TOKEN = 250 vs Ethereum's 40)
- EIP-2935  Historical Block Hashes  (system contract 0x0000F90827F1C53a10cb7A02335B175320002935, 8,191 hashes)
- EIP-2537  BLS12-381 Precompiles  (addresses 0x0b–0x11)

Gas parameters introduced by EIP-7702
- Per authorization     :  12,500 gas
- New delegated account :  25,000 gas
Source: github.com/iotexproject/iotex-core/releases/tag/v2.4.0

Mechanism — what each EIP changes

EIP-7702 lets an externally-owned account temporarily delegate code execution to a contract via a new transaction type 0x04. For IoTeX's DePIN use case — devices signing transactions from constrained hardware — that means a device's EOA can be batched, sponsored, or session-scoped without migrating to a permanent smart-contract wallet. The tx type 0x04 is the same opcode-level shape as Ethereum mainnet's Pectra rollout from May 2025, which the Ethereum Foundation announced here.

EIP-7623 repurposes calldata pricing. IoTeX's TX_COST_FLOOR_PER_TOKEN = 250 against Ethereum's 40 is a deliberate departure: at 100 gas/byte baseline (vs Ethereum's 16), uncompressed device telemetry posted to chain becomes meaningfully more expensive. The intent is to push DePIN builders toward batched, compressed payloads — a calldata-cost lever Ethereum doesn't pull this hard.

EIP-2935 plants a system contract at 0x0000F90827F1C53a10cb7A02335B175320002935 that stores the last 8,191 block hashes in state. Light clients and bridges that previously had to ask an archive node for historical hashes can now read them from state directly.

EIP-2537 adds BLS12-381 precompiles at addresses 0x0b through 0x11. That unlocks cheap on-chain verification of BLS aggregate signatures — relevant for cross-chain proof systems, light-client bridges, and any cryptography that uses BLS rather than ECDSA.

Candidate exit queue

The other half of v2.4.0 is a three-stage candidate-exit process for IoTeX delegates: Request → Schedule → Confirm. Only one candidate may enter the queue per ExitAdmissionInterval (default: 24 epochs). The change replaces the prior instant-deactivation path that had allowed multiple delegates to exit in the same epoch.

The mandatory follow-up patch v2.4.1, also in the same GitHub releases page, ships fixes against the candidate-exit-queue code path itself — archive-node panics and Web3 access to the exit queue. Operators upgrading for the fork must run v2.4.1 or later, not v2.4.0 on its own.

Impact

  • Wallet and SDK vendors targeting IoTeX get the same EIP-7702 surface as Ethereum mainnet. dApp wallets that already implement Pectra-style account abstraction (Metamask, Rabby, smart wallet SDKs from Alchemy, Pimlico, Biconomy) get IoTeX support effectively for free past Yap.
  • DePIN device builders face a calldata-price ceiling that wasn't there yesterday. Telemetry batching libraries become a hard requirement, not a nice-to-have, for devices that previously dumped raw sensor payloads on-chain.
  • Bridge and light-client operators can drop archive-node dependencies for historical block-hash reads.
  • Delegate operators must redeploy on v2.4.1+ before activation height to avoid the exit-queue bug surfaced post-v2.4.0.

What to watch

  1. Activation drift. Block 48,985,561 is an ETA, not a guaranteed wall-clock time. Confirm via IoTeXScan once the fork is live.
  2. Node consensus. A non-trivial share of delegates running stale v2.4.0 (rather than v2.4.1) is the chain-split risk profile for tonight. Delegate dashboards on IoTeXScan will surface this quickly.
  3. First EIP-7702 transactions. Once activated, the 0x04 tx type is the first new ingress on IoTeX. Block explorers' decoders need to update before complex flows are readable to users.
  4. Calldata-fee impact on existing DePIN projects. IoTeX hosts DIMO, Drop, Envirobloq and a long tail of telemetry-heavy projects. The post-Yap gas spend on those contracts is the cleanest empirical test of the EIP-7623 lever.

Context — Pectra ports keep coming

IoTeX joins a growing list of EVM L1s and L2s pulling Pectra EIPs into their own forks. Optimism's Pectra notice shipped earlier; rollups that compose with Ethereum settled this question through the standard L2 codepath. For a non-rollup L1 like IoTeX, the port is more selective — EIP-7702 and EIP-2537 are net-positive for the chain's DePIN narrative; EIP-7623 is a deliberate tuning lever; the validator-balance changes from EIP-7251 (which Pectra also shipped on Ethereum) aren't relevant to IoTeX's delegated PoS model and don't appear in Yap.

The trend across non-Ethereum EVM chains in 2026 has been to lift Pectra primitives — particularly EIP-7702 — into their own roadmaps within twelve months of mainnet. IoTeX hits that window with weeks to spare.

Sources:

Related stories