Qu’est-ce que preconfSubscribe ?
preconfSubscribe est une méthode WebSocket Helius qui diffuse les préconfirmations — transactions livrées avant qu’elles ne soient collectées en entrées et fragmentées. C’est le signal de transaction à la latence la plus faible que Helius offre. Un abonnement fournit à la fois les préconfirmations Helius, émises au moment où le leader exécute la transaction et portant son statut d’exécution, et les préconfirmations BAM des validateurs exécutant le client Block Assembly Marketplace de Jito, émises lorsque le validateur s’engage à exécuter la transaction. L’accès nécessite un plan Professionnel ou supérieur — voir Tarification.
Le flux n’est pas continu. La couverture évolue avec la part de mise en avant
pour Helius ou exécutant BAM, donc attendez-vous à des créneaux sans messages — gérez
ces lacunes avec souplesse. Voir Couverture.
preconfSubscribe est servi depuis wss://beta.helius-rpc.com — le point de terminaison Gatekeeper Helius — plutôt que mainnet.helius-rpc.com. Authentifiez-vous avec votre clé API en tant que paramètre de requête.
Le nom d’hôte
beta fait référence au déploiement de Gatekeeper,
non à la maturité des préconfirmations. Les préconfirmations sont lancées sur le
point de terminaison Gatekeeper en premier ; cela deviendra le point de terminaison standard à mesure que Helius
migre le trafic vers Gatekeeper.S’abonner
Envoyez une requête JSON-RPC avec la méthodepreconfSubscribe. Le serveur répond avec un identifiant d’abonnement, puis diffuse une notification pour chaque transaction. Passez un filtre optionnel comme premier élément params pour ne recevoir que les transactions correspondantes ; omettez params pour recevoir le flux complet de Helius et BAM.
Réponse d’abonnement
result — c’est l’identifiant d’abonnement que vous utilisez pour vous désabonner. Après cet accusé de réception, les notifications sont diffusées sous forme de trames binaires (voir ci-dessous).
Filtrage
Par défaut,preconfSubscribe diffuse chaque transaction des deux sources. Pour restreindre le flux, passez un objet filtre comme premier élément d’params. Le filtrage se fait côté serveur, vous ne payez donc que pour et ne recevez que les transactions qui vous intéressent.
params) correspond à chaque transaction des deux sources.
Règles de filtrage :
- Tous les prédicats sont ANDés ensemble, évalués dans l’ordre
includeBam→failed→regionInclude→accountExclude→accountRequired→accountInclude. - Les préconfirmations BAM ignorent le filtre de statut
failedet sont toujours livrées si elles correspondent aux filtres source, région et compte. - Les comptes sont des clés publiques encodées en base58. Une valeur invalide retourne l’erreur JSON-RPC
-32602(paramètres invalides). - Chaque liste de comptes est limitée à 500 entrées.
Résolution de la table de consultation 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 consultation d’adresses v0 address lookup tables côté serveur, doncaccountInclude, accountExclude, et accountRequired correspondent également aux comptes qu’une transaction charge via une ALT.
Cela signifie que vous pouvez filtrer sur n’importe quel compte qu’une transaction touche, même lorsqu’il n’apparaît qu’à travers une table de consultation — pas besoin de maintenir des mappages ALT ou de résoudre les tables vous-même. Passez simplement la clé publique du compte et Helius gère la résolution avant que le filtre ne soit appliqué.
Filtrage de lieu
UtilisezregionInclude pour ne recevoir que les transactions provenant de régions spécifiques. Passez un ou plusieurs codes régionaux ; une transaction est validée lorsque sa région d’origine correspond à l’un d’eux.
sgp et dal.
Codes régionaux valides :
Lorsque
regionInclude est défini, les transactions qui ne portent pas d’informations régionales sont abandonnées. Un code de région non reconnu renvoie l’erreur JSON-RPC -32602 (paramètres invalides).Charge utile de notification
Les notifications sont délivrées sous forme de trames WebSocket binaires (et non JSON). Les préconfirmations Helius et BAM partagent le même format. Chaque trame est un format de paquet binaire transportant une seule transaction :
La charge utile n’a pas de champ source. Ne déduisez pas une origine BAM de
tx_index = 0 et status = 2, car les préconfirmations Helius peuvent porter les mêmes valeurs.
Distinguer les deux sources
Comme il n’y a pas de champ source, vous ne pouvez pas identifier arbitrairement un message comme étant Helius ou BAM. L’octetstatus vous donne un classificateur à sens unique :
statusest0ou1— le message est une préconfirmation Helius et la transaction a été exécutée. BAM ne signale jamais ces valeurs.statusest2— la source est ambigüe : soit une préconfirmation BAM, soit une préconfirmation Helius dont le statut d’exécution n’était pas disponible.
regionInclude est un filtre d’abonnement plutôt qu’un champ de charge utile, donc il ne peut pas être lu par message.
Si vous avez besoin que chaque message d’un flux porte le même type de preuve, définissez includeBam: false — cela laisse uniquement les préconfirmations Helius, toutes émises à l’exécution par le leader. Il n’existe pas de filtre BAM uniquement.
Seules les préconfirmations Helius portent un statut d’exécution. Les préconfirmations
Helius signalent
0 (échoué) ou 1 (réussi) lorsque le validateur
le fournit, et 2 uniquement lorsqu’il n’est pas disponible. Les préconfirmations BAM signalent toujours
2 (inconnu), donc status seul ne peut pas vous dire si une transaction issue de BAM
a réussi. Si votre stratégie dépend du statut d’exécution, définissez includeBam: false ou confirmez le résultat sur la chaîne.Une préconfirmation est un signal précoce, pas une garantie. La transaction n’a pas
encore atterri sur la chaîne et pourrait encore être abandonnée — et le statut d’exécution d’une préconfirmation Helius
reflète le résultat local du leader, qui n’est pas final jusqu’à la confirmation du bloc. Confirmez l’atterrissage par des vérifications d’engagement standard avant de le traiter comme final.
Décoder la transaction
Les octets de la transaction sont transférés exactement comme le validateur les a sérialisés, dans le codage standard par fil pour la version de la transaction. Les transactions Legacy et v0 utilisent le formatage signatures-premier produit parbincode. La transaction v1 (SIMD-0385) utilise une mise en page message-premier avec les signatures à la fin, donc bincode échoue sur les charges 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 les versions legacy et v0. Utilisez@solana/kit8.0+ ou@solana/web3.jsv3. Voir Support des transactions v1.
Notifications en double
Les préconfirmations Helius et BAM sont dédupliquées par source, pas entre les sources. Une petite part de transactions parvient à Helius par les deux, vous pouvez donc recevoir la même signature deux fois, et les deux copies peuvent signaler des créneaux différents. Dédupliquez par signature sur le client et rendez les actions déclenchées par les transactions idempotentes, afin qu’une seconde notification ne déclenche pas deux fois la même action. Confirmez l’exécution et l’atterrissage par des vérifications d’engagement standard.Exemple
Désabonnement
Pour arrêter de recevoir des notifications, appelezpreconfUnsubscribe avec l’identifiant d’abonnement retourné par preconfSubscribe.
Tarification
Les préconfirmations nécessitent un plan Professionnel ou supérieur et coûtent 10 crédits par message — un message par transaction diffusée — facturé à partir de votre plan. Voir Crédits pour les détails. La facturation se fait par message, pas par signature unique. Une transaction livrée par Helius et BAM compte deux fois. DéfinissezincludeBam: false si vous ne voulez que les préconfirmations Helius.
Les préconfirmations sont un nouveau produit et la tarification est sujette à modification.
Connexe
Aperçu des préconfirmations
Ce que sont les préconfirmations et où elles se situent dans le pipeline de validation.
transactionSubscribe
Diffusez les transactions confirmées avec un filtrage riche.
Référence API preconfSubscribe
Paramètres de requête, champs de filtre, et disposition binaire de notification.