Solana has been running Alpenglow on mainnet since October 21, replacing a voting system that could take several seconds to finalize a block with one designed to finish in a fraction of a second. The Solana Foundation records the switch in epoch 1064, after 446 of 654 validators certified a genesis block.
Summary
- Alpenglow began finalizing mainnet blocks at slot 459,653,000 on October 21, after the network certified its handoff block.
- Solana describes 150 milliseconds as a finality target; an October 23 outside measurement put median observed finality at 404 milliseconds.
- The change removes validator vote transactions from blocks, so headline transaction counts can fall without fewer user payments.
- RPC providers and indexers must account for competing block candidates, while ordinary wallet signing and transaction fees remain the same.
- The Votor voting system is live, but Rotor, the planned block distribution replacement, has no activation date.
A user sending SOL might see a payment appear almost at once and wonder what the upgrade improved. A wallet can show that a transaction was processed before the network has made it final. Alpenglow compresses the wait for the stronger assurance, but the app still has to submit the payment, hear back from a node and decide when to change its own display. An exchange may impose another wait before crediting an account.
The Foundation’s upgrade record says transaction formats, programs and fees did not change. Developers who only submit payments and read account balances need no new transaction format. Those handling block streams have more work, because the route from a proposed block to an agreed one is different. The practical question now is which services pass that faster finality through to customers and which continue to use their old confirmation schedules.
The switch has happened, but 150 milliseconds is a target
Alpenglow replaced TowerBFT, Solana’s old consensus process, on October 21. In the old system validators put vote transactions onchain and a block gathered enough votes across later slots to become final. Votor, the live part of Alpenglow, carries votes directly between validators and combines them into certificates. A block can be finalized in one or two voting rounds.
The Foundation uses 12.8 seconds as a reference for old finality and roughly 150 milliseconds as the new target. Those numbers describe a protocol comparison, not two measurements taken from the same wallet under identical conditions. The October 21 preparation report warned that unstaked RPC nodes could hear about finality later than participating validators, sometimes after another block is produced. Internet latency and an application’s chosen node add to what the user sees.
An outside measurement published October 23 put median finality at 404 milliseconds over its preceding 24 hours, with a 579 millisecond 90th percentile and a 765 millisecond 99th percentile. Its earlier reference was about seven seconds under TowerBFT. On those figures the median improved by about 17 times, calculated by dividing seven seconds by 0.404 seconds. The methodology and observation point differ from the Foundation’s 12.8-second baseline and 150-millisecond design target.
The Foundation’s live dashboard displays a changing latest observed finality reading and trends over several time windows. A latest value should not be promoted into a typical customer experience. The useful series includes median and tail latency, outages and the time different providers take to report the same finalized block. A single especially fast slot proves that the protocol can reach that speed once; it says little about a merchant’s payment during a busy hour.
The distinction between target and measurement was central to the validator readiness question before activation. Mainnet has since supplied a certificate and several days of measurable blocks. One question has been answered: the validators did coordinate the switch. Whether the typical RPC customer sees something close to the advertised target is now a different question, because the foundation and outside monitors start their clocks at different points. Reporting both figures with those starting points lets readers compare actual performance without treating the slower observation as evidence the consensus design failed.
Solana’s block production accelerated through another programme that reduced target slot time from 400 to 200 milliseconds in October. That measure concerns how often a leader produces a block. Finality concerns when the network agrees a particular block cannot be reversed under its rules. Faster slots and faster finality can both help a user, but the two figures should not be added together or treated as the same clock.
The advertised figure depends on which participants receive a proposed block in time to vote. A fast route can certify a block promptly, while a fallback route accommodates slower communication. A slow round does not by itself imply a failed upgrade: consensus must still agree when a validator misses a message or a leader’s proposal competes with another. The median can improve dramatically while a small number of slots take longer. Services handling large transfers will care about the slow tail as much as the headline target.
A public observer should ask where a finality timer starts. Starting when a validator receives a proposed block excludes the time a wallet spent broadcasting its transaction. Starting when a merchant taps “charge” includes a human and several software systems. Starting when an RPC server sees a certificate includes the lag between the validators and the server. Each clock answers a different question. The October 23 outside measurement is useful because its method and distribution can be examined separately from the Foundation’s design claim.
A wallet has more than one clock
Imagine paying for a coffee with a Solana wallet. The user first approves a transaction locally. The wallet sends it through an RPC service, the network includes it in a candidate block and validators certify that block. The merchant’s system receives a status update and decides whether to hand over the coffee. Alpenglow changes the certification stage, not the time taken to open the wallet or the merchant’s own policy.
Many applications already showed a success message before TowerBFT’s finality. They were using a less final commitment level because most retail payments do not wait for the strongest consensus guarantee before changing the screen. A faster finalized status could let an app offer stronger assurance at about the speed of its previous early status. The improvement will be visible only if the service updates its waiting rule and its provider delivers the result promptly.
An exchange deposit illustrates the limit. A transfer can be final on Solana while the exchange still checks the sender, associates the address with an account, screens for risk and applies an internal crediting policy. The chain’s new finality time cannot compel the exchange to release a balance immediately. A bridge needs a message relay, destination-chain execution and often its own safeguards. Settlement across two systems therefore remains slower than the finality of the source chain alone.
The September testnet account set out the distinction before launch. It described a new voting process, not a new way of signing ordinary payments. Now there is a mainnet record to check. Providers can compare the time a client submits a transaction, the time a validator certifies it and the time their API reports finality. Without those separate timestamps, a claim of a 150-millisecond user payment conceals whichever parts were not measured.
The word “instant” will remain tempting in marketing. A customer standing at a counter cares whether the merchant gets a trustworthy acceptance before turning away, which is an end-to-end service measure. A trader cares whether a venue updates balances before the next market opportunity. Both may benefit even if the wallet never displays an explicit finality status. Neither should be promised that every interaction completes in 150 milliseconds.
A point-of-sale operator makes two independent decisions. It chooses when a payment is sufficiently secure to release goods, and it chooses how to handle an interrupted connection. A quick consensus certificate improves the first decision but does not cause an offline terminal to receive a response. A processor can send a provisional success message and reconcile it later, or wait for finalized status. What matters at checkout is the actual policy, including how duplicate submissions and delayed responses appear on the screen.
Financial applications have other reasons to distinguish speed from policy. A lending app may record collateral when a transfer is processed but permit borrowing only after finalization. A centralized venue may watch finalized balances while applying its own withdrawal hold. A bridge must handle the receiving chain’s risk in addition to Solana’s. A faster certificate creates an opportunity to shorten the chain-dependent portion of each workflow. Publishing before-and-after service times would show where providers use that opportunity.
Fewer transactions on the chart can mean the same amount of use
Under TowerBFT, validator voting was part of the onchain transaction stream. Alpenglow’s validators communicate directly and put certification information in block footers, so those vote transactions no longer appear in the ordinary block transaction count. A dashboard that displayed all transactions per second can drop after the switch without a drop in transfers, swaps or payments made by users.
Solana co-founder Anatoly Yakovenko discussed the removal of vote transactions shortly before activation, when the change to headline TPS was drawing attention. Analysts comparing traffic on October 20 with traffic after October 21 should isolate non-vote transactions on both sides. Otherwise an accounting change looks like lost demand. The reverse mistake would be to claim that lower vote traffic itself creates an equal number of additional useful user transactions; spare capacity and actual usage are different things.
The arithmetic can be checked without inventing a new throughput estimate. If a pre-upgrade count combines user transactions U and validator votes V, its total is U + V. After votes leave the block, a similar chart may show roughly U even when customers submit just as many transfers. The difference V is a change in what the chart counts. Calculating actual growth requires comparable user-only series, not the headline totals before and after.
This matters for fee and revenue commentary as well. Vote transaction fees disappear, while validators instead pay a Validator Admission Ticket. User transaction fee mechanics stay in place. A change in total fee revenue tied to the lost vote category cannot simply be presented as a change in consumer willingness to transact. A careful comparison separates vote-related expenses, admission fees and fees users pay for sending or prioritizing their own transactions.
Block explorers and data vendors face a related task. Participation once read from vote-program instructions now has to be read from the certificates and the footer data. A vendor continuing to parse the old field may show missing validator votes even while the network is finalizing blocks normally. The Solana documentation warns that some streaming interfaces do not yet forward every item of certificate metadata, which makes provider documentation part of any serious performance comparison.
A chart of transactions per second is vulnerable during a protocol change because it often aggregates different categories. A venue claiming user activity fell immediately after activation needs the user-only count on both dates, ideally broken into successful transfers, swaps and failed attempts. Transactions are not unique people or completed purchases. A bot can generate many instructions, and an unsuccessful instruction can still appear in a submitted-transaction series. A reduction in validator voting says nothing by itself about merchants accepting Solana.
The distinction also matters to network economics. The disappearance of vote fees reduces one type of onchain payment by validators. The admission ticket is burned from another account on a different schedule. User fees depend on what customers submit and the priority they pay for. Combining all three into a single revenue trend would obscure whether demand changed or the accounting moved. Consistent categories on either side of October 21 offer a sounder basis for interpreting a fee chart.
Data services have to follow the winning block
A fast voting decision does not make every proposed block the winner. Solana’s updated data streams can expose more than one candidate bank for a slot, and Agave 4.3 tags events with a bank_id so clients can keep candidates separate. An indexer grouping all data under a slot number can accidentally mix transactions from competing candidates into a record of a block that never existed in that form.
The Foundation directs streaming consumers to buffer by the pair of slot and bank identifier and retain the bank that reaches confirmation. If they merge feeds from different providers, the identifier is only meaningful within each connection; the block hash is the cross-provider reference. Some of the more frequent multiple-bank behaviour is expected in Agave 4.4, so there is time to adjust before it becomes common, but applications handling current block streams should prepare now.
Most wallet users will never see a bank identifier. A portfolio app or exchange that reconstructs deposits from a faulty feed might show a payment too soon, miss one or attach a transfer to the wrong block candidate. A trading system that reacts to early stream events has to know whether they belonged to the final block. The protocol can finalize quickly while an indexer’s mistakes still delay or distort what people see.
The Foundation’s mainnet migration notes say the confirmed and finalized commitment levels now describe the same state, though the former remains available for the moment and will be removed in a later release. Developers are advised to point new work at finalized and review timeout or retry settings tuned to the old wait. A service that waits 12 seconds by habit may remain slow despite a much faster chain.
Data streams have other changes. Proof of History no longer paces block production in the same way, so tick entries leave the shred stream. A program reading the Clock timestamp may see a different source than before. These details are not signs that user transactions have changed their format. They are places where software built around the old ledger timing may need work before the network’s new speed reaches the screen.
For an indexer, the problem is more than a new field name. It may receive the same slot through two connections and process transactions in arrival order. If the feeds carry events from competing banks and its database keys records only by slot, later records can overwrite earlier ones or create an impossible mixture. The migration guidance’s slot-and-bank key prevents this within a feed; the eventual winning block hash reconciles providers. Customers notice this work only when a balance or trade history becomes more reliable.
Retry logic deserves another look. A client polling once a second can miss most of the benefit of a few-hundred-millisecond consensus improvement. Another may submit the same payment again because a reply arrives after its timeout. Well-designed clients distinguish a slow response from an unprocessed transaction and preserve identifiers across retries. Operators need to test those behaviours with the new commitment stream before promising a fixed checkout time.
Validators have a new recurring bill
Removing onchain vote transactions alters validator costs. The Solana Foundation says voting previously cost about 1 SOL per epoch in transaction fees, paid from a validator’s identity account. The new Validator Admission Ticket burns 0.8 SOL per epoch from its vote account, on top of the rent-exempt minimum. The ticket purchased at the start of one epoch admits the validator for the next.
A validator that fails to keep enough SOL in the correct account cannot vote or produce blocks in the following epoch and loses the opportunity to earn its rewards there. Sending the amount to the old identity account will not pay the new fee. Operators may route block revenue into the vote account, although the Foundation says that change takes two epochs and commission income may be insufficient at a given boundary.
The comparison between roughly 1 SOL and 0.8 SOL is not a universal net saving. Revenue, stake, software costs, commissions and the timing of each charge differ across validators. The reliable fact is which account pays, how much the flat admission fee is and what happens if it is missed. Long-term concentration will depend on whether smaller operators can sustain the operational and financial requirements while remaining competitive.
The launch required Agave 4.3.2 or compatible Jito-Solana or Harmonic Salsa clients. Firedancer and Frankendancer were not supported for the migration, according to the Foundation’s operator page. Alpenglow’s activation proves the network could switch with participating validators; it does not show that every alternative validator client was ready for the same day. Client diversity remains a separate resilience question.
Governance approval came before the migration.The earlier rollout plan described the code in Agave 4.2 during testing, but installation alone was never the mainnet switch. The genesis certificate and the consensus start at slot 459,653,000 are the evidence of activation. The first certificate’s 446 signers represented a concrete coordination event, not a promise about the attendance or performance of all 654 validators every hour afterward.
The flat ticket changes validator economics differently by size. A large operator and a small one pay the same 0.8 SOL for entry, so the charge consumes a greater fraction of a small operator’s gross rewards. Whether it drives anyone away depends on delegated stake, commission, operating costs and other income. The operator guidance establishes payment mechanics; it does not forecast how many validators will leave. A useful follow-up would compare active independent operators and stake concentration across multiple epochs.
The account switch can create an avoidable interruption even for a healthy operation. The ticket comes from the vote account in advance, whereas operators funded old vote fees from the identity account as votes were sent. A validator with enough SOL overall but the wrong allocation between accounts may miss admission. Uptime reports should distinguish that migration problem from a fault in the new voting protocol. They are separate operational failures with different remedies.
The upgrade solves a narrower problem than payment apps do
Solana’s case for Alpenglow is powerful: if finality arrives much sooner, services that need irreversible settlement can stop waiting through several seconds of uncertainty. The October 23 outside measurements support a material improvement on mainnet even though their 404-millisecond median was slower than the design target. Merchants and exchanges can choose to rely on that stronger, quicker status.
A service may still keep a buffer. It might use several RPC providers, require anti-fraud screening or credit a customer only after its own ledger reconciles deposits. A low-value payment could be released on a processed status, making Alpenglow nearly invisible in its current interface. A large transfer might use finalized status and gain several seconds. The upgrade does not make a cautious service irrational; it gives the service a faster network signal to include in its decision.
The first measurable change may be reliability of the promise behind a confirmation rather than a spectacular animation in a wallet. Users who already saw fast confirmation did not necessarily know whether it was reversible. Providers can now decide whether to show or require stronger finality in that same window. Publishing the time from customer approval to merchant acceptance would settle the user-facing claim more clearly than advertising the consensus number alone.
The second part of Alpenglow, Rotor, is still planned for a later release with no activation date. Votor changed voting and finality; block distribution still uses the old Turbine approach. The package name can give the impression that all proposed components arrived together. The Foundation’s current status table makes the separation clear. Any performance gain attributed to Rotor in current mainnet data would get the chronology wrong.
Block distribution remains relevant when data travels unevenly through the network. Faster voting cannot help a validator certify a proposal it has not received. The planned Rotor component would address a different stage from Votor’s certificates. For now, slow observations may reflect propagation, voting, public RPC delivery or several together. Recording each stage would tell an operator whether its next improvement belongs in validator software, data distribution or customer infrastructure.
The initial launch is a short performance sample. Client versions, provider migration work and validator attendance define current conditions. Later releases may change how consistently outside services hear about certificates even without another consensus switch. A rolling week of observations across several independent RPC providers, including peak periods, would be more valuable to a merchant than a single fast demonstration.
What remains to be measured
There is no single finality number that captures every user’s wait. Validator certificates, public RPC observations, wallet status and exchange credit times measure different steps. The Foundation dashboard supplies live network readings, while outside monitors observe from their own nodes. Agreement across methods and providers over several days would show whether the quick results hold beyond launch week and how often the slow tail appears.
The mainnet record is already stronger than a testnet promise. Alpenglow is active, vote transactions have left blocks, and developers have published the integration changes. It is still too soon to credit the consensus upgrade with more app users, higher token prices or a given improvement in every checkout. Such claims need transaction cohorts, before-and-after service measurements and comparable user-only data.
For a wallet or payment provider, the next decision is concrete: use the finalized signal promptly, publish when the user sees it and keep the extra checks that its product requires. The chain has altered one step. People will notice when the software around it changes the rest of the journey.
What to watch
- Observed finality: Compare rolling median and slowest-percentile readings on the Foundation dashboard and independent nodes, with the observation points stated.
- Wallet and exchange times: Measure the interval from customer approval to visible confirmation or credited balance, not only the validator certificate.
- Comparable traffic: Track non-vote user transactions before and after October 21 so removed vote transactions do not distort the trend.
- Streaming errors: Check whether RPC and indexer providers support bank-aware block reconstruction and timely finalized status.
- Validator admission: Watch vote-account funding, active validators and supported client diversity as the 0.8 SOL fee recurs each epoch.
FAQ
Is Alpenglow live on Solana mainnet?
Yes. The Solana Foundation dates activation to October 21, 2026, with Alpenglow consensus starting at slot 459,653,000.
Does a Solana transfer now settle in 150 milliseconds?
That is the Foundation’s target for consensus finality, not a guarantee for every transfer or app. An outside October 23 observation measured 404 milliseconds at the median from a public node.
Why might an exchange deposit still take longer?
An exchange receives network confirmation and then applies its own matching, screening and account-crediting rules. The chain cannot remove those additional steps.
Did the upgrade change Solana transaction fees?
No. The Foundation says user transaction formats, programs and fee mechanics remain the same. Validator vote costs changed to a 0.8 SOL admission fee per epoch.
Why did Solana’s transaction count fall after Alpenglow?
Validator vote transactions no longer appear in blocks. A total count that used to include them can decline while the number of user transfers stays unchanged.
What is the difference between Votor and Rotor?
Votor is the voting and finality system live on mainnet. Rotor would replace block distribution, but it has no scheduled launch date.
Do wallets need an update?
Ordinary users do not need to change how they sign or send. Providers streaming blocks and building indexers have new bank-aware data requirements.
How can users tell whether the upgrade helps?
Compare a wallet or payment provider’s actual time from approval to reliable acceptance before and after activation. Network finality alone measures only one step. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of October 27, 2026.
