> ## 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. # preconfSubscribe > Verwenden Sie preconfSubscribe, um Solana-Transaktionen vor dem Schreddern zu streamen — Helius-Vorbestätigungen tragen den Ausführungsstatus, BAM-Vorbestätigungen kommen vor der Ausführung an. Starten Sie ein Abonnement für [Vorbestätigungen](/docs/de/pre-confirmations/overview) — Transaktionen, die bereitgestellt werden, bevor sie zu Einträgen gesammelt und in Schreds umgewandelt werden. Dies ist das Transaktionssignal mit der niedrigsten Latenzzeit, das Helius anbietet. Ein Abonnement streamt sowohl Helius-Vorbestätigungen, die im Moment der Ausführung der Transaktion durch den Leiter ausgegeben werden und ihren Ausführungsstatus tragen, als auch [BAM-Vorbestätigungen](/docs/de/pre-confirmations/overview#bam-vorbestätigungen), die ausgegeben werden, wenn der Validator sich verpflichtet, sie auszuführen; stellen Sie `includeBam: false` ein, um nur Helius-Vorbestätigungen zu erhalten. ## Endpunkte `preconfSubscribe` wird vom Helius [Gatekeeper](/docs/de/gatekeeper/overview) Endpunkt bereitgestellt: * `wss://beta.helius-rpc.com/?api-key=` Der `beta`-Hostname bezieht sich auf die Gatekeeper-Einführung, nicht auf die Reife der Vorbestätigungen — es wird der Standardendpunkt, sobald der Verkehr auf Gatekeeper migriert ist. Der Stream ist nicht kontinuierlich. Die Abdeckung skaliert mit dem Anteil des Netzwerkanteils, der an Helius weitergeleitet wird oder BAM ausführt, daher erwarten Sie Slots ohne Nachrichten — behandeln Sie diese Lücken mit Sorgfalt. Sehen Sie [Abdeckung](/docs/de/pre-confirmations/overview#abdeckung). ## Authorisierungen Ihr Helius-API-Schlüssel, übergeben als `api-key`-Parameter. Erfordert einen Professional-Plan oder höher. ## Body Optional. Lassen Sie `params` weg, um jede Transaktion sowohl von Helius als auch von BAM zu erhalten. Um den Stream einzuschränken, übergeben Sie ein Filterobjekt als erstes Element — das Filtern erfolgt serverseitig, sodass Sie nur für die Transaktionen bezahlen und sie empfangen, die Sie interessieren. Jedes Feld ist optional — ein fehlendes Feld bedeutet "keine Einschränkung" für dieses Prädikat, also entspricht ein leerer Filter jeder Transaktion aus beiden Quellen. Gesetzte Felder werden mit **UND** kombiniert, ausgewertet in der Reihenfolge `includeBam` → `failed` → `regionInclude` → `accountExclude` → `accountRequired` → `accountInclude`. `false` lässt BAM-Vorbestätigungen wegfallen, sodass Sie nur Helius-Vorbestätigungen erhalten. `true`, wie das Weglassen des Feldes, behält beide Quellen bei. Statusfilterung wird nur für Helius-Vorbestätigungen unterstützt und wird für BAM-Vorbestätigungen ignoriert. Für Helius gibt `true` nur fehlgeschlagene (zurückgesetzte) Transaktionen zurück; `false` gibt nur erfolgreiche Transaktionen zurück. Entweder der Wert schließt Helius-Transaktionen mit unbekanntem Status aus. Lassen Sie das Feld weg, um alle Status zu erhalten. BAM-Vorbestätigungen werden weiterhin geliefert, wenn sie den Quell-, Regions- und Kontenfiltern entsprechen. Wenn nicht leer, muss die Transaktion aus **einer dieser** [Regionen](#region-codes) stammen. Transaktionen ohne Regionsinformationen werden ausgelassen, wenn dies festgelegt ist. Wenn nicht leer, muss die Transaktion auf **mindestens eines** dieser Konten (base58 Pubkeys) verweisen. Begrenzung auf 500 Einträge. Die Transaktion wird ausgelassen, wenn sie auf **eines dieser** Konten verweist. Hat Vorrang vor `accountInclude`. Begrenzung auf 500 Einträge. Die Transaktion muss auf **alle** diese Konten verweisen. Begrenzung auf 500 Einträge. Ein ungültiger Kontenwert oder ein nicht erkennbarer Regionscode gibt den JSON-RPC-Fehler `-32602` (ungültige Parameter) zurück. Kontenfilter stimmen mehr als nur mit den statischen Kontoschlüsseln der Transaktion überein — Helius löst v0 [Adressnachschlagetabellen](/docs/de/glossary#address-lookup-table-alt) serverseitig auf, sodass `accountInclude`, `accountExclude` und `accountRequired` auch zu Konten passen, die eine Transaktion über eine ALT lädt. ### Region-Codes | Code | Standort | Code | Standort | | ----- | -------------- | ----- | ----------------- | | `slc` | Salt Lake City | `tyo` | Tokio | | `fra` | Frankfurt | `ams` | Amsterdam | | `lon` | London | `dal` | Dallas | | `pit` | Pittsburgh | `dub` | Dublin | | `sgp` | Singapur | `mia` | Miami | | `ewr` | Newark | `lax` | Los Angeles | | `iad` | Ashburn | `sea` | Seattle | | `hkg` | Hongkong | `sqq` | Šiauliai, Litauen | Für Helius-Vorbestätigungen ist die Region der Ort, an dem Helius die Transaktion aufgenommen hat. Für BAM-Vorbestätigungen ist es der regionale BAM-Endpunkt, der die Vorbestätigung ausgegeben hat, nicht wo Helius sie aufgenommen hat. BAM's Singapur- und Dallas-Endpunkte werden `sgp` und `dal` zugeordnet. ## Antwort Abonnement-ID (erforderlich zum Abbestellen) ```json Request theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "preconfSubscribe", "params": [ { "failed": false, "regionInclude": ["ewr", "fra"], "accountInclude": ["9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM"] } ] } ``` ```json Helius only theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "preconfSubscribe", "params": [{ "includeBam": false }] } ``` ```javascript 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 filter: // params: [{ failed: false, accountInclude: ['9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM'] }] // Helius preconfirmations only: // params: [{ includeBam: false }] })); 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); 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:', { slot, txIndex, status, bytes: txBytes.length }); }); ``` ```json Response theme={"system"} { "jsonrpc": "2.0", "id": 1, "result": 24040 } ``` ```text Notification (binary frame) theme={"system"} version u8 payload schema version, currently 1 slot u64 (LE) slot the transaction is scheduled in tx_index u64 (LE) index of the transaction within the slot (always 0 for BAM) status u8 0 = failed, 1 = success, 2 = unknown (always 2 for BAM) tx bytes transaction in Solana wire format (legacy, v0, or v1) ``` ## Benachrichtigungen Nach der JSON-Bestätigung werden Benachrichtigungen als **binäre** WebSocket-Frames (nicht JSON) bereitgestellt. Helius- und BAM-Vorbestätigungen teilen dasselbe Format. Jedes 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, in dem die Transaktion geplant ist. | | 9–16 | `tx_index` | `u64` (little-endian) | Index der Transaktion innerhalb des Slots. Immer `0` für BAM-Vorbestätigungen, die eine Sequenz-ID und eine Paketposition anstelle eines Slot-Index tragen. | | 17 | `status` | `u8` | Transaktionsstatus: `0` = fehlgeschlagen, `1` = Erfolg, `2` = unbekannt. Helius-Vorbestätigungen berichten den Ausführungsstatus auf Basis einer Best-Effort-Methodik, `2`, wenn dieser nicht verfügbar ist. BAM-Vorbestätigungen melden immer `2`. | | 18+ | `transaction` | `bytes` | Die Transaktion im Solana-Wire-Format. Siehe [Decoding the transaction](#decoding-the-transaction). | Die Nutzlast hat kein Quellfeld. Schließen Sie nicht auf einen BAM-Ursprung aus `tx_index = 0` und `status = 2`, da Helius-Vorbestätigungen dieselben Werte tragen können. **Nur Helius-Vorbestätigungen enthalten einen Ausführungsstatus.** Helius Vorbestätigungen berichten `0` (fehlgeschlagen) oder `1` (erfolgreich), wenn der Validator es bereitstellt, und `2` nur, wenn es nicht verfügbar ist. BAM-Vorbestätigungen berichten immer `2` (unbekannt), sodass `status` allein Ihnen nicht sagen kann, ob eine von BAM stammende Transaktion erfolgreich war. Wenn Ihre Strategie vom Ausführungsstatus abhängt, stellen Sie `includeBam: false` ein oder bestätigen Sie das Ergebnis onchain. **Lesen und prüfen Sie immer zuerst das `version`-Byte.** Es ist derzeit `1`. Wenn Helius das Nutzlastformat aktualisieren muss, wird die Version inkrementiert — verzweigen Sie darauf, damit Ihr Decoder über Schemaänderungen hinweg funktioniert. Eine Vorbestätigung ist ein frühes Signal, keine Garantie. Die Transaktion wurde noch nicht onchain eingetragen und könnte noch fehlschlagen oder verworfen werden. Bestätigen Sie das Eintragen durch Standard-Commitment-Überprüfungen, bevor Sie es als endgültig betrachten. ### Decoding the transaction Die Transaktionsbytes werden exakt so weitergeleitet, wie der Validator sie serialisiert hat, im standardmäßigen Wire-Encoding für die Version der Transaktion. Legacy- und v0-Transaktionen verwenden das Signaturen-First-Layout, das `bincode` produziert. Transaktion v1 ([SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md)) verwendet ein Nachrichten-First-Layout mit Signaturen am Ende, sodass `bincode` bei v1-Nutzlasten fehlschlägt. Verwenden Sie einen Decoder, der jede Version verarbeitet. In Rust analysiert [`agave-transaction-view`](https://docs.rs/agave-transaction-view) Legacy-, v0- und v1-Transaktionen direkt und wird empfohlen; [`wincode`](https://docs.rs/wincode) mit einem aktuellen Solana-SDK `VersionedTransaction` funktioniert ebenfalls. In JavaScript stellen Sie sicher, dass Ihre Bibliotheksversion Transaktion v1 unterstützt. Siehe den [Leitfaden](/docs/de/pre-confirmations/preconf-subscribe#dekodierung-der-transaktion) für ein Rust-Beispiel. ## Doppelte Benachrichtigungen Helius- und BAM-Vorbestätigungen werden pro Quelle dedupliziert, nicht überquellübergreifend. Ein kleiner Anteil von Transaktionen erreicht Helius über 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 transaktionsgesteuerte Aktionen idempotent. Siehe den [Leitfaden](/docs/de/pre-confirmations/preconf-subscribe#doppelte-benachrichtigungen). ## Preisgestaltung Vorbestätigungen erfordern einen **Professional-Plan oder höher** und kosten **10 Credits pro Nachricht** — eine Nachricht pro gestreamter Transaktion. 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 bereitgestellt wird, zählt doppelt. Stellen Sie `includeBam: false` ein, wenn Sie nur Helius-Vorbestätigungen wünschen. ## Verwandte Inhalte Was Vorbestätigungen sind und wo sie sich in der Validator-Pipeline befinden. Beenden Sie ein Abonnement durch seine ID.