Zum Hauptinhalt springen
preprocessedSubscribe überträgt signierte Transaktionen, bevor sie das Commitment-Level processed erreichen. Die Transaktionen werden direkt bei ihrer Ankunft am Validator aus shreds decodiert. Du benötigst dafür keine eigene Infrastruktur zum Zusammensetzen der shreds. In diesem Leitfaden erstellst du einen Monitor, der ein Handelsprogramm vor der Ausführung beobachtet, doppelte Einträge aus dem Feed entfernt, unter dem Backpressure-Limit des Servers bleibt und die Daten vor einer Aktion mit verarbeiteten Daten abgleicht.
Vorverarbeitete Transaktionen sind in allen kostenpflichtigen Tarifen verfügbar und kosten 0,1 Credits pro Nachricht. Pro API key sind bis zu 10 gleichzeitige Verbindungen möglich.

Beschränke das Abonnement auf dein Ziel

Es gibt keinen ungefilterten Stream: accountInclude und accountRequired müssen zusammen mindestens ein Konto angeben. Füge für einen Handelsmonitor das Programm hinzu, mit dem du handelst, und schließe irrelevante Daten aus, für die du sonst bezahlen würdest:
Filter werden mit AND kombiniert. Jede Liste akzeptiert bis zu 5.000 Adressen. Helius löst Adress-Lookup-Tabellen serverseitig auf, sodass auch ein über eine ALT geladenes Konto übereinstimmt. Wenn du die Interaktionen einer bestimmten Wallet mit dem Programm beobachten möchtest, trage stattdessen beide in das Feld accountRequired ein.

Decodiere Frames und entferne Duplikate anhand der Signatur

Benachrichtigungen treffen als binäre Frames ein: zuerst ein Präfix mit 73 Byte, danach die mit bincode serialisierte Transaktion. Die Signatur befindet sich im Präfix. Du kannst Duplikate daher entfernen, ohne den Inhalt zu decodieren. Der Stream bündelt mehrere Quellen vor der Ausführung, sodass dieselbe Transaktion mehrfach eintreffen kann:
monitor.js

Verarbeite Daten schneller, als der Stream sie liefert

Helius puffert Daten für langsame Verbraucher nicht unbegrenzt. Wenn sich serverseitig mehr als 4.000 Nachrichten stauen, wird die Verbindung geschlossen. Deshalb liest der obige Handler nur das 73-Byte-Präfix und stellt die Nachricht in die Warteschlange. Die Deserialisierung und die Strategielogik laufen in einer separaten Schleife:
Wenn die Warteschlange unbegrenzt wächst, schränke die Filter stärker ein. Transaktionen, die du clientseitig verwirfst, kosten weiterhin jeweils 0,1 Credits und werden weiterhin auf das Backpressure-Limit angerechnet.

Gleiche die Daten mit verarbeiteten Daten ab

Eine vorverarbeitete Transaktion zeigt, was der Absender versucht hat, nicht was tatsächlich passiert ist. Sie enthält weder einen Ausführungsstatus noch Kontostandsänderungen oder Protokolle. Sie kann fehlschlagen, verworfen werden oder auf einem anderen Fork landen. Die Zustellung erfolgt nach dem Best-Effort-Prinzip und ohne historisches Replay. Deshalb gilt:
  • Gleiche die Transaktion bei einem Commitment von processed oder confirmed mit transactionSubscribe ab, bevor deine Strategie etwas als Tatsache verbucht.
  • Stelle nach einem Verbindungsabbruch sofort ein neues Abonnement her und akzeptiere die Lücke. Es gibt kein Replay für einen backfill.
  • Wenn du statt Transaktionsabsichten den Kontostatus in Echtzeit benötigst, ist dieser erst nach der Ausführung verfügbar. Verwende LaserStream gRPC mit dem Commitment processed.

Verwandte Leitfäden

preprocessedSubscribe reference

Vollständige Struktur des payload, Filterregeln, Backpressure und Preise

Trade on Preconfirmations

Das früheste Transaktionssignal von Helius, direkt vom Scheduler