includeSource, um eine der beiden Quellen auszuwählen.
Endpoints
preconfSubscribe wird über den Helius Gatekeeper endpoint bereitgestellt:
wss://beta.helius-rpc.com/?api-key=<API_KEY>
beta bezieht sich auf den Rollout von Gatekeeper, nicht auf den Reifegrad von Preconfirmations. Er wird zum standardmäßigen endpoint, sobald der Datenverkehr zu Gatekeeper migriert.
Der stream ist nicht kontinuierlich. Die Abdeckung skaliert mit dem Anteil des Netzwerk-Stakes,
der Daten an Helius weiterleitet oder BAM ausführt. Rechne daher mit slots ohne Nachrichten und behandle
diese Lücken korrekt. Weitere Informationen findest du unter Abdeckung.
Autorisierung
string
erforderlich
Dein Helius API key, der als
api-key-Abfrageparameter übergeben wird. Preconfirmations sind mit allen kostenpflichtigen Tarifen verfügbar.Body
array
Optional. Lasse
params weg, um alle Transaktionen von Helius und BAM zu empfangen. Um den stream einzuschränken, übergib ein Filterobjekt als erstes Element. Die Filterung erfolgt serverseitig, sodass du nur für relevante Transaktionen zahlst und auch nur diese empfängst.-32602 (ungültige Parameter) zurück. Wenn du includeSource mit dem veralteten Feld includeBam kombinierst, wird ebenfalls -32602 zurückgegeben. Anweisungsfilter prüfen nur Anweisungen der obersten Ebene. Sie stimmen nicht mit Anweisungen überein, die über einen programmübergreifenden Aufruf (CPI) aufgerufen werden. Ein End-Offset von memcmp und dataSize dürfen zusammen 4.096 Bytes nicht überschreiten.
Kontofilter stimmen nicht nur mit den statischen Kontoschlüsseln der Transaktion überein — Helius löst v0-Address Lookup Tables serverseitig auf. Daher stimmen accountInclude, accountExclude und accountRequired auch mit Konten überein, die eine Transaktion über eine ALT lädt.
Regionscodes
Bei Helius-Preconfirmations bezeichnet die Region den Ort, an dem Helius die Transaktion aufgenommen hat. Bei BAM-Preconfirmations bezeichnet sie den regionalen BAM-endpoint, der die Preconfirmation ausgegeben hat, und nicht den Ort, an dem Helius sie aufgenommen hat. Die BAM-endpoints in Singapur und Dallas werden
sgp und dal zugeordnet.
Response
integer
Abonnement-ID (zum Abbestellen erforderlich)
Benachrichtigungen
Nach der JSON-Bestätigung werden Benachrichtigungen als binäre WebSocket-Frames zugestellt, nicht als JSON. Helius- und BAM-Preconfirmations verwenden dasselbe Layout. Jeder Frame ist ein kompaktes Byte-Layout mit einer einzelnen Transaktion:
Das payload enthält kein Quellenfeld. Leite aus
tx_index = 0 keine BAM-Herkunft ab, da auch andere Quellen 0 melden können.
Eine Preconfirmation ist ein frühes Signal, keine Garantie. Die Transaktion wurde noch nicht onchain aufgenommen und kann weiterhin fehlschlagen oder verworfen werden. Bestätige ihre Aufnahme mit standardmäßigen commitment-Prüfungen, bevor du sie als endgültig behandelst.
Transaktion decodieren
Die Transaktionsbytes werden exakt so weitergeleitet, wie der Validator sie serialisiert hat. Sie verwenden die standardmäßige Wire-Codierung für die jeweilige Transaktionsversion. Legacy- und v0-Transaktionen verwenden das Signaturen-zuerst-Layout, dasbincode erzeugt. Transaktion v1 (SIMD-0385) verwendet ein Nachricht-zuerst-Layout mit den Signaturen am Ende. Deshalb schlägt bincode bei v1-payloads fehl.
Verwende einen Decoder, der jede Version unterstützt. In Rust parst agave-transaction-view Legacy-, v0- und v1-Transaktionen direkt und ist die empfohlene Option. wincode funktioniert mit einem aktuellen Solana SDK VersionedTransaction ebenfalls. Stelle in JavaScript sicher, dass deine Bibliotheksversion Transaktion v1 unterstützt. Ein Rust-Beispiel findest du im Leitfaden.
Doppelte Benachrichtigungen
Helius- und BAM-Preconfirmations werden pro Quelle dedupliziert, aber nicht quellenübergreifend. Ein kleiner Anteil der Transaktionen erreicht Helius über beide Quellen. Daher kannst du dieselbe Signatur zweimal empfangen, und die beiden Kopien können unterschiedliche slots melden. Dedupliziere auf dem Client anhand der Signatur und gestalte transaktionsgesteuerte Aktionen idempotent. Siehe den Leitfaden.Preise
Preconfirmations sind mit allen kostenpflichtigen Tarifen verfügbar: Developer, Business, Professional und Enterprise. Kostenlose Tarife sind nicht berechtigt. Weitere Informationen findest du unter Credits. Für einen slot ohne zugestellte Nachrichten fallen keine Credits an, selbst wenn der slot durch Preconfirmations abgedeckt ist. Sobald in einem slot mindestens eine Nachricht zugestellt wird, werden für jedes offenepreconfSubscribe-Abonnement entweder 300 Credits oder 10 Credits pro zugestellter Nachricht berechnet, je nachdem, welcher Betrag höher ist. Für nicht abgedeckte slot fallen keine Kosten an. Unter Preise erfährst du, welche Quellen und Regionen abgerechnet werden können.
Jedes gleichzeitige Abonnement wird separat abgerechnet, sobald es mindestens eine Nachricht empfängt. Schließe nicht mehr benötigte Abonnements mit
preconfUnsubscribe. Mit includeSource: ["helius"] werden ausschließlich durch BAM abgedeckte slot von der Abrechnung ausgeschlossen. Wenn regionInclude festgelegt ist, fallen für abgedeckte slot außerhalb der ausgewählten Regionen für dieses Abonnement keine Kosten an. Übereinstimmende slot werden nur abgerechnet, wenn das Abonnement mindestens eine Nachricht empfängt.
Die Abrechnung erfolgt pro Nachricht, nicht pro eindeutiger Signatur. Eine Transaktion, die sowohl von Helius als auch von BAM zugestellt wird, zählt doppelt. Lege includeSource: ["helius"] fest, wenn du nur Preconfirmations von Helius erhalten möchtest.
Verwandte Themen
Preconfirmations Overview
Was Preconfirmations sind und wo sie sich in der Validator-Pipeline befinden.
preconfUnsubscribe
Beende ein Abonnement anhand seiner ID.