Wir stellen die Parsed Events API und Parsed Streams vor

Warum ist es schwierig, Solana-Transaktionen zu lesen?

Wenn du Standard-RPC-Nodes danach abfragst, was in einer Transaktion passiert ist, erhältst du eine Liste unbenannter Kontoadressen und Instruktionsdaten als undurchsichtigen Base58-Blob.

Um daraus „Dieses Wallet hat auf Jupiter 1.500 SOL gegen PUMP getauscht“ zu machen, musstest du bisher:

1. Die Transaktion abrufen und jedes beteiligte Programm identifizieren
2. Die IDL jedes Programms finden – also seine veröffentlichte Schnittstelle –, sofern eine existiert
3. Die Instruktionsdaten anhand dieser IDL dekodieren, normalerweise mit Borsh
4. Positionsabhängige Konten ihren Rollen zuordnen: Ist die dritte Adresse die Autorität oder das Ziel? Das weiß nur die Schnittstelle des Programms
5. Rekursiv innere Instruktionen (CPIs) verarbeiten, in denen der Großteil der tatsächlichen Aktivität stattfindet, etwa die Token-Bewegungen innerhalb eines Swaps
6. Dies für jedes relevante Programm wiederholen und deine Decoder aktuell halten, während Programme neue Versionen veröffentlichen

Das bedeutet wochenlange Entwicklungsarbeit, bevor du eine einzige Frage beantwortet hast. Gleichzeitig ist es eine der steilsten Lernkurven beim Einstieg in Solana. Die Daten der Chain sind öffentlich, aber nicht lesbar.

Deshalb haben wir eine serverseitige Dekodierungsschicht entwickelt.

Was enthält eine Antwort von Parsed Events?

Jede Transaktion wird anhand des Helius-IDL-Katalogs dekodiert zurückgegeben. 

Hier ist ein echter Jupiter-Swap, gekürzt auf die wichtigsten Details:

{
  "summary": {
    "type": "swap",
    "description": "GV6UUm… swapped 1500 SOL for 64672839.26195 PUMP via Jupiter",
    "parsedData": {
      "protocol": "jupiter",
      "in_amount": "1500000000000",
      "actual_out_amount": "64672839261950",
      "input_mint": "So11111111111111111111111111111111111111112",
      "output_mint": "pumpCmXqMfrsAkQ5r49WcJnRayYRqmXz6ae8H7H9Dfn"
    }
  },
  "instructions": [
    {
      "programName": "jupiter",
      "instructionName": "shared_accounts_route_v2",
      "decoded": {
        "args": { "in_amount": "1500000000000", "slippage_bps": 2200 },
        "accounts": [
          { "name": "user_transfer_authority", "pubkey": "GV6UUm…", "isSigner": true },
          { "name": "source_mint", "pubkey": "So1111…" }
        ]
      }
    }
  ]
}

Statt zu raten, was die dritte Adresse in einer Kontoliste bedeutet, liest du "name": "user_transfer_authority". 

Auch Argumente werden dekodiert geliefert: "slippage_bps": 2200 statt Rohbytes.

Und die summary auf Transaktionsebene könnte Nutzern unverändert angezeigt werden.

Jedes Ergebnis enthält außerdem die Gebühr und den Gebührenzahler, native SOL-Übertragungen, SPL- und Token-2022-Übertragungen sowie dekodierte benutzerdefinierte Programmfehler, sofern Metadaten verfügbar sind. 

Bei Programmen außerhalb des Katalogs greifen Instruktionen auf Rohdaten und unverarbeitete Konten zurück. So hast du immer Daten, mit denen du arbeiten kannst.

Parsed Streams: Dekodierte Transaktionen, direkt an dich gesendet

Parsed Streams ist ein WebSocket-Service, der jede bestätigte Transaktion überwacht, dekodiert und dir serverseitig diejenigen sendet, die auf Instruktionsebene deinem Filter entsprechen.

Du musst weder einen Firehose-Datenstrom verarbeiten noch einen Decoder warten.

Ein Filter besteht aus fünf Feldern:

1. programs
2. instructionNames
3. accounts (durch Einbeziehung oder anhand einer benannten Rolle)
4. includeCpi
5. includeFailed

„Jede Jupiter-Route-Instruktion, die dieses Wallet betrifft“ sieht beispielsweise so aus:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "parsedTransactionSubscribe",
  "params": [
    {
      "programs": ["JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4"],
      "instructionNames": ["route", "shared_accounts_route"]
    }
  ]
}

Jede Benachrichtigung enthält die gesamte dekodierte Transaktion. Zusätzlich verweist matchedIndexes auf die Instruktionen, die deinem Filter entsprachen.

Wie erhältst du Instruktionsnamen für Solana-Programme?

Das Raten von Instruktionsnamen ist der häufigste Grund dafür, dass ein Filter unbemerkt keine Treffer liefert. Um die Instruktionsnamen für Solana-Programme abzurufen, rufst du describeProgram mit der Adresse eines beliebigen Programms auf. Du erhältst die Instruktionen, Ereignisse und Kontorollen, die der Matcher vergleicht:

{
  "id": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4",
  "name": "jupiter",
  "instructions": ["route", "shared_accounts_route", "exact_out_route"],
  "events": ["SwapEvent"],
  "roles": ["user_transfer_authority", "destination_token_account"]
}

Schlage das Programm nach, füge die Namen deinem Filter hinzu und abonniere anschließend den Stream. 

Der Leitfaden Jupiter-Swaps verfolgen führt dich durch den gesamten Workflow.

Die Parsed Events API: Dekodierte Transaktionen bei Bedarf

Für Abfragen statt Live-Daten nutzt die Parsed Events API auf Anfrage dieselbe Dekodierung anhand des IDL-Katalogs.

Transaktionen parsen akzeptiert Signaturen und gibt sie dekodiert zurück.

Der geparste Transaktionsverlauf durchläuft den vollständigen dekodierten Verlauf einer Adresse seitenweise und gibt die neuesten Transaktionen zuerst zurück.

curl -X POST "https://mainnet.helius-rpc.com/v1/parsed-events/transactions?api-key=YOUR_API_KEY" \
  -H "content-type: application/json" \
  -d '{"transactions": ["5xSKzM8bvpudE521jikHqASzMr23Ms4X4ieY3K8oFPFrJWCSSgYocJmHznrR8b12voDxKDH8ykdCLXSRrx6duVLH"]}'

Beide Methoden sind auch über GraphQL verfügbar. So kannst du gezielt die geparsten Felder auswählen, die deine App benötigt.

Parsed Events im Vergleich zur Enhanced Transactions API

Parsed Events ist der Nachfolger der Enhanced Transactions API. 

Während Enhanced Transactions Transaktionen in eine feste Liste von Ereignistypen einordnete, dekodiert Parsed Events jede Instruktion anhand des IDL-Katalogs. Bei unbekannten Programmen werden Rohdaten zurückgegeben statt UNKNOWN.

Wenn du derzeit die Enhanced Transactions API verwendest, ordnet der Migrationsleitfaden jeden Endpunkt, Parameter und jedes Antwortfeld zu. Er enthält außerdem einen Prompt, den dein Agent ausführen kann, um die Migration für dich abzuschließen.

Welches Parsing-Tool ist das richtige für mich?

Die beiden neuen Produkte verwenden dieselbe Dekodierungs-Engine. Eine Transaktion sieht daher gleich aus, egal ob sie über einen Stream oder einen REST-Aufruf eingegangen ist. Besonders wichtig: Du kannst mit Parsed Events anhand historischer Daten einen Prototyp erstellen und anschließend mit Parsed Streams zu Live-Daten wechseln, ohne deinen Parsing-Code zu ändern.

Erste Schritte

Parsed Streams und die Parsed Events API befinden sich in der offenen Beta und sind in allen kostenpflichtigen Plänen verfügbar. Hole dir deinen API-Schlüssel im Helius-Dashboard.

Verwende zum Herstellen einer Verbindung die folgenden Endpunkte:

Parsed Streams: 

wss://fs-beta.helius-rpc.com/?api-key=YOUR_API_KEY

Parsed Events API: 

https://mainnet.helius-rpc.com/v1/parsed-events/...?api-key=YOUR_API_KEY

Leitfäden

Mit dem Parsed Streams Quickstart erhältst du innerhalb weniger Minuten deine erste dekodierte Benachrichtigung. Der Parsed Events Quickstart führt dich ebenso schnell zu deiner ersten geparsten Signatur. 

Wenn du Fragen hast, kontaktiere uns bitte über Telegram oder Discord.