Zum Hauptinhalt springen
Verwende Sender Max (Mindest-Tip: 0,001 SOL), um auf Preconfirmations zu reagieren. Eine Preconfirmation lohnt sich nur, wenn deine Transaktion zuerst landet. Sender Max ist der schnellste Weg dorthin. Baue von Anfang an auf Sender Max auf, um Preconfirmations vollständig zu nutzen.

Was ist preconfSubscribe?

preconfSubscribe ist eine WebSocket-Methode von Helius, die Preconfirmations per stream bereitstellt. Das sind Transaktionen, die übermittelt werden, bevor sie zu Einträgen zusammengefasst und in shred zerlegt werden. Dies ist das Transaktionssignal mit der niedrigsten Latenz, das Helius anbietet. Ein Abonnement liefert sowohl Preconfirmations von Helius als auch BAM Preconfirmations. Helius gibt sie aus, sobald der Leader die Transaktion ausführt. Sie enthalten den Ausführungsstatus. BAM Preconfirmations stammen von Validatoren, auf denen der Client für Jitos Block Assembly Marketplace läuft. Sie werden ausgegeben, wenn sich der Validator zur Ausführung der Transaktion verpflichtet. Der Zugriff ist mit allen kostenpflichtigen Tarifen verfügbar. Weitere Informationen findest du unter Preise.
Der stream ist nicht kontinuierlich. Die Abdeckung skaliert mit dem Anteil des Stakes, der an Helius weitergeleitet wird oder BAM ausführt. Rechne daher mit slot ohne Nachrichten und behandle diese Lücken ordnungsgemäß. Weitere Informationen findest du unter Abdeckung.
preconfSubscribe wird über wss://beta.helius-rpc.com bereitgestellt, den Helius-Gatekeeper-endpoint, und nicht über mainnet.helius-rpc.com. Authentifiziere dich mit deinem API key als Abfrageparameter.
Der Hostname beta bezieht sich auf die Einführung von Gatekeeper, nicht auf den Reifegrad von Preconfirmations. Preconfirmations starten zuerst am Gatekeeper-endpoint. Dieser wird zum Standard-endpoint, sobald Helius den Datenverkehr zu Gatekeeper migriert.

Abonnieren

Sende einen JSON-RPC-request mit der Methode preconfSubscribe. Der Server antwortet mit einer Abonnement-ID und streamt anschließend für jede Transaktion eine Benachrichtigung. Übergib als erstes params-Element einen optionalen Filter, um nur passende Transaktionen zu empfangen. Lasse params weg, um den vollständigen stream von Helius und BAM zu empfangen.

Abonnement-response

Speichere result. Dies ist die Abonnement-ID, mit der du das Abonnement beendest. Nach dieser Bestätigung werden die Benachrichtigungen als Binär-Frames gestreamt (siehe unten).

Filtern

Standardmäßig streamt preconfSubscribe jede Transaktion aus beiden Quellen. Um den stream einzugrenzen, übergib ein Filterobjekt als erstes Element von params. Die Filterung erfolgt serverseitig. Du bezahlst und empfängst daher nur die Transaktionen, die für dich relevant sind.
Jedes Feld ist optional. Ein fehlendes Feld bedeutet für das jeweilige Prädikat „keine Einschränkung“. Ein leerer Filter oder kein params stimmt daher mit jeder Transaktion aus beiden Quellen überein. Filterregeln:
  • Alle Prädikate werden mit AND verknüpft und in dieser Reihenfolge ausgewertet: includeSource → failed → regionInclude → signatures → accountExclude → accountRequired → accountInclude → signerExclude → signerInclude → instructions.
  • BAM-Preconfirmations mit unbekanntem Status ignorieren den Filter failed. Helius-Preconfirmations mit unbekanntem Status stimmen nicht mit einem expliziten Filter failed überein.
  • includeSource muss ein Array sein, das ausschließlich helius und bam enthält. Ein ungültiger Wert gibt den JSON-RPC-Fehler -32602 (ungültige Parameter) zurück.
  • Accounts sind base58-codierte Pubkeys. Ein ungültiger Wert gibt den JSON-RPC-Fehler -32602 (ungültige Parameter) zurück.
  • Jede Account- oder Signer-Liste ist auf 10.000 Einträge begrenzt. signatures ist auf 1.000 Einträge begrenzt.
Der veraltete Filter includeBam bleibt aus Gründen der Abwärtskompatibilität verfügbar. includeBam: false entspricht includeSource: ["helius"]. includeBam: true oder ein ausgelassenes Feld wählt beide Quellen aus. Sende includeBam und includeSource nicht zusammen.
So empfängst du ausschließlich Helius-Preconfirmations:

Nach Signer und Signatur filtern

Verwende signerInclude, um Transaktionen zu finden, die von einem bestimmten Account signiert wurden. Verwende signerExclude, um Transaktionen auszuschließen, die von einem der aufgeführten Accounts signiert wurden. Ein referenzierter Account zählt nicht als Signer. Verwende signatures, wenn du die zu verfolgenden Transaktionen bereits kennst. Der Filter gleicht die erste Transaktionssignatur ab. Das ist die von Solana-RPC-Methoden verwendete Signatur. Du kannst den Filter nach dem Abonnieren nicht mehr ändern. Erstelle daher eine neue Subscription, um neue Signaturen zu verfolgen.

Nach Instructions filtern

Verwende instructions, um Instructions auf oberster Ebene anhand des Programms und der Instruction-Daten abzugleichen. Jeder Instruction-Filter unterstützt diese Felder: Jeder memcmp-Eintrag akzeptiert die Codierung base58, base64 oder hex. Der Standardwert ist base58. Eine Transaktion stimmt überein, wenn eine Instruction auf oberster Ebene alle Bedingungen eines beliebigen Instruction-Filters erfüllt. Der folgende request gleicht pump.fun-Instructions vom Typ buy anhand ihres Anchor-Diskriminators ab:
Der Filter prüft nur Instructions auf oberster Ebene. Er kann keine Instructions abgleichen, die über einen Cross-Program Invocation (CPI) aufgerufen werden, da diese Instructions vor der Ausführung nicht vorhanden sind. Du kannst bis zu 16 Instruction-Filter und vier memcmp-Einträge pro Instruction-Filter angeben. Jeder memcmp-Wert muss zu 1–128 Bytes dekodiert werden. Ein End-Offset für memcmp und dataSize dürfen 4.096 Bytes nicht überschreiten.

Auflösung von Address Lookup Tables (ALT)

Account-Filter gleichen mehr als nur die statischen Account-Keys einer Transaktion ab. Helius löst v0-Address Lookup Tables serverseitig auf. Daher gleichen accountInclude, accountExclude und accountRequired auch Accounts ab, die eine Transaktion über eine ALT lädt. Du kannst also nach jedem Account filtern, auf den eine Transaktion zugreift, selbst wenn er nur über eine Lookup Table referenziert wird. Du musst keine ALT-Zuordnungen pflegen oder Tabellen selbst auflösen. Übergib einfach den Pubkey des Accounts. Helius löst ihn auf, bevor der Filter angewendet wird.

Nach Standort filtern

Verwende regionInclude, um nur Transaktionen zu empfangen, die aus bestimmten Regionen stammen. Übergib einen oder mehrere Regionscodes. Eine Transaktion passiert den Filter, wenn ihre Ursprungsregion mit einem davon übereinstimmt.
Die Ursprungsregion hängt von der Quelle ab. Bei Helius-Preconfirmations ist es die Helius-Region, in der die Transaktion eingegangen ist. Bei BAM-Preconfirmations ist es der regionale BAM-endpoint, der die Preconfirmation ausgegeben hat, und nicht der Ort, an dem Helius sie empfangen hat. Die BAM-endpoints in Singapur und Dallas werden sgp beziehungsweise dal zugeordnet. Gültige Regionscodes:
Wenn regionInclude gesetzt ist, werden Transaktionen ohne Regionsinformationen verworfen. Ein unbekannter Regionscode gibt den JSON-RPC-Fehler -32602 (ungültige Parameter) zurück.

Benachrichtigungs-Payload

Benachrichtigungen werden als binäre WebSocket-Frames übermittelt, nicht als JSON. Helius- und BAM-Preconfirmations verwenden dasselbe Layout. Jeder Frame ist ein kompaktes Byte-Layout, das eine einzelne Transaktion enthält: Der Payload enthält kein Quellenfeld. Leite aus tx_index = 0 keine BAM-Herkunft ab, da auch andere Quellen 0 melden können.

Die beiden Quellen unterscheiden

Da kein Quellenfeld vorhanden ist, kannst du eine beliebige Nachricht nicht als Helius oder BAM kennzeichnen. Das Byte status bietet eine einseitige Klassifizierung:
  • status ist 0 oder 1 — die Nachricht ist eine Helius-Preconfirmation und die Transaktion wurde ausgeführt. BAM meldet diese Werte nie.
  • status ist 2 — die Quelle ist nicht eindeutig: Es handelt sich entweder um eine BAM-Preconfirmation oder um eine Helius-Preconfirmation, deren Ausführungsstatus nicht verfügbar war.
Kein anderes Feld ermöglicht eine Unterscheidung. Die Sequenz-ID und Bundle-Position von BAM werden in diesem stream nicht übertragen. Daher gibt es keine BAM-Reihenfolgemetadaten, die du dafür verwenden kannst. regionInclude ist ein Subscription-Filter und kein Payload-Feld. Du kannst es daher nicht pro Nachricht auslesen. Wenn jede Nachricht in einem stream dieselbe Art von Nachweis enthalten soll, setze includeSource: ["helius"] oder includeSource: ["bam"]. Ein reiner Helius-stream enthält Preconfirmations, die während der Ausführung durch den Leader ausgegeben werden.
Lies und prüfe immer zuerst das Byte version. Es ist derzeit 1. Wenn Helius das Payload-Format aktualisieren muss, wird die Version erhöht. Verzweige anhand der Version, damit dein Decoder auch nach Schemaänderungen funktioniert.
Eine Preconfirmation ist ein frühes Signal und keine Garantie. Die Transaktion wurde noch nicht onchain aufgenommen und könnte weiterhin verworfen werden. Der Ausführungsstatus einer Helius-Preconfirmation spiegelt außerdem das lokale Ergebnis des Leaders wider. Er ist erst final, wenn der Block bestätigt wurde. Bestätige die Aufnahme mit standardmäßigen commitment-Prüfungen, bevor du sie als final behandelst.

Transaktion dekodieren

Die Transaktionsbytes werden genau so weitergeleitet, wie der Validator sie serialisiert hat: in der standardmäßigen Wire-Codierung der jeweiligen Transaktionsversion. Legacy- und v0-Transaktionen verwenden das Signatures-First-Layout, das bincode erzeugt. Transaktion v1 (SIMD-0385) verwendet ein Message-First-Layout mit Signaturen am Ende. Daher schlägt bincode bei v1-Payloads fehl. Verwende einen Decoder, der alle Versionen verarbeitet:
  • Rust: agave-transaction-view parst Legacy-, v0- und v1-Transaktionen direkt und ohne Zwischenkopie. Dies ist die empfohlene Option. wincode, der von aktuellen Solana-SDKs verwendete bincode-kompatible Serializer, dekodiert v1 ebenfalls in VersionedTransaction.
  • JavaScript / TypeScript: Stelle sicher, dass deine Bibliotheksversion Transaktion v1 unterstützt. Ältere Implementierungen von VersionedTransaction.deserialize verarbeiten nur Legacy und v0. Verwende @solana/kit 8.0+ oder @solana/web3.js v3. Siehe Unterstützung für Transaktion v1.

Doppelte Benachrichtigungen

Helius- und BAM-Preconfirmations werden pro Quelle dedupliziert, 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 durch Transaktionen ausgelöste Aktionen idempotent. So löst eine zweite Benachrichtigung dieselbe Aktion nicht erneut aus. Bestätige die Ausführung und Aufnahme mit standardmäßigen commitment-Prüfungen.

Beispiel

Subscription beenden

Um keine weiteren Benachrichtigungen zu empfangen, rufe preconfUnsubscribe mit der Subscription-ID auf, die preconfSubscribe zurückgegeben hat.

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. Ein slot ohne übermittelte Nachrichten kostet keine Credits, selbst wenn für den slot eine Abdeckung durch Preconfirmations besteht. Wenn ein slot mindestens eine Nachricht liefert, wird für jedes offene Abonnement von preconfSubscribe der höhere Betrag aus 300 Credits oder 10 Credits pro übermittelter Nachricht berechnet. Nicht abgedeckte slot kosten nichts. 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 abgedeckte slot, die ausschließlich BAM unterstützen, von der Abrechnung ausgeschlossen. Wenn regionInclude festgelegt ist, kosten abgedeckte slot außerhalb der ausgewählten Regionen für dieses Abonnement nichts. Ü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. Setze includeSource: ["helius"], wenn du nur Helius-Preconfirmations empfangen möchtest.
Fasse Kontofilter nach Möglichkeit in einem Abonnement zusammen, um Kosten zu kontrollieren. Begrenze die Abrechnung mit regionInclude auf die benötigten Regionen. Lege includeSource: ["helius"] fest, wenn du BAM nicht benötigst, und überwache deine Credits im Helius Dashboard.
Preconfirmations ist ein neues Produkt. Die Preise können sich ändern.

Weitere Informationen

Preconfirmations Overview

Was Preconfirmations sind und wo sie sich in der Validator-Pipeline befinden.

transactionSubscribe

Empfange Transaktionen mit confirmed commitment und umfangreichen Filtermöglichkeiten per stream.

preconfSubscribe API reference

Parameter für den request, Filterfelder und das binäre Benachrichtigungsformat.