Skip to main content
Verwenden Sie 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 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 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 — siehe 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.
preconfSubscribe wird von wss://beta.helius-rpc.com — dem Helius Gatekeeper Endpoint — anstatt von mainnet.helius-rpc.com bedient. Authentifizieren Sie sich mit Ihrem API-Schlüssel als Query-Parameter.
Der beta Hostname bezieht sich auf das Gatekeeper 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 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.

Antwort auf Abonnieren

Speichern Sie die result — es ist die Abonnement-ID, die Sie zum Kündigen 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.
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. Filterregeln:
  • Alle Prädikate werden miteinander UND-verknüpft, ausgewertet in der Reihenfolge includeBamfailedregionIncludeaccountExcludeaccountRequiredaccountInclude.
  • 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:

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 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.
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:
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: 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) 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 parst Legacy-, v0- und v1-Transaktionen vor Ort, ohne eine Zwischencopie. Dies ist die empfohlene Option. 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.

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

Abbestellen

Um keine Benachrichtigungen mehr zu erhalten, rufen Sie preconfUnsubscribe mit der von preconfSubscribe zurückgegebenen Abonnement-ID auf.

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 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

Überblick über Vorbestätigungen

Was Vorbestätigungen sind und wo sie im Validierungspipeline sitzen.

transactionSubscribe

Streamen Sie bestätigte Transaktionen mit umfangreicher Filterung.

preconfSubscribe API-Referenz

Anforderungsparameter, Filterfelder und das binäre Benachrichtigungs-Layout.