BAM Changelog — October 9–23, 2026 Two big network changes landed in the last two weeks. Solana moved to 200ms slots, and Alpenglow went live on mainnet. BAM came through both on schedule. We also launched Direct Bundle Ingest, shipped a run of Alpenglow-ready client releases, and set new highs for BAM stake. At a Glance Alpenglow is live. All BAM Nodes were back to regular operations at 17:28 UTC on October 21. Required now: Jito-Solana v4.3.2-jito, or FireBAM v26.10.3+ on Firedancer. Frankendancer is no longer supported. It has no Alpenglow support. 200ms slots went live at Epoch 1053. BAM's auction moved to 20ms rounds automatically. BAM secures 161.5M SOL across 372 validators, 37% of network stake, with new all-time highs during the window. Scaling DBI (Direct Bundle Ingest), with new searchers onboarded every week Validator Action Required 1. Run a supported version v4.3.2 was the Solana Foundation's minimum version for the Alpenglow feature gate. 99.65 percent of AgaveBAM stake had upgraded before activation. Reminder: never run a production validator built with dev-context-only-utils (DCOU) 2. Turn BAM back on if you turned it off If you cleared --bam-url for the transition, set it again. See Runtime configuration. Everyone else reconnected automatically. For Agave BAM: https://bam.dev/validators/#runtime-configuration For FireBAM: https://bam.dev/validators/#runtime-bam-control 3. FireBAM operators: switch back carefully Follow the "After activation" steps in the Alpenglow migration guide: Run a FireBAM release based on Firedancer v26.10.3 or later. Enable Alpenglow with --alpenglow or [consensus] alpenglow = true, both when re-running configure init and at startup. Load an incremental snapshot from slot 5,002 or later. Earlier snapshots will not start. Watch the cluster delinquency rate as you fail back. 4. Frankendancer operators: move clients Frankendancer does not support Alpenglow. Move to FireBAM on Firedancer, or to Jito-Solana v4.3.2-jito. Alpenglow: How the Transition Went Alpenglow activation began at the start of Epoch 1064, about 13:35 UTC on October 21. Consensus switched to Votor 5,000 slots later. Timeline (UTC): October 21, ~01:10 — All mainnet BAM Nodes entered Maintenance Mode. Connected validators fell back to Jito-Agave Block Engine mode. ~13:35 — Alpenglow activation began at Epoch 1064. Around slot 4,000 — Block Engine forwarding paused for about 13 minutes over the vote-only blocks, and resumed once the genesis certificate formed. 14:24–17:28 — BAM Nodes came back region by region, from low-stake to high-stake regions. 17:28 — All mainnet BAM Nodes back to regular operations. MPP, BAM DBI and BAM Preconfirmations were paused during Maintenance Mode and resumed as BAM nodes came back online. Block Engine bundles kept flowing throughout (except the small window noted above) About the Block Engine failure spike: some users reported elevated failure rates right after forwarding resumed. That was the backlog of bundles queued during the 13-minute pause being flushed at once. It cleared on its own. 200ms Slots Slot times dropped to 200ms at Epoch 1053 on October 9. The median slot duration fell from 254ms to about 204ms and has held at 203–205ms since. BAM's auction cadence is derived from slot length, so it tightened from 25ms to 20ms rounds with no configuration change. In the first minutes after the switch, BAM validators produced 99.78 percent of their leader blocks, against 99.91 percent for the network. Releases Jito-Solana v4.3.2-jito (October 16): required mainnet release. v4.3.1-jito (October 14): withdrawn after Anza abandoned v4.3.1. v4.3.0-jito.1 (October 8): block-packing improvements for Alpenglow. v4.4.0-beta.1-jito (October 15): recommended testnet release. FireBAM v26.10.4 (October 21): fixes a gossip table mismatch with Agave that caused excess traffic. v26.10.3 (October 20): repair and Alpenglow consensus improvements. This is the minimum version. v26.10.2 (October 14): first mainnet-ready Alpenglow build, with lower memory use and faster snapshot loading. Performance What shipped: TEE v0.24 is live across the fleet of BAM Nodes. It includes the first-slot network delay fix we announced last time. The small-block rate in BAM's own leader slots fell from 0.130 percent to 0.089 percent. Two more root causes were fixed in this window, and work continues. Faster bundle rollback improves throughput when bundles contend for the same accounts. Alpenglow-readiness fixes: BAM Node stops sending work past each slot's deadline, handles a bank being replaced mid-slot, and detects replay lag from finalization certificates. BAM Registry and Attestations The BAM Registry remains on testnet. Validator-side discovery is complete, and mainnet enrollment is still targeted for late October. Currently conducting early testing of attestation reports on BAM Nodes on testnet, with mainnet soon to follow. Direct Bundle Ingest Direct Bundle Ingest (DBI) early announcement and capacity scaling. Searchers can now send bundles straight to BAM Nodes, which simulate and filter them from the first hop. Early results comparing the previous weeks to the immediate weeks after launch on Sept 20th: Improved land rates: BAM received 7.5% fewer bundles but landed 16.9% more, lifting the end-to-end land rate from 0.45% to 0.57%. Higher efficiency: Simulation success rose from 11.4% to 16.1%, auction success from 3.4% to 4.7%, and the share of compute spent on failed simulations fell from 50% to 41% Rewards optimizations: Median fee per CU consumed increased 53%, and average reward per landed bundle rose 72% Read the DBI blog post: https://bam.dev/blog/introducing-bams-direct-bundle-ingest/ For searchers: DBI access is granted through an application form and is expanding gradually. A Block Engine UUID or pubkey does not grant DBI access. Block Engine bundles for BAM leaders now go directly to the BAM Node, and BAM auction rounds are 20ms at 200ms slots. Also new Maker Priority Plugins (MPP) carry more than 80 percent of PropAMM oracle updates. Explorer API: the new /api/v1/leader_slots endpoint returns leader slots per BAM-client validator. BAM Boost 1,932.3 SOL was distributed to 377 validators over Epochs 1053–1063. One epoch paid out unusually high because of a one-time fee paid to the Jito DAO. Under JIP-31, DAO revenue is distributed to BAM validators. Check your claims on the JIP-31 Subsidy Program Rewards page: https://jito.retool.com/embedded/public/a3aa9814-18e6-4706-99d5-c4efadb1c37f/page1 Operator FAQ My validator disconnected from BAM on October 21. Do I need to do anything? No, unless you manually cleared --bam-url. Validators reconnect automatically once their regional BAM Node leaves Maintenance Mode. How do I check that I'm connected to BAM again? Look up your identity at bam.dev/explorer/validators/. If you run several identities, check each one. My region's BAM Node isn't in the Explorer node list. Is it down? The node list shows healthy nodes only. Nodes in Maintenance Mode or still coming back online don't appear. Does --block-engine-url have to be the generic mainnet URL? No, any Block Engine URL works. The generic https://mainnet.block-engine.jito.wtf routes to the lowest-latency Block Engine. Regional endpoints are in the Jito API reference. You do need one set, or BAM has nothing to fall back to. Can I switch back to FireBAM now? Yes, on FireBAM v26.10.3 or later (we recommend v26.10.4)Frankendancer does not support Alpenglow. Why did Block Engine failure rates spike after activation? Forwarding was paused for about 13 minutes during the migration. When it resumed, the queued backlog was flushed at once and many stale bundles failed. Rates normalized once it cleared. Do I need to claim preconfirmation revenue? No. Validators are opted in automatically. It will arrive as a priority fee on a special memo transaction, separate from BAM Boost. git checkout v4.3.2-jito says pathspec ... did not match. Run git fetch --tags origin first, and check that origin is https://github.com/jito-foundation/jito-solana.git. Git only fetches tags automatically when they point into the branch you're fetching.(Historical earnings: For fiscal 2026Q3 (period ended 2026-02-28), Oracle reported basic EPS of 4.47, diluted EPS of 4.38, and net income of USD 12.783 billion, versus basic EPS of 3.24, diluted EPS of 3.15, and net income of USD 9.016 billion in the prior-year period. The preceding 2026Q2 (period ended 2025-11-30) showed basic EPS of 3.19, diluted EPS of 3.11, and net income of USD 9.062 billion. Consensus expectations: For the upcoming 2027Q1 event, consensus expects EPS of 1.7766 and revenue of USD 19.527 billion.)