includeBam: false to receive Helius preconfirmations only.
Endpoints
preconfSubscribe is served from the Helius Gatekeeper endpoint:
wss://beta.helius-rpc.com/?api-key=<API_KEY>
beta hostname refers to the Gatekeeper rollout, not the maturity of Preconfirmations — it will become the standard endpoint as traffic migrates to Gatekeeper.
The stream is not continuous. Coverage scales with the share of network stake
forwarding to Helius or running BAM, so expect slots with no messages — handle
these gaps gracefully. See Coverage.
Authorizations
string
required
Your Helius API key, passed as the
api-key query parameter. Requires a Professional plan or higher.Body
array
Optional. Omit
params to receive every scheduled transaction from both Helius and BAM. To narrow the stream, pass a filter object as the first element — filtering happens server-side, so you only pay for and receive the transactions you care about.-32602 (invalid params).
Account filters match more than the transaction’s static account keys — Helius resolves v0 address lookup tables server-side, so accountInclude, accountExclude, and accountRequired also match accounts a transaction loads through an ALT.
Region codes
For Helius preconfirmations the region is where Helius ingested the transaction. For BAM preconfirmations it is the regional BAM endpoint that emitted the preconfirmation, not where Helius ingested it. BAM’s Singapore and Dallas endpoints map to
sgp and dal.
Response
integer
Subscription id (needed to unsubscribe)
Notifications
After the JSON acknowledgement, notifications are delivered as binary WebSocket frames (not JSON). Helius and BAM preconfirmations share the same layout. Each frame is a packed byte layout carrying a single scheduled transaction:
The payload has no source field. Don’t infer a BAM origin from
tx_index = 0 and status = 2, since Helius preconfirmations can carry the same values.
Only Helius preconfirmations carry an execution status. Helius
preconfirmations report
0 (failed) or 1 (success) when the validator
provides it, and 2 only when it’s unavailable. BAM preconfirmations always
report 2 (unknown), so status alone cannot tell you whether a BAM-sourced
transaction succeeded. If your strategy depends on execution status, set
includeBam: false or confirm the result onchain.Decoding the transaction
The transaction bytes are forwarded exactly as the validator serialized them, in the standard wire encoding for the transaction’s version. Legacy and v0 transactions use the signatures-first layout thatbincode produces. Transaction v1 (SIMD-0385) uses a message-first layout with signatures at the end, so bincode fails on v1 payloads.
Use a decoder that handles every version. In Rust, agave-transaction-view parses legacy, v0, and v1 transactions in place and is the recommended option; wincode with a current Solana SDK VersionedTransaction also works. In JavaScript, make sure your library version supports transaction v1. See the guide for a Rust example.
Duplicate notifications
Helius and BAM preconfirmations are deduplicated per source, not across sources. A small share of transactions reach Helius through both, so you can receive the same signature twice, and the two copies may report different slots. Deduplicate by signature on the client and make transaction-triggered actions idempotent. See the guide.Pricing
Preconfirmations require a Professional plan or higher and cost 10 credits per message — one message per streamed transaction. See Credits for details. Billing is per message, not per unique signature. A transaction delivered by both Helius and BAM counts twice. SetincludeBam: false if you only want Helius preconfirmations.
Related
Preconfirmations Overview
What Preconfirmations are and where they sit in the validator pipeline.
preconfUnsubscribe
Stop a subscription by its id.