The October 9 validator update sets out temporary service changes and software warnings. Two BAM-specific features will be unavailable during maintenance.
Jito plans to put its Block Assembly Marketplace (BAM) nodes into temporary maintenance mode ahead of Solana’s Alpenglow upgrade. Its October 9 update says validators connected to BAM will fall back to the standard Jito-Agave Block Engine during maintenance. It does not specify a confirmed activation epoch or maintenance window.
BAM provides infrastructure for ordering transactions and building blocks. The maintenance plan does not describe a shutdown of the entire Solana network: Jito says standard Block Engine transaction bundles will continue to work.
Two BAM-specific features will be unavailable
Jito’s October 6 readiness note says maintenance will begin in the days leading up to mainnet activation. After Alpenglow is activated, BAM nodes will be brought back online gradually while performance is monitored. The team reports testing transaction and bundle traffic on both testnet and a dedicated Alpenglow test cluster.
Maker Priority Plugin (MPP) and Direct Bundle Ingest (DBI) will be unavailable during maintenance. MPP users are asked to submit oracle updates, which carry external data onto the chain, through TPU or Block Engine. DBI users will need to use the legacy Block Engine bundle-submission path.
FullSend and standard Block Engine users are not expected to take additional action during the transition window. Validators still need to prepare a compatible client beforehand; the absence of a task during the window does not remove the software requirements.
Version recommendations differ
The official documents do not consistently recommend one version. The October 6 blog post, plus the heading and releases section of the October 9 update, recommend v4.3.0-jito.0. Transition instructions in the later update link to v4.3.0-jito.1; one link in that section displays v4.3.0-jito.01 as its label.
The GitHub entry for v4.3.0-jito.1 was published on October 8 and is marked “Pre-release”. Its changes include support for Alpenglow-aware transaction and bundle buffering. Jito also says Anza and the Solana Foundation have yet to specify the minimum version required for the mainnet transition.
Still unconfirmed: The activation epoch, maintenance timing, minimum supported version and BAM restoration updates will be announced through Jito’s Discord. The notes reviewed do not establish that Alpenglow has been activated on mainnet.
Jito warns that production validators built with dev-context-only-utils will be forked off during activation. Operators are also told not to run FireBAM or FrankenBAM through the transition and to use version 26.10 or later afterwards; version 26.09 is described as not ready for Alpenglow.
385 validators and performance fixes
The infrastructure covered by these preparations had 164 million SOL delegated across 385 validators as of epoch 1050, according to Jito. The team puts that at roughly 37% of the network’s total stake. The separate figures of 12 validators and 7.3 million SOL for FireBAM describe a subset within BAM.
The update also identifies operational problems. A mitigation has been deployed for Linux networking behaviour that delayed the first slot of some block-production windows by 90–330 milliseconds. A host-setting change is being used to address memory compaction associated with periodic 7%–17% slowdowns on BAM hosts.
Jito reports that a separate fix to memory sharing reduced transaction replay latency by about 20%. These are the team’s own measurements, not results from an independent performance test.
Mainnet enrollment for BAM Registry, which helps validators discover BAM nodes, is targeted for late October. The team reports more than two weeks on testnet without anomalous behaviour, but the registry schedule is not a confirmed date for Alpenglow activation.
