BAM Changelog - Sept 9-24

ACTION REQUIRED: Upgrade to Current Mainnet Minimum Versions
Validator operators should upgrade to the current minimum supported mainnet versions:
Current Mainnet Minimum Versions:
AgaveBAM (jito-solana): v4.3.0
FireBAM (Firedancer): v26.09.4
FrankenBAM (Frankendancer): v0.1204.40300
Transaction V1 Activation Complete
Transaction V1 (SIMD-0385) successfully activated on Mainnet at the start of Epoch 1035 on September 15.
All FireBAM validators completed the required upgrade ahead of activation. A small number of AgaveBAM validators remain on v4.2.0 or v4.2.1. These clients process Transaction V1 in consensus and replay, but do not process V1 bundles or transactions sent to their own leader slots, resulting in lost revenue during every leader slot. These operators should upgrade immediately.
AgaveBAM validators on v4.2.2 are Transaction V1 compliant but are below the current v4.3.0 minimum and should upgrade at their convenience.
Developer Impact: Compute Budgets
Transaction V1 sets compute budgets through a new transaction configuration field. Existing compute budget instructions remain effective for V0 transactions but are no-ops for V1 transactions.
The Maker Priority Plugin (MPP) and pass-through TPU (PTPU) paths currently do not support V1 transactions.
Releases & Upgrades
FireBAM Mainnet (v26.09.4): Recommended release and current mainnet minimum. Also shipped during this window: v26.08.4 and v26.08.5, synced with their corresponding upstream Firedancer releases.
AgaveBAM Mainnet (v4.3.0): Recommended release and current mainnet minimum. The large majority of AgaveBAM validators have already upgraded.
DCOU Fix: v4.3.0 supersedes the v4.3.0-beta.3 and v4.4.0-alpha.3 builds previously flagged for the dev-context-only-utils issue. Operators still running these pre-release builds should move to v4.3.0.
FireBAM Operator Note: Validators upgrading directly from a Frankendancer-based FireBAM build to a full Firedancer-based FireBAM build may experience CPU spikes and skipped slots. A reboot is recommended when making this transition.
Performance & Reliability
BAM Bundle Ingestion: Critical upgrades to the bundle ingestion pipeline have improved rewards performance, primarily through higher tips. BAM-native block rewards have been higher than all other client types over the past five epochs.
FireBAM Performance: Across Epochs 1032–1039, FireBAM reached 100.6% of the AgaveBAM average for compute units per block, up from 96% earlier this month. Rewards per block reached approximately 92% of AgaveBAM, with continued work underway toward parity.
Skip Rate: FireBAM averaged a 0.05% skip rate versus 0.13% for AgaveBAM, with seven of eight measured epochs recording zero skipped slots.
Maintenance Mode: BAM Nodes can now be taken offline for maintenance without disrupting connected validators.
Monitoring & Response: Shipped stricter small-block alerting and updated internal playbooks for faster response to degraded performance.
BAM Registry
The BAM Registry is now working end-to-end on testnet.
Today, validators connect to a specific BAM Node address configured at startup. The BAM Registry replaces this static configuration with a service discovery layer. Validators query the Registry for healthy BAM Nodes, measure latency to each, and automatically connect to the fastest available node.
This enables validators to:
Automatically connect to the lowest-latency healthy BAM Node.
Move to another node without operator intervention during maintenance or regional failures.
Continue operating from a cached node list if the Registry itself becomes unavailable.
A full test was completed on September 18 across three testnet regions. When a BAM Node entered maintenance mode, it was removed from the Registry within approximately 90 seconds and validators automatically migrated to the next best node.
Mainnet rollout is planned, with an announcement coming soon. No validator action is required today.
BAM Alpenglow Testing
BAM has successfully completed initial testing on the Alpenglow community cluster ahead of SIMD-0326 activation.
A dedicated BAM Node was deployed in Frankfurt to test the full path from bundle submission through transaction landing under real Alpenglow conditions. Testing surfaced two issues:
The previously identified DCOU build defect, which would have applied a 32-slot migration offset instead of 5,000 and caused the BAM Node to fork at activation.
A stall in the opening header broadcast path after migration, which prevented transactions from landing despite healthy consensus and bundle forwarding.
Both issues have been resolved. On September 15, BAM successfully landed transactions on the Alpenglow cluster following deployment of the opening-header fix and Jito tip program.
AgaveBAM v4.3.0 is the minimum version for Alpenglow support.
Jump has stated that Frankendancer will not have an Alpenglow-compatible release and will be unsupported after activation. Firedancer and Frankendancer operators are advised to fail over to Jito-Agave before migration and wait for an official announcement regarding a supported Firedancer release on Alpenglow.
Protocol & Ecosystem
Market Tick: BAM now schedules an increment to the permissionless Market Tick program at the start of every 25ms batch auction, giving on-chain programs roughly 10 sub-slot timing updates per slot instead of one. This provides market makers with more granular timing information for quoting.
Maker Priority Plugin: Onboarded prop AMM usage of MPP has reached 89%, above the 80% target.
BAM Preconfirmations: Preconfirmations are live with paying subscribers through Helius and Triton. BAM validators earn 35% of all preconfirmation revenue through priority fees, with first distributions expected to begin in October 2026.
JIP-39: JIP-39 has passed, with subsidy distributions expected in October. To remain eligible, validators must be connected to a BAM Node and execute only BAM transactions for at least six full epochs of the previous ten. When not running BAM, validators must run a Jito validator client connected to the Jito Block Engine.