> ## Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Parsed Streams

> Subscribe to decoded Solana transactions over WebSocket with server-side filtering by program, account, and instruction name.

<Note>
  Parsed Streams is in **closed beta**. Access is limited to whitelisted project ids for now, and the API may change before general availability. To join the closed beta, [apply here](https://form.typeform.com/to/BlFWKbC9).
</Note>

## What is Parsed Streams?

Parsed Streams is a WebSocket service that watches every confirmed Solana transaction (vote transactions excluded), decodes it, and pushes you the transactions that match a filter you define. You say "I care about Jupiter route instructions" or "I care about anything touching this account", and the server does the watching, decoding, and matching for you.

You receive **whole transactions, already decoded**: every instruction with named arguments and named accounts, plus the fee, the full account key list, a transaction-level `summary` of what happened, the SOL and token transfers, and pointers to the exact instructions that matched your filter. All data is delivered at **confirmed** commitment.

## The mental model

If you already know Solana internals, skip ahead. If not, this is the model the whole API is built on.

**A transaction** is a signed message. It names a fee payer, lists every account it will touch, and carries a list of instructions. When you look at one you see: a signature (its unique id), the slot it landed in, the fee paid, the account keys, whether it succeeded or failed, and the instructions.

**An instruction** is one action: run this program, with this input, using these accounts. A swap on Jupiter, a token transfer, a memo. A transaction usually carries several instructions, and they run in order.

**Programs can call other programs.** When Jupiter executes a swap, it does not move the tokens itself. Its route instruction calls the token program to move tokens and the exchange programs that hold the liquidity. Those nested calls are instructions too, called inner instructions (or CPIs, cross program invocations). This matters when you write a filter: much of the real activity, like the actual token movements inside a swap, happens in inner instructions, so your filter matches them by default. If you only want the instructions a user signed for, set `includeCpi` to false.

**Accounts** are the on-chain things an instruction works with: wallets, token balances, pools, mints. Each instruction carries them as an ordered list of addresses, and the order is the contract: the program defines what each position means. The token program, for example, expects the account to take tokens from first, then the account to receive them, then the owner approving the transfer.

**Roles** give those positions names. Most well known programs publish a machine readable manual for their interface, called an IDL. The manual lists every instruction the program has, what its data fields mean, and what each account position is for. Helius keeps a catalog of these manuals for thousands of programs. Using it, a bare address list turns into named accounts: for a token transfer, position 0 becomes `source`, position 1 becomes `destination`, position 2 becomes `authority`. Instead of guessing what the third address means, you read `{"name": "authority", "pubkey": "9xQe...", "isSigner": true}`. These names are the roles you can filter on.

**Decoding** is the same idea applied to the instruction's input data. On the wire that data is opaque bytes. With the program's manual, the bytes become named values: `{"in_amount": "1000000", "slippage_bps": 50}`. Not every instruction can be decoded, so each one lands in one of three states you can see directly from its fields:

* **Decoded**: the instruction carries a `decoded` object with named `args` and named `accounts`.
* **Recognized**: on top of `decoded`, the instruction carries a `summary` with a `type` (such as `swap`), a human-readable `description`, and a structured `parsedData` payload, such as swap metadata with amounts and mints.
* **Undecoded**: the program or instruction is not in the catalog, `decoded` is `null`, and the instruction carries the raw bytes (`rawData`) and the plain address list (`rawAccounts`) instead, so you always have something to work with.

That is the whole model, and your filter is built directly from it:

* `programs`: which program the instruction calls
* `instructionNames`: what the program's manual calls that action
* `accounts.include`: which addresses it touches
* `accounts.roles`: which named position must hold which address
* `includeCpi` and `includeFailed`: whether inner instructions and failed transactions count

**Filters select instructions; notifications deliver the whole transaction.**

### How it compares

<CardGroup cols={2}>
  <Card title="vs Enhanced WebSockets" icon="bolt">
    [Enhanced WebSockets](/docs/rpc/websocket) stream whole transactions or account updates without decoding. Parsed Streams matches at the instruction level and decodes everything for you.
  </Card>

  <Card title="vs LaserStream gRPC" icon="server">
    [LaserStream](/docs/laserstream) is a high-throughput gRPC firehose that you filter and decode on the client. Parsed Streams is a WebSocket API that filters and decodes on the server.
  </Card>

  <Card title="vs Parsed Events" icon="clock-rotate-left">
    [Parsed Events](/docs/parsed-events) applies the same decoding to historical transactions: parse signatures or page through an address's history on demand over REST and GraphQL. Parsed Streams pushes new transactions as they land.
  </Card>
</CardGroup>

## Supported programs

Parsed Streams decodes **3,600+ programs** from their on-chain IDLs, plus core programs like SPL Token, Token-2022, and the System Program through built in decoders. You can filter by *any* program address. Instructions the service cannot decode stream as raw instruction data instead.

A few of the most-used decoded programs:

<AccordionGroup>
  <Accordion title="DEXs & AMMs" icon="arrow-right-arrow-left">
    | Program               | Address                                        |
    | --------------------- | ---------------------------------------------- |
    | Jupiter Aggregator v6 | `JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4`  |
    | Raydium CLMM          | `CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK` |
    | Raydium CPMM          | `CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C` |
    | Orca Whirlpool        | `whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc`  |
    | Meteora DLMM          | `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`  |
    | Meteora Pools         | `Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB` |
    | Lifinity v2           | `2wT8Yq49kHgDzXuPxZSaeLaH1qbmGXtEyPy64bL7aD3c` |
  </Accordion>

  <Accordion title="Launchpads" icon="rocket">
    | Program  | Address                                       |
    | -------- | --------------------------------------------- |
    | Pump.fun | `6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P` |
    | PumpSwap | `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA` |
  </Accordion>

  <Accordion title="Lending & Perps" icon="building-columns">
    | Program        | Address                                       |
    | -------------- | --------------------------------------------- |
    | marginfi v2    | `MFv2hWf31Z9kbCa1snEPYctwafyhdvnV7FZnsebVacA` |
    | Kamino Lending | `KLend2g3cP87fffoy8q1mQqGKjrxjC8boSyAYavgmjD` |
  </Accordion>

  <Accordion title="NFTs & Compression" icon="image">
    | Program                   | Address                                        |
    | ------------------------- | ---------------------------------------------- |
    | Metaplex Bubblegum (cNFT) | `BGUMAp9Gq7iTEuizy4pqaxsTyUCBK68MDfK752saRPUY` |
  </Accordion>
</AccordionGroup>

<Tip>
  Don't see a program? It's likely still in the catalog. Call [`describeProgram`](/docs/parsed-streams/quickstart#discovery) with its address to see its instructions, events, and account roles.
</Tip>

## Access

Only whitelisted project ids can connect during the closed beta. The Helius team shares the connection endpoint with you when your project is whitelisted.

Authenticate with your project's API key, passed as the `api-key` query parameter (or the `x-api-key` header). The key is checked when the connection opens: a missing, invalid, or non-whitelisted key is rejected with HTTP 401, and a project at its connection cap gets HTTP 429.

## Get Started

<CardGroup cols={2}>
  <Card title="Quickstart" icon="bolt" href="/docs/parsed-streams/quickstart">
    Connect, send your first filter, and read a notification.
  </Card>

  <Card title="Track Jupiter Swaps" icon="arrow-right-arrow-left" href="/docs/parsed-streams/guides/track-jupiter-swaps">
    Build and subscribe a real filter using program discovery.
  </Card>

  <Card title="Track Pump.fun Mints" icon="rocket" href="/docs/parsed-streams/guides/track-pumpfun-mints">
    A reconnect-safe listener that logs every new Pump.fun token deploy.
  </Card>

  <Card title="Handling Reconnects" icon="rotate" href="/docs/parsed-streams/guides/handling-reconnects">
    Detect disconnects, back off, resubscribe, and backfill missed slots.
  </Card>
</CardGroup>