IOTA has released mainnet software version 1.35.2, introducing protocol version 39 ahead of a possible activation on November 5. The network change cannot take effect before 07:42 UTC, at the start of epoch 549, and depends on validators reaching the required upgrade threshold.
The update puts validator operators on a deadline. Those who fail to install the new software risk losing their places on the active committee and, with them, staking rewards.
IOTA Raises Validator Entry Threshold to 6 Million Tokens
Protocol 39 raises the minimum stake needed for a validator to join the network to 6 million IOTA. The low-stake threshold moves to 5.5 million IOTA, while the very-low-stake threshold is set at 5 million IOTA.
Read also: KChain Solutions Markets IOTA Tools After Spanish Entity Was Dissolved
The revised levels change the conditions under which validators can participate in network operations. They also make the timing of the software update particularly important for operators managing delegated funds.
The release notes carry an explicit warning:
“Please ensure that you update your validators before this epoch change. Otherwise, if the upgrade threshold is reached, the protocol will remove you from the committee, and both you and your delegators will lose rewards.”
The scheduled time is the earliest point at which the new protocol can be enabled, rather than confirmation that it has already gone live.
Consensus and Security Changes Target Network Reliability
Beyond the staking thresholds, the release changes how consensus handles duplicate messages. Under protocol 39, a message is treated as a duplicate only if an earlier message with the same key was recorded as processed or passed verification in the same commit. This is intended to ensure validators reach consistent decisions when messages are dropped and subsequently resent.
Mixed-scheme multisignature accounts also face tighter validation. When a signing committee combines Ed25519 with other key schemes, every committee member must sign for the transaction to be accepted.
For node operators, version 1.35.2 addresses checkpoint-execution stalls and adjusts fast commit synchronisation to process responses in smaller chunks. It also updates networking libraries to address several published Rust security advisories.
Developers will notice changes in data access. JSON-RPC methods now distinguish pruned historical records from genuinely missing data, while some responses expose the oldest checkpoint still available. The Rust SDK adds an oldest_available_checkpoint field to its Page type, which is a breaking change for applications that construct or fully destructure that type.
Separately, on devnet and testnet, a delayed random-beacon process can continue after its timeout and restore randomness during the same epoch. The corresponding mainnet behaviour is not specified in the release notes.
