A trading bot needs to know what it has observed before it decides how to act. A BAM preconfirmation, a shred and a decoded transaction can describe related activity, but they arrive at different points in Solana’s pipeline and carry different guarantees.
The quick answer
BAM preconfirmations report a participating leader’s commitment to execute a scheduled batch. They can arrive before shreds, but they cover only participating leader slots and are not finality. Raw shreds expose propagated block data to teams that can reconstruct it. Decoded transactions remove that reconstruction work and deliver signed transactions, still before the canonical execution outcome is known.
These are different observation points, not interchangeable names for a guaranteed trade.
Where each signal appears
According to Jito’s explanation, a BAM Node schedules a transaction batch and sends it to the BAM-enabled leader. Once that leader commits to executing the batch, the BAM Node can distribute a preconfirmation. The transactions are then shredded and propagated through the network.
A preconfirmation is therefore an earlier view of committed, scheduled transactions from a participating leader. It is not a view into every private transaction being considered by every validator. The leader can still skip its slot or build a block that lands on a fork.
Shreds sit later in this path. They carry propagated block data. A consumer needs to receive enough packets, recover entries and decode transactions before using them in a strategy. Shredo Raw Shreds delivers deduplicated shred packets over UDP to one configured destination; UDP transport does not promise retransmission or perfect continuity.
Shredo Decoded Transactions performs that reconstruction and serves authenticated signed transaction events over TLS gRPC, with program and account filters. The event tells you what transaction was observed, not whether its instructions executed successfully or what final balances became.
BAM preconfirmations vs raw shreds vs decoded transactions
| Signal | What a bot receives | Important limit |
|---|---|---|
| BAM preconfirmation | A participating leader’s commitment to a scheduled batch | Participating leader slots only; no landing or finality guarantee |
| Raw Shreds | Propagated shred packets for your own reconstruction pipeline | Packet loss and reconstruction are your responsibility |
| Decoded Transactions | Reconstructed signed transactions and observation metadata | Execution outcome must be checked separately |
Coverage and latency are separate questions
Jito reported that BAM preconfirmations covered validators representing more than 34% of network stake at its September 2026 launch. That number is a launch snapshot, not a promise of present-day coverage. Ask a provider which leaders and slots its feed currently covers. Jito’s launch announcement.
Jito also reported an early-test median head start of roughly 5–10 ms over its distribution partners’ existing shred streams. This is Jito’s reported comparison, not a benchmark against Shredo. A bot’s useful lead time depends on its location, filters, decoding work, decision path and submission route.
For a strategy, record both when the signal arrived and which leader or slot it described. A fast signal for a limited subset of slots and a broader public feed answer different needs.
Where can you get preconfirmations?
Jito named Helius and Triton as its BAM preconfirmation distribution partners at launch. The BAM documentation points subscribers to those providers for access and pricing.
Our partner Blokok also offers access to Solana preconfirmation feeds with a connected transaction-submission route. Your system evaluates the signal and signs its response; Blokok forwards the signed transaction or bundle according to the applicable route. Ask Blokok which preconfirmation source, leader coverage, current availability and commercial terms apply to your integration.
Availability deserves a fresh check. Jito announced temporary BAM maintenance around the Alpenglow transition and a gradual return afterward. Confirm the current state with the feed provider before building a strategy that depends on BAM-specific signals.
Build around uncertainty, not just speed
Keep provisional observations separate from landed outcomes. Deduplicate by transaction signature and the source’s event identity, retain slot and receipt timestamps, detect stream gaps, and reconcile against executed transactions and account state. If the feed disconnects, the interval is unknown; it does not mean no transaction occurred.
For example, a bot might use a preconfirmation to start evaluating an opportunity, observe the subsequent shreds or decoded transaction, and then check the execution result before recording a trade as landed. A fast observation can trigger work. Verified state supports the conclusion.
Which feed should a Solana bot choose?
If you run your own shred parser, start with Raw Shreds. If you want filtered signed transaction events without operating reconstruction, use Decoded Transactions. If your strategy benefits from a participating leader’s earlier commitment and you have an eligible route, evaluate a preconfirmation feed too.
The right setup may use more than one feed. What matters is that the bot knows which part of the network each feed covers and never mistakes an early signal for a completed execution.
Explore Shredo data products → Discuss preconfirmation access with Blokok →