Skip to main content
Il s’agit du chemin d’envoi de transactions basique — facturé par envoi et préférable lorsque la fiabilité est plus importante que la vitesse brute (paiements, portefeuilles, applications). Si vous effectuez des transactions et avez besoin de la plus faible latence, utilisez plutôt Helius Sender.
Construire votre propre logique d’envoi de transactions est le meilleur moyen d’assurer des performances maximales, un contrôle et une fiabilité pour votre application. Bien que le Helius SDK fournisse un emballage pratique pour commencer, comprendre et mettre en œuvre ce flux de travail manuel est fortement recommandé pour les systèmes de production. Ce guide vous guidera à travers les étapes nécessaires pour construire votre propre solution.

Le flux de travail manuel

L’envoi manuel d’une transaction implique les étapes suivantes :
1

Construire la transaction initiale

Assemblez vos instructions et signez la transaction afin qu’elle puisse être simulée.
2

Optimiser les unités de calcul

Simulez la transaction pour déterminer précisément les unités de calcul nécessaires et ajoutez une petite marge.
3

Ajouter des frais prioritaires

Obtenez une estimation des frais de l’API Helius Priority Fee et ajoutez-la à votre transaction.
4

Envoyer et rediffuser

Envoyez la transaction finale et implémentez une stratégie de sondage robuste pour gérer la confirmation.
Les SDK Helius sont open-source. Vous pouvez consulter le code sous-jacent pour la méthode sendSmartTransaction dans notre SDK TypeScript et SDK Rust pour voir une mise en œuvre de qualité production de ce flux de travail.

1. Construire la transaction initiale

Tout d’abord, rassemblez toutes les instructions que vous souhaitez inclure dans votre transaction. Ensuite, créez un objet Transaction ou VersionedTransaction. Vous devrez également récupérer un blockhash récent. Cet exemple prépare une transaction versionnée. À ce stade, vous devez également la signer pour qu’elle puisse être simulée à l’étape suivante.

2. Optimiser l’utilisation des unités de calcul (CU)

Pour éviter de gaspiller des frais ou que votre transaction échoue, vous devez définir la limite des unités de calcul (CU) aussi précisément que possible. Vous pouvez le faire en simulant la transaction à l’aide de la méthode RPC simulateTransaction. Il est recommandé de simuler d’abord avec une limite de CU élevée pour garantir que la simulation réussit, puis d’utiliser unitsConsumed de la réponse pour définir votre limite réelle.
Vous avez maintenant une instruction qui définit précisément la limite de calcul. Vous l’ajouterez à votre transaction finale.

3. Définir le bon frais prioritaire

Ensuite, déterminez le frais prioritaire optimal à ajouter à votre transaction. Utiliser l’API de frais prioritaires Helius Priority Fee API est le meilleur moyen d’obtenir une estimation en temps réel basée sur les conditions actuelles du réseau. Vous devrez appeler la méthode RPC getPriorityFeeEstimate. Pour maximiser les chances d’inclusion via les connexions misées de Helius, utilisez l’option recommended: true.

4. Construire, envoyer et confirmer

Maintenant, assemblez la transaction finale avec les nouvelles instructions de budget de calcul, envoyez-la et implémentez un mécanisme de sondage robuste pour confirmer qu’elle a bien été enregistrée.
Ne vous fiez pas à la logique de réessai par défaut du fournisseur RPC (maxRetries dans sendTransaction). Bien que les connexions mises de Helius transmettent votre transaction directement au leader, elle peut toujours être abandonnée. Vous devez implémenter votre propre logique de rediffusion pour une confirmation fiable.
Un modèle courant est de renvoyer la même transaction périodiquement jusqu’à l’expiration du blockhash. Ne resignez la transaction que si vous obtenez également un nouveau blockhash. Resigner avec le même blockhash peut entraîner la confirmation de transactions dupliquées.
Cet exemple fournit une boucle de sondage basique. Une application de qualité production nécessiterait une logique plus sophistiquée, y compris la gestion des différents statuts de confirmation et des délais d’attente potentiels.

Protégez-vous contre les attaques sandwich

Pour détourner votre transaction des validateurs statistiquement liés aux attaques sandwich, ajoutez le paramètre de requête mev-protect=true à votre URL RPC — aucun changement à votre logique de transaction :

MEV Protect

Voyez comment fonctionne MEV Protect, quelles méthodes il prend en charge et ses compromis.

Gagnez des remises sur vos transactions

Vous pouvez opter pour gagner une part du MEV généré par vos transactions, payée automatiquement en SOL — aucun changement à votre logique de transaction.

Remises de transaction

Ajoutez un paramètre à vos appels sendTransaction pour commencer à gagner des remises en SOL.

Méthodes associées

sendTransaction

Envoyer une transaction signée au réseau

simulateTransaction

Simuler une transaction pour estimer les unités de calcul

getSignatureStatuses

Vérifier le statut de confirmation des transactions

getLatestBlockhash

Obtenez un blockhash récent pour signer la transaction

getBlockHeight

Obtenez la hauteur de bloc actuelle pour les vérifications d’expiration