Protocol version 32 just landed on devnet. This beta release changes how nodes handle requests and how consensus behaves during timeouts. If you're running a node on devnet, expect changes to your configuration and how you monitor performance.

Protocol and Consensus Changes

Version 32 brings several shifts to the core logic. On devnet, this version becomes active starting 2026-08-03 11:26 UTC (epoch 154).

• Starfish Consensus: We've enabled the optimistic commit rule (StarfishSpeed) on testnet. Also, the default soft_leader_timeout dropped from 100 ms to 5 ms. Validators propose sooner when strong votes for the previous leader don't arrive fast enough. You can still override this via consensus-config.parameters.soft_leader_timeout if you need more breathing room.
• Checkpointing: The minimum checkpoint interval now uses an amortized sliding window of 20 checkpoints on testnet.
• Move-based Auth: We've enabled Move-based sponsor account authentication. This includes pre-consensus logic to authenticate only the sponsor Move authentication when present in mainnet.
• P-COOL: The P-COOL flow is now active on devnet for protocol version 32.
• System Params: Validator count limits and stake thresholds now follow the protocol config. On new networks, deprecated on-chain system parameter fields just record zero.

Node Performance and Resource Isolation

This is where the real work happened. We've decoupled client-facing requests from the core node work.

Request handling for validator gRPC, JSON-RPC, and gRPC read APIs now runs on a dedicated tokio runtime. It's isolated from consensus, execution, and checkpointing. This means a flood of incoming transactions won't starve consensus commits or checkpoint signing. We've added tokio_runtime_* metrics so you can see exactly how saturated each runtime is.

We've also tightened up gRPC traffic control. The validator gRPC server now enforces concurrency limits per service (Validator, ValidatorV2, ValidatorPeer) instead of one global limit. We've replaced grpc_concurrency_limit with grpc_concurrency_limit_per_core (default 1000). The effective limit is that value multiplied by your CPU cores. If you hit the limit, grpc_load_shed rejects excess requests with RESOURCE_EXHAUSTED.

Full node gRPC traffic control now tracks batch APIs per item. Every item in ExecuteTransactions, SimulateTransactions, GetObjects, or GetTransactions counts as one request for the spam policy. You can cap batch sizes for GetObjects and GetTransactions using max_get_objects_batch_size and max_get_transactions_batch_size (default 1000).

State Sync and Indexing

State sync has moved from the archival store to a checkpoints bucket. Nodes don't write or read a separate state archive anymore. Instead, historical checkpoints sync from a checkpoints archive via an ingestion URL. You'll need to add checkpoint-archive-config to your node configuration:

checkpoint-archive-config:
  url: "https://checkpoints.<mainnet|testnet|devnet>.iota.cafe/ingestion/historical"
  download-concurrency: 5

Also, the IOTA Indexer can now be restored from a formal snapshot. And for anyone still using the old --optimistic-pruner-batch-size argument, it's gone. Use the new config instead.

Metrics and Observability

We've overhauled the Starfish consensus histograms. 21 avg-only histograms are now plain _sum/_count counter pairs. We also replaced several histograms—like consensus_transaction_synchronizer_fetch_latency—with gauges that expose fixed per-node quantiles: {0.05, 0.33, 0.5, 0.66, 0.95}. If you have custom histogram_quantile() queries in your dashboards, you'll need to update them because the _bucket series are no longer exposed.

Sources: v1.29.0-beta, v1.29.0-alpha, v1.28.3