Preconfirmations: The Earliest Transaction Signal on Solana

Stream Solana transactions before they are shredded on any paid Helius plan, with execution status from Helius and pre-execution signals from Jito BAM.

Use Sender Max (min tip: 0.001 SOL) to act on Preconfirmations. A preconfirmation only pays off if you land your transaction first — Sender Max is the fastest way to do that. Build on Sender Max from the start to get the full benefit of Preconfirmations.

​

Overview

Preconfirmations stream transactions at the earliest point they can be observed — before they are collected into entries and converted into shreds. This is the lowest-latency transaction signal Helius offers — earlier than Shred Delivery and earlier than processed commitment streams.

You subscribe over a WebSocket with the preconfSubscribe method and receive each transaction as it happens. The stream combines two sources, both included by default, and the two emit at different points in the pipeline:

• Helius preconfirmations from validators that forward to Helius. Emitted the instant the leader executes the transaction, together with its execution status — the first moment the outcome exists anywhere.
• BAM preconfirmations from validators running Jito’s Block Assembly Marketplace (BAM) client. Emitted when the validator commits to executing the transaction, before it runs — so they carry no execution status.

Preconfirmations are served from the Helius Gatekeeper endpoint, wss://beta.helius-rpc.com. The beta hostname refers to the Gatekeeper rollout, not the maturity of Preconfirmations — it will become the standard endpoint as traffic migrates to Gatekeeper.

Lowest Latency

Transactions are delivered ahead of shreds and processed commitment streams

WebSocket Streaming

Subscribe once with preconfSubscribe and receive Helius and BAM preconfirmations in a single stream

Credit-Based Pricing

All paid plans; 10 credits per delivered message. Zero-message slots cost zero, and slots with messages have a 300-credit minimum per subscription

Built for Traders

React to onchain activity before it lands, for propAMMs, snipers, copy traders, and liquidation bots

​

Where Preconfirmations sit in the pipeline

A transaction passes through several stages inside a validator before it lands onchain. Latency increases left to right — the further right you observe, the later you learn about the transaction.

Preconfirmations deliver transactions ahead of shreds and processed commitment streams.

Helius preconfirmations are emitted from the execution stage — the instant the leader executes the transaction and its status is known, but before the result is recorded into an entry and turned into shreds. This is the first point in the lifecycle at which a transaction’s outcome both exists and can be reported.

BAM preconfirmations are emitted one stage earlier, when the validator commits to executing the transaction but before it has run. Both arrive before the transaction is shredded, which makes them strictly lower latency than shred-based delivery for the same transaction.

​

BAM preconfirmations

BAM (Block Assembly Marketplace) is Jito’s block-building system for Solana. Validators running BAM-compatible clients emit a preconfirmation the instant they commit to executing a transaction. Helius ingests these from Jito’s regional BAM endpoints and delivers them through the same preconfSubscribe subscription and binary payload as Helius preconfirmations. At launch, BAM added coverage from validators representing over 34% of network stake.

BAM preconfirmations follow the same payload layout but differ in a few fields:

• tx_index is always 0. BAM orders transactions by sequence ID and bundle position rather than a slot index; neither maps onto the Helius field, and neither is carried on the stream. See Telling the two sources apart.
• regionInclude matches the regional BAM endpoint that emitted the preconfirmation, not the Helius region that ingested it.
• A small share of transactions reach Helius through both sources, so the same signature can arrive twice. See Duplicate notifications.

To receive one source, pass includeSource: ["helius"] or includeSource: ["bam"] in the subscription filter.

​

When to use Preconfirmations

Good fit

propAMMs, snipers, copy traders, and liquidation bots — any strategy that needs to react to a transaction as early as physically possible.

Consider alternatives

For full historical or confirmed data, use LaserStream or Enhanced WebSockets. For raw network data, see Shred Delivery.

A preconfirmation is an early signal, not a guarantee. The transaction has not yet landed onchain and could still be dropped — and a Helius preconfirmation’s execution status reflects the leader’s local result, which is not final until the block is confirmed. Confirm landing through standard commitment checks before treating it as final.

​

Pricing

Preconfirmations are available on all paid plans: Developer, Business, Professional, and Enterprise. Free plans are not eligible.

Slots with zero delivered messages cost zero credits, even when the slot has preconfirmation coverage. When a slot delivers at least one message, each open preconfSubscribe subscription is billed the greater of 300 credits or 10 credits per delivered message. Uncovered slots cost zero. See Credits for details.

Messages delivered in a covered slot	Credits billed
0	0
10	300
30	300
100	1,000

Whether a slot is eligible for billing depends on how its leader is covered and on your includeSource setting:

Preconfirmation source	Default (both sources)	includeSource: ["helius"]
Helius source	Eligible	Eligible
BAM source	Eligible	Not eligible
Neither	Not eligible	Not eligible

regionInclude narrows the eligible set further. Covered slots outside the selected regions cost zero for that subscription. Matching slots are billed only when the subscription receives at least one message.

Each concurrent subscription is billed independently when it receives at least one message. Close subscriptions you no longer need with preconfUnsubscribe. With includeSource: ["helius"], BAM-only covered slots are excluded from billing.

To control costs, consolidate account filters into one subscription where practical, use regionInclude to limit billing to the regions you need, set includeSource: ["helius"] when you do not need BAM, and monitor credits in the Helius Dashboard.

Preconfirmations is a new product and pricing is subject to change.

​

Coverage

Preconfirmations are only available for transactions scheduled by validators that forward their stream to Helius or run a BAM-compatible client. Coverage scales with the share of network stake covered by those two sources, so the stream is not continuous. Setting includeSource: ["helius"] limits coverage to validators forwarding directly to Helius.

Use getPreConfCoverage to get Preconfirmations coverage as a percentage of network stake, with a breakdown by region.

Expect gaps. During slots whose leader is covered by neither source, you’ll receive no preconfirmation messages for that slot. Design your integration to tolerate these gaps — don’t assume an unbroken stream, and fall back to other signals such as LaserStream or Shred Delivery when you need continuous coverage.

Coverage grows as more validators forward to Helius. If you operate a validator, you can help close these gaps and earn revenue.

​

For validators

Operate a validator? You can earn revenue by forwarding your preconfirmation stream to Helius — and improve coverage for everyone consuming Preconfirmations.

Validators: earn by sending Preconfirmations

Learn how to start forwarding preconfirmations and earn revenue.

​

Next steps

preconfSubscribe reference

Subscribe, message format, and a complete WebSocket example.

Helius Sender

Pair Preconfirmations with Sender to act on what you see with the fastest landing.