> ## Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

> [!TIP]
>
> **Use [Sender Max](https://www.helius.dev/docs/sending-transactions/sender-max.md) (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](https://www.helius.dev/docs/shred-delivery/raw-shreds.md) 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](#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.

> [!NOTE]
>
> Preconfirmations are served from the Helius [Gatekeeper](https://www.helius.dev/docs/gatekeeper/overview.md)
> 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.

> [card] Lowest Latency
>
> Transactions are delivered ahead of shreds and processed commitment
> streams

> [card] WebSocket Streaming
>
> Subscribe once with `preconfSubscribe` and receive Helius and BAM
> preconfirmations in a single stream

> [card] 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

> [card] 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.

![Transaction latency flow inside a validator: User Tx to TPU to Scheduler to Preconf (scheduled transaction) to Shreds, with latency increasing left to right.](https://mintcdn.com/helius/8YmEB-0rF0Db0-AR/images/pre-confirmations-latency.png?fit=max\&auto=format\&n=8YmEB-0rF0Db0-AR\&q=85\&s=40a2de7b866c2e5f65f1009914b64bc1)

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)](https://bam.dev/docs/bam/bam-overview/) 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](https://www.helius.dev/docs/pre-confirmations/preconf-subscribe.md#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](https://www.helius.dev/docs/pre-confirmations/preconf-subscribe.md#duplicate-notifications).

To receive one source, pass `includeSource: ["helius"]` or `includeSource: ["bam"]` in the [subscription filter](https://www.helius.dev/docs/pre-confirmations/preconf-subscribe.md#filtering).

## When to use Preconfirmations

> [card] Good fit
>
> propAMMs, snipers, copy traders, and liquidation bots — any strategy that
> needs to react to a transaction as early as physically possible.

> [card] Consider alternatives
>
> For full historical or confirmed data, use [LaserStream](https://www.helius.dev/docs/laserstream.md) or
> [Enhanced WebSockets](https://www.helius.dev/docs/rpc/websocket/transaction-subscribe.md). For raw network
> data, see [Shred Delivery](https://www.helius.dev/docs/shred-delivery/raw-shreds.md).

> [!WARNING]
>
> 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](https://www.helius.dev/docs/billing/credits.md) 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.

> [!TIP]
>
> 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](https://dashboard.helius.dev).

> [!NOTE]
>
> 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`](https://www.helius.dev/docs/api-reference/pre-confirmations/getpreconfcoverage) to get Preconfirmations coverage as a percentage of network stake, with a breakdown by region.

> [!WARNING]
>
> 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](https://www.helius.dev/docs/laserstream.md) or [Shred
> Delivery](https://www.helius.dev/docs/shred-delivery/raw-shreds.md) 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](https://www.helius.dev/docs/pre-confirmations/for-validators.md).

## For validators

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

> [card] [Validators: earn by sending Preconfirmations](https://www.helius.dev/docs/pre-confirmations/for-validators.md)
>
> Learn how to start forwarding preconfirmations and earn revenue.

## Next steps

> [card] [preconfSubscribe reference](https://www.helius.dev/docs/pre-confirmations/preconf-subscribe.md)
>
> Subscribe, message format, and a complete WebSocket example.

> [card] [Helius Sender](https://www.helius.dev/docs/sending-transactions/sender.md)
>
> Pair Preconfirmations with Sender to act on what you see with the fastest
> landing.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.