> ## 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. # Preprocessed Transactions: Pre-Execution Solana Data Without Deshredding > Stream pre-execution Solana transactions before they reach processed commitment. Helius handles the shred decoding — you receive signed transactions over WebSocket. ## 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](/docs/pre-confirmations/overview)) 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](/docs/pre-confirmations/overview) product, which remains the earliest access to them. The primary way to consume preprocessed transactions is the [`preprocessedSubscribe` WebSocket method](/docs/preprocessed-transactions/preprocessed-subscribe) (Public Beta) — available on **all paid plans** at **0.1 credits per message**. The earlier [gRPC delivery](/docs/preprocessed-transactions/grpc) will be deprecated in its favor. The recommended way to stream preprocessed transactions: account filtering, compact binary payloads, all paid plans. 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)](/docs/shred-delivery/raw-shreds)** 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](/docs/laserstream)** and **[LaserStream WebSocket](/docs/rpc/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](/docs/pre-confirmations/overview) 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](/docs/laserstream) 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](/docs/laserstream) 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)](/docs/shred-delivery/raw-shreds). If you need the earliest possible signal of all, use [Preconfirmations](/docs/pre-confirmations/overview). ## Pricing [`preprocessedSubscribe`](/docs/preprocessed-transactions/preprocessed-subscribe) is available on **all paid plans** and metered at **0.1 credits per message** — one message per delivered transaction. The legacy [gRPC delivery](/docs/preprocessed-transactions/grpc) is available to Professional plan subscribers at 2 credits per 0.1 MB of uncompressed streamed data. See [Credits](/docs/billing/credits) for details. ## Next steps Endpoint, account filtering, binary payload layout, and code examples. Scheduled transactions streamed before they become shreds — the earliest transaction signal. Unprocessed shred packets over UDP. You implement the deshredding. Act on what you see with the fastest transaction landing.