Triton One Publishes Alpenglow Integrator Guide: What Solana RPC, gRPC and Indexing Users Must Change

Triton One published a guide on 7 October 2026 setting out what developers who rely on Solana SOL$102.07+1.2% RPC endpoints, gRPC data streams and indexers need to change before the Alpenglow consensus upgrade reaches mainnet. Alpenglow has been running on testnet since 24 September and on devnet since 25 September. It has not activated on mainnet. Triton One, which sells RPC and data-streaming infrastructure, sorts its customers into two groups: "If you only send transactions and read accounts, you have nothing to do." Teams that stream blocks, build indexes or read data at the confirmed commitment level have changes to make.

On timing, Triton One's post says Alpenglow "hits mainnet mid-October" and adds that "Anza will name the exact epoch for Mainnet." Anza, the team behind the Agave validator client, has not named one. Anza's 5 October post says only that Alpenglow "is headed to mainnet-beta soon" and lists "what we're watching before the mainnet-beta announcement" among the topics for a public session on the migration.

What Alpenglow changes for Solana RPC, gRPC and indexing users

Alpenglow replaces TowerBFT, the process Solana validators use to agree on which blocks are final. Transactions execute the same way afterwards. The data that describes blocks changes in five ways, according to Triton One's guide:

• Finality drops from 12.8 seconds to about 150 milliseconds, and the confirmed and finalized commitment levels become the same state.
• Vote transactions no longer appear inside blocks.
• A slot can have more than one candidate block, and streamed updates carry a bank_id to tell the candidates apart.
• Ticks, the timing entries that older code may use as a clock, disappear.
• Blocks gain a footer that carries certificates, the proof that enough stake voted for the block.

The Alpenglow upgrade page on solana.com describes the first four changes in the same terms. The block footer and its delivery details come from Triton One's guide alone.

Vote transactions leave blocks, and TPS dashboards fall

Under TowerBFT, every validator vote is an ordinary transaction that lands in a block. Under Alpenglow, solana.com's upgrade page says, "votes are no longer transactions, so they no longer appear in blocks." Anything that counts transactions per block or per second will show a sudden fall on activation day with no change in user activity. Triton One's illustration is a block that held 1,200 transactions before the switch holding 400 after it, and the company tells teams to reset TPS baselines and any alert that fires when a block looks too small.

Solana Compass network data puts a size on that drop. Over the seven days from 30 September to 6 October 2026, validators submitted about 215 million vote transactions a day, against between 154 million and 182 million user transactions a day. Votes were about 56% of all transactions on the network across that week.

Filters that already exclude votes keep working. A gRPC subscription set to vote: false "just has nothing left to remove," Triton One writes.

confirmed and finalized commitment levels converge at about 150ms

A commitment level is the setting an application passes to an RPC node to say how settled data must be before the node returns it. Under TowerBFT, finalized lags by about 12.8 seconds. Under Alpenglow a block is final once a finalization certificate exists, roughly 150 milliseconds after the block was proposed, and solana.com's upgrade page says confirmed and finalized then "describe the same state."

The order of operations matters. Triton One warns developers not to move to finalized before activation, because requests would wait out the full 12.8 seconds until the switch happens. Solana.com gives the same instruction: "Move to finalized only after Alpenglow is live." Once it is live, Triton One recommends making the move and shortening any timeout or retry built around the old delay. Triton One also says confirmed "will be removed in the future." That removal is Triton One's statement; solana.com's page says all three commitment levels keep working on activation day.

The 150ms figure measures finality. Slot time is on a separate track: Anza said on 7 October that 200ms slots are scheduled to take effect at the epoch 1053 boundary, around 15:00 UTC on 9 October 2026.

bank_id: more than one candidate block per slot in Yellowstone streams

Streaming users who assemble blocks themselves from individual transaction or account updates face the largest code change. Since Agave 4.3, a slot can carry more than one candidate block, and solana.com's page says every event from Geyser, the validator's streaming interface, carries a bank_id identifying its candidate. The instruction there is to "buffer per (slot, bank_id), never per slot." Triton One adds that subscribers to full blocks can ignore the field because those blocks arrive already sorted.

Multi-provider setups need extra care. Triton One describes bank_id as a counter each node picks for itself, so "the same block can be 7 on one connection and 12 on another." Its advice is to keep one buffer per connection and match blocks across providers by blockhash only.

Competing candidates should be rare. Triton One expects them in fewer than 1 in 100 slots, and solana.com says Anza expects the rate to stay below 1% of slots once Agave v4.4 enables fast leader handoff. Existing gRPC clients keep connecting, according to Triton One, because fields are added and none are renamed or removed, though an older client cannot see bank_id or footers until its Yellowstone gRPC libraries are updated.

getAgGenesisCert: detecting the consensus switch without a calendar date

Both sources point developers to a new RPC method, getAgGenesisCert, as the trigger for any behaviour that depends on Alpenglow. Solana.com says the method returns null while TowerBFT is running and Alpenglow's genesis certificate after the migration. Triton One notes that a "Method not found" error means the node is running software older than Agave v4.3. Its guidance is to "base any switch in your code on this call, not on a date."

With no epoch named by Anza, that advice covers the timing question too. Three further details are Triton One's alone:

• During the switch, blocks hold only votes for about 20 minutes, after which the cluster deletes some of those slots and restarts from a single agreed block. Triton One tells users to treat processed data from that window as temporary and trust only what reaches finalized.
• Block footers are available over Triton One's gRPC products only, with JSON-RPC getBlock support to follow in a later release.
• Vote accounts read as jsonParsed gain an optional blsPubkeyCompressed field holding the validator's new voting key, and parsers that reject unknown fields need to allow it.

By Triton One's account, an application that only sends transactions and reads accounts gets the faster finality with no code change. The work falls on explorers, analytics dashboards and indexers, whose block parsers and transaction counts are built around votes, ticks and one block per slot.