The commitment ladder

Every read of Solana sits somewhere on a ladder of certainty. The higher you climb, the more sure you are - and the longer you waited.

LevelWhat it meansCertaintyLatency
First-seen (shreds)Transaction observed propagating, pre-blockLowestEarliest
processedA validator executed it (possibly on a minority fork)LowVery low
confirmedA supermajority voted for its blockHighHigher
finalizedRooted, irreversible (~31+ confirmations)HighestHighest

Most applications read at confirmed or finalized because they want certainty. Searchers and market makers often want the opposite end: the earliest possible glimpse, accepting that it's provisional. The skill is knowing which rung a given decision belongs on.

Certainty and speed sit at opposite ends of the same ladder. The art isn't picking one - it's using the earliest rung for signal and the highest rung for settlement.

What "first-seen from shreds" actually is

When a leader produces a block, it doesn't broadcast the block whole - it splits it into shreds, small erasure-coded packets that propagate across the cluster through Turbine. Decode the data shreds for a slot and you can reconstruct the entries, and from the entries, the individual transactions - while the block is still in flight. (The mechanics are in What Are Solana Shreds?.)

That means you can see a transaction before any validator has finished assembling its block, and well before your RPC node would surface it at confirmed. You're reading the network's intent at the moment it's expressed, not after it's been ratified.

first-seen.ts
// decoded transactions, straight from the propagation layer
const stream = await rpcedge.subscribe({
  endpoint: "grpc://iad1.rpcedge.com:443",
  source: "shreds",
  decode: true,
  filter: { programs: [RAYDIUM, PUMP_FUN] },
});
 
for await (const tx of stream) {
  // tx is decoded, first-seen, pre-confirmation
  signal.evaluate(tx); // react now - but don't settle yet
}

Where pre-confirmation state bites

The whole value of first-seen is that it's early. The whole risk is that it's provisional. Three ways it can turn on you:

  • Forks. The slot you saw can land on a fork that loses the vote. Solana resolves forks quickly, but "quickly" is not "instantly," and a transaction on the losing fork never happened.
  • Skipped slots. A leader can fail to produce, or its block can be skipped. Shreds you began reassembling may never complete into a finalized block.
  • Ordering and inclusion. Seeing a transaction propagate doesn't guarantee its final position, or that a competing transaction won't reorder the outcome you were counting on.

None of these make first-seen useless. They make it conditional. Treat a pre-confirmation transaction as a high-quality prediction, not a settled fact.

Using it safely

The teams that win with pre-confirmation data don't pretend the risk away - they engineer around it. A few non-negotiables:

  • Separate signal from settlement. Let first-seen drive your decision to act; let a finalized read drive your accounting. Never book a position as real on shred data alone.
  • Reconcile against finality. Every action you take on first-seen should have a follow-up that confirms the transaction finalized - and an explicit path for when it didn't (unwind, hedge, cancel).
  • Bound the exposure. Size first-seen-driven actions so a reorg or drop is survivable. The head start is an edge, not a license to bet the book on provisional state.
  • Make it idempotent. If you re-see the same transaction (or a corrected version after de-shredding fills in gaps), your pipeline should converge, not double-act.

Who should read this early

First-seen earns its keep when milliseconds change the outcome and you can tolerate provisional input: arbitrage and sniping, MEV searching, liquidations, and copy-trading where landing first is the entire game. It's the wrong tool for accounting, settlement, user balances, or anything where correctness must beat speed - those belong at confirmed or finalized.

In practice the strongest pipelines layer all three commitment regimes: shreds for first-seen signal, gRPC for live state, and RPC for confirmed truth - each doing the job it's actually good at.

Want first-seen decoded transactions?

rpc edge decodes shreds co-located with the cluster and streams them over gRPC - the earliest view, reconciled against finality on your terms.

View plans & pricing →

The takeaway

Pre-confirmation state is the fastest read of Solana there is - and the least certain. That tension isn't a flaw to fix; it's the trade you're choosing. React on first-seen, settle on finality, and keep the exposure in between small enough to survive a reorg. Do that, and the head start is pure edge instead of hidden risk.

Frequently asked questions

What does "first-seen" mean on Solana?
First-seen is the earliest moment you can observe a transaction - while its block is still propagating across the cluster as shreds, before any validator has rolled it into a confirmed block. It's upstream of the processed, confirmed, and finalized commitments.
Is pre-confirmation data safe to trade on?
It's safe to react to, not to settle on. A pre-confirmation transaction can still be dropped or land in a fork that never finalizes. Use it for signal and speed, but bound your exposure and reconcile every action against a finalized commitment before you treat it as money-good.
What's the difference between processed, confirmed, and finalized?
Processed means a validator has executed it (may be on a minority fork). Confirmed means a supermajority has voted for its block. Finalized means it's rooted and irreversible (~31+ confirmations). First-seen-from-shreds sits even earlier than processed.
How do you decode a transaction from shreds?
Ingest the data shreds for a slot, reassemble them into entries (de-shredding), deserialize the entries into transactions, then decode each transaction against the relevant program layouts. rpc edge does this server-side and streams the decoded result over gRPC.
Can a transaction I saw in shreds disappear?
Yes. If the slot lands on a fork that loses out, or the leader's block is skipped, a transaction you saw propagating may never finalize. This is the core risk of pre-confirmation data and why reconciliation against finality is mandatory.