Skip to main content
Starten Sie ein Abonnement für Vorbestätigungen — 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, 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 Endpunkt bereitgestellt:
  • wss://beta.helius-rpc.com/?api-key=<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.

Authorisierungen

string
erforderlich
Ihr Helius-API-Schlüssel, übergeben als api-key-Parameter. Erfordert einen Professional-Plan oder höher.

Body

array
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.
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 serverseitig auf, sodass accountInclude, accountExclude und accountRequired auch zu Konten passen, die eine Transaktion über eine ALT lädt.

Region-Codes

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

integer
Abonnement-ID (erforderlich zum Abbestellen)

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: 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) 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 Legacy-, v0- und v1-Transaktionen direkt und wird empfohlen; wincode mit einem aktuellen Solana-SDK VersionedTransaction funktioniert ebenfalls. In JavaScript stellen Sie sicher, dass Ihre Bibliotheksversion Transaktion v1 unterstützt. Siehe den Leitfaden 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.

Preisgestaltung

Vorbestätigungen erfordern einen Professional-Plan oder höher und kosten 10 Credits pro Nachricht — eine Nachricht pro gestreamter Transaktion. Siehe 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

Vorbestätigungen Übersicht

Was Vorbestätigungen sind und wo sie sich in der Validator-Pipeline befinden.

preconfUnsubscribe

Beenden Sie ein Abonnement durch seine ID.