SOLANA·HUB
DE
Infrastructure

Ahead of Alpenglow, Jito lists several client versions and schedules BAM maintenance

Jito's 9 October changelog names more than one client version ahead of Alpenglow, and the strings do not match. BAM nodes enter maintenance before activation. No activation epoch is set.

SOLANA·HUB Editorial
Source: Jito

Client versions and BAM maintenance

On 9 October 2026 at 15:25 UTC, Jito published an X article from the account @jito. The title is “BAM Changelog — Sept 23-Oct 9”. It names the client versions for the period before Alpenglow and says mainnet nodes of the Block Assembly Marketplace (BAM) will enter maintenance mode in the days leading up to activation. It does not give a confirmed activation epoch.

BAM is Jito’s layer for building blocks. Validators connected to it take block assembly from BAM nodes. In maintenance mode they fall back to the ordinary Jito-Agave block engine. Anza’s own page still has no mainnet date: Anza publishes an Alpenglow overview with no mainnet date. The finished testnet migration is in Alpenglow migration starts on testnet.

Jito writes that mainnet activation is approaching in mid-October, “per latest Solana Foundation / Anza information”. The same text says the confirmed epoch, the maintenance timing, the minimum supported version, and the restoration updates will be published through Discord announcements. The FAQ says Anza and the Solana Foundation have not yet specified the mainnet transition version. Anza’s overview page names no date. Mid-October is Jito’s phrasing in this changelog, not a date printed in those other texts.

Note: This is reporting, not investment advice.

Which versions the changelog names

The 9 October article does not name one version string for the transition. The passages do not agree. There is no GitHub tag v4.3.0-jito.01. The link on that string points at the tag v4.3.0-jito.1.

Place in the changelogWhat it says
HeadlineRun Jito-Solana v4.3.0-jito.0 during the transition period
Upgrade bullet“v4.3.0-jito.01”. The link target is v4.3.0-jito.1. The minimum supported version will be confirmed before activation.
FireBAM and FrankenBAM bulletDuring the transition, switch to v4.3.0-jito.1 of the Agave-based client. After activation, use version 26.10 or later. 26.09 is not Alpenglow-ready.
200 ms slots sectionv4.3.0-jito.0, described there as the release with the best performance optimizations
Releases sectionv4.3.0-jito.0 (2 October) is the recommended mainnet release. v4.4.0-beta.0-jito (29 September) is the recommended testnet release. FireBAM v26.09.5 (30 September) is the recommended mainnet and testnet release.

Under that, a second table is labeled as the current mainnet-beta minimum versions, unchanged:

Client, as Jito labels itMinimum version
Agave (Jito Agave / Jito BAM)v4.3.0-jito
Firedancer (FireBAM)v26.09.5
Frankendancer (FireBAM)v0.1204.40300

That is the floor for current mainnet-beta operation. It is not the recommendation for the Alpenglow transition. The bullet says “FrankenBAM”. The table says “Frankendancer (FireBAM)”. The text does not explicitly equate the two names.

The bam.dev blog of 5 October recommends v4.3.0-jito.0 and says the minimum supported version will be confirmed before activation. It does not mention v4.3.0-jito.1. It says not to run FireBAM or FrankenBAM during the transition. After activation it also says version 26.10 or later, and that 26.09 is not Alpenglow-ready.

A check of the releases on 10 October 2026 shows:

  • v4.3.0-jito.0 was published on 2 October 2026 and is not a pre-release. The commit starts with c21f9074. That is the prefix in the line Jito tells operators to confirm: solana-cli 4.3.0 (src:c21f9074; feat:c9ad34d2, client:JitoLabs).
  • v4.3.0-jito.1 was published on 8 October 2026 and is marked as a pre-release. The changelog line on that release is “support Alpenglow-aware transaction and bundle buffering”.
  • v4.3.0-jito, with no further suffix, was published on 21 September 2026 and is not a pre-release.
  • v4.4.0-beta.0-jito was published on 29 September 2026 and is a pre-release.
  • Tag v26.09.5 is on jito-foundation/firebam. The commit is dated 30 September 2026. On 10 October the same tag list also contained v26.09.6, commit dated 7 October, and v26.10.1, commit dated 9 October at 21:38 UTC. The changelog posted at 15:25 UTC on 9 October does not name those two tags.
  • The string v0.1204.40300 exists as the Frankendancer mainnet release of 21 September 2026 on firedancer-io/firedancer. The note says “Update Agave submodule to v4.3.0”. The same string is also a tag on jito-foundation/firebam, commit dated 22 September 2026. The changelog table links neither tag.

What maintenance mode changes

All mainnet BAM nodes go into maintenance mode during the days leading up to activation. No calendar day is attached. Validators connected to BAM revert to ordinary Jito-Agave block engine mode. MPP, the Maker Priority Plugin, and BAM DBI, Direct Bundle Ingest, are unavailable during that period. Block engine bundles continue to work. After activation, BAM nodes are brought back gradually while performance is monitored.

A production validator built with dev-context-only-utils (DCOU) will be forked off during activation. That warning is in the changelog and in the 5 October blog.

What to do before activation

The two Jito texts name actions. They do not name a calendar deadline. They say “before activation” and “in the days leading up to” it. The timing is to be announced on Discord.

  • Validators, FullSend users, and users of standard block engine bundles: no action.
  • MPP users: submit oracle updates via TPU or the block engine.
  • DBI users: use the legacy block engine bundle-submission path.
  • Do not run production builds with dev-context-only-utils.
  • Do not run FireBAM or FrankenBAM during the transition. The 9 October changelog says to switch to v4.3.0-jito.1 for that window. The 5 October blog, and the releases section of the same changelog, name v4.3.0-jito.0 for mainnet.
  • Upgrade to a supported Jito-Solana release. The texts do not agree on the suffix. The minimum supported version is to be confirmed before activation.
  • To check whether v4.3.0-jito.0 is running, the changelog says to run solana --version and confirm solana-cli 4.3.0 (src:c21f9074; feat:c9ad34d2, client:JitoLabs).

The FAQ answers “can I run Jito during the Alpenglow transition?” with yes. Run Jito Agave (jito-solana) as usual. Only block engine mode is enabled during the transition, not BAM. A validator that is normally connected to BAM falls back to block engine mode when BAM nodes enter maintenance, and the nodes are re-enabled once they are healthy after activation.

200 ms slots and the auction cadence

The changelog says the slot time reduction to 200 ms will be active at epoch 1053, approximately 15:00 UTC on Friday 9 October. Anyone running Jito Agave on mainnet is, in that section, strongly encouraged to be on v4.3.0-jito.0. BAM’s auction cadence is derived from slot length and will tighten automatically from 25 ms rounds to 20 ms rounds. No BAM configuration change is required.

The changelog was posted at 15:25 UTC and still phrases the switch as upcoming. The switch itself is documented separately. Anza confirmed it on 9 October at 14:42 UTC, from the epoch 1053 boundary. That report is in SIMD-0525: slot time down to 200 ms. “Approximately 15:00 UTC” is the wording in Jito’s changelog, not the time in Anza’s confirmation.

How large BAM is, according to Jito

As of epoch 1050, Jito says BAM secures 164 million SOL across 385 connected validators, 37 percent of total network stake. That figure is Jito’s. An earlier report counted validators, not stake: Jito: more than 50 percent of Solana validators run BAM.

In the same section Jito says FireBAM reached 7.3 million SOL across 12 validators, 4.6 percent of BAM stake, and calls that a new high. That figure is also Jito’s. The client is described in Jito FireBAM on Frankendancer.

What to watch

  • Which minimum version Jito confirms before activation, and whether v4.3.0-jito.0, the string v4.3.0-jito.01, and v4.3.0-jito.1 are reconciled
  • When Discord names the activation epoch, the maintenance window, and the restoration of BAM nodes
  • Whether a FireBAM release that Jito describes as 26.10 or later, and as Alpenglow-ready, appears for the period after activation

Sources

#jito #bam #alpenglow #validator #infrastructure

Related Articles