Passer au contenu principal
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 de Helius qui diffuse les Preconfirmations, c’est-à-dire les transactions livrées avant d’être regroupées dans des entrées et découpées en shreds. Il s’agit du signal de transaction offrant la plus faible latence chez Helius. Un même abonnement fournit à la fois les Preconfirmations de Helius, émises dès que le leader exécute la transaction et accompagnées de son statut d’exécution, et les Preconfirmations BAM provenant des validateurs qui exécutent le client Block Assembly Marketplace de Jito, émises lorsque le validateur s’engage à exécuter la transaction. L’accès est disponible avec tous les forfaits payants. Consultez la section 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 combinés par un ET logique et évalués dans l’ordre includeSource → failed → regionInclude → signatures → accountExclude → accountRequired → accountInclude → signerExclude → signerInclude → instructions.
  • Les préconfirmations BAM dont le statut est inconnu ignorent le filtre failed. Les préconfirmations Helius dont le statut est inconnu ne correspondent pas à un filtre failed explicite.
  • includeSource doit être un tableau contenant uniquement helius et bam. Une valeur non valide renvoie l’erreur JSON-RPC -32602 (paramètres non valides).
  • Les comptes sont des clés publiques encodées en base58. Une valeur non valide renvoie l’erreur JSON-RPC -32602 (paramètres non valides).
  • Chaque liste de comptes ou de signataires est limitée à 10 000 entrées. signatures est limité à 1 000 entrées.
Le filtre obsolète includeBam reste disponible à des fins de rétrocompatibilité. includeBam: false équivaut à includeSource: ["helius"]. includeBam: true ou l’omission du champ sélectionne les deux sources. N’envoyez pas includeBam et includeSource ensemble.
Pour recevoir uniquement les préconfirmations Helius :

Filtrage par signataire et par signature

Utilisez signerInclude pour sélectionner les transactions signées par un compte spécifique. Utilisez signerExclude pour exclure les transactions signées par l’un des comptes répertoriés. Un compte référencé n’est pas considéré comme un signataire. Utilisez signatures lorsque vous connaissez déjà les transactions à suivre. Le filtre vérifie la première signature de la transaction, qui est celle utilisée par les méthodes RPC de Solana. Le filtre ne peut pas être modifié après votre abonnement. Créez donc un nouvel abonnement pour suivre de nouvelles signatures.

Filtrage des instructions

Utilisez instructions pour sélectionner les instructions de niveau supérieur selon le programme et les données d’instruction. Chaque filtre d’instructions prend en charge les champs suivants : Chaque entrée memcmp accepte l’encodage base58, base64 ou hex. La valeur par défaut est base58. Une transaction correspond lorsqu’une instruction de niveau supérieur satisfait toutes les conditions d’un filtre d’instructions. La requête suivante sélectionne les instructions buy de pump.fun selon leur discriminateur Anchor :
Le filtre vérifie uniquement les instructions de niveau supérieur. Il ne peut pas sélectionner les instructions invoquées par un appel interprogramme (CPI), car ces instructions n’existent pas avant l’exécution. Vous pouvez fournir jusqu’à 16 filtres d’instructions et quatre entrées memcmp par filtre d’instructions. Chaque valeur memcmp doit être décodée en 1 à 128 octets. Le décalage de fin d’un memcmp et dataSize ne doivent pas dépasser 4 096 octets.

Résolution des tables de recherche d’adresses (ALT)

Les filtres de comptes ne se limitent pas aux clés de comptes statiques de la transaction : Helius résout côté serveur les tables de recherche d’adresses v0. Ainsi, accountInclude, accountExclude et accountRequired correspondent également aux comptes chargés par une transaction via une ALT. Vous pouvez donc filtrer sur n’importe quel compte auquel une transaction accède, même s’il apparaît uniquement derrière une table de recherche. Vous n’avez pas besoin de gérer les correspondances ALT ni de résoudre vous-même les tables. Transmettez simplement la clé publique du compte. Helius effectue la résolution avant d’appliquer le filtre.

Filtrage par région

Utilisez regionInclude pour recevoir uniquement les transactions provenant de régions spécifiques. Transmettez un ou plusieurs codes de région. Une transaction est acceptée lorsque sa région d’origine correspond à l’un de ces codes.
La région d’origine dépend de la source. Pour les préconfirmations Helius, il s’agit de la région Helius qui a reçu la transaction. Pour les préconfirmations BAM, il s’agit de l’endpoint BAM régional qui a émis la préconfirmation, et non de l’endroit où Helius l’a reçue. Les endpoints de BAM à Singapour et Dallas correspondent à sgp et dal. Codes de région valides :
Lorsque regionInclude est défini, les transactions qui ne contiennent aucune information de région sont ignorées. Un code de région non reconnu renvoie l’erreur JSON-RPC -32602 (paramètres non valides).

Charge utile des notifications

Les notifications sont transmises sous forme de trames WebSocket binaires et non en JSON. Les préconfirmations Helius et BAM utilisent la même structure. Chaque trame suit une structure d’octets compacte contenant une seule transaction : La charge utile ne comporte aucun champ indiquant la source. Ne déduisez pas une origine BAM de tx_index = 0, car d’autres sources peuvent également indiquer 0.

Distinguer les deux sources

Comme il n’existe aucun champ indiquant la source, vous ne pouvez pas identifier un message arbitraire comme provenant de Helius ou de BAM. L’octet status fournit une classification à sens unique :
  • status vaut 0 ou 1 — le message est une préconfirmation Helius et la transaction a été exécutée. BAM n’indique jamais ces valeurs.
  • status vaut 2 — la source est ambiguë : il peut s’agir d’une préconfirmation BAM ou d’une préconfirmation Helius dont le statut d’exécution n’était pas disponible.
Aucun autre champ ne permet de les distinguer. L’identifiant de séquence et la position dans le bundle de BAM ne sont pas transmis dans ce flux. Il n’existe donc aucune métadonnée d’ordonnancement BAM sur laquelle s’appuyer. De plus, regionInclude est un filtre d’abonnement et non un champ de la charge utile. Il ne peut donc pas être lu pour chaque message. Si vous souhaitez que chaque message d’un flux contienne le même type d’indication, définissez includeSource: ["helius"] ou includeSource: ["bam"]. Un flux Helius uniquement contient les préconfirmations émises lors de l’exécution par le leader.
Lisez et vérifiez toujours d’abord l’octet version. Il vaut actuellement 1. Si Helius doit mettre à jour le format de la charge utile, le numéro de version augmentera. Adaptez le traitement selon cette valeur pour que votre décodeur continue de fonctionner après les modifications du schéma.
Une préconfirmation est un signal précoce, pas une garantie. La transaction n’a pas encore été enregistrée on-chain et peut toujours être abandonnée. De plus, le statut d’exécution d’une préconfirmation Helius reflète le résultat local du leader, qui n’est pas définitif tant que le bloc n’est pas confirmé. Confirmez l’enregistrement avec les vérifications standard du niveau de commitment avant de le considérer comme définitif.

Décodage de la transaction

Les octets de la transaction sont transférés exactement tels que le validateur les a sérialisés, dans l’encodage binaire standard correspondant à la version de la transaction. Les transactions legacy et v0 utilisent une structure commençant par les signatures, produite par bincode. Les transactions v1 (SIMD-0385) utilisent une structure commençant par le message et plaçant les signatures à la fin. bincode échoue donc avec les charges utiles v1. Utilisez un décodeur compatible avec toutes les versions :
  • Rust : agave-transaction-view analyse sur place les transactions legacy, v0 et v1, sans copie intermédiaire. Cette option est recommandée. wincode, le sérialiseur compatible avec bincode utilisé par les SDK Solana actuels, décode également la v1 dans VersionedTransaction.
  • JavaScript / TypeScript : assurez-vous que la version de votre bibliothèque prend en charge les transactions v1. Les anciennes implémentations de VersionedTransaction.deserialize ne gèrent que les transactions legacy et v0. Utilisez @solana/kit 8.0+ ou @solana/web3.js v3. Consultez Prise en charge des transactions v1.

Notifications en double

Les préconfirmations Helius et BAM sont dédupliquées par source, et non entre les sources. Une faible proportion de transactions atteint Helius par les deux sources. Vous pouvez donc recevoir deux fois la même signature, et les deux exemplaires peuvent indiquer des slots différents. Dédupliquez les transactions par signature côté client et rendez idempotentes les actions déclenchées par les transactions, afin qu’une seconde notification ne déclenche pas deux fois la même action. Confirmez l’exécution et l’enregistrement à l’aide des vérifications standard du niveau de commitment.

Exemple

Désabonnement

Pour ne plus recevoir de notifications, appelez preconfUnsubscribe avec l’identifiant d’abonnement renvoyé par preconfSubscribe.

Tarification

Les Preconfirmations sont disponibles avec tous les forfaits payants : Developer, Business, Professional et Enterprise. Les forfaits gratuits ne sont pas éligibles. Consultez la section Crédits pour plus de détails. Les slots dans lesquels aucun message n’est livré ne coûtent aucun crédit, même lorsqu’ils bénéficient d’une couverture des Preconfirmations. Lorsqu’un slot livre au moins un message, chaque abonnement preconfSubscribe ouvert est facturé selon le montant le plus élevé entre 300 crédits et 10 crédits par message livré. Les slots non couverts ne coûtent rien. Consultez la section Tarification pour connaître les conditions de facturation selon la source et la région. Chaque abonnement simultané est facturé indépendamment dès qu’il reçoit au moins un message. Fermez les abonnements dont vous n’avez plus besoin avec preconfUnsubscribe. Avec includeSource: ["helius"], les slots couverts uniquement par BAM sont exclus de la facturation. Lorsque regionInclude est défini, les slots couverts en dehors des régions sélectionnées ne coûtent rien pour cet abonnement ; les slots correspondants ne sont facturés que si l’abonnement reçoit au moins un message. La facturation s’effectue par message, et non par signature unique. Une transaction transmise à la fois par Helius et BAM est comptabilisée deux fois. Définissez includeSource: ["helius"] si vous souhaitez uniquement les préconfirmations Helius.
Pour maîtriser les coûts, regroupez si possible les filtres de comptes dans un seul abonnement, utilisez regionInclude pour limiter la facturation aux régions dont vous avez besoin, définissez includeSource: ["helius"] lorsque vous n’avez pas besoin de BAM et surveillez vos crédits dans le tableau de bord Helius.
Preconfirmations est un nouveau produit et sa tarification est susceptible de changer.

Ressources associées

Preconfirmations Overview

Découvrez ce que sont les Preconfirmations et où elles se situent dans le pipeline du validateur.

transactionSubscribe

Diffusez les transactions avec le niveau d’engagement confirmed à l’aide de filtres avancés.

preconfSubscribe API reference

Consultez les paramètres de requête, les champs de filtre et la structure binaire des notifications.