> ## 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. # Anleitung zur Verwendung von preprocessedSubscribe > Streamen Sie Solana-Transaktionen vor der Ausführung über WebSocket mit der Methode preprocessedSubscribe — abonnieren, nach Konto filtern und binäre Nutzlasten dekodieren. **Öffentliche Beta.** `preprocessedSubscribe` ist auf **allen kostenpflichtigen Plänen** verfügbar und wird mit **0,1 Credits pro Nachricht** berechnet (eine Nachricht pro ausgelieferter Transaktion). ## Was ist `preprocessedSubscribe`? `preprocessedSubscribe` ist eine Helius WebSocket-Methode, die vorverarbeitete Transaktionen streamt — Solana-Transaktionen vor der Ausführung geliefert **bevor sie das `processed`-Verpflichtungsniveau erreichen**. Helius aggregiert mehrere Quellen vor der Ausführung — hauptsächlich Shreds, die direkt dekodiert werden, sobald sie beim Validator eintreffen, ergänzt durch [Prekonfirmationssignale](/docs/de/pre-confirmations/overview) — und liefert sie als einen einzelnen deduplizierten Stream kompakter binärer Nachrichten, ohne dass auf Ihrer Seite eine Deshredding-Infrastruktur notwendig ist. Transaktionen, die aus Prekonfirmationssignalen stammen, kommen später in diesem Feed an als im dedizierten [Preconfirmations](/docs/de/pre-confirmations/overview) Produkt, das nach wie vor den frühesten Zugang zu ihnen bietet. Es ist der Nachfolger des früheren vorverarbeiteten LaserStream (gRPC) Produkts. Wenn Sie derzeit vorverarbeitete Transaktionen über gRPC konsumieren, wechseln Sie zu dieser Methode — sie liefert die gleiche Datenklasse über eine einfache WebSocket-Verbindung bei geringerer Latenz, und die gRPC-Lieferung wird eingestellt. | Stream | Relative Timing | Abdeckung | Daten | | --------------------------------------------------------------------------------- | ----------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | [Preconfirmations](/docs/de/pre-confirmations/overview) | Frühest | Transaktionen, die von teilnehmenden Validatoren geplant wurden | Transaktions- und Ausführungsstatus (nur Helius-Prekonfirmationen; BAM-Prekonfirmationen berichten unbekannt) | | `preprocessedSubscribe` | Typischerweise nach Preconfirmations, vor `processed` | Breite Solana-Transaktionsabdeckung | Unterzeichnete Transaktion vor der Ausführung | | [`transactionSubscribe`](/docs/de/rpc/websocket/transaction-subscribe) bei `processed` | Nach der Ausführung | Verarbeitete Transaktionen | Transaktion mit Ausführungsmetadaten | `preprocessedSubscribe` ist ein **Best-Effort, Signal vor der Ausführung**, kein Verpflichtungsniveau. Eine gestreamte Transaktion kann fehlschlagen, fallen gelassen oder auf einem anderen Fork landen. Vergleichen Sie mit einem verarbeiteten oder bestätigten Stream, bevor Sie sie als endgültig betrachten. ## Endpoint `preprocessedSubscribe` wird vom `wss://beta.helius-rpc.com` — dem Helius Gatekeeper-Endpoint — bereitgestellt, anstatt `mainnet.helius-rpc.com`. Authentifizieren Sie sich mit Ihrem API-Schlüssel als Abfrageparameter: ``` wss://beta.helius-rpc.com/?api-key= ``` Jeder API-Schlüssel ist auf **10 gleichzeitige Verbindungen/Abonnements** begrenzt. ## Abonnieren Senden Sie eine JSON-RPC-Anfrage mit der `preprocessedSubscribe`-Methode. `params` führt die Kontofilter und ist erforderlich — `accountInclude` und `accountRequired` müssen mindestens ein Konto zwischen sich angeben (siehe [Filterung](#filterung)): ```json theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "preprocessedSubscribe", "params": { "accountInclude": ["JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4"], "accountExclude": [], "accountRequired": [] } } ``` Der Server bestätigt das Abonnement mit einem JSON-Text-Frame, der die Abonnement-ID enthält: ```json theme={"system"} { "jsonrpc": "2.0", "result": 1, "id": 1 } ``` Nach dieser Bestätigung kommen Transaktionsaktualisierungen als **binäre** WebSocket-Frames an — siehe [Benachrichtigungsnutzlast](#benachrichtigungsnutzlast). ## Filterung Jedes Abonnement ist durch die Kontofilter in `params` begrenzt. Die Filterung erfolgt serverseitig, sodass Sie nur die Transaktionen erhalten, die Sie interessieren: ```json theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "preprocessedSubscribe", "params": { "accountInclude": ["JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4"], "accountExclude": ["Vote111111111111111111111111111111111111111"], "accountRequired": [] } } ``` | Filter | Übereinstimmungsverhalten | | ----------------- | ---------------------------------------------------------------------------------------- | | `accountInclude` | Übereinstimmung, wenn die Transaktion **eines** der aufgelisteten Konten referenziert. | | `accountExclude` | Verwerfen Sie die Transaktion, wenn sie **eines** der aufgelisteten Konten referenziert. | | `accountRequired` | Übereinstimmen nur, wenn die Transaktion **alle** aufgelisteten Konten referenziert. | Filterregeln: * Die drei Filter werden mit UND-Logik kombiniert. * `accountInclude` und `accountRequired` müssen **mindestens ein Konto** zwischen sich angeben — es gibt keinen ungefilterten vollständigen Stream. * Konten sind base58-codierte Pubkeys. Jede Liste akzeptiert bis zu **5.000** Adressen. ### Auflösung der Address Lookup Table (ALT) Kontofilter stimmen mit mehr als den statischen Kontoschlüsseln der Transaktion überein — Helius löst [Address Lookup Tables](/docs/de/glossary#address-lookup-table-alt) serverseitig auf, sodass `accountInclude`, `accountExclude` und `accountRequired` auch Konten übereinstimmen, die eine Transaktion über eine ALT lädt. Geben Sie einfach den Pubkey des Kontos an; es ist nicht notwendig, ALT-Zuordnungen zu pflegen oder Tabellen selbst aufzulösen. ## Benachrichtigungsnutzlast Benachrichtigungen werden als **binäre** WebSocket-Frames (nicht JSON) geliefert. Jeder Frame enthält eine einzelne Transaktion in einem kompakten Byte-Layout: | Bytes | Feld | Typ | Beschreibung | | ----- | ------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------ | | 0 | `version` | `u8` | Nutzlast-Schemaversion. Derzeit `1`. | | 1–8 | `slot` | `u64` (little-endian) | Der Slot, in dem die Transaktion beobachtet wurde. | | 9–72 | `signature` | 64 Bytes | Die erste Signatur der Transaktion in binärer Form. | | 73+ | `transaction` | `bytes` | Die unterzeichnete Transaktion im Solana-Wire-Format. Siehe [Dekodierung der Transaktion](#dekodierung-der-transaktion). | Lesen Sie das feste Präfix von 73 Byte in der Reihenfolge und dekodieren Sie dann die restlichen Bytes, um Anweisungen, Konten und Address-Table-Lookups zu lesen. Die Signatur ist im Präfix enthalten, damit Sie eine Transaktion identifizieren und deduplizieren können, ohne den vollständigen Transaktionskörper zu dekodieren. Lesen und überprüfen Sie immer zuerst das `version`-Byte. Wenn Helius das Nutzlastformat aktualisieren muss, wird die Version inkrementiert — verzweigen Sie darauf, damit Ihr Decoder bei Schemaänderungen weiterhin funktioniert. ### Dekodierung der Transaktion Die Transaktionsbytes werden genau so weitergeleitet, wie sie im Netzwerk beobachtet wurden, in der Standard-Wire-Codierung für die Version der Transaktion. Legacy- und v0-Transaktionen verwenden das signaturerste Layout, das `bincode` erzeugt. Die Transaktion v1 ([SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md)) verwendet ein Nachrichten-erste-Layout mit den Signaturen am Ende, sodass `bincode` bei v1-Nutzlasten fehlschlägt. Verwenden Sie einen Decoder, der jede Version handhabt: * **Rust:** [`agave-transaction-view`](https://docs.rs/agave-transaction-view) analysiert Legacy-, v0- und v1-Transaktionen an Ort und Stelle, ohne eine Zwischenkopie. Dies ist die empfohlene Option. [`wincode`](https://docs.rs/wincode), der mit Bincode kompatible Serializer, der von aktuellen Solana-SDKs verwendet wird, dekodiert auch v1 in `VersionedTransaction`. * **JavaScript / TypeScript:** Stellen Sie sicher, dass Ihre Bibliotheksversion die Transaktion v1 unterstützt. Ältere `VersionedTransaction.deserialize`-Implementierungen behandeln nur Legacy und v0. Verwenden Sie `@solana/kit` 8.0+ oder `@solana/web3.js` v3. Siehe [Transaktion v1 Unterstützung](/docs/de/rpc/transaction-v1). ```rust theme={"system"} use agave_transaction_view::transaction_view::TransactionView; // `frame` is the full binary WebSocket message let tx_bytes = &frame[73..]; let tx = TransactionView::try_new_unsanitized(tx_bytes)?; println!("version: {:?}", tx.version()); // Legacy, V0, or V1 for ix in tx.instructions_iter() { println!("program index {}: {} bytes", ix.program_id_index, ix.data.len()); } ``` ## Beispiel ```javascript theme={"system"} const WebSocket = require('ws'); const bs58module = require('bs58'); const bs58 = bs58module.default ?? bs58module; const ws = new WebSocket('wss://beta.helius-rpc.com/?api-key='); ws.on('open', () => { ws.send(JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'preprocessedSubscribe', // Only Jupiter v6 transactions — accountInclude/accountRequired must // specify at least one account between them. params: { accountInclude: ['JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4'], accountExclude: [], accountRequired: [] } })); // Keep the connection alive setInterval(() => ws.ping(), 30_000); }); ws.on('message', (data, isBinary) => { // The subscribe acknowledgement arrives as a JSON text frame if (!isBinary) { const msg = JSON.parse(data.toString()); if (msg.id === 1) console.log('Subscribed, ID:', msg.result); return; } // Notifications arrive as binary frames: // version (u8) | slot (u64 LE) | signature ([u8; 64]) | transaction bytes const buf = Buffer.from(data); const version = buf.readUInt8(0); // currently 1 — branch on this if it changes if (version !== 1) return; // unknown schema version; update your decoder const slot = buf.readBigUInt64LE(1); const signature = bs58.encode(buf.subarray(9, 73)); const txBytes = buf.subarray(73); // transaction in Solana wire format (legacy, v0, or v1) console.log('Preprocessed transaction:', { slot, signature, bytes: txBytes.length }); // Decode txBytes with a decoder that supports transaction v1 (see "Decoding the transaction") }); ws.on('error', console.error); ws.on('close', () => process.exit(1)); ``` ## Welche Daten sind verfügbar? Jede Benachrichtigung enthält die unterzeichnete Transaktion, ihre erste Signatur und ihren Slot. Da die Lieferung vor der Ausführung erfolgt, enthält der Stream **nicht**: * Ausführungsstatus oder Fehler * Vor-/Nach-Salden oder Token-Saldenänderungen * Log-Nachrichten oder innere Anweisungen * Verbrauchte Computereinheiten Betrachten Sie es als den Erhalt des "Vorschlags" ohne das "Ergebnis" — Sie sehen, was der Absender versucht hat zu tun, aber nicht, was tatsächlich passiert ist. Konto- und Programmstatusaktualisierungen existieren in diesem Stadium ebenfalls noch nicht; wenn Sie Echtzeit-Kontostatus benötigen, verwenden Sie [LaserStream gRPC](/docs/de/laserstream) bei `processed`-Verpflichtung. ## Rückstau Der Stream puffert nicht unbegrenzt für langsame Konsumenten. Wenn Ihr Client zu langsam liest und mehr als **4.000 Nachrichten** serverseitig aufstauen, schließt Helius die Verbindung — Sie erhalten einen sauberen WebSocket-Schluss-Frame. Entleeren Sie Frames schneller, als sie ankommen: halten Sie schwere Arbeiten wie Transaktionsdekodierung und Strategie-Logik von der Empfängerschleife fern und stellen Sie nach einer Trennung die Verbindung erneut her und abonnieren Sie neu. ## Liefergarantien Die Lieferung ist best-effort und nicht garantiert, und es gibt keinen historischen Replay. Clients sollten: 1. Nach dem Schließen einer Verbindung erneut verbinden und abonnieren. 2. Nach Transaktionssignatur deduplizieren. 3. Behandeln Sie den Slot als Beobachtung, nicht als Finalität. 4. Vergleichen Sie mit einem verarbeiteten oder bestätigten Stream, wenn Ausführungsergebnisse wichtig sind. ## Preisgestaltung `preprocessedSubscribe` ist auf **allen kostenpflichtigen Plänen** verfügbar und wird mit **0,1 Credits pro Nachricht** berechnet — eine Nachricht pro ausgelieferter Transaktion, die von Ihrem Plan abgerechnet wird. Siehe [Credits](/docs/de/billing/credits) für Details. ## Verwandte Themen Transaktionen, die gestreamt werden, bevor sie zu Shreds werden — das früheste Transaktionssignal. Unverarbeitete Shred-Pakete über UDP. Sie implementieren das Deshredding. Post-Ausführungs-Transaktionen mit umfangreicher Filterung und Ausführungsmetadaten.