Skip to main content

Pourquoi migrer ?

La manière standard de récupérer l’historique des transactions d’une adresse sur Solana nécessite deux étapes : appeler getSignaturesForAddress pour lister les signatures, puis appeler getTransaction une fois par signature pour récupérer les détails. Pour 1 000 transactions, cela représente 1 001 requêtes HTTP. getTransactionsForAddress est une méthode RPC exclusive à Helius qui regroupe les deux étapes en un seul appel. Elle renvoie jusqu’à 1 000 transactions complètes par requête, avec filtrage, tri bidirectionnel et prise en charge des comptes de jetons que les méthodes standard n’ont pas. Résultat : environ 10 fois moins de crédits, 1 000 fois moins d’allers-retours, et pas de lotissement côté client, de gestion des limites de taux ou de logique de réessai pour la diffusion getTransaction.

Avant et après

Voici la même tâche — récupérer les 1 000 dernières transactions pour une adresse avec tous les détails — dans les deux modèles :
getTransactionsForAddress ne fait pas partie du RPC standard de Solana, donc @solana/web3.js n’a pas de Connection d’aide pour cela. Appelez-le avec une requête JSON-RPC brute comme indiqué ci-dessus — cela fonctionne sur le même point de terminaison Helius que le reste de votre trafic RPC.

Correspondance des paramètres

Chaque option de l’ancien flux en deux étapes a un équivalent direct. La plupart des noms restent inchangés — seule la pagination fonctionne différemment.

De getSignaturesForAddress

De getTransaction

Deux fonctionnalités n’ont pas d’équivalent ancien :
  • filters — affinez les résultats par blockTime, slot, status, tokenTransfer, ou tokenAccounts côté serveur au lieu de tout récupérer et de filtrer dans votre code.
  • sortOrder: "asc" — résultats chronologiques (le plus ancien en premier), que les méthodes standard ne peuvent pas retourner sans récupérer tout l’historique et le renverser.

Étapes de migration

1

Confirmez que vous êtes sur un point de terminaison Helius

getTransactionsForAddress est exclusif à Helius. Il fonctionne sur https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY (et devnet) — le même point de terminaison que vos appels existants utilisent déjà si vous êtes client Helius. Aucun changement de clé API ou de plan n’est nécessaire.
2

Remplacez la récupération en deux étapes par un seul appel

Supprimez l’appel getSignaturesForAddress et la boucle getTransaction. Faites une seule demande getTransactionsForAddress avec transactionDetails: "full", en reportant vos valeurs encoding, maxSupportedTransactionVersion, et commitment comme indiqué dans la correspondance des paramètres.Si vous avez seulement besoin de signatures (par exemple, pour alimenter un pipeline existant), utilisez plutôt transactionDetails: "signatures" — cela coûte 10 crédits au total par appel.
3

Mettez à jour la gestion des réponses

L’enveloppe de réponse change de trois manières :
  • Les résultats se trouvent dans result.data (un tableau), pas directement dans result.
  • Chaque entrée en mode complet est { slot, transactionIndex, blockTime, transaction, meta }. Les objets transaction et meta ont la même forme que ce que renvoie getTransaction, donc votre code de parsing est inchangé.
  • Les entrées en mode signatures correspondent à la sortie getSignaturesForAddress (signature, slot, err, memo, blockTime, confirmationStatus) plus un nouveau champ transactionIndex.
Une différence de comportement à garder : avec l’ancien modèle, un appel getTransaction pouvait retourner null pour une signature. Avec getTransactionsForAddress, chaque entrée dans result.data est une transaction complète — supprimez tout traitement des nulls pour les détails manquants.
4

Remplacez la pagination basée sur les signatures

Remplacez la boucle de curseur before pour paginationToken :
La boucle se termine lorsque paginationToken est null — plus besoin de comparer des listes de signatures ou de suivre la dernière signature vous-même.Si vous utilisiez until pour arrêter à une signature connue, remplacez-le par filters.signature: { gt: "KNOWN_SIGNATURE" }. Si vous l’utilisiez pour arrêter à un moment donné, filters.blockTime ou filters.slot est généralement plus approprié.
5

Optionnel : activez l'historique complet des jetons

L’ancien modèle manque entièrement l’activité du compte de jeton associé (ATA) à moins que vous n’appeliez également getTokenAccountsByOwner et récupériez des signatures pour chaque compte de jeton. Pour l’inclure, ajoutez un filtre :
balanceChanged renvoie les transactions qui référencent le portefeuille ou modifient le solde de tout compte de jeton qu’il possède, filtrant le spam. Voir comptes de jetons associés pour les options none/balanceChanged/all et l’avertissement pré-2022.
6

Vérifiez par rapport à l'ancienne sortie

Pour une adresse d’exemple, récupérez l’historique des deux manières et comparez les ensembles de signatures. Avec filters.tokenAccounts désactivé (configuration par défaut none), getTransactionsForAddress renvoie les mêmes transactions que getSignaturesForAddress pour la même plage. Déployez ensuite et supprimez l’ancien chemin de code.

Différences de comportement à revoir

La plupart des migrations sont un remplacement simple, mais vérifiez les points suivants avant de livrer :
  • Engagement. processed n’est pas pris en charge ; utilisez confirmed ou finalized. Si votre ancien code interrogeait l’historique récent à processed, basculez à confirmed.
  • Mesure. Les réponses de transactions complètes coûtent 10 crédits par 100 transactions renvoyées (minimum de 10 crédits) ; les réponses de seules signatures coûtent 10 crédits au total. L’ancien modèle coûtait 1 crédit par appel — moins cher par requête, mais bien plus cher par transaction récupérée. Les réponses échouées sont gratuites. Voir mesure.
  • Support réseau. Mainnet a une rétention illimitée. Devnet est supporté avec 2 semaines de rétention. Testnet n’est pas supporté.
  • Adresses réservées. Un petit ensemble d’adresses système (Programme de vote, Programme système, sysvars) se dirige vers des chemins archivaux ou retourne vide. Si vous indexez celles-ci, revoyez limitations et cas particuliers.
  • Adresses multiples. Comme l’ancien flux, une requête couvre une adresse. Interrogez les adresses en parallèle et fusionnez ; voir adresses multiples.

Questions fréquemment posées

Est-ce que getTransactionsForAddress est une méthode RPC standard de Solana ?

Non. C’est une méthode exclusive à Helius disponible sur les points de terminaison RPC de Helius. Le RPC standard de Solana et d’autres fournisseurs n’offrent que getSignaturesForAddress et getTransaction. Vos autres appels RPC ne sont pas affectés — la méthode se trouve sur le même point de terminaison avec toute la surface RPC standard.

Ai-je encore besoin de getTransaction après la migration ?

Seulement pour des recherches ponctuelles où vous avez déjà une signature et aucun contexte d’adresse, comme vérifier une transaction spécifique qu’un utilisateur a collée. Pour tout historique basé sur l’adresse — compléments, indexation, flux d’activité du portefeuille — getTransactionsForAddress remplace les deux méthodes.

Est-ce que cela fonctionne avec @solana/web3.js ?

La méthode n’est pas dans la classe Connection, mais elle fonctionne avec n’importe quel client HTTP contre votre URL RPC Helius. Utilisez fetch (ou l’équivalent dans votre langage) avec un corps JSON-RPC standard, comme indiqué dans les exemples ci-dessus. Vous pouvez continuer à utiliser Connection pour tout le reste.

Est-ce que ça renverra les mêmes transactions que getSignaturesForAddress ?

Oui. Avec les paramètres par défaut (filters.tokenAccounts: "none"), cela renvoie les transactions qui référencent l’adresse interrogée — le même ensemble que getSignaturesForAddress. Paramétrer tokenAccounts à balanceChanged ou all en renvoie plus : cela ajoute l’activité des comptes de jetons associés au portefeuille, que la méthode standard ne peut pas voir.

Combien cela coûte-t-il comparé à l’ancien modèle ?

Récupérer 1 000 transactions complètes coûte 100 crédits avec getTransactionsForAddress contre environ 1 001 crédits (et 1 001 requêtes) avec getSignaturesForAddress + getTransaction. Les réponses avec seulement des signatures coûtent 10 crédits au total par appel. Voir crédits Helius pour la tarification complète.

Laissez un agent IA faire la migration

Si vous utilisez Claude Code, Cursor ou un autre agent de codage, collez l’invite ci-dessous dans la session de l’agent de votre dépôt. Il trouve l’ancien modèle dans votre base de code et le réécrit.
L’invite est autonome — l’agent n’a pas besoin d’accès à cette page. Pour des documents prêts pour les agents, la recherche MCP et les compétences, voir Helius pour agents IA.

Prochaines étapes

Guide getTransactionsForAddress

Tutoriel complet couvrant les filtres, le tri, la pagination et les comptes de jetons.

Référence API

Schéma complet des requêtes et réponses.

Guide d'indexation

Utilisez getTransactionsForAddress pour compléter et synchroniser un index Solana.

Aperçu des données historiques

Comparez toutes les méthodes de données historiques de Solana.