Skip to main content
Parsed Streams est en bêta ouverte. Il est disponible sur les plans payants — authentifiez-vous avec la clé API de votre projet. L’API peut encore changer avant la disponibilité générale.

​
Qu’est-ce que Parsed Streams ?

Parsed Streams est un service WebSocket qui surveille chaque transaction Solana confirmée (à l’exclusion des transactions de vote), la décode et vous envoie les transactions qui correspondent à un filtre que vous définissez. Vous dites “Je m’intéresse aux instructions de route Jupiter” ou “Je m’intéresse à tout ce qui touche ce compte”, et le serveur effectue la surveillance, le décodage et la correspondance pour vous. Vous recevez des transactions complètes, déjà décodées : chaque instruction avec des arguments et des comptes nommés, plus les frais, la liste complète des clés de compte, un summary du niveau de transaction de ce qui s’est passé, les transferts SOL et token, et des pointeurs vers les instructions exactes qui ont correspondu à votre filtre. Toutes les données sont livrées à l’engagement confirmé.

​
Le modèle mental

Si vous connaissez déjà les internes de Solana, passez à la suite. Sinon, voici le modèle sur lequel toute l’API est construite. Une transaction est un message signé. Elle nomme un payeur de frais, liste chaque compte qu’elle touchera et contient une liste d’instructions. Lorsque vous en consultez une, vous voyez : une signature (son identifiant unique), l’emplacement dans lequel elle est arrivée, les frais payés, les clés de compte, si elle a réussi ou échoué, et les instructions. Une instruction est une action : exécuter ce programme, avec cette entrée, en utilisant ces comptes. Un échange sur Jupiter, un transfert de token, 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 échange, il ne déplace pas les tokens lui-même. Son instruction de route appelle le programme de token pour déplacer les tokens et les programmes d’échange qui détiennent la liquidité. Ces appels imbriqués sont également des instructions, appelées instructions internes (ou CPI, appels inter-programme). Cela est important lorsque vous écrivez un filtre : beaucoup de l’activité réelle, comme les mouvements de tokens dans un échange, se passe dans des instructions internes, donc votre filtre les correspond par défaut. Si vous ne voulez que les instructions pour lesquelles un utilisateur a signé, définissez includeCpi à false. Les comptes sont les éléments sur la chaîne avec lesquels une instruction travaille : portefeuilles, soldes de tokens, pools, frappes. Chaque instruction les transporte comme une liste ordonnée d’adresses, et cet ordre est le contrat : le programme définit ce que chaque position signifie. Le programme de token, par exemple, attend que le compte prenne les tokens en premier, puis le compte les reçoive, puis le propriétaire approuve le transfert. Les rôles donnent des noms à ces positions. La plupart des programmes bien connus publient un manuel lisible par machine pour leur interface, appelé un IDL. Le manuel répertorie chaque instruction que le programme possède, ce que ses champs de données signifient, et à quoi chaque position de compte sert. Helius conserve un catalogue de ces manuels pour des milliers de programmes. Grâce à cela, une simple liste d’adresses devient des comptes nommés : pour un transfert de token, la position 0 devient source, la position 1 devient destination, la position 2 devient authority. Au lieu de deviner ce que la troisième adresse signifie, vous lisez {"name": "authority", "pubkey": "9xQe...", "isSigner": true}. Ces noms sont les rôles sur lesquels vous pouvez filtrer. Le décodage est la même idée appliquée aux données d’entrée de l’instruction. Sur le fil, ces données sont des octets opaques. Avec le manuel du programme, les octets deviennent des valeurs nommées : {"in_amount": "1000000", "slippage_bps": 50}. Toutes les instructions ne peuvent pas être décodées, alors chacune d’elles se retrouve dans l’un des trois états que vous pouvez voir directement à partir de ses champs :
  • Décodé : l’instruction possède un objet decoded avec des args nommés et des accounts nommés.
  • Reconnu : en plus de decoded, l’instruction possède un summary avec un type (comme swap), un description lisible par l’homme, et une charge utile structurée parsedData, telle que des métadonnées d’échange avec quantités et frappes.
  • Non décodé : le programme ou l’instruction n’est pas dans le catalogue, decoded est null, et l’instruction transporte les octets bruts (rawData) et la liste d’adresses simple (rawAccounts) à la place, donc vous avez toujours quelque chose avec lequel travailler.
C’est tout le modèle, et votre filtre est directement construit à partir de cela :
  • programs : quel programme l’instruction appelle
  • instructionNames : ce que le manuel du programme appelle cette action
  • accounts.include : quelles adresses il touche
  • accounts.roles : quelle position nommée doit contenir quelle adresse
  • includeCpi et includeFailed : si les instructions internes et les transactions échouées comptent
Les filtres sélectionnent les instructions ; les notifications livrent la transaction complète.

​
Comment il se compare

vs Enhanced WebSockets

Enhanced WebSockets diffuse des transactions entières ou des mises à jour de comptes sans décodage. Parsed Streams correspond 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 côté serveur.

vs Parsed Events

Parsed Events applique le même décodage aux transactions historiques : analysez les signatures ou parcourez l’historique d’une adresse à la demande via REST et GraphQL. Parsed Streams pousse de nouvelles transactions au fur et à mesure qu’elles arrivent.

​
Programmes pris en charge

Parsed Streams décode plus de 3 600 programmes à partir de leurs IDLs sur la chaîne, plus des programmes de base comme SPL Token, Token-2022 et le System Program via des décodeurs intégrés. Vous pouvez filtrer par l’adresse de n’importe quel programme. Les instructions que le service ne peut pas décoder diffusent à la place des données d’instruction brutes. Quelques-uns des programmes décodés les plus utilisés :
Vous ne voyez pas un programme ? Il est probablement encore dans le catalogue. Appelez describeProgram avec son adresse pour voir ses instructions, événements et rôles de compte.

​
Accès

Parsed Streams est en bêta ouverte et disponible sur des plans payants. Obtenez votre clé API depuis le Tableau de bord Helius. Connectez-vous au point de terminaison bêta :
Authentifiez-vous avec la clé API de votre projet, passée en tant que paramètre de requête api-key (ou l’en-tête x-api-key). La clé est vérifiée lors de l’ouverture de la connexion : une clé manquante ou invalide est rejetée avec le code HTTP 401, et un projet ayant atteint sa limite de connexion reçoit le code HTTP 429.

​
Commencer

Démarrage rapide

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

Suivi des échanges Jupiter

Construisez et abonnez-vous à un véritable filtre en utilisant la découverte de programme.

Suivi des créations Pump.fun

Un écouteur sécurisé pour les reconnexions qui enregistre chaque nouveau déploiement de token Pump.fun.

Gestion des reconnexions

Détectez les déconnexions, reculez, réabonnez-vous et récupérez les emplacements manqués.