Alpenglow makes Solana’s path to finality much faster. It does not make transaction data arrive everywhere at the same time—or remove the need for a reliable trading-data pipeline.

For developers building arbitrage bots, transaction monitors and market-data systems, that distinction matters.

According to the Solana Foundation, Alpenglow activated on mainnet on October 21, 2026. Its voting protocol, Votor, targets roughly 150 milliseconds of finality instead of the approximately 12.8 seconds associated with TowerBFT. Solana’s upgrade guide.

But faster finality answers only one question: when does the network consider a block final?

Your application still needs to answer two others:

  • When do I receive the data?
  • What can I correctly calculate from it?

That is where raw shreds, reconstructed transactions and pool discovery remain useful.

What Alpenglow actually changes

Alpenglow separates two important parts of Solana’s architecture.

Votor handles voting and finalization. Validators exchange votes directly and aggregate them into certificates, allowing blocks to finalize in one or two voting rounds.

Rotor is the planned block-propagation component. It is intended to replace Turbine’s tree-based distribution with a single relay layer. Rotor is a later phase, not part of the already-live Votor rollout.

Transaction execution remains separate: the SVM and onchain programs are not replaced by the consensus upgrade. Solana’s Alpenglow overview.

For trading infrastructure, the practical takeaway is straightforward: consensus has changed, but applications still need access to the transactions and state they analyse.

Finality latency is not data-feed latency

The widely discussed 150-millisecond figure describes a finality target—not a universal delivery guarantee for wallets, RPC endpoints or trading bots.

Anza’s original estimates were based on simulations using the network’s stake distribution. Real application latency also depends on propagation, receiving infrastructure and processing overhead. Anza’s protocol introduction.

Consider two applications observing the same transaction. One receives and processes the relevant data earlier than the other.

Faster consensus does not automatically eliminate that difference. Both applications still have to ingest the event, identify affected markets, calculate a response and submit their own transaction.

Nor does earlier observation guarantee a profitable trade. Execution costs, competing transactions and changing liquidity remain part of the problem.

Alpenglow accelerates certainty. A data feed determines what your application can observe and when it can act on that observation.

Do Solana shreds disappear after Alpenglow?

No.

Shreds are fragments of block data that receiving systems can use to reconstruct entries and transactions. Changing the voting protocol does not eliminate the need to distribute that data.

Turbine remains the propagation layer during the Votor phase; Rotor is planned separately. Shred-based infrastructure therefore remains relevant, although consumers must account for protocol and parser changes. Alpenglow rollout.

The choice for developers is not simply “shreds or Alpenglow.” It is which interface should sit at the beginning of the application’s data pipeline?

Raw Shreds: control your own reconstruction pipeline

Teams that already operate a deshredder—or want to build their own ingestion stack—can start with Shredo Raw Shreds.

Raw Shreds delivers deduplicated Solana shreds over UDP to one public IPv4 address and port.

Your infrastructure handles packet reception, reconstruction, transaction parsing and application-specific processing. This gives you control over the pipeline, while leaving receiving capacity and packet-loss handling in your hands.

UDP does not guarantee delivery or ordering. A production integration should track incomplete data rather than assume every shred in a slot arrived.

Price: 99 USDC per calendar month.

Raw Shreds is a fit when your team wants the raw input and is prepared to operate the processing infrastructure around it.

Decoded Transactions: begin at the transaction layer

Not every application needs to implement shred reconstruction.

Shredo Decoded Transactions delivers reconstructed, signed Solana transactions through a TLS-protected gRPC stream.

Events expose signatures, instructions, account information and observation metadata. Program and account filters help narrow the stream to activity relevant to your application.

This can be useful for:

  • Monitoring transactions involving selected DEX programs.
  • Following activity associated with particular accounts.
  • Building transaction classifiers and alerts.
  • Triggering further analysis in a trading system.

A separate Raw Shreds subscription is not required.

Price: 399 USDC per calendar month.

Here, “decoded” means transaction-level reconstruction and parsing. An observed signed transaction is not proof of successful execution, a confirmed swap or finality. The feed does not replace canonical execution results or live account state.

Transaction signals and pool state serve different purposes

Seeing a transaction reference a pool does not, by itself, tell your application the pool’s resulting reserves or executable price.

A trading engine also needs a state model.

For example, an AMM strategy may need reserves, liquidity parameters, tick arrays or bins before it can calculate a route accurately. Geyser-based account streams provide account updates from transaction processing and can support that state-maintenance layer. Agave’s Geyser documentation.

A system can therefore combine:

  • A transaction feed to identify relevant activity.
  • An account-state feed to maintain its market models.
  • Its own quoting, simulation and execution logic.

Predicted state and observed execution results should remain distinct. Applications acting on non-final data must also handle competing branches and invalidated assumptions.

Pool Catalogue: discover what to follow

Before maintaining pool state, an application needs to identify the pools and dependency accounts it cares about.

Shredo Pool Catalogue provides signed inventory snapshots, pool search and resumable catalogue changes through an authenticated HTTPS API.

Developers can use it to establish a starting inventory and find supported pools by token, pair or DEX.

Price: 99 USDC per calendar month.

Pool Catalogue is a discovery product—not a live price feed. Catalogue membership does not prove that a pool is liquid or currently executable, and coverage is limited to supported pools and protocols.

It complements transaction and state ingestion rather than replacing them.

What developers should review after Alpenglow

Existing infrastructure should not assume that a consensus upgrade requires no downstream work.

Important checks include:

  • Handling candidate banks without merging everything under a slot alone.
  • Treating bank_id as local to its originating node or connection.
  • Revisiting logic that inferred timing or completeness from tick entries.
  • Re-baselining metrics that previously counted vote transactions.
  • Reviewing commitment handling, reconnects and incomplete observations.

The exact requirements depend on the interface and client version. Use the official migration checklist rather than assuming every stream exposes the same metadata.

Choose where your application’s work begins

Alpenglow changes how quickly Solana reaches agreement. It does not build your market-data system, reconstruct transactions for your application or maintain your pool models.

Choose Raw Shreds when you want to operate the reconstruction pipeline.

Choose Decoded Transactions when your application should begin with filtered transaction events.

Add Pool Catalogue when you need a searchable, verifiable inventory of supported pools and their dependency accounts.

Faster finality is a network improvement. Turning network data into useful decisions is still an application problem.

Explore Shredo products in the console →