Zum Hauptinhalt springen

​
Was ist Parsed Streams?

Parsed Streams ist ein WebSocket-Dienst, der jede bestätigte Solana-Transaktion überwacht (außer Vote-Transaktionen), sie decodiert und dir die Transaktionen sendet, die einem von dir definierten Filter entsprechen. Du gibst etwa an: „Jupiter-Route-Instruktionen sind für mich relevant“ oder „Alles, was diesen Account betrifft, ist für mich relevant“. Der Server übernimmt die Überwachung, Decodierung und Zuordnung. Du erhältst vollständige, bereits decodierte Transaktionen: jede Instruktion mit benannten Argumenten und Accounts, dazu die Gebühr, die vollständige Liste der Account-Keys, eine Zusammenfassung auf Transaktionsebene in summary, die SOL- und token-Übertragungen sowie Verweise auf genau die Instruktionen, die deinem Filter entsprachen. Alle Daten werden mit confirmed commitment bereitgestellt.

​
Das mentale Modell

Wenn du bereits mit den internen Abläufen von Solana vertraut bist, kannst du diesen Abschnitt überspringen. Andernfalls erklärt er das Modell, auf dem die gesamte API basiert. Eine Transaktion ist eine signierte Nachricht. Sie nennt den Gebührenzahler, führt alle betroffenen Accounts auf und enthält eine Liste von Instruktionen. Wenn du eine Transaktion betrachtest, siehst du eine Signatur als eindeutige ID, den slot, in dem sie aufgenommen wurde, die gezahlte Gebühr, die Account-Keys, ihren Erfolg oder Fehler und die Instruktionen. Eine Instruktion ist eine einzelne Aktion: Führe dieses Programm mit diesen Eingabedaten und diesen Accounts aus. Zum Beispiel einen Swap auf Jupiter, eine token-Übertragung oder ein Memo. Eine Transaktion enthält normalerweise mehrere Instruktionen, die nacheinander ausgeführt werden. Programme können andere Programme aufrufen. Wenn Jupiter einen Swap ausführt, verschiebt es die token nicht selbst. Seine Route-Instruktion ruft das token-Programm auf, um token zu verschieben, sowie die Börsenprogramme, welche die Liquidität halten. Diese verschachtelten Aufrufe sind ebenfalls Instruktionen. Sie heißen innere Instruktionen oder CPIs (Cross-Program Invocations). Das ist beim Erstellen eines Filters wichtig: Ein großer Teil der tatsächlichen Aktivität findet in inneren Instruktionen statt, etwa die eigentlichen token-Bewegungen innerhalb eines Swaps. Dein Filter berücksichtigt sie daher standardmäßig. Wenn du nur die Instruktionen erfassen möchtest, die ein Benutzer signiert hat, setze includeCpi auf false. Accounts sind die On-Chain-Objekte, mit denen eine Instruktion arbeitet: Wallets, token-Guthaben, Pools und Mints. Jede Instruktion enthält sie als geordnete Liste von Adressen. Die Reihenfolge ist Teil des Vertrags: Das Programm legt fest, was jede Position bedeutet. Das token-Programm erwartet beispielsweise zuerst den Account, von dem token abgebucht werden, dann den empfangenden Account und schließlich den Eigentümer, der die Übertragung genehmigt. Rollen geben diesen Positionen Namen. Die meisten bekannten Programme veröffentlichen eine maschinenlesbare Dokumentation ihrer Schnittstelle, die sogenannte IDL. Sie listet alle Instruktionen des Programms auf und erklärt die Bedeutung ihrer Datenfelder sowie den Zweck jeder Account-Position. Helius verwaltet einen Katalog dieser Dokumentationen für Tausende von Programmen. Damit wird aus einer einfachen Adressliste eine Liste benannter Accounts: Bei einer token-Übertragung wird Position 0 zu source, Position 1 zu destination und Position 2 zu authority. Statt zu raten, was die dritte Adresse bedeutet, liest du {"name": "authority", "pubkey": "9xQe...", "isSigner": true}. Nach diesen Rollen kannst du filtern. Decodierung wendet dasselbe Prinzip auf die Eingabedaten der Instruktion an. Bei der Übertragung bestehen diese Daten aus undurchsichtigen Bytes. Mithilfe der Programmdokumentation werden daraus benannte Werte: {"in_amount": "1000000", "slippage_bps": 50}. Nicht jede Instruktion kann decodiert werden. Jede Instruktion erhält daher einen von drei Zuständen, den du direkt an ihren Feldern erkennst:
  • Decodiert: Die Instruktion enthält ein decoded-Objekt mit benannten args und benannten accounts.
  • Erkannt: Zusätzlich zu decoded enthält die Instruktion ein summary mit einem type wie swap, einem menschenlesbaren description und einem strukturierten parsedData-payload, beispielsweise Swap-Metadaten mit Beträgen und Mints.
  • Nicht decodiert: Das Programm oder die Instruktion ist nicht im Katalog enthalten, decoded ist null und die Instruktion enthält stattdessen die Rohbytes (rawData) und die einfache Adressliste (rawAccounts). So stehen dir immer Daten zur weiteren Verarbeitung zur Verfügung.
Das ist das gesamte Modell. Dein Filter baut direkt darauf auf:
  • programs: welches Programm die Instruktion aufruft
  • instructionNames: wie die Programmdokumentation diese Aktion bezeichnet
  • accounts.include: welche Adressen betroffen sind
  • accounts.roles: welche benannte Position welche Adresse enthalten muss
  • includeCpi und includeFailed: ob innere Instruktionen und fehlgeschlagene Transaktionen berücksichtigt werden
Filter wählen Instruktionen aus. Benachrichtigungen liefern die vollständige Transaktion.

​
Vergleich

vs Enhanced WebSockets

Enhanced WebSockets streamt vollständige Transaktionen oder Account-Aktualisierungen ohne Decodierung. Parsed Streams gleicht Daten auf Instruktionsebene ab und decodiert alles für dich.

vs LaserStream gRPC

LaserStream ist ein gRPC-Datenstrom mit hohem Durchsatz, den du auf dem Client filterst und decodierst. Parsed Streams ist eine WebSocket API, die Daten auf dem Server filtert und decodiert.

vs Parsed Events

Parsed Events wendet dieselbe Decodierung auf historische Transaktionen an: Parse Signaturen oder rufe den Verlauf einer Adresse bei Bedarf seitenweise über REST ab. Parsed Streams sendet neue Transaktionen, sobald sie aufgenommen werden.

​
Unterstützte Programme

Parsed Streams decodiert mehr als 3.600 Programme anhand ihrer On-Chain-IDLs. Hinzu kommen Kernprogramme wie SPL Token, Token-2022 und das System Program, die über integrierte Decoder unterstützt werden. Du kannst nach jeder Programmadresse filtern. Instruktionen, die der Dienst nicht decodieren kann, werden stattdessen als rohe Instruktionsdaten gestreamt. Einige der am häufigsten verwendeten decodierten Programme:
Du findest ein Programm nicht? Wahrscheinlich ist es trotzdem im Katalog enthalten. Rufe describeProgram mit seiner Adresse auf, um seine Instruktionen, Ereignisse und Account-Rollen anzuzeigen.

​
Zugriff und Preise

Parsed Streams ist allgemein in allen Tarifen verfügbar, einschließlich Free. Es ersetzt Enhanced Transaction Webhooks für geparste Echtzeit-Transaktionsdaten. Du erhältst deinen API key im Helius Dashboard. Jedes zugestellte Ereignis kostet 1 Credit. Das entspricht dem Preis für webhook-Ereignisse. Die vollständige Preisliste findest du unter Credits. Parsed Streams wird über den Gatekeeper-endpoint bereitgestellt. Das ist derselbe Host wie für den Helius RPC- und WebSocket-Datenverkehr. Es gibt keinen separaten Host für Parsed Streams:
Authentifiziere dich mit dem API key deines Projekts. Übergib ihn als Query-Parameter api-key oder im Header x-api-key. Der API key wird beim Verbindungsaufbau geprüft. Fehlt er oder ist er ungültig, wird die Verbindung mit HTTP 401 abgelehnt. Hat ein Projekt sein Verbindungslimit erreicht, erhält es HTTP 429.

​
Erste Schritte

Quickstart

Stelle eine Verbindung her, sende deinen ersten Filter und lies eine Benachrichtigung.

Track Jupiter Swaps

Erstelle mithilfe der Programmerkennung einen echten Filter und abonniere ihn.

Track Pump.fun Mints

Ein Listener, der Neuverbindungen unterstützt und jedes neue Pump.fun token deployment protokolliert.

Handling Reconnects

Erkenne Verbindungsabbrüche, warte zunehmend länger, abonniere erneut und ergänze verpasste slots per backfill.