TL;DR:
Jito issued operational guidance requiring node operators to upgrade to supported clients such as Jito-Solana v4.3.0-jito.0 and Firedancer v26.09.5.
The Block Assembly Marketplace (BAM) infrastructure captured 164 million SOL delegated across 385 validators in Epoch 1050, representing 37% of Solana’s total stake.
BAM nodes will enter maintenance mode prior to activation, temporarily pausing Multi-Packet Processing (MPP) and Dynamic Block Incentives (DBI).
This Friday, Jito published operational guidelines and validator requirements ahead of Solana’s Alpenglow upgrade, alerting operators to temporary adjustments across its block assembly services.
https://t.co/VZO6sSl8mQ
— Jito (@jito) October 9, 2026
The technical upgrade encompasses software compatibility updates, modifications to auction cadences, and the temporary disabling of advanced features within its Block Assembly Marketplace (BAM) .
The Jito team noted that the mainnet transition to Alpenglow is approaching on the development schedule. However, official documentation clarifies that neither a definitive activation epoch nor the exact timetable for pre-upgrade maintenance has been finalized.
To maintain network synchronization and avoid accidental forks, the organization published supported client versions. Operators must run Jito-Solana v4.3.0-jito.0 , Agave v4.3.0-jito , Firedancer (FireBAM) v26.09.5 , or Frankendancer v0.1204.40300 . Jito explicitly warned that production validators running development-context utilities risk being dropped from network consensus.
BAM nodes will transition into maintenance mode several days prior to final activation. During this interval, the infrastructure will temporarily fall back to the standard Jito-Agave Block Engine.
Bundled transactions will continue executing as normal under this contingency model. However, dedicated BAM features—such as Multi-Packet Processing (MPP) and Dynamic Block Incentives (DBI) —will remain disabled throughout the maintenance window. Users relying on oracle updates will need to route their transaction flow directly through the Transaction Processing Unit (TPU) or standard Block Engine pathways.
Latency Optimizations and BAM Participation Metrics
The planned reduction of slot times to 200 milliseconds on Solana , scheduled for Epoch 1053 , prompted operational adjustments to the auction engine. BAM’s internal auction cadence was trimmed from 25 to 20 milliseconds to stay in sync with faster block generation speeds.
Technical disclosures from the firm also highlighted the mitigation of latency bottlenecks discovered in prior testing. A Linux kernel issue previously caused delays ranging between 90 and 330 milliseconds on the initial slot of certain leader windows—an anomaly that has now been patched. Additionally, memory compaction inside Trusted Execution Environments (TEEs) had slowed throughput by 7% to 17% , while resolving false data sharing issues reduced replay latency by roughly 20% .
At the close of Epoch 1050 , Jito logs showed 164 million SOL staked through BAM across 385 validators , accounting for roughly 37% of the entire Solana network stake. An additional 7.3 million SOL was managed across 12 validators running FireBAM, contributing another 4.6% of total stake to the infrastructure.
Preconfirmation revenue distribution is already live, with the initial validator payouts under this model scheduled for late October 2026 —coinciding with the planned mainnet enrollment of validators into the BAM registry.
