TL;DR
- Alpenglow, Solana's new consensus, hits mainnet mid-October
- If you only send transactions and read accounts, you have nothing to do
- If you stream blocks, index data or read at confirmed, this isn’t going to fit in a TL;DR… read on
What changes and what doesn't
Alpenglow is live on testnet (since 24 September) and devnet (since 25 September). Anza will name the exact epoch for Mainnet.
What stays the same: sending transactions, interacting with on-chain programs, priority fees/tips and account data. Alpenglow changes how validators agree on blocks, not how transactions run.
What changes:
- Finality drops from 12.8 seconds to about 150 ms. confirmed and finalized commitments become the same thing.
- Vote transactions will no longer be inside blocks. Thus, transaction counts (TPS) will fall sharply. No real activity is lost.
- A slot can have more than one candidate block. Streams now tag every update with a bank_id so you can tell them apart.
- Ticks are gone. Code that reads time from ticks stops working.
- Blocks get a footer. It carries the vote proof (certificates) and is available over gRPC.
What it means for each Triton product
RPC polling and WebSocket (Whirligig)
No new fields, and nothing breaks on activation day. finalized now arrives in about 150 ms. Since confirmed and finalized will arrive at the same time, ensure that your code can handle the ingress.
After Alpenglow is live on Mainnet, it is recommended that you update your code to use the finalized commitment, as the confirmed will be removed in the future. It remains now, so you don't have to worry about it immediately.
Also shorten any timeout or retry built around the old 12.8 second wait.
Note: Do NOT switch to finalized before Alpenglow is live, otherwise you'll wait for 12.8 seconds. Switch only after it is live on Mainnet.
Commitment levels before and after Alpenglow
Dragon's Mouth (Yellowstone gRPC) & Fumarole
Most updates now carry a bank_id, which says which candidate block they belong to. A new block footer message is also available, with certificates as an opt-in. You only need bank_id if you put updates together into blocks yourself.
An empty bank_id on an account or slot update is normal. It means that update doesn't belong to one block.
What to do:
- Update your dependencies: yellowstone-grpc-client and yellowstone-grpc-proto to [latest version] (Rust), @triton-one/yellowstone-grpc to [latest version] (TypeScript).
- You subscribe to full blocks: upgrade to the Alpenglow release of the client. It sorts candidate blocks for you.
- You build blocks from transaction or account updates: group them by (slot, bank_id), not by slot. Keep the one that reaches confirmed and drop the rest. yellowstone-block-machine does this for you.
- You want footers: add a block_footer filter, with include_certificates: true if you need the vote proof.
Superbank (historical data)
Nothing new at launch. Blocks after activation have no vote transactions, so they are smaller. Your code now has less bandwidth and filtering to handle.
Footers over JSON-RPC come in a later release. If you want them immediately, you'll have to stream them via gRPC.
What to do: nothing. Just expect smaller numbers. For example, a block that held 1,200 transactions before the switch might hold 400 after, because the votes are gone. Real user activity is the same.
Cloudbreak and DAS API
Nothing changes for getProgramAccounts, getAccountInfo or DAS responses.
One field matters if you read vote accounts as jsonParsed: blsPubkeyCompressed. It holds the validator's new voting key, and it is null when the validator has not registered one.
{
"program": "vote",
"parsed": {
"type": "vote",
"info": {
"nodePubkey": "...",
"commission": 0,
"blsPubkeyCompressed": null
}
}
}What to do: nothing changes for you. If you read vote accounts:
- If your parser rejects unknown fields, allow blsPubkeyCompressed.
- Treat it as optional. It can be null.
- If you track validators, null means that validator can't vote under Alpenglow.
Jet (transaction sending)
Sending works exactly as before.
What to do: nothing. If you wait for confirmed after a send, see the RPC advice above.
If you read blocks (getBlock, Superbank or gRPC)
Transaction counts drop. This applies however you get blocks: getBlock, Superbank or a gRPC block subscription. For example, a TPS chart will show a sudden fall, and an alert like "fewer than 500 transactions in a block" may start firing. Reset those baselines. If you filter out votes (for example vote: false in a gRPC filter), the filter still works. It just has nothing left to remove.
Bandwidth: less data overall. Blocks are smaller without vote transactions, so block and transaction streams use less bandwidth. But confirmed and finalized updates for a block now arrive together, back to back, instead of 12.8 seconds apart. If you listen at both confirmed and finalized commitment levels, for example, two gRPC streams or a slot subscription that sends every status, you get the same block's updates twice in a short burst.
You use more than one provider. bank_id is a counter that each Solana node picks for itself. The same block can be 7 on one connection and 12 on another. Keep one buffer per connection and match blocks across providers on the blockhash only.
You read time from ticks. Ticks no longer exist. Use block meta and the footer to know when a block is complete.
You ingest at processed on switch day. For about 20 minutes during the switch, blocks hold only votes. The cluster then deletes some of those slots and restarts from a single agreed block. Treat processed data from that window as temporary, and trust only what reaches finalized.
FAQ
Is there a new "notarized" commitment level? No. You still pick processed, confirmed or finalized. Notarized is a step inside the protocol, not something you can request.
What is a slot, and what is a block? A slot is a time window when one leader builds. A block is what it builds. Usually, a slot has one block. Now and then, it has several candidates, and only one wins. More info here:https://solana.com/upgrades/alpenglow#breaking-change-merging-streams-from-multiple-providers:~:text=place%20of%20it.-,Slots%2C%20Blocks%2C%20and%20Banks,-A%20slot%20is
Will I see updates from more than one block in a slot at processed? Yes, but Rarely. On v4.3 this happens only when a leader produces twice by mistake. From v4.4 (planned for November), it can also happen when a leader starts building on a block the network then skips. The leader starts over, so that slot briefly has two versions. Expect this in fewer than 1 in 100 slots. bank_id tells the candidates apart.
Is 150 ms the new slot time? No. Slots stay 250 ms, and a separate upgrade will cut them to 200 ms. The 150 ms is how long a block takes to become final after the leader proposes it. Before Alpenglow it's 12.8 seconds. After Alpenglow it'll be 150ms.
What is a certificate? Proof that enough stake voted on a block: one combined signature, plus a list of which validators signed it.
See the full structure in Agave's code.
Certificates are optional. How do I know a block is final? You don't need the certificate. If our node says finalized, the block is final. Certificates let you check this yourself, using that epoch's validator keys. A footer without certificates is normal.
bank_id, bank hash or blockhash. which do I use?
Does getBlock return the footer? Not yet. Footers come only over gRPC today (Dragon's Mouth and Fumarole). JSON-RPC support from Superbank & Agave follows in a later release. We archive footers from the first Alpenglow block, so history will be there when it ships.
Will my existing gRPC client keep working? Yes. New fields are added, nothing is renamed or removed. An older client still connects, but it can't see bank_id or footers.
How do I decode the certificates? They arrive as raw bytes. Decode them with the solana_entry::block_component types from Agave v4.3.
How to tell when Alpenglow is live
Call the new getAgGenesisCert method on your RPC endpoint. It returns null while the old consensus runs, and a certificate once Alpenglow is live. A Method not found error means the node is older than v4.3.
curl https://<your-endpoint> -s -X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getAgGenesisCert"}'Base any switch in your code on this call, not on a date.