Skip to main content
Utilisez Sender Max (pourboire minimum : 0,001 SOL) pour agir sur les préconfirmations. Une préconfirmation est efficace uniquement si vous exécutez votre transaction en premier — Sender Max est le moyen le plus rapide pour y parvenir. Construisez avec Sender Max dès le départ pour tirer pleinement parti des préconfirmations.

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éthode preconfSubscribe. 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

Conservez l’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.
Chaque champ est facultatif — un champ manquant signifie “aucune contrainte” pour ce prédicat, donc un filtre vide (ou aucun params) correspond à chaque transaction des deux sources. Règles de filtrage :
  • Tous les prédicats sont ANDés ensemble, évalués dans l’ordre includeBamfailedregionIncludeaccountExcludeaccountRequiredaccountInclude.
  • Les préconfirmations BAM ignorent le filtre de statut failed et 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.
Pour recevoir uniquement les préconfirmations Helius :

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, donc accountInclude, 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

Utilisez regionInclude 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.
La région d’origine dépend de la source. Pour les préconfirmations Helius, c’est la région Helius qui a ingéré la transaction. Pour les préconfirmations BAM, c’est le point de terminaison BAM régional qui a émis la préconfirmation, pas où Helius l’a ingérée. Les points de terminaison de Singapour et Dallas de BAM correspondent à 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’octet status vous donne un classificateur à sens unique :
  • status est 0 ou 1 — le message est une préconfirmation Helius et la transaction a été exécutée. BAM ne signale jamais ces valeurs.
  • status est 2 — 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.
Aucun autre champ ne permet la discrimination. Les ID de séquence et positions de groupe de BAM ne sont pas portés sur ce flux, il n’y a donc pas de métadonnées de classement BAM auxquelles se référer, et 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.
Lisez et vérifiez toujours le premier octet version. Il est actuellement 1. Si Helius doit mettre à jour le format de la charge utile, la version augmentera — branchez-vous dessus pour que votre décodeur continue de fonctionner à travers les changements de schéma.
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 par bincode. 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-view analyse 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 en VersionedTransaction.
  • JavaScript / TypeScript : assurez-vous que votre version de bibliothèque prend en charge la transaction v1. Les anciennes implémentations VersionedTransaction.deserialize ne gèrent que les versions legacy et v0. Utilisez @solana/kit 8.0+ ou @solana/web3.js v3. 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, appelez preconfUnsubscribe 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éfinissez includeBam: 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.