Bêta publique.
preprocessedSubscribe est disponible sur tous les plans payants
et est facturé à 0.1 crédit par message (un message par transaction livrée).Qu’est-ce que preprocessedSubscribe ?
preprocessedSubscribe est une méthode WebSocket de Helius qui diffuse des transactions prétraitées — des transactions Solana pré-exécution livrées avant d’atteindre le niveau de commitment processed. Helius agrège plusieurs sources pré-exécution — principalement des shreds décodés directement à leur arrivée chez le validateur, complétés par des signaux de préconfirmation — et les livre comme un flux unique dédupliqué de messages binaires compacts, sans infrastructure de désassemblage de votre côté.
Les transactions provenant de signaux de préconfirmation arrivent plus tard sur ce flux que sur le produit dédié Préconfirmations, qui reste l’accès le plus précoce à celles-ci.
C’est le successeur du produit prétraité LaserStream (gRPC) antérieur. Si vous consommez aujourd’hui des transactions prétraitées via gRPC, passez à cette méthode — elle livre la même classe de données sur une connexion WebSocket simple avec une latence plus faible, et la livraison gRPC sera dépréciée.
Point de terminaison
preprocessedSubscribe est servi depuis wss://beta.helius-rpc.com — le point de terminaison Helius Gatekeeper — plutôt que mainnet.helius-rpc.com. Authentifiez-vous avec votre clé API comme paramètre de requête :
S’abonner
Envoyez une requête JSON-RPC avec la méthodepreprocessedSubscribe. params contient les filtres de compte et est requis — accountInclude et accountRequired doivent spécifier au moins un compte entre eux (voir Filtrage):
Filtrage
Chaque abonnement est défini par les filtres de compte dansparams. Le filtrage se fait côté serveur, donc vous ne recevez que les transactions qui vous intéressent :
Règles de filtrage :
- Les trois filtres sont combinés avec une logique ET.
accountIncludeetaccountRequireddoivent spécifier au moins un compte entre eux — il n’y a pas de flux complet non filtré.- Les comptes sont des clés publiques codées en base58. Chaque liste accepte jusqu’à 5,000 adresses.
Résolution de la table de recherche d’adresses (ALT)
Les filtres de compte correspondent à plus que les clés de compte statiques de la transaction — Helius résout les tables de recherche d’adresses côté serveur, doncaccountInclude, accountExclude, et accountRequired correspondent également aux comptes qu’une transaction charge via un ALT. Passez simplement la clé publique du compte ; pas besoin de maintenir les mappages ALT ou de résoudre les tables vous-même.
Notification payload
Les notifications sont livrées sous forme de cadres WebSocket binaires (pas JSON). Chaque cadre porte une seule transaction dans une mise en page de byte compact :
Lisez le préfixe fixe de 73 octets dans l’ordre, puis décodez les octets restants pour lire les instructions, les comptes et les recherches de table d’adresses. La signature est incluse dans le préfixe pour que vous puissiez identifier et dédupliquer une transaction sans décoder le corps complet de la transaction.
Lisez et vérifiez toujours d’abord l’octet
version. Si Helius a besoin de mettre à jour le format de payload, la version s’incrémentera — branchez dessus pour que votre décodeur continue de fonctionner malgré les changements de schéma.
Décoder la transaction
Les octets de transaction sont transmis exactement comme observé sur le réseau, dans le codage wire standard pour la version de la transaction. Les transactions legacy et v0 utilisent la mise en page signatures en premier quebincode produit. La transaction v1 (SIMD-0385) utilise une mise en page message en premier avec signatures à la fin, donc bincode échoue sur les payloads v1. Utilisez un décodeur qui gère chaque version :
- Rust :
agave-transaction-viewanalyse les transactions legacy, v0 et v1 sur place, sans copie intermédiaire. C’est l’option recommandée.wincode, le sérialiseur compatible bincode utilisé par les SDK Solana actuels, décode également v1 enVersionedTransaction. - JavaScript / TypeScript : assurez-vous que votre version de bibliothèque prend en charge la transaction v1. Les anciennes implémentations
VersionedTransaction.deserializene gèrent que legacy et v0. Utilisez@solana/kit8.0+ ou@solana/web3.jsv3. Voir Transaction v1 support.
Exemple
Quelles données sont disponibles ?
Chaque notification transporte la transaction signée, sa première signature et son slot. Comme la livraison se fait avant l’exécution, le flux n’inclut pas :- Statut d’exécution ou erreurs
- Soldes pré/post ou changements de solde de jetons
- Messages de journal ou instructions internes
- Unités de calcul consommées
processed.
Contre-pression
Le flux ne tamponne pas indéfiniment pour les consommateurs lents. Si votre client lit trop lentement et que plus de 4,000 messages s’accumulent côté serveur, Helius ferme la connexion — vous recevez un cadre de fermeture WebSocket propre. Drainez les cadres plus rapidement qu’ils n’arrivent : gardez les travaux lourds tels que le décodage de transaction et la logique de stratégie hors de la boucle de réception, et reconnectez-vous et réabonnez-vous après une déconnexion.Garanties de livraison
La livraison est au mieux des efforts, non garantie, et il n’y a pas de lecture historique. Les clients doivent :- Se reconnecter et se réabonner après une fermeture de connexion.
- Dédupliquer par signature de transaction.
- Considérer le slot comme une observation, pas une finalité.
- Reconcilez avec un flux traité ou confirmé lorsque les résultats d’exécution sont importants.
Tarification
preprocessedSubscribe est disponible sur tous les plans payants et facturé à 0.1 crédit par message — un message par transaction livrée, facturé à partir de votre plan. Voir Crédits pour plus de détails.
Connexes
Préconfirmations
Transactions diffusées avant de devenir des shreds — le signal de transaction le plus précoce.
Shreds bruts (UDP)
Paquets shred non traités via UDP. Vous implémentez le désassemblage.
transactionSubscribe
Transactions post-exécution avec filtrage riche et métadonnées d’exécution.