IOTA Mainnet Moves to Protocol 34
IOTA has released v1.31.2, a new Mainnet software version that introduces Protocol 34 and a series of changes aimed at improving consensus, transaction processing, networking and data access. The release was published on GitHub ahead of the protocol activation window beginning September 10, 2026.
Protocol 34 can be enabled on Mainnet no earlier than 07:42 UTC on September 10, corresponding to the start of epoch 493. IOTA is warning validators to upgrade before the epoch change because nodes that fail to meet the required upgrade threshold could be removed from the committee and lose rewards for themselves and their delegators.
One of the most important areas of the release is the continued development of IOTA’s consensus and leader-schedule system. Protocol 34 includes changes supporting a redesigned leader schedule based on a sliding window and absolute-score selection for poorly performing nodes. The objective is to make validator coordination more resilient.
The release also prepares additional infrastructure for P-COOL, IOTA’s certificate-less transaction flow. IOTA said earlier this year that P-COOL had reached significant implementation milestones, with testing and public-network deployment among the remaining steps. The project is designed to increase transaction performance while reducing the resources traditionally required for transaction processing.
Another significant change involves execution-worker congestion control. Transactions can be scheduled against a bounded pool of execution workers, with transactions that cannot fit being deferred and potentially cancelled once defined limits are reached. Cancelled transactions are still charged gas and recorded in checkpoints, with a suggested gas price for users attempting to resubmit them.
Deny Rules and Infrastructure Improvements
Protocol 34 also introduces the dormant iota::transaction_deny_rules system module. The functionality is not immediately active, however. The relevant governance mechanism must first be enabled before deny rules can affect transactions, meaning the release should not be interpreted as an immediate censorship or transaction-filtering change.
The upgrade also changes how immutable transaction inputs are handled under P-COOL. Certain immutable objects will no longer acquire owned-object locks during post-consensus conflict resolution. The change is designed to prevent unnecessary transaction conflicts, but remains inactive unless the relevant P-COOL flow is enabled.
Networking has received several practical improvements as well. IOTA is reducing the maximum size of peer-to-peer request frames to 1 MiB and response frames to 128 MiB, down from 1 GiB for both. The default QUIC idle timeout is also being reduced from 30 seconds to 10 seconds so stale connections can be identified and replaced faster.
Full nodes are also becoming more efficient during synchronization. Nodes catching up with the network will no longer repeatedly download and verify checkpoint summaries that have already been stored by checkpoint-archive synchronization. That should reduce redundant processing and the amount of work imposed on peers during recovery.
The Indexer receives an important maintenance fix involving restored database partitions. IOTA says a bug could cause transaction and event tables to grow indefinitely without being properly handled by the pruner. Operators running an Indexer restored from a formal snapshot are advised to upgrade so partition self-healing can occur, although some read-path downtime may occur during the process.
Related: IOTA Disaster Pilot Cuts Japan Shelter Check-In Time by More Than Half
GraphQL also receives several changes focused on historical data and query reliability. Queries can now fall back to archival key-value storage when information has been pruned from PostgreSQL, while new functionality allows transactions to be retrieved by digest in paginated form. This gives developers more flexibility when working with older network data.
For developers, the release also updates transaction tooling and APIs. The CLI now uses the gRPC API for publishing, upgrading and building programmable transaction blocks, while JSON-RPC adds a specific error code for transactions that cannot be found. Several GraphQL filters and transaction-query functions are also being updated or deprecated ahead of future releases.
The v1.31.2 release therefore goes beyond a simple software maintenance update. It touches several layers of the IOTA stack, from validator coordination and transaction execution to peer networking, indexing, GraphQL and developer tooling. That matters as IOTA positions its Mainnet as infrastructure for applications involving tokenization, trade, identity and other real-world use cases. The network currently operates as a Move-based Layer 1 with an object-centric architecture, alongside IOTA EVM for EVM-compatible applications.
For IOTA holders and developers, the key point is that Protocol 34 is primarily an infrastructure upgrade rather than a direct token-price catalyst. Its importance will ultimately depend on how the new consensus, congestion-control and data-access mechanisms perform under real network conditions. The upgrade gives IOTA another step toward making its Mainnet more efficient and resilient as activity and application requirements grow.
About The Author
