Skip to main content

Overview

Preprocessed transactions are pre-execution Solana transactions delivered before they reach the processed commitment level. Helius aggregates multiple pre-execution sources โ€” primarily shreds decoded directly as they arrive at the validator, supplemented by scheduled-transaction (preconfirmation) signals โ€” and delivers them as a single deduplicated stream, with no raw shred packets to receive or deshredding infrastructure to operate on your side. Transactions sourced from preconfirmation signals arrive later on this feed than on the dedicated Preconfirmations product, which remains the earliest access to them. The primary way to consume preprocessed transactions is the preprocessedSubscribe WebSocket method (Public Beta) โ€” available on all paid plans at 0.1 credits per message. The earlier gRPC delivery will be deprecated in its favor.

preprocessedSubscribe (WSS)

The recommended way to stream preprocessed transactions: account filtering, compact binary payloads, all paid plans.

gRPC (legacy)

The earlier LaserStream-based delivery. Will be deprecated โ€” new integrations should use the WebSocket method.

Where preprocessed transactions sit in the lifecycle

In Solanaโ€™s architecture, transactions flow through several stages before becoming fully processed:
  1. Shred Reception โ†’ Validator receives transaction shreds (data fragments). โ† Raw shreds (UDP) are delivered here.
  2. Shred Decoding โ†’ Shreds are decoded into raw transactions. โ† Preprocessed transactions are primarily delivered here.
  3. Transaction Execution โ†’ Transaction is executed by the runtime.
  4. Metadata Generation โ†’ Pre/post balances, logs, and error information are computed.
  5. Commitment โ†’ Transaction reaches processed/confirmed/finalized state. โ† LaserStream gRPC and LaserStream WebSocket deliver here.
Post-execution subscriptions deliver data at stage 5 โ€” after full execution and metadata generation. Preprocessed transactions are delivered at stage-2 timing โ€” after shred decoding, before execution completes. For an even earlier signal, Preconfirmations stream scheduled transactions before they become shreds. The tradeoff: you receive transaction data earlier, but without execution metadata like balance changes, logs, or error information.
This is a transactions-only stream. Account and program state updates donโ€™t exist until the runtime executes the transaction. If you need real-time account or program updates โ€” token balances, bonding-curve state, program accounts โ€” use LaserStream gRPC at processed commitment instead.

What data is available?

Preprocessed transactions include the complete signed transaction, but lack execution metadata:

Available Data

  • โœ… Transaction signature - Unique transaction identifier
  • โœ… Account keys - All accounts referenced by the transaction
  • โœ… Instructions - Complete instruction data and program calls
  • โœ… Recent blockhash - Transaction expiration reference
  • โœ… Signatures - All transaction signatures
  • โœ… Slot number - Which slot the transaction was observed in

Missing Data

  • โŒ Transaction metadata - Token balance changes, pre/post balances, transaction status
  • โŒ Transaction errors - We cannot determine if the transaction failed
  • โŒ Inner instructions - Cross-program invocations (CPIs) are not included
  • โŒ Log messages - Program logs are generated during execution
  • โŒ Compute units consumed - Execution metrics unavailable
Think of preprocessed transactions as receiving the โ€œproposalโ€ without the โ€œresult.โ€ You see what the sender tried to do, but not what actually happened.

Delivery guarantees

Delivery is best-effort, not guaranteed, and there is no historical replay. A streamed transaction is a pre-execution signal, not a commitment level โ€” it can fail, be dropped, or land on a different fork. Deduplicate by signature and reconcile against a processed or confirmed stream when execution results matter. For critical applications requiring guaranteed delivery and complete data, use LaserStream gRPC instead.

When to use preprocessed transactions

Latency-sensitive applications that want decoded, pre-execution transactions without operating a shred decoder:
  • propAMMs
  • Snipers
  • Copy traders
  • Liquidation bots
  • Arbitrage
If every microsecond matters and you can deshred at line rate, use raw shreds (UDP). If you need the earliest possible signal of all, use Preconfirmations.

Pricing

preprocessedSubscribe is available on all paid plans and metered at 0.1 credits per message โ€” one message per delivered transaction. The legacy gRPC delivery is available to Professional plan subscribers at 2 credits per 0.1 MB of uncompressed streamed data. See Credits for details.

Next steps

Subscribe with preprocessedSubscribe

Endpoint, account filtering, binary payload layout, and code examples.

Preconfirmations

Scheduled transactions streamed before they become shreds โ€” the earliest transaction signal.

Raw Shreds (UDP)

Unprocessed shred packets over UDP. You implement the deshredding.

Helius Sender

Act on what you see with the fastest transaction landing.