What are Preconfirmations (Preconfs) on Solana?

Preconfirmations (preconfs) are the earliest available signal that a transaction is about to land on Solana. A preconfirmation is emitted the moment a block leader executes a transaction, after the outcome is known locally and before it is recorded into an entry, shredded, and propagated across the network. Consuming preconfirmations allows developers to observe transactions one stage earlier than shred streams and several stages earlier than any RPC commitment level.

Consider how the average application learns about a transaction’s status: most learn of it only after it reaches a processed commitment. That is, after the transaction is executed, packaged into shreds, and broadcast through Turbine. 

Latency-sensitive systems improved on this by tapping into shreds directly, reconstructing transactions from the raw data that validators exchange.

Preconfirmations move the observation point one stage further upstream to when the transaction’s execution outcome is already known—each preconfirmation carries the transaction status—but before any block data has left the leader’s machine. Nothing observable exists earlier, because before execution, a transaction is just one of thousands of candidates waiting in a queue.

To understand exactly where this signal comes from, and why nothing earlier in the pipeline can be streamed, we must walk through what happens inside the leader during its slot.

The Lifecycle of a Transaction Inside the Leader

What follows is a deliberately narrow walkthrough of the transaction lifecycle within the leader, as it pertains to preconfirmations and observability. For a full walkthrough of the lifecycle of a transaction on Solana, see our technical overview of the Solana Virtual Machine (SVM).

Before the Leader

On Solana, signed transactions are sent directly to the block producer (i.e., the leader) and to upcoming leaders. It arrives via QUIC, with connection capacity allocated by stake-weight, so transactions relayed through staked connections are far more likely to be admitted under load.

At this point, a transaction is only visible to the sender and whatever RPC node or transaction landing service that is relaying it to the current and upcoming leaders. 

Nothing about the transaction’s fate at this stage is knowable. 

Stage 1: Ingest and SigVerify

The leader’s Transaction Processing Unit (TPU) receives incoming transactions as packets, deserializes them, verifies their signatures, and discards any duplicates. Under heavy load, malformed packets and spam transactions are dropped before consuming any further resources.

A transaction that is ingested and passes signature verification in the SigVerify stage is merely a candidate; thousands of candidate transactions arrive per slot, with many never making it into a block.

There is no meaningful observability at this stage because streaming these transactions would mean streaming noise. 

Stage 2: The Scheduler

Block production happens at the Banking Stage, and since Agave 1.18 its heart has been the central scheduler: a single scheduling thread with a global view of all pending transactions, dispatching work to a pool of execution workers. The idea is that a single thread with full context packs blocks with far fewer lock conflicts than n threads greedily competing for a shared queue.

In essence, the scheduler puts transactions through three main steps:

1. Buffering and Prioritization

Incoming transactions land in the scheduler’s receive and buffer component, where each transaction’s priority and cost are computed and inserted into a priority-ordered container.

At this moment, a transaction is still one of thousands of “maybes” that could be evicted if the buffer fills with higher-priority work.

2. Scheduling 

The control loop in the scheduler’s controller repeatedly pops the highest-priority transactions from the container, checks for any account-lock conflicts, and batches them for execution.

Since Agave 2.3, the scheduling algorithm shipped is the greedy scheduler, which replaces the earlier prio-graph design after testing showed the greedy approach packed blocks with less overhead.

3. Dispatch 

The scheduled batch is sent over a channel to an execution worker. The leader has now committed real resources—a worker thread, account locks, a place in the block being assembled—to this specific transaction.

At this point, the transaction is still pending. The leader intends to execute it, but nothing has run yet, so there is no result to report. Preconfirmations come one step after.

How does Firedancer’s scheduler architecture differ from Agave?

Firedancer arrives at the same moment through a slightly different architecture. Instead of threads sharing memory, Firedancer runs isolated tiles connected via shared-memory queues, with its scheduling logic residing in the pack tile. 

The pack tile maintains all the pending transactions, tracks which accounts each bank tile currently holds, and selects non-conflicting, fee-maximizing transactions into microblocks that it hands to the bank tiles for execution. 

The same handoff occurs, in which selected transactions flow from the packing logic to the execution units, where their outcomes are determined.

Stage 3: Execution

Workers in Agave, or bank tiles in Firedancer, execute the scheduled batch of transactions against the current bank, loading accounts, running programs, and committing their results.

This is also where a scheduled transaction can fail for various reasons, including insufficient funds, a program error, a slippage check that reverts, or other runtime conditions. Either way, the outcome now exists only locally, on the leader’s machine.

This is the moment that a preconfirmation is emitted. A leader streams each transaction the instant it is executed, together with its status, before the results are recorded into an entry and long before any block data leaves the machine.

This is the first moment in the entire lifecycle at which a transaction’s outcome both exists and can be reported. Upstream of execution, there is only a pool of pending candidates with no results to stream; downstream, the information is already being packed into the block racing toward the rest of the network.

Execution is, therefore, the only place an early signal of this kind can exist, and it is why every preconfirmation carries the transaction’s actual result rather than a prediction.

What a preconfirmation cannot tell you, however, is whether the block containing the transaction will become canonical. That block has not yet been shredded, propagated, or voted on. 

For this reason, preconfirmations are a signal rather than a guarantee.

Stage 4: Proof of History and Entries

Executed batches are recorded into the Proof of History stream to produce entries, which are hashed bundles of transactions woven into the leader’s verifiable clock. Entries are the ledger’s native format, but they currently only exist on the leader’s machine.

Observability is effectively zero for anyone outside of the leader.

Note that Proof of History will be removed with the Alpenglow update, as Rotor and Votor remove the need for a decentralized clock on Solana. The preconfirmation model is unaffected: leaders will still execute transactions before disseminating them, so the earliest observable signal remains the leader’s local execution results. 

Stage 5: Shredding and Broadcast

Entries are sliced into shreds, or MTU-sized fragments that are erasure-coded for loss tolerance. These shreds are signed and broadcast through Turbine’s stake-weighted tree.

This is where the observability floodgates open. Shreds are the first artifact of a given block to leave the leader’s machine, which is why every other early-data product on Solana, including shred streams, begins here. Anyone reconstructing transactions from shreds is fast relative to RPC commitment levels but late relative to a preconfirmation, given that the leader executed the transaction before shreds exist. 

The story continues from here with validators replaying the block, voting, and transactions climbing through the processed, confirmed, and finalized commitment levels. 

Where do preconfirmations sit on the latency ladder?

Preconfirmations are the fastest signal on Solana, compared to all others, including raw and decoded shreds, LaserStream, and other data streaming methods. 

However, preconfs are best understood as a rung on a latency ladder wherein each rung trades some form of completeness or certainty for earlier observation.

Descending from earliest to latest:

Two observations follow from this table. 

First, these signals are all complementary, rather than direct replacements for one another per se.

For example, preconfirmations report what a leader has just executed before the network knows, whereas a message from LaserStream indicates what happened with full metadata.

Production systems typically need to consume both, acting on preconfirmations and using downstream signals for verification.  

Second, the gap between rungs is not uniform.

The step from processed streams down to shreds saves single-digit milliseconds, while the step from shreds up to preconfirmations skips the remainder of the block production pipeline (i.e., entry recording, shredding, and propagation) because the observation point moves from the block’s first public artifact to results that only exist inside the leader. 

As a result, preconfirmations are approximately 5 to 50 milliseconds faster than shreds. 

The Preconfirmations Trust Model: Signal, Not Guarantee

Everything a preconfirmation promises can be contained to a single sentence: the leader has executed this transaction with this result. Everything a preconf does not promise follows from the same sentence.

An executed transaction is not yet a landed transaction, meaning the block carrying it has not been shredded, propagated, or voted on. It is still possible for this block to be skipped or forked off before it is confirmed by the network. Almost all preconfirmed transactions successfully land onchain. However, any system acting on preconfirmations must confirm outcomes through other observability checks before treating them as final.

Coverage is also partial by design. Preconfirmations exist only for slots whose leader forwards its scheduled-transaction stream to Helius. Coverage therefore scales with the share of the network stake that participates, and the stream is not necessarily continuous.

If services need continuous coverage as an absolute guarantee, they should consider falling back to LaserStream or Shred Delivery when gaps occur.

The signal is honest about what it is: there is no economic commitment backing a preconfirmation, and none is claimed. The leader reports its local results, but does not stake anything on follow-through. For the strategies that preconfirmations serve, this is the correct trade.

A liquidation bot, for example, does not need an infallible, slashable promise that a transaction will land; it needs to know a given transaction’s outcome milliseconds before its competitors do.

How do Helius Preconfirmations work?

Helius Preconfirmations are delivered over a single WebSocket subscription. A client can connect to our Gatekeeper endpoint (i.e., wss://beta.helius-rpc.com) and send a preconfSubscribe request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

Filters are applied server-side by account (i.e., include, exclude, required), region, and status, with support for lookup tables (LUTs), so a subscriber receives and pays for only the scheduled transactions relevant to their strategy. 

Because preconfirmations are emitted after execution, the status filter operates on real outcomes: failed: false, which means failed transactions are never streamed or billed.

Pricing is credit-based, matching other Helius WebSocket subscriptions at 10 credits per message, one message per streamed transaction, available on Professional plans and higher. 

From there, every scheduled transaction matching the filters arrives as a compact binary frame. That is, a fixed 18-byte header containing the transaction version, the slot it is scheduled in, the transaction’s index within the slot, and its status, followed by the full transaction bytes. 

The format is deliberately austere because a fixed header can be decoded in nanoseconds without needing JSON parsing on the hot path. The only JSON we need in this exchange is the subscription acknowledgment for convenience. 

Note that a preconfirmation is only half a trade. Seeing a transaction first only matters if the response lands first, which is why we’ve also launched Sender Max, the highest-performance Helius Sender tier.

Sender Max routes a submission (i.e., a single transaction or an atomic bundle of up to four transactions) across every available high-speed pathway and enters into a priority tip buffer that favors the highest tips. The minimum tip is 0.001 SOL.

Get signals with preconfSubscribe, land transactions with Sender Max.  

What can you build with preconfirmations?

Any strategy in which profit decays with every millisecond between when a transaction is decided and when it is observed benefits from preconfs. This includes, but is not limited to, the following use cases: 

Sniping

New pool creations and token launches are visible the instant the deploying transaction executes inside the leader. A sniper consuming preconfirmations reacts while shred-watchers are still waiting for the block’s first fragments to arrive. 

Copy Trading

A target wallet’s movements appear in the preconfirmation stream the moment the leader executes them. Filtering on a target’s address using accountInclude turns the stream into a purpose-built mirror feed, giving insights into movements before other copy traders.

Liquidations

An oracle update that pushes a position underwater is knowable the moment it executes. The liquidation bot that sees it there fires an entire pipeline ahead of one watching shreds or a processed commitment, making preconfirmations extremely important to liquidation activities.

Market Making and propAMMs

Incoming flow visible at the moment of execution gives propAMMs and other quoting systems a head start on repricing or pulling stale quotes before the flow becomes public. 

In every case, preconfirmations move the strategy’s reaction point from “after the network learns” to “the moment the leader executes.”

Earn By Forwarding Preconfirmations

Preconfirmation coverage is a network effect, with validators on the supply side. Any validator can forward its stream to Helius and earn revenue for doing so, turning a byproduct of block production into an income stream that exists whether or not the validator is otherwise monetizing its position.

The more participating stake, the broader the coverage. Validators interested in participating can contact us and find more information in our preconfirmations for validators documentation. 

What is the difference between Ethereum preconfs and Solana preconfs?

Ethereum preconfirmations are proposer commitments that guarantee a transaction will land in a future block, while Solana preconfirmations are real-time, onchain transaction signals for transactions that were just executed locally by the leader for the current block. The former is about knowing sooner, whereas the latter is about seeing sooner.

On Ethereum, preconfirmations—often written as based preconfs in the research literature—are inclusion commitments. A proposer promises, in advance of its slot, that a transaction will be included in a future block, with that promise backed by an economic mechanism such as slashing.

Most importantly, Ethereum preconfirmations are:

• About your own transaction
• Issued before execution
• Optimizes for certainty

Ethereum preconfirmations guarantee your transaction will land before it actually does.

Solana preconfirmations are real-time onchain signals rather than a future promise: the leader reports transactions it has already executed before those transactions propagate to the rest of the network.

Most importantly, Solana preconfirmations are:

• Inclusive of everyone’s transactions
• Emitted after execution
• Optimized for latency

Solana preconfirmations let you see executed transactions milliseconds before they are observed across the network via shreds or RPC requests at standard commitment levels.

The closest Solana analog to Ethereum’s blockspace-reservation preconfirmation is Raiku’s compute unit marketplace for Ahead-of-Time (AOT) Transactions, which allows apps to reserve guaranteed inclusion in future blocks.

Conclusion

Every transaction on Solana passes through a single moment where its fate flips from unknown to decided: the instant the leader executes it. Preconfirmations are that moment, streamed before the rest of the network can see it. They sit above shreds on the latency ladder because they observe the leader’s execution results, rather than the block’s public artifacts. Preconfirmations are a signal, not a guarantee, because a block is not considered canonical until the network confirms it.

For latency-sensitive systems—snipers, copy traders, liquidators, market makers, and searchers—subscribe with preconfSubscribe, filter for the accounts that matter, respond to signals with Sender Max, and verify through standard commitment checks.

The full subscription reference, message format, and integration examples are all available in our preconfirmations documentation.