> ## 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 scheduled transactions the moment a validator commits to executing them — before they are shredded. The lowest-latency transaction signal Helius offers, delivered over a WebSocket subscription.

<Tip>
  **Use [Sender Max](/docs/sending-transactions/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.
</Tip>

## Overview

Preconfirmations stream transactions at the earliest point they can be observed: the moment a validator schedules them, **before** they are collected into entries and converted into shreds. This is the lowest-latency transaction signal Helius offers — earlier than [Shred Delivery](/docs/shred-delivery/raw-shreds) and earlier than processed commitment streams.

You subscribe over a WebSocket with the `preconfSubscribe` method and receive each scheduled transaction as it happens.

<Note>
  Preconfirmations are served from the Helius [Gatekeeper](/docs/gatekeeper/overview)
  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.
</Note>

<CardGroup cols={2}>
  <Card title="Lowest Latency" icon="bolt">
    Transactions are delivered at the scheduled-transaction stage, ahead of
    shreds and processed commitment streams
  </Card>

  <Card title="WebSocket Streaming" icon="tower-broadcast">
    Subscribe once with `preconfSubscribe` and receive a continuous stream of
    scheduled transactions
  </Card>

  <Card title="Credit-Based Pricing" icon="coins">
    Professional plan or higher; 10 credits per message (each streamed
    transaction)
  </Card>

  <Card title="Built for Traders" icon="chart-line">
    React to onchain activity before it lands, for propAMMs, snipers, copy
    traders, and liquidation bots
  </Card>
</CardGroup>

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

<Frame caption="Preconfirmations deliver scheduled transactions one stage before shreds.">
  <img src="https://mintcdn.com/helius/8YmEB-0rF0Db0-AR/images/pre-confirmations-latency.png?fit=max&auto=format&n=8YmEB-0rF0Db0-AR&q=85&s=40a2de7b866c2e5f65f1009914b64bc1" alt="Transaction latency flow inside a validator: User Tx to TPU to Scheduler to Preconf (scheduled transaction) to Shreds, with latency increasing left to right." width="1024" height="244" data-path="images/pre-confirmations-latency.png" />
</Frame>

Preconfirmations tap the **scheduled-transaction** stage — after the validator has scheduled the transaction, but before being collected into an entry and turned into shreds. That makes them strictly lower latency than shred-based delivery for the same transaction.

## When to use Preconfirmations

<CardGroup cols={2}>
  <Card title="Good fit" icon="circle-check">
    propAMMs, snipers, copy traders, and liquidation bots — any strategy that
    needs to react to a transaction as early as physically possible.
  </Card>

  <Card title="Consider alternatives" icon="circle-info">
    For full historical or confirmed data, use [LaserStream](/docs/laserstream) or
    [Enhanced WebSockets](/docs/rpc/websocket/transaction-subscribe). For raw network
    data, see [Shred Delivery](/docs/shred-delivery/raw-shreds).
  </Card>
</CardGroup>

<Warning>
  A preconfirmation is an early signal, not a guarantee. A scheduled transaction
  has not yet landed onchain and could still fail or be dropped. Confirm landing
  through standard commitment checks before treating it as final.
</Warning>

## Pricing

Preconfirmations require a **Professional plan or higher** and cost **10 credits per message** — one message per streamed transaction — billed from your plan. See [Credits](/docs/billing/credits) for details.

<Note>
  Preconfirmations is a new product and pricing is subject to change.
</Note>

## Coverage

Preconfirmations are only available for transactions scheduled by validators that forward their stream to Helius. Coverage scales with the share of network stake currently sending to Helius, so the stream is **not continuous**.

<Warning>
  Expect gaps. During slots whose leader doesn't forward to Helius, 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](/docs/laserstream) or [Shred
  Delivery](/docs/shred-delivery/raw-shreds) when you need continuous coverage.
</Warning>

Coverage grows as more validators forward to Helius. If you operate a validator, you can [help close these gaps and earn revenue](/docs/pre-confirmations/for-validators).

## For validators

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

<Card title="Validators: earn by sending Preconfirmations" icon="server" href="/docs/pre-confirmations/for-validators">
  Learn how to start forwarding preconfirmations and earn revenue.
</Card>

## Next steps

<CardGroup cols={2}>
  <Card title="preconfSubscribe reference" icon="code" href="/docs/pre-confirmations/preconf-subscribe">
    Subscribe, message format, and a complete WebSocket example.
  </Card>

  <Card title="Helius Sender" icon="rocket" href="/docs/sending-transactions/sender">
    Pair Preconfirmations with Sender to act on what you see with the fastest
    landing.
  </Card>
</CardGroup>