Skip to main content
Meilleures pratiques et modèles recommandés pour les agents utilisant le Helius TypeScript SDK. Pour l’installation et le démarrage, voir la vue d’ensemble.

Recommandations pour les Agents

Utiliser getTransactionsForAddress au lieu de la recherche en deux étapes

getTransactionsForAddress combine la recherche de signatures et la récupération des transactions en un seul appel avec filtrage côté serveur. Il prend en charge les plages de temps/slot, le filtrage des comptes de jetons et la pagination.

Utiliser sendSmartTransaction pour les envois standards

Il simule automatiquement, estime les unités de calcul, récupère les frais prioritaires, et confirme. Ne construisez pas manuellement les instructions ComputeBudget — le SDK les ajoute automatiquement.

Utiliser Helius Sender pour une latence ultra-faible

Pour les transactions sensibles au temps (arbitrage, sniping, liquidations), utiliser sendTransactionWithSender. Il passe par l’infrastructure multi-régionale de Helius et Jito.

Utiliser getAssetBatch pour plusieurs actifs

Lors de la récupération de plusieurs actifs, regroupez-les. Ne pas appeler getAsset dans une boucle.

Utiliser les webhooks ou WebSockets au lieu du polling

Ne pas interroger getTransactionsForAddress dans une boucle. Utilisez les webhooks pour les notifications serveur à serveur ou les WebSockets pour le streaming client en temps réel.

Pagination

Le SDK utilise différentes stratégies de pagination selon la méthode.

Basé sur les jetons/cursors (Méthodes RPC V2)

Basé sur les pages (API DAS)

Filtre tokenAccounts

Lors de la requête getTransactionsForAddress, le filtre tokenAccounts contrôle si l’activité du compte de jetons est incluse :

changedSinceSlot — Récupération de Compte Incrémentielle

changedSinceSlot retourne uniquement les comptes modifiés après un slot donné. Utile pour les flux de synchronisation ou d’indexation. Pris en charge par getProgramAccountsV2, getTokenAccountsByOwnerV2, getAccountInfo, getMultipleAccounts, getProgramAccounts, et getTokenAccountsByOwner.

Erreurs Communes

  1. transactionDetails: "full" n’est pas par défaut — Par défaut, getTransactionsForAddress retourne uniquement les signatures. Définissez transactionDetails: "full" pour obtenir les données complètes de transaction.
  2. Ne pas ajouter d’instructions ComputeBudget avec sendSmartTransaction — Le SDK les ajoute automatiquement. Ajouter les vôtres entraîne des instructions en double et l’échec de la transaction.
  3. Les frais prioritaires sont en microlamports par unité de calcul — Pas en lamports. Les valeurs de getPriorityFeeEstimate sont déjà dans l’unité correcte pour SetComputeUnitPrice.
  4. La pagination DAS commence à 1page: 1 est la première page, pas page: 0.
  5. blockTime est en secondes Unix, pas en millisecondes — Utilisez Math.floor(Date.now() / 1000) lors du filtrage par blockTime.
  6. getAsset masque par défaut les jetons fongibles — Passez options: { showFungible: true } pour les inclure.
  7. Les flux WebSocket nécessitent un nettoyage — Utilisez toujours un signal AbortController et appelez helius.ws.close() lorsque terminé pour éviter les fuites de connexion.
  8. Définir maxSupportedTransactionVersion: 1 lors de la récupération des transactions. getTransaction, getBlock, et getTransactionsForAddress avec transactionDetails: "full" échouent avec l’erreur -32015 sur transaction v1 autrement. Sur les transactions v1, les frais prioritaires sont message.transactionConfig.priorityFee, un total en lamports; il n’y a pas d’instructions ComputeBudget à scanner. Voir Support des transactions v1.

Gestion des Erreurs et Réessais

Le SDK lance des objets Error natifs avec le code de statut HTTP intégré dans la chaîne de message (par ex., "API error (429): ..."). Il n’y a pas de propriété .status sur l’objet error, donc la détection du statut nécessite l’analyse du message.