Passer au contenu principal

​
Qu’est-ce que Parsed Streams ?

Parsed Streams est un service WebSocket qui surveille chaque transaction Solana confirmée (à l’exception des transactions de vote), la décode et vous transmet les transactions correspondant à un filtre que vous définissez. Vous indiquez « Je m’intéresse aux instructions de routage de Jupiter » ou « Je m’intéresse à tout ce qui touche ce compte », et le serveur se charge de la surveillance, du décodage et de la mise en correspondance. Vous recevez des transactions complètes, déjà décodées : chaque instruction avec des arguments et des comptes nommés, ainsi que les frais, la liste complète des clés de compte, un summary au niveau de la transaction décrivant ce qui s’est passé, les transferts de SOL et de tokens, et des références aux instructions exactes qui correspondent à votre filtre. Toutes les données sont fournies avec le niveau d’engagement confirmed.

​
Le modèle mental

Si vous connaissez déjà le fonctionnement interne de Solana, passez à la suite. Sinon, voici le modèle sur lequel repose toute l’API. Une transaction est un message signé. Elle désigne le payeur des frais, répertorie tous les comptes qu’elle va toucher et contient une liste d’instructions. Lorsque vous en examinez une, vous voyez : une signature (son identifiant unique), le slot dans lequel elle a été intégrée, les frais payés, les clés de compte, son succès ou son échec, ainsi que les instructions. Une instruction est une action : exécuter ce programme, avec cette entrée, en utilisant ces comptes. Il peut s’agir d’un swap sur Jupiter, d’un transfert de tokens ou d’un mémo. Une transaction contient généralement plusieurs instructions, qui s’exécutent dans l’ordre. Les programmes peuvent appeler d’autres programmes. Lorsque Jupiter exécute un swap, il ne déplace pas lui-même les tokens. Son instruction de routage appelle le programme de tokens pour déplacer les tokens, ainsi que les programmes d’échange qui détiennent la liquidité. Ces appels imbriqués sont également des instructions, appelées instructions internes (ou CPI, pour cross-program invocations). Cela compte lorsque vous écrivez un filtre : une grande partie de l’activité réelle, comme les mouvements effectifs de tokens au sein d’un swap, se déroule dans les instructions internes. Votre filtre les inclut donc par défaut. Si vous ne souhaitez obtenir que les instructions signées par un utilisateur, définissez includeCpi sur false. Les comptes sont les éléments on-chain avec lesquels une instruction interagit : portefeuilles, soldes de tokens, pools et mints. Chaque instruction les contient sous la forme d’une liste ordonnée d’adresses, et cet ordre constitue le contrat : le programme définit la signification de chaque position. Par exemple, le programme de tokens attend d’abord le compte depuis lequel prélever les tokens, puis le compte qui doit les recevoir, et enfin le propriétaire qui approuve le transfert. Les rôles donnent un nom à ces positions. La plupart des programmes connus publient un manuel lisible par machine pour leur interface, appelé IDL. Ce manuel répertorie chaque instruction du programme, la signification de ses champs de données et la fonction de chaque position de compte. Helius tient à jour un catalogue de ces manuels pour des milliers de programmes. Grâce à celui-ci, une simple liste d’adresses devient un ensemble de comptes nommés : pour un transfert de tokens, la position 0 devient source, la position 1 devient destination et la position 2 devient authority. Au lieu de deviner la signification de la troisième adresse, vous lisez {"name": "authority", "pubkey": "9xQe...", "isSigner": true}. Ces noms correspondent aux rôles sur lesquels vous pouvez appliquer des filtres. Le décodage applique le même principe aux données d’entrée de l’instruction. Lors de la transmission, ces données sont constituées d’octets opaques. Grâce au manuel du programme, ces octets deviennent des valeurs nommées : {"in_amount": "1000000", "slippage_bps": 50}. Toutes les instructions ne peuvent pas être décodées. Chacune se trouve donc dans l’un des trois états que vous pouvez identifier directement à partir de ses champs :
  • Décodée : l’instruction contient un objet decoded avec des args nommés et des accounts nommés.
  • Reconnue : en plus de decoded, l’instruction contient un summary avec un type (tel que swap), un description lisible par l’utilisateur et une charge utile parsedData structurée, comme des métadonnées de swap comprenant les montants et les mints.
  • Non décodée : le programme ou l’instruction ne figure pas dans le catalogue, decoded vaut null, et l’instruction contient à la place les octets bruts (rawData) et la liste d’adresses non enrichie (rawAccounts), afin que vous disposiez toujours de données exploitables.
Voilà l’intégralité du modèle. Votre filtre est construit directement à partir de celui-ci :
  • programs : le programme appelé par l’instruction
  • instructionNames : le nom donné à cette action dans le manuel du programme
  • accounts.include : les adresses qu’elle touche
  • accounts.roles : l’adresse que chaque position nommée doit contenir
  • includeCpi et includeFailed : si les instructions internes et les transactions ayant échoué sont prises en compte
Les filtres sélectionnent des instructions ; les notifications transmettent la transaction complète.

​
Comparaison

vs Enhanced WebSockets

Enhanced WebSockets diffuse des transactions complètes ou des mises à jour de comptes sans les décoder. Parsed Streams effectue la mise en correspondance au niveau des instructions et décode tout pour vous.

vs LaserStream gRPC

LaserStream est un flux gRPC à haut débit que vous filtrez et décodez côté client. Parsed Streams est une API WebSocket qui filtre et décode les données côté serveur.

vs Parsed Events

Parsed Events applique le même décodage aux transactions historiques : analysez des signatures ou parcourez à la demande l’historique d’une adresse via REST. Parsed Streams transmet les nouvelles transactions dès qu’elles sont enregistrées.

​
Programmes pris en charge

Parsed Streams décode plus de 3 600 programmes à partir de leurs IDL on-chain, ainsi que des programmes principaux tels que SPL Token, Token-2022 et System Program grâce à des décodeurs intégrés. Vous pouvez filtrer sur l’adresse de n’importe quel programme. Les instructions que le service ne peut pas décoder sont diffusées sous forme de données d’instruction brutes. Voici quelques-uns des programmes décodés les plus utilisés :
Vous ne trouvez pas un programme ? Il figure probablement tout de même dans le catalogue. Appelez describeProgram avec son adresse pour afficher ses instructions, ses événements et ses rôles de compte.

​
Accès et tarification

Parsed Streams est disponible pour tous les forfaits, y compris le forfait gratuit. Il remplace Enhanced Transaction Webhooks pour les données de transaction analysées en temps réel. Obtenez votre clé API depuis le tableau de bord Helius. Chaque événement transmis coûte 1 crédit, soit le même tarif que les événements de webhook. Consultez la page Crédits pour obtenir la liste complète des tarifs. Parsed Streams est disponible sur le point de terminaison Gatekeeper, le même hôte que celui utilisé pour le trafic RPC et WebSocket de Helius. Il n’existe pas d’hôte distinct pour Parsed Streams :
Authentifiez-vous avec la clé API de votre projet, transmise en tant que paramètre de requête api-key (ou dans l’en-tête x-api-key). La clé est vérifiée lors de l’ouverture de la connexion : une clé manquante ou non valide entraîne une erreur HTTP 401, tandis qu’un projet ayant atteint sa limite de connexions reçoit une erreur HTTP 429.

​
Premiers pas

Quickstart

Connectez-vous, envoyez votre premier filtre et lisez une notification.

Track Jupiter Swaps

Créez un filtre concret à l’aide de la découverte de programmes et abonnez-vous à celui-ci.

Track Pump.fun Mints

Un écouteur résistant aux reconnexions qui journalise chaque nouveau déploiement de jeton Pump.fun.

Handling Reconnects

Détectez les déconnexions, appliquez un délai progressif, réabonnez-vous et récupérez les slots manqués.