IIP-42: Reduce Block Interval to 3 Seconds for IoTeX L1

IIP: 42
Title: Reduce Block Interval to 3 Seconds for IoTeX L1
Author: Chen Chen (chenchen@iotex.io) Zhi (zhi@iotex.io) Raullen Chai (raullen@iotex.io)
Status: Draft
Type: Standards Track
Category: Core
Created: 2025-03-20
  1. Abstract

This proposal advocates reducing the block interval of the IoTeX blockchain from 5 seconds to 3 seconds through targeted consensus parameter optimization and network-layer enhancements. By shortening the block interval, the network aims to achieve lower latency for transaction finality, and improved user experience, particularly for latency-sensitive applications in DeFi and DePIN (Decentralized Physical Infrastructure Networks).

  1. Motivation

High Latency Concerns: The current 5-second block interval is suboptimal for applications requiring near-instant finality, such as gaming, DeFi arbitrage, and micropayments in DePIN ecosystems.

Competitive Benchmarking: Leading Layer-1 blockchains (e.g., Solana, Avalanche, BSC) and Layer-2 solutions (e.g., Polygon PoS) have adopted sub-3-second intervals, setting user expectations for faster confirmations. Retaining a 5-second interval risks ecosystem migration to faster chains.

DePIN Requirements: IoTeX’s focus on machine-economy and DePIN applications necessitates faster transaction processing for device-to-device interactions and real-time data transmission scenarios.

  1. Specification

3.1 Consensus Parameter Adjustments

Block Interval Redistribution

The consensus process in IoTeX’s DPOS-like mechanism is divided into four stages: Propose, Endorsement, Lock, and Commit. Currently, the block interval is 5 seconds. We propose to reduce the processing time allocated to the each stage to lower the overall block interval to 3 seconds.

The time allocation will be modified as follows based our optimization and benchmarking:

  • Propose stage: Reduced from 2 seconds to 1 second

  • Endorsement stage: Remains at 1 second

  • Lock stage: Reduced from 1 second to 0.5 seconds

  • Commit stage: Reduced from 1 second to 0.5 seconds

  • Total: 3 seconds

td {white-space:nowrap;border:0.5pt solid #dee0e3;font-size:10pt;font-style:normal;font-weight:normal;vertical-align:middle;word-break:normal;word-wrap:normal;}
Stage Propose Endorsement Lock Commit
Functions Mint proposal and broadcast Validate proposal and vote Vote Commit to storage
Current (5s) 2s 1s 1s 1s
Proposed (3s) 1s 1s 0.5s 0.5s

Epoch Restructuring

  • Delegates**:** Fixed at 24.

  • Sub-Epochs**:** Increased from 30 to 50 per epoch.

  • Blocks per Epoch**:** Increased from 720 to 1,200 blocks, maintaining a 1-hour epoch duration (1,200 × 3s = 3,600s).

Gas Limit Adjustment

  • Block Gas Limit**:** Reduced from 50M to 30M

  • Effective Throughput**:** Maintained at 10M gas/second (30M ÷ 3s = 10M/s).

3.2 Optimistic Block Minting

To ensure blocks can be produced reliably within the shorter time interval, we introduce an optimistic block minting mechanism:

  • Proactive Proposal Preparation: Once receiving a valid proposal of current block (P1), the next proposer will start preparing the proposal for the next block (P2). When the next round starts, the pre-prepared P2 will be broadcasted right away. Consequently, delegates receiving P2 will have a longer time to validate the proposal.

  • Fallback Process: If consensus fails in a certain round(N, 0), delegates discard the optimistic proposal(N+1, 0), and restart the next round(N, 1) within 1 second for proposal.

  • Max-Mint-Time: The time limit for preparing the next proposal must not exceed 1 second, ensuring that the proposal can complete subsequent consensus stages within the allotted time frame.

By introducing optimistic minting, the actual total duration of the proposal stage and the endorsement stage now is 4 seconds, which is longer than the previous 3 seconds. This indicates that we have ensured adequate processing time while reducing the block interval, thereby maintaining network stability under high load.

3.3 Reward Recalibration

To maintain the same token emission per epoch, the rewards to delegates will be adjusted as follows:

  • Epoch Reward: Because the duration of an epoch is the same as before, the epoch reward won’t be changed.

  • Block Reward: The total block reward per epoch, 5,760 IOTX (8 IOTX/block * 720 block), will be evenly distributed to the 1,200 blocks. Such that the reward per block will be adjusted to$$8 * 720 / 1200 = 4.8$$IOTX.

3.4 System Staking Changes

The reduction in block intervals has had a certain impact on the staking contracts. Since the staking duration in the system is recorded based on block numbers, this results in issues such as early withdrawal and a reduced maximum staking duration. To address these problems, we have made the following changes:

V1 Staking Contract - Add bucket types

Add three bucket types to re-enable 91 days staking:

  • 10,000 IOTX , 2,620,800 blocks

  • 100,000 IOTX, 2,620,800 blocks

  • 1,000,000 IOTX, 2,620,800 blocks

V2 Staking Contract - Deprecated

  • V2 staking will be deprecated in products(e.g. Staking Portal and ioPay)

  • New Stakes do not have voting weights any more

  • Existed Stakes are allowed to unstake or migrate to v3 contract

Introduce V3 Staking Contract

To fundamentally address the issue of changes in the block interval causing the duration of old contracts to also change, we are introducing a v3 staking contract.

  • Timestamp Based Duration : The main change in v3 is that the staking duration is calculated using natural timestamps instead of block numbers.

  • Legacy Migration : Another feature is the support for migrating v2 buckets to v3, allowing for a one-to-one exchange.

    • Only the bucket owner, and only when it is in a locked state, can perform the migration.

    • The original bucket’s owner is changed to the v3 contract address, while the voting rights are directed to a null address.

    • A v3 bucket will be generated owned by the staker, with the amount and delegate of the new bucket being the same as the original bucket, and the duration calculated based on the original bucket’s duration multiplied by 5 seconds.

Native Migration

After the hard fork, the buckets generated by the native migration action will also be changed to the v3 contract.

3.5 Rationale

Impacts on Legacy System Staking Contracts

In the Quebec Upgrade, we introduced the Staking Contract (v1: 0x68db92a6a78a39dcaff1745da9e89e230ef49d3d) to unlock liquidity staking. In the Upernavik Upgrade, we introduced the Native Staking Migration feature. Due to the limitations on staking types in the v1 contract, we also introduced the v2 contract (0x8ee521d2179576bcc4bd33a00904e96a11678052) to facilitate a smooth migration experience.

Currently, both versions are in use. The v1 version has been integrated into dapps such as uniIOTX, while the v2 version is only used by retail users.

Block interval reduction impacts these two staking contracts, since the contract staking duration is determined based on the block number, and given that the block interval has been reduced to three seconds. The impacts are as follows:

  • Early Withdrawal: for existing buckets, allowing unstaking to occur 40% earlier by natural time.

  • Voting Weight Reduction: the staking votes for the buckets are correspondingly reduced.

  • Maximum Staking Duration Reduction:

    • v2: reduced from 36 months to around 21.6 months.

    • v1: reduced from 91 days to 54.6 days

  1. Backward Compatibility

Legacy Staking Contracts

Due to the impact on legacy staking, we recommend users to take the following actions to avoid issues:

  • V1 Contract: stakers can send ExpandBucket transaction to change duration to 2,620,800 blocks, re-enabling 91 days staking

  • V2 Contract: Staker has two options

    • Send Unstake transaction to withdraw your IOTX

    • Send Migrate transaction to transmit your assets to the v3 contract

  1. Security Considerations

Network Stability

  • The risk of increased consensus failures has been mitigated through the optimistic mint mechanism

  • Comprehensive monitoring tools will be deployed to track consensus performance

  • A rollback mechanism has been prepared in case of unexpected network behavior

Delegate Requirements

  • Minimum hardware and bandwidth specifications for delegates will be updated to ensure reliable performance

  • Monitoring systems will identify delegates who consistently lag in consensus participation

Smart Contract Auditing

  • All modified contracts have undergone formal verification and comprehensive auditing and testing

  • The v3 staking contract will be audited right away by [Independent Security Firm]

  • Migration paths have been tested extensively to ensure data integrity during transitions

  1. Integrations and Rollout

If passed, we plan to introduce this proposal with the v2.2.0 core hardfork, which is expected by the end of April, 2025. The release will include updates to ecosystem tools, such as Staking Portal, ioPay, IoTeX Explorer, in order to support the new block time.

  1. Copyright

Copyright and related rights waived via CC0.

2 Likes
       Rethinking Speed Optimizations on Underutilized Blockchains... :pinching_hand:

JUST MY OPINON!

While reducing block time is often framed as a user experience upgrade, its impact is questionable on chains with little real usage. A review of the Iotex public explorer reveals minimal daily activity, with most transactions appearing automated or economically hollow. With no congestion to relieve, accelerating block production adds technical complexity without delivering clear benefits.

Moreover, pushing for speed improvements can create a misleading narrative suggesting technical progress while core adoption metrics remain stagnant. This risks prioritizing optics over outcomes, and engineering over engagement.

Resource Misallocation Engineering talent and infrastructure costs are being directed toward marginal gains, rather than solving adoption bottlenecks or improving developer tooling.
Erosion of Network Stability: Faster block times may increase the likelihood of forks, validator desyncs, or missed blocks, especially in a globally distributed validator set with variable network conditions.
Without an active developer or user base requesting lower latency, the optimization feels speculative a solution in search of a problem.

Instead of optimizing for performance that few users experience, the focus should shift to ecosystem growth, practical developer incentives, and applications that create sustained demand. Speed is only meaningful when there’s something worth racing toward.

Despite following IoTeX over the years, it’s hard to ignore the lack of real adoption. On-chain activity remains low, and genuine user engagement is minimal. A significant portion of IOID allocations is funneled into Network3, a project with questionable legitimacy and transparency, raising concerns about governance and resource distribution.

IoTeX risks becoming a closed ecosystem, focusing on performance improvements with little real-world impact. A shift towards trust-building and genuine developer engagement is needed to create lasting value. :frowning:

7 Likes

Great dude,this is a good evolution :dna: ,agree

Iotex chill and build @qevan @raullen @tian

2 Likes

This is a very valuable proposal.
Reducing the block interval to 3 seconds will significantly improve the developer experience on IoTeX, especially for teams building latency-sensitive dApps. Faster finality means smoother UX, quicker state updates, and better alignment with the expectations of modern Web3 users.

For DePIN projects in particular, where real-world data often needs to trigger on-chain actions in near real time (e.g., device reporting, microtransactions, access control), a 3-second interval can make a meaningful difference. This update helps IoTeX remain competitive and technically aligned with the performance standards of leading L1 and L2 chains.

Ghost chain no one build nothing there. Everyone left and the TVL is from team money haha


1 Like