Alpenglow Is Live: Solana Transaction Data Has Changed

Solana activated Alpenglow on mainnet on October 21, 2026, during epoch 1064. One immediate consequence for data analysis is the removal of validator vote transactions from blocks. A dashboard’s transaction count can therefore fall even if application activity does not. The activation is confirmed in Solana’s official documentation.

This matters for investors who use transactions per second, or TPS, to assess network usage. Earlier figures may include internal consensus activity, while later figures no longer contain the same component. Comparing them directly risks producing a misleading account of growth or contraction.

Assessing SOL requires separating accounting changes, network performance, and economic demand. These can move differently. Faster settlement does not immediately create new users, while a lower headline transaction count does not necessarily mean that users are abandoning applications.

Alpenglow activation and changes to validator-vote accounting. Source: Solana Foundation, October 2026 update; checked October 23, 2026..

Why Validator Votes Previously Counted as Transactions

Validators must agree on which blocks the network accepts. The previous mechanism used vote transactions to communicate that agreement. Those transactions performed a consensus function, distinct from payments, token swaps, or other application interactions.

Alpenglow uses Votor to change voting and block finalization. Validators communicate directly and combine votes into certificates. The developers explain the design in Anza’s introduction to Alpenglow.

The shift changes what appears in block transaction statistics. Validators still perform consensus work, but that work no longer appears through the same accounting mechanism. Its disappearance from the transaction count does not mean the network has stopped reaching consensus.

Dashboard definitions therefore matter. A service that already excluded votes has a different comparison baseline from one that previously combined vote and non-vote transactions. A headline stating that “Solana transactions fell” does not establish which series declined.

How Total Transactions Can Fall While Non-vote Activity Rises

The following scenario uses hypothetical figures for a 60-second period, not observed mainnet data. It illustrates the effect of changing the composition of a metric.

Suppose the earlier period records:

• 180,000 total transactions.

• 120,000 validator vote transactions.

• 60,000 non-vote transactions.

Headline throughput is 180,000 ÷ 60 = 3,000 TPS, while non-vote throughput is only 60,000 ÷ 60 = 1,000 TPS.

After votes leave blocks, suppose non-vote transactions rise to 72,000 over 60 seconds. The visible total becomes 72,000 ÷ 60 = 1,200 TPS.

A raw comparison shows throughput falling from 3,000 to 1,200 TPS, a decline of 60%. Yet non-vote transactions have increased from 60,000 to 72,000, or 20%.

Both conclusions come from the same illustrative figures but use different baselines. A decline in the combined statistic cannot establish a decline in application activity. Equally, removing votes does not guarantee that non-vote activity grows. Actual outcomes require measurement.

What the Initial Transition Data Shows

Solana Compass reported approximately 2,500 non-vote TPS during the 14:00 UTC hour on October 21, compared with about 2,640 during the same hour the previous day. That hour corresponds to 21:00 WIB in Indonesia. It provides an early like-for-like comparison, not evidence of a lasting growth trend. Source: Solana Compass measurements.

Non-vote TPS during the 14:00 UTC, or 21:00 WIB, hour on October 20 and 21, 2026. Source: Solana Compass, October 21, 2026.

A single hour cannot represent all network conditions. Trading activity changes with time of day, asset volatility, and application launches. A stronger assessment requires longer periods and consistent comparison windows.

Non-vote activity is also not identical to human activity. Bots, arbitrage, automated updates, and transaction attempts can increase the count. The statistic improves comparability but does not reveal the number of unique people or the economic value created.

Four Measures for Evaluating Activity After the Upgrade

Solana activity becomes easier to interpret when several indicators are assessed together. Each answers a different question, so no single number needs to represent the entire network.

A. Successful Non-vote Transactions

Non-vote transaction counts help remove the effect of changing vote accounting. Investors should still check whether a provider includes failed transactions and how it handles retries.

Solana distinguishes transactions from their underlying instructions. One transaction can contain multiple instructions, and an instruction failure reverts the transaction’s state changes. A failed transaction can still incur fees. These mechanics are explained in Solana’s transaction documentation.

Instruction counts, transaction counts, and successful transaction counts are therefore different measures. Their definitions must remain consistent before percentage changes become meaningful.

B. Returning Users and Application Distribution

Active addresses measure addresses, not people. One person can control multiple wallets, while one service can represent many users through shared infrastructure.

A stronger analysis asks whether activity survives after incentives end and whether users return to the applications. Growth distributed across several applications also has a different meaning from a temporary surge concentrated in one token or bot.

C. Economic Value and Fees Paid

Transaction counts should be compared with value transferred, trading volume, and user-paid fees. Numerous low-value transactions can produce large activity figures without a proportional increase in economic demand.

Volume requires scrutiny as well. Repeated trades between related accounts can inflate statistics without representing new demand. Gross transaction value is not automatically fresh capital entering Solana.

D. Settlement Reliability and Execution Quality

Finality measures when consensus treats a transaction’s result as final. The user experience includes a longer process: submission, network acceptance, execution, application updates, and possible retries.

Traders also face bid-ask spreads, slippage, and token liquidity. Faster settlement does not remove the risk of buying into a shallow market or approving an incorrect transaction.

A Finality Target Is Not an End-to-End Execution Guarantee

Anza introduced a finality target of roughly 150 milliseconds in the Alpenglow design. That figure must be understood in its testing context rather than treated as a promise that every user transaction completes in the same time. Source: Anza’s design explanation.

A transaction that has not successfully landed in a block can still require retries. Applications may add their own waiting periods. Comparing user experience requires measuring the entire path rather than one stage of consensus.

Solana’s RPC documentation exposes separate fields for transaction counts, non-vote transaction counts, and sample duration through getRecentPerformanceSamples. However, example responses in the documentation are not current mainnet statistics and should not be presented as live measurements.

What This Means for SOL’s Price

Faster settlement can help applications that depend on timely execution. Its contribution to SOL demand becomes more convincing when accompanied by sustained usage, transaction needs, and additional economic activity.

The token’s price also responds to spot trading, derivatives positioning, liquidity, and risk appetite. A rally after an upgrade cannot by itself establish causation. A price decline likewise does not demonstrate that the upgrade failed.

Readers can use the SOL/USDT market on MEXC to examine price and trading activity separately from network statistics. Volume on one trading pair measures activity at that venue, not total activity across Solana applications.

What to Monitor Next

Post-Alpenglow analysis should preserve consistent definitions and comparison periods:

• Non-vote transactions, separated into successful and failed transactions where available.

• Returning-user activity and its concentration across applications.

• Measured finality, including periods of heavy load.

• Economic value and fees under a consistent methodology.

• Service disruptions or changes in data-indexing methods.

A decline caused by removing vote transactions has a technical explanation. But if successful non-vote transactions, returning usage, and economic value also weaken persistently, that deterioration still needs to be acknowledged.

Alpenglow requires investors to repair their comparison baseline. Claims that Solana is becoming busier or quieter should follow only after accounting changes have been separated from actual changes in usage.

Disclaimer: This article provides general information and analysis, not investment advice. Illustrative figures are not mainnet statistics. Protocol performance, dashboard methodologies, and liquidity conditions may change and do not guarantee SOL’s price direction.