> ## 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. # Wie man preconfSubscribe verwendet > Streamen Sie Solana-Transaktionen mit der geringstmöglichen Latenz über die preconfSubscribe WebSocket-Methode — abonnieren, filtern und dekodieren Sie die Nutzlast. **Verwenden Sie [Sender Max](/docs/de/sending-transactions/sender-max) (minimales Trinkgeld: 0.001 SOL), um auf Preconfirmations zu reagieren.** Eine Vorbestätigung zahlt sich nur aus, wenn Sie Ihre Transaktion zuerst platzieren — Sender Max ist der schnellste Weg, dies zu tun. Bauen Sie von Anfang an auf Sender Max, um den vollen Nutzen aus Preconfirmations zu ziehen. ## Was ist `preconfSubscribe`? `preconfSubscribe` ist eine Helius WebSocket-Methode, die [Preconfirmations](/docs/de/pre-confirmations/overview) streamt — Transaktionen, die geliefert werden, bevor sie in Einträge gesammelt und zerstückelt werden. Es ist das Transaktionssignal mit der geringsten Latenz, das Helius anbietet. Ein Abonnement liefert sowohl Helius-Vorbestätigungen, die sofort nach der Ausführung der Transaktion durch den Leader ausgegeben werden und den Ausführungsstatus tragen, als auch [BAM-Vorbestätigungen](/docs/de/pre-confirmations/overview#bam-vorbestätigungen) von Validatoren, die Jitos Block Assembly Marketplace-Client ausführen, und die ausgegeben werden, wenn der Validator sich zur Ausführung der Transaktion verpflichtet. Der Zugang erfordert einen [Professional-Plan oder höher](/docs/de/billing/plans) — siehe [Preise](#preise). Der Stream ist nicht kontinuierlich. Die Abdeckung skaliert mit dem Anteil der Staking-Weiterleitungen an Helius oder BAM, daher erwarten Sie Slots ohne Nachrichten — behandeln Sie diese Lücken großzügig. Siehe [Abdeckung](/docs/de/pre-confirmations/overview#abdeckung). `preconfSubscribe` wird von `wss://beta.helius-rpc.com` — dem Helius [Gatekeeper](/docs/de/gatekeeper/overview) Endpoint — anstatt von `mainnet.helius-rpc.com` bedient. Authentifizieren Sie sich mit Ihrem API-Schlüssel als Query-Parameter. ``` wss://beta.helius-rpc.com/?api-key= ``` Der `beta` Hostname bezieht sich auf das [Gatekeeper](/docs/de/gatekeeper/overview) Rollout, nicht auf die Reife der Vorbestätigungen. Vorbestätigungen starten zuerst auf dem Gatekeeper-Endpunkt; er wird der Standardendpunkt, wenn Helius den Verkehr zu Gatekeeper migriert. ## Abonnieren Senden Sie eine JSON-RPC-Anfrage mit der Methode `preconfSubscribe`. Der Server antwortet mit einer Abonnement-ID und streamt dann eine Benachrichtigung für jede Transaktion. Übergeben Sie einen optionalen [Filter](#filtern) als erstes `params` Element, um nur passende Transaktionen zu erhalten; lassen Sie `params` weg, um den vollständigen Stream von Helius und BAM zu erhalten. ```json theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "preconfSubscribe" } ``` ### Antwort auf Abonnieren ```json theme={"system"} { "jsonrpc": "2.0", "result": 24040, "id": 1 } ``` Speichern Sie die `result` — es ist die Abonnement-ID, die Sie zum [Kündigen](#abbestellen) verwenden. Nach dieser Bestätigung werden Benachrichtigungen als Binärrahmen gestreamt (siehe unten). ## Filtern Standardmäßig streamt `preconfSubscribe` jede Transaktion aus beiden Quellen. Um den Stream einzugrenzen, übergeben Sie ein Filterobjekt als erstes Element von `params`. Das Filtern erfolgt serverseitig, sodass Sie nur für die Transaktionen zahlen und diese erhalten, die für Sie von Interesse sind. ```json theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "preconfSubscribe", "params": [ { "includeBam": true, "failed": false, "regionInclude": ["ewr", "fra"], "accountInclude": ["9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM"], "accountExclude": ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"], "accountRequired": ["11111111111111111111111111111111"] } ] } ``` Jedes Feld ist optional — ein fehlendes Feld bedeutet "keine Einschränkung" für dieses Prädikat, sodass ein leerer Filter (oder kein `params`) jede Transaktion aus beiden Quellen übereinstimmt. | Feld | Typ | Semantik | | ----------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `includeBam` | `boolean` | Standardmäßig `true`. `false` lässt BAM-Vorbestätigungen weg, sodass Sie nur Helius-Vorbestätigungen erhalten. | | `failed` | `boolean` | Statusfiltern wird nur für Helius-Vorbestätigungen unterstützt und wird bei BAM-Vorbestätigungen ignoriert. Für Helius gibt `true` nur fehlgeschlagene (zurückgewiesene) Transaktionen zurück; `false` gibt nur erfolgreiche Transaktionen zurück. Beide Werte schließen Helius-Transaktionen mit unbekanntem Status aus. Lassen Sie das Feld weg, um alle Status zu erhalten. | | `regionInclude` | `string[]` | Wenn nicht leer, muss die Transaktion aus **einer der** diesen [Regionen](#standortfiltern) stammen. | | `accountInclude` | `string[]` | Wenn nicht leer, muss die Transaktion **mindestens eines** dieser Konten referenzieren. | | `accountExclude` | `string[]` | Die Transaktion wird verworfen, wenn sie **eines** dieser Konten referenziert. Hat Priorität über `accountInclude`. | | `accountRequired` | `string[]` | Die Transaktion muss **alle** diese Konten referenzieren. | Filterregeln: * Alle Prädikate werden miteinander UND-verknüpft, ausgewertet in der Reihenfolge `includeBam` → `failed` → `regionInclude` → `accountExclude` → `accountRequired` → `accountInclude`. * BAM-Vorbestätigungen ignorieren den `failed` Statusfilter und werden trotzdem geliefert, wenn sie mit den Quell-, Regions- und Kontenfiltern übereinstimmen. * Konten sind base58-codierte Pubkeys. Ein ungültiger Wert gibt den JSON-RPC-Fehler `-32602` (ungültige Parameter) zurück. * Jede Kontenliste ist auf **500** Einträge begrenzt. Um nur Helius-Vorbestätigungen zu erhalten: ```json theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "preconfSubscribe", "params": [{ "includeBam": false }] } ``` ### Adress-Lookup-Tabellen (ALT) Auflösung Kontofilter stimmen mit mehr als den statischen Kontoschlüsseln der Transaktion überein — Helius löst v0 [Adress-Lookup-Tabellen](/docs/de/glossary#address-lookup-table-alt) serverseitig auf, sodass `accountInclude`, `accountExclude` und `accountRequired` auch mit Konten übereinstimmen, auf die eine Transaktion über einen ALT zugreift. Das bedeutet, dass Sie auf jedes Konto filtern können, mit dem eine Transaktion in Berührung kommt, selbst wenn es nur hinter einer Nachschlagetabelle angezeigt wird — es ist nicht erforderlich, ALT-Mappings zu pflegen oder Tabellen selbst aufzulösen. Übergeben Sie einfach den Pubkey des Kontos und Helius kümmert sich um die Auflösung, bevor der Filter angewendet wird. ### Standortfiltern Verwenden Sie `regionInclude`, um nur Transaktionen zu empfangen, die aus bestimmten Regionen stammen. Geben Sie einen oder mehrere Regionscodes an; eine Transaktion wird zugelassen, wenn ihre Ursprungsregion mit einem von ihnen übereinstimmt. ```json theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "preconfSubscribe", "params": [{ "regionInclude": ["ewr", "fra"] }] } ``` Die Ursprungsregion hängt von der Quelle ab. Für Helius-Vorbestätigungen ist es die Helius-Region, die die Transaktion aufgenommen hat. Für BAM-Vorbestätigungen ist es der regionale BAM-Endpunkt, der die Vorbestätigung ausgegeben hat, nicht der Ort, an dem Helius sie aufgenommen hat. Bams Singapur- und Dallas-Endpunkte entsprechen `sgp` und `dal`. Gültige Regionscodes: | Code | Standort | | ----- | ----------------- | | `slc` | Salt Lake City | | `fra` | Frankfurt | | `lon` | London | | `pit` | Pittsburgh | | `sgp` | Singapur | | `ewr` | Newark | | `tyo` | Tokio | | `ams` | Amsterdam | | `dal` | Dallas | | `dub` | Dublin | | `mia` | Miami | | `lax` | Los Angeles | | `iad` | Ashburn | | `sea` | Seattle | | `hkg` | Hongkong | | `sqq` | Šiauliai, Litauen | Wenn `regionInclude` gesetzt ist, werden Transaktionen, die keine Regioneninformationen tragen, verworfen. Ein nicht erkannter Regionscode gibt den JSON-RPC-Fehler `-32602` (ungültige Parameter) zurück. ## Benachrichtigungsnutzlast Benachrichtigungen werden als **binäre** WebSocket-Frames (nicht JSON) geliefert. Helius und BAM-Vorbestätigungen haben dasselbe Layout. Jeder Frame ist ein gepacktes Byte-Layout, das eine einzelne Transaktion trägt: | Bytes | Feld | Typ | Beschreibung | | ----- | ------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 | `version` | `u8` | Nutzlastschema-Version. Derzeit `1`. | | 1–8 | `slot` | `u64` (little-endian) | Der Slot, zu dem die Transaktion gehört. | | 9–16 | `tx_index` | `u64` (little-endian) | Index der Transaktion innerhalb des Slots. Immer `0` für BAM-Vorbestätigungen — BAM ordnet Transaktionen nach Sequenz-ID und Paketposition anstelle eines Slot-Indexes, und keines davon wird in diesem Stream getragen. | | 17 | `status` | `u8` | Transaktionsstatus: `0` = fehlgeschlagen, `1` = Erfolg, `2` = unbekannt. Helius-Vorbestätigungen melden den Ausführungsstatus auf bestmöglicher Basis, `2`, wenn er nicht verfügbar ist. BAM-Vorbestätigungen melden immer `2`. | | 18+ | `transaction` | `bytes` | Die Transaktion im Solana-Wire-Format. Siehe [Dekodierung der Transaktion](#dekodierung-der-transaktion). | Die Nutzlast hat kein Quellenfeld. Schließen Sie nicht auf eine BAM-Herkunft aus `tx_index = 0` und `status = 2`, da Helius-Vorbestätigungen dieselben Werte tragen können. ### Unterscheidung der beiden Quellen Da es kein Quellenfeld gibt, können Sie keine willkürliche Nachricht als Helius oder BAM kennzeichnen. Das `status` Byte gibt Ihnen einen Einwegklassifizierer: * **`status` ist `0` oder `1`** — die Nachricht ist eine Helius-Vorbestätigung und die Transaktion wurde ausgeführt. BAM meldet diese Werte nie. * **`status` ist `2`** — die Quelle ist mehrdeutig: entweder eine BAM-Vorbestätigung oder eine Helius-Vorbestätigung, deren Ausführungsstatus nicht verfügbar war. Kein anderes Feld diskriminiert. BAMs Sequenz-ID und Paketposition werden in diesem Stream nicht übertragen, daher gibt es keine BAM-Ordnungsmessdaten zum Schlüsseln, und `regionInclude` ist ein Abonnementfilter anstelle eines Nutzlastfeldes, sodass es nicht pro Nachricht gelesen werden kann. Wenn Sie möchten, dass jede Nachricht in einem Stream dieselbe Art von Beweis enthält, setzen Sie `includeBam: false` — das lässt nur Helius-Vorbestätigungen übrig, die alle bei der Ausführung durch den Leader ausgegeben werden. Es gibt keinen BAM-only-Filter. **Nur Helius-Vorbestätigungen tragen einen Ausführungsstatus.** Helius-Vorbestätigungen melden `0` (fehlgeschlagen) oder `1` (Erfolg), wenn der Validator es bereitstellt, und `2` nur, wenn er nicht verfügbar ist. BAM-Vorbestätigungen melden immer `2` (unbekannt), daher kann `status` allein Ihnen nicht sagen, ob eine BAM-stammende Transaktion erfolgreich war. Wenn Ihre Strategie vom Ausführungsstatus abhängt, setzen Sie `includeBam: false` oder bestätigen Sie das Ergebnis on-chain. **Lesen und prüfen Sie immer zuerst das `version` Byte.** Derzeit ist es `1`. Wenn Helius das Nutzlastformat aktualisieren muss, wird die Version inkrementiert — verzweigen Sie darauf, damit Ihr Decoder weiterhin über Schemaänderungen hinweg funktioniert. Eine Vorbestätigung ist ein frühes Signal, keine Garantie. Die Transaktion ist noch nicht on-chain gelandet und könnte noch abgelehnt werden — und der Ausführungsstatus einer Helius-Vorbestätigung spiegelt das lokale Ergebnis des Leaders wider, das nicht endgültig ist, bis der Block bestätigt wird. Bestätigen Sie das Landen durch Standard-Commitment-Checks, bevor Sie es als endgültig betrachten. ### Dekodierung der Transaktion Die Transaktionsbytes werden genau so weitergeleitet, wie der Validator sie serialisiert hat, im Standard-Wire-Encoding für die Version der Transaktion. Legacy- und v0-Transaktionen verwenden das Signaturen-zuerst-Layout, das `bincode` produziert. Transaction v1 ([SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md)) verwendet ein Nachrichten-zuerst-Layout mit Signaturen am Ende, sodass `bincode` bei v1-Nutzlasten fehlschlägt. Verwenden Sie einen Decoder, der jede Version behandelt: * **Rust:** [`agave-transaction-view`](https://docs.rs/agave-transaction-view) parst Legacy-, v0- und v1-Transaktionen vor Ort, ohne eine Zwischencopie. Dies ist die empfohlene Option. [`wincode`](https://docs.rs/wincode), der bincode-kompatible Serializer, der von aktuellen Solana SDKs verwendet wird, dekodiert ebenfalls v1 zu `VersionedTransaction`. * **JavaScript / TypeScript:** Stellen Sie sicher, dass Ihre Bibliotheksversion Transaktion v1 unterstützt. Ältere `VersionedTransaction.deserialize` Implementierungen behandelten 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[18..]; let tx = TransactionView::try_new_unsanitized(tx_bytes)?; println!("version: {:?}", tx.version()); // Legacy, V0, or V1 println!("signature: {}", tx.signatures()[0]); for ix in tx.instructions_iter() { println!("program index {}: {} bytes", ix.program_id_index, ix.data.len()); } ``` ## Doppelte Benachrichtigungen Helius- und BAM-Vorbestätigungen werden pro Quelle dedupliziert, nicht über die Quellen hinweg. Ein kleiner Anteil von Transaktionen erreicht Helius durch beide, sodass Sie dieselbe Signatur zweimal erhalten können und die beiden Kopien möglicherweise unterschiedliche Slots melden. Deduplizieren Sie nach Signatur auf dem Client und machen Sie transaktionsgetriggerte Aktionen idempotent, damit eine zweite Benachrichtigung dieselbe Aktion nicht zweimal auslöst. Bestätigen Sie die Ausführung und das Landen durch Standard-Commitment-Checks. ## Beispiel ```javascript theme={"system"} const WebSocket = require('ws'); const ws = new WebSocket('wss://beta.helius-rpc.com/?api-key='); ws.on('open', () => { ws.send(JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'preconfSubscribe' // Helius and BAM preconfirmations by default // Optional: txs from EWR/FRA touching a given account; Helius txs must be successful. // BAM ignores the status filter; region and account filters still apply. // params: [{ failed: false, regionInclude: ['ewr', 'fra'], accountInclude: ['9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM'] }] // Optional: Helius preconfirmations only // params: [{ includeBam: false }] })); // 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) | tx_index (u64 LE) | status (u8) | 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 txIndex = buf.readBigUInt64LE(9); // always 0 for BAM preconfirmations const status = buf.readUInt8(17); // 0 = failed, 1 = success, 2 = unknown (always 2 for BAM) const txBytes = buf.subarray(18); // transaction in Solana wire format (legacy, v0, or v1) console.log('Preconfirmation:', { version, slot, txIndex, status, 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)); ``` ## Abbestellen Um keine Benachrichtigungen mehr zu erhalten, rufen Sie `preconfUnsubscribe` mit der von `preconfSubscribe` zurückgegebenen Abonnement-ID auf. ```json theme={"system"} { "jsonrpc": "2.0", "id": 2, "method": "preconfUnsubscribe", "params": [24040] } ``` ```json theme={"system"} { "jsonrpc": "2.0", "result": true, "id": 2 } ``` ## Preise Vorbestätigungen erfordern einen **Professional-Plan oder höher** und kosten **10 Credits pro Nachricht** — eine Nachricht pro gestreamte Transaktion — abgerechnet von Ihrem Plan. Siehe [Credits](/docs/de/billing/credits) für Details. Die Abrechnung erfolgt pro Nachricht, nicht pro eindeutiger Signatur. Eine Transaktion, die sowohl von Helius als auch von BAM geliefert wird, zählt doppelt. Setzen Sie `includeBam: false`, wenn Sie nur Helius-Vorbestätigungen haben möchten. Vorbestätigungen sind ein neues Produkt und die Preise können sich ändern. ## Verwandt Was Vorbestätigungen sind und wo sie im Validierungspipeline sitzen. Streamen Sie bestätigte Transaktionen mit umfangreicher Filterung. Anforderungsparameter, Filterfelder und das binäre Benachrichtigungs-Layout.