Skip to main content
Démarrez une souscription aux Préconfirmations — transactions livrées avant qu’elles ne soient collectées en entrées et converties en fragments. Il s’agit du signal de transaction à la latence la plus faible offert par Helius. Un abonnement diffuse à la fois les préconfirmations Helius, émises dès que le leader exécute la transaction et portant son statut d’exécution, et les préconfirmations BAM, émises lorsque le validateur s’engage à l’exécuter; réglez includeBam: false pour recevoir uniquement les préconfirmations Helius.

Points de terminaison

preconfSubscribe est servi depuis le point de terminaison Helius Gatekeeper :
  • wss://beta.helius-rpc.com/?api-key=<API_KEY>
Le nom d’hôte beta se réfère au déploiement de Gatekeeper, non à la maturité des Préconfirmations — il deviendra le point de terminaison standard à mesure que le trafic migrera vers Gatekeeper.
Le flux n’est pas continu. La couverture s’adapte avec la part de participation réseau transmise à Helius ou exécutant BAM, donc attendez-vous à des créneaux sans messages — gérez ces lacunes avec précaution. Voir Couverture.

Autorisations

string
requis
Votre clé API Helius, passée en tant que paramètre de requête api-key. Nécessite un plan Professionnel ou supérieur.

Corps

array
Optionnel. Omettez params pour recevoir chaque transaction à la fois de Helius et de BAM. Pour restreindre le flux, passez un objet filtre en premier élément — le filtrage se fait côté serveur, vous ne payez donc que pour les transactions qui vous intéressent et que vous recevez.
Une valeur de compte invalide ou un code de région non reconnu renvoie une erreur JSON-RPC -32602 (paramètres invalides). Les filtres de compte correspondent à plus que les clés de compte statiques de la transaction — Helius résout les tableaux de recherche d’adresse v0 côté serveur, donc accountInclude, accountExclude, et accountRequired correspondent également aux comptes qu’une transaction charge par une ALT.

Codes régionaux

Pour les préconfirmations Helius, la région est celle où Helius 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, non pas l’endroit où Helius l’a ingéré. Les points de terminaison de BAM à Singapour et Dallas se mappent à sgp et dal.

Réponse

integer
ID de souscription (nécessaire pour se désabonner)

Notifications

Après l’accusé de réception JSON, les notifications sont livrées sous forme de trames WebSocket binaires (pas de JSON). Les préconfirmations Helius et BAM partagent la même structure. Chaque trame est un format de byte packé 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.
Seules les préconfirmations Helius portent un statut d’exécution. Les préconfirmations Helius rapportent 0 (échec) ou 1 (succès) lorsque le validateur le fournit, et 2 uniquement lorsqu’il est indisponible. Les préconfirmations BAM rapportent toujours 2 (inconnu), donc status seul ne peut pas vous dire si une transaction d’origine BAM a réussi. Si votre stratégie dépend sur le statut d’exécution, réglez includeBam: false ou confirmez le résultat sur la chaîne.
Lisez et vérifiez toujours d’abord l’octet version. Il est actuellement 1. Si Helius doit mettre à jour le format de charge utile, la version s’incrémentera — branchez-vous dessus pour que votre décodeur continue de fonctionner quel que soit 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 échouer ou être abandonnée. Confirmez l’atterrissage grâce à des vérifications d’engagement standard avant de la considérer comme définitive.

Décodage de la transaction

Les octets de la transaction sont transmis exactement comme le validateur les a sérialisés, dans le codage filaire standard pour la version de la transaction. Les transactions Legacy et v0 utilisent la disposition signatures d’abord que bincode produit. La transaction v1 (SIMD-0385) utilise une disposition messages d’abord avec des signatures à la fin, donc bincode échoue sur les charges utiles v1. Utilisez un décodeur qui gère chaque version. En Rust, agave-transaction-view analyse les transactions legacy, v0 et v1 sur place et est l’option recommandée; wincode avec un SDK Solana actuel VersionedTransaction fonctionne également. En JavaScript, assurez-vous que votre version de la bibliothèque prend en charge la transaction v1. Voir le guide pour un exemple Rust.

Notifications en double

Les préconfirmations Helius et BAM sont dédupliquées par source, pas entre les sources. Une petite part des transactions atteignent Helius par les deux, donc vous pouvez recevoir la même signature deux fois, et les deux copies peuvent indiquer différents créneaux. Dédupliquez par signature côté client et rendez les actions déclenchées par les transactions idempotentes. Voir le guide.

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. Voir Crédits pour plus de détails. La facturation se fait par message, non par signature unique. Une transaction livrée à la fois par Helius et BAM compte double. Réglez includeBam: false si vous ne souhaitez recevoir que les préconfirmations Helius.

Connexe

Aperçu des Préconfirmations

Ce que sont les Préconfirmations et où elles se situent dans le pipeline des validateurs.

preconfUnsubscribe

Arrêtez un abonnement par son ID.