> For the complete documentation index, see [llms.txt](https://raiden-4.gitbook.io/raiden.wtf.docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://raiden-4.gitbook.io/raiden.wtf.docs/shred-streaming-decoded-pulse/overview.md).

# Overview

Binary decoded Solana shreds via gRPC — pre-confirmation transactions with microsecond overhead

> **⚡** Decoded transactions. Delivered via gRPC. Microsecond overhead. No client-side decoding.

Raiden Pulse runs the full shred decoding pipeline server-side and streams you **binary-encoded decoded transactions** over gRPC. You skip FEC reassembly, borsh deserialization, and Merkle verification entirely — the client receives ready-to-use transactions before blocks confirm on-chain.

## Pulse vs Surge

|                          | **Raiden Surge**              | **Raiden Pulse**            |
| ------------------------ | ----------------------------- | --------------------------- |
| **Data format**          | Raw shred bytes               | Binary decoded transactions |
| **Delivery**             | UDP + TCP                     | gRPC streaming              |
| **Client-side decoding** | Required                      | Not required                |
| **FEC reassembly**       | Self-managed                  | Handled server-side         |
| **Best for**             | Infra teams, custom pipelines | Bots, arb engines, indexers |
| **Decode overhead**      | N/A (raw)                     | Microsecond-level           |

## How It Works

1. Choose region(s) — FRA, NYC, or AMS
2. Client connects via gRPC stream
3. Decoded transactions arrive **before block confirmation**

## Available Regions

| Region  | Location               | Status |
| ------- | ---------------------- | ------ |
| **FRA** | Frankfurt, Germany     | Live   |
| **NYC** | New York, USA          | Live   |
| **AMS** | Amsterdam, Netherlands | Live   |

## Limits

Included at every plan duration:

| Limit                      | Value                  |
| -------------------------- | ---------------------- |
| **Concurrent connections** | 10                     |
| **Named filters**          | 35 per connection      |
| **Account filters**        | 5,000 per named filter |

Filtering happens server-side, so a filter that excludes traffic also saves you the bandwidth.

## Pulse V2

Pulse V2 moves off the third-party `shreder_binary` proto onto Raiden's own, `raiden_binary`, and adds the change worth caring about: **address lookup tables are resolved server-side**.

A V0 transaction names most of its accounts through a lookup table, so knowing what it actually touches means resolving those tables yourself. In V2 that resolution ships with the transaction, and a client can see the full account set without maintaining its own ALT map.

Both protos are served during the transition. See [Getting Started](/raiden.wtf.docs/shred-streaming-decoded-pulse/getting-started.md#8-pulse-v2-raiden_binary-proto-and-resolved-alts).

## Use Cases

**Sniper bots** — detect token launches and liquidity adds the instant shreds land, before blocks confirm.

**Arbitrage engines** — spot pool price divergence pre-confirmation; execute counter-orders while the window is still open.

**Real-time indexers** — stream pre-parsed transactions directly into your analytics or database pipeline without running a decoder.

**MEV searchers** — mempool-grade visibility without running a validator.