TriportRPC

Pre-execution transaction stream (deshred)

Last updated:

How it works

A Solana leader slices its block into shreds and broadcasts them to the cluster while still building the block. Triport ingests that shred flow, reassembles (deshreds) complete transactions as soon as enough shreds arrive, and pushes each one to your WebSocket session as JSON — signature, accounts, instructions and raw message — without waiting for execution, vote confirmation or RPC visibility. For latency-sensitive order-flow analysis this is the earliest transaction-level view of the chain that exists outside of running your own shred pipeline.

Connect

websocat "wss://triport.io/ws/sol-preexec?api-key=<api-key>"
# subscribe frame (Pro: account_include required)
{"account_include": ["<pubkey>", "..."]}

Use cases

  • Seeing swaps and liquidity events on tracked programs before execution results propagate.
  • Latency benchmarking: measuring the gap between shred arrival and confirmed status.
  • Feeding trading systems that need transaction intent ahead of standard streams.

FAQ

How is this different from a mempool stream?
Solana has no public mempool — transactions go to the current leader. The pre-execution stream reconstructs transactions from the shreds the leader broadcasts, so you observe them after the leader sequenced them but before execution results are available anywhere over RPC.
How much earlier is it than logsSubscribe or a gRPC transaction stream?
Standard streams emit after a transaction executes at processed commitment. The pre-execution feed emits as soon as the transaction can be reassembled from shreds — typically a slot-fraction earlier, before execution status exists.
Can I filter the stream?
Yes — on Pro the stream is filtered by the accounts you list (account_include). Business unlocks the unfiltered firehose of every deshredded transaction. Note: an empty filter list on the filtered tier is rejected rather than silently streaming everything.