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), utilisersendTransactionWithSender. 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 interrogergetTransactionsForAddress 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
-
transactionDetails: "full"n’est pas par défaut — Par défaut,getTransactionsForAddressretourne uniquement les signatures. DéfinisseztransactionDetails: "full"pour obtenir les données complètes de transaction. -
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. -
Les frais prioritaires sont en microlamports par unité de calcul — Pas en lamports. Les valeurs de
getPriorityFeeEstimatesont déjà dans l’unité correcte pourSetComputeUnitPrice. -
La pagination DAS commence à 1 —
page: 1est la première page, paspage: 0. -
blockTimeest en secondes Unix, pas en millisecondes — UtilisezMath.floor(Date.now() / 1000)lors du filtrage parblockTime. -
getAssetmasque par défaut les jetons fongibles — Passezoptions: { showFungible: true }pour les inclure. -
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. -
Définir
maxSupportedTransactionVersion: 1lors de la récupération des transactions.getTransaction,getBlock, etgetTransactionsForAddressavectransactionDetails: "full"échouent avec l’erreur-32015sur transaction v1 autrement. Sur les transactions v1, les frais prioritaires sontmessage.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 objetsError 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.