SHREDS · DECODED

Decoded transactions from Solana shreds.

First-seen, pre-confirmation transactions decoded straight from the propagation layer - the earliest possible view of the network, aggregated from multiple sources.

Get started →◢ Join the community

Read the Decoded Shreds docs →

◆ OVERVIEW

Shreds are the fragments validators propagate before a block is assembled. rpc edge reconstructs and decodes transactions straight from that propagation layer and streams them to you over gRPC - giving you a first-seen, pre-confirmation view well ahead of any confirmed RPC response.

We aggregate shreds from multiple independent sources and serve whichever copy arrives first, so you never wait on a single point of delay. The decoding happens server-side, co-located with the cluster, so you receive ready-to-use transactions, not raw bytes.

decoded-shreds.first-seen MULTI-SOURCE

// first-seen Δ distribution - illustrative figures

◆ CAPABILITIES

What it does.

First-seen, pre-confirmation

Read transactions while the block is still in flight - the earliest moment the network makes them observable.

Multi-source aggregation

Shreds aggregated from independent upstreams; you get whichever copy lands first, with built-in redundancy.

Decoded server-side

Reassembled, deserialized, and decoded against program layouts before they hit your stream - act immediately.

Delivered over gRPC

Filter by program and stream decoded transactions on the same fast path as Yellowstone gRPC.

first-seen.ts
// decoded transactions, straight from the propagation layer
const stream = await rpcedge.subscribe({
  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, reconcile on finality
}

◆ WHY rpc edge

Latency is a location problem.

01

Co-located by design

Our nodes are racked beside Solana stake clusters and the Jito Block Engine. Fewer hops, less distance, lower latency - physics, not promises.

02

Shreds from many sources

We aggregate shreds across multiple upstreams and serve whichever arrives first - so you never wait on a single point of delay.

03

Tuned for HFT

Every node is performance-optimized for high-frequency streaming - kernel, network stack, and RPC layer, end to end.

◆ USE CASES

  • Arbitrage and sniping where landing first is everything
  • MEV searchers needing the earliest signal
  • Liquidation bots reacting before confirmation

◆ RELATED

Frequently asked questions

Is pre-confirmation data safe to act on?
It's safe to react to, not to settle on. First-seen data can still be dropped or reorganized. Use it for speed, bound your exposure, and reconcile every action against a finalized commitment before treating it as money-good.
How is this different from Yellowstone gRPC?
gRPC surfaces data at the validator's processed commitment. Decoded shreds read one layer further upstream - at the propagation layer - so you see transactions before any block is assembled.

◆ GET ACCESS

Put Decoded Shreds on your strategy.

Start free, or talk to the infra team to scope a dedicated, co-located setup tuned to your latency and volume.

Get started →◢ Join the community

SHREDS · DECODED

  • First-seen, pre-confirmation
  • Multi-source aggregation
  • Decoded server-side
  • Delivered over gRPC