Aperçu
getTransactionsForAddress est une méthode RPC exclusive à Helius qui renvoie l’historique des transactions d’une adresse avec un filtrage avancé, un tri flexible et une pagination efficace. Elle ne fait pas partie du standard RPC de Solana.
Contrairement à getSignaturesForAddress, qui retourne uniquement des signatures et ignore les comptes de jetons associés, getTransactionsForAddress peut retourner des données complètes sur les transactions, y compris l’activité du compte de jetons associé (ATA) d’un portefeuille, en un seul appel. Cela en fait le chemin le plus rapide vers un historique complet d’adresse pour le remplissage rétroactif, l’indexation et l’analyse.
Cette méthode retourne jusqu’à 1 000 transactions complètes par appel.
Tri flexible
Triez chronologiquement (du plus ancien au plus récent) ou inversement (du plus récent au plus ancien).
Filtrage avancé
Filtrez par plages horaires, créneaux, signatures, statut et transferts de jetons.
Données transactionnelles complètes
Obtenez des détails complets sur les transactions en un seul appel, sans besoin de suivi getTransaction.
Comptes de jetons
Incluez les transactions pour les comptes de jetons associés à une adresse.
Quand l’utiliser
UtilisezgetTransactionsForAddress lorsque vous avez besoin de :
- Historique complet des jetons de portefeuille, y compris les comptes de jetons associés
- Un remplissage rétroactif rapide en un seul appel pour un indexeur ou un pipeline de données
- Analyse et rapport de transactions basés sur le temps ou les créneaux
- Filtrage par statut pour garder uniquement les transactions réussies ou échouées
- Relecture historique chronologique (tri du plus ancien au plus récent)
- Analyse de lancement de jetons : premières transactions de frappe et premiers détenteurs
- Historique de financement de portefeuille et découverte de contreparties
- Rapports de conformité et d’audit pour une période spécifique
getTransfersByAddress à la place.
Support réseau
Démarrage rapide
1
Obtenez votre clé API
Obtenez votre clé API depuis le Tableau de bord Helius.
2
Interrogez avec des fonctionnalités avancées
Obtenez toutes les transactions réussies pour un portefeuille entre deux dates, triées chronologiquement :
3
Comprendre les paramètres
Cet exemple montre les caractéristiques clés :
- transactionDetails : définissez sur
'full'pour obtenir des données de transaction complètes en un seul appel - sortOrder : utilisez
'asc'pour un ordre chronologique (du plus ancien au plus récent) ou'desc'pour le plus récent en premier - filters.blockTime : définissez des plages horaires avec
gte(supérieur ou égal) etlte(inférieur ou égal) - filters.status : filtrez uniquement
'succeeded'ou'failed'transactions - filters.tokenAccounts : incluez les transferts, frappes et brûlures pour les comptes de jetons associés
Paramètres de requête
string
requis
Clé publique encodée en Base-58 du compte pour lequel interroger l’historique des transactions
string
défaut:"signatures"
Niveau de détail de transaction à retourner :
signatures: Infos de signature de base (plus rapide)full: Données complètes de transaction (élimine le besoin pour les appels getTransaction, supporte une limite jusqu’à 1 000)
string
défaut:"desc"
Ordre de tri des résultats :
desc: Le plus récent en premier (par défaut)asc: Le plus ancien en premier (chronologique, idéal pour l’analyse historique)
number
défaut:"1000"
Nombre maximum de transactions à retourner :
- Jusqu’à 1000 lorsque
transactionDetails: "signatures" - Jusqu’à 1000 lorsque
transactionDetails: "full"
string
Jeton de pagination de la réponse précédente (format :
"slot:position")string
défaut:"finalized"
Niveau d’engagement :
finalized ou confirmed. L’engagement processed n’est pas pris en charge.object
Options de filtrage avancées pour affiner les résultats.
object
Filtrez par numéro de créneau à l’aide d’opérateurs de comparaison :
gte, gt, lte, ltExemple : { "slot": { "gte": 1000, "lte": 2000 } }object
Filtrez par horodatage Unix avec des opérateurs de comparaison :
gte, gt, lte, lt, eqExemple : { "blockTime": { "gte": 1640995200, "lte": 1641081600 } }object
Filtrez par signature de transaction à l’aide d’opérateurs de comparaison :
gte, gt, lte, ltExemple : { "signature": { "lt": "SIGNATURE_STRING" } }string
Filtrez par statut de réussite/échec des transactions :
succeeded: Uniquement les transactions réussiesfailed: Uniquement les transactions échouéesany: Les deux réussies et échouées (par défaut)
{ "status": "succeeded" }string
défaut:"none"
Filtrez les transactions pour les comptes de jetons associés :
none: Retournez uniquement les transactions qui font référence à l’adresse fournie (par défaut)balanceChanged: Retournez les transactions qui font référence à l’adresse fournie ou modifient le solde d’un compte de jetons détenu par l’adresse fournie (recommandé)all: Retournez les transactions qui font référence à l’adresse fournie ou à tout compte de jetons détenu par l’adresse fournie
{ "tokenAccounts": "balanceChanged" }object
Filtrez pour les transactions où l’adresse interrogée a participé à un transfert de jetons correspondant à une contrepartie, une direction, une frappe ou une plage de montants brute. Tous les champs sont optionnels et combinés par AND.Exemple :
{ "tokenTransfer": { "direction": "in", "mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v" } }string
Adresse de contrepartie. Correspond aux transferts dont l’autre côté est cette adresse.
string
défaut:"any"
Filtrez par direction du transfert par rapport à l’adresse interrogée :
in: Transferts reçus par l’adresse interrogéeout: Transferts envoyés par l’adresse interrogéeany: Transferts entrants et sortants
string
Frappe de jeton à filtrer.
object
Comparaison de montant en utilisant le montant brut sur la chaîne, et non le montant ajusté à l’interface utilisateur ou aux décimales. Supporte
gt, gte, lt, et lte.string
Format d’encodage pour les données de transaction (s’applique uniquement lorsque
transactionDetails: "full"). Idem que getTransaction API. Options : json, jsonParsed, base64, base58number
Définissez la version de transaction maximale à retourner. Si omis, seules les transactions héritées seront retournées. Définissez sur
1 pour inclure les transactions héritées, v0 et v1.number
Le créneau minimum auquel la requête peut être évaluée
Métrique
Les réponses réussies sont mesurées en fonction de ce qui est retourné :Réponse
La forme de la réponse dépend detransactionDetails. Le mode signatures renvoie des enregistrements de signatures légers ; le mode complet renvoie des objets complets de transaction et de métadonnées.
- Réponse Signatures
- Réponse Transaction Complète
Champs de réponse
Le champ
transactionIndex est exclusif à getTransactionsForAddress. D’autres points de terminaison similaires comme getSignaturesForAddress, getTransaction, et getTransactions n’incluent pas ce champ.
En mode complet, meta est l’objet de métadonnées de transaction complet — identique en forme à ce que getTransaction retourne. Il inclut preTokenBalances et postTokenBalances, vous pouvez donc calculer les changements de solde des jetons (par exemple, pour détecter les échanges) directement à partir de la réponse sans appels de suivi.
Filtres
Vous pouvez utiliser des opérateurs de comparaison pourslot, blockTime, et signature, plus les filtres spéciaux status, tokenAccounts, et tokenTransfer. La combinaison de plusieurs filtres réduit le résultat à leur intersection.
Opérateurs de comparaison
Ces opérateurs fonctionnent comme des requêtes de base de données pour vous donner un contrôle précis sur votre plage de données.Filtres énumérés
Exemples de filtres combinés :
Comptes de jetons associés
Sur Solana, un portefeuille ne détient pas directement des jetons. Au lieu de cela, le portefeuille possède des comptes de jetons, et ces comptes de jetons détiennent les jetons. Lorsque quelqu’un vous envoie de l’USDC, il va sur votre compte de jetons USDC, pas sur l’adresse principale de votre portefeuille. Cette méthode est unique car elle peut interroger l’historique complet des jetons, y compris les comptes de jetons associés d’un portefeuille (ATAs). Les méthodes RPC natives telles quegetSignaturesForAddress n’incluent pas les ATAs.
Le filtre tokenAccounts contrôle ce comportement :
none(par défaut) : Retourne uniquement les transactions qui font référence directement à l’adresse du portefeuille. Utilisez ceci lorsque vous vous intéressez uniquement aux interactions directes avec le portefeuille.balanceChanged(recommandé) : Retourne les transactions qui font référence à l’adresse du portefeuille ou modifient le solde d’un compte de jetons détenu par le portefeuille. Cela filtre le spam et les opérations non liées telles que les collectes de frais ou les délégations, vous donnant une vue claire des activités pertinentes du portefeuille.all: Retourne toutes les transactions qui font référence à l’adresse du portefeuille ou à tout compte de jetons détenu par le portefeuille.
tokenAccounts ne prend pas en charge les transactions antérieures à décembre 2022. Il dépend des métadonnées de transfert de jetons introduites à Solana sur le créneau 111,491,819. Pour couvrir les activités antérieures, consultez la solution de contournement des comptes de jetons historiques.
Filtre de transfert de jetons
Le filtretokenTransfer restreint les résultats aux transactions où l’adresse interrogée a participé à un transfert de jetons correspondant à des critères spécifiques : une contrepartie particulière, une frappe, une direction ou une plage de montants.
Utilisez-le pour répondre à des questions comme :
- Quand ce portefeuille a-t-il reçu de l’USDC d’une contrepartie spécifique ?
- Affichez chaque transfert sortant supérieur à 1 000 jetons.
- Quand ce portefeuille a-t-il déjà touché une frappe spécifique ?
filters de la configuration de la requête :
tokenTransfer sont optionnels. La combinaison de plusieurs champs est traitée comme AND.
Opérateurs de plage de montants :
Vous pouvez combiner les opérateurs de montants, comme
{ "gte": 1000000, "lte": 5000000 } pour une plage fermée. tokenTransfer se compose avec les autres filtres de niveau supérieur (slot, blockTime, status, et tokenAccounts); le résultat final est l’intersection.
Exemples
Analytique basée sur le temps
Générez des rapports mensuels de transactions :Création de frappe de jetons
Trouvez la transaction de création de frappe pour un jeton spécifique :Transactions de financement
Trouvez qui a financé une adresse spécifique :Transferts de jetons
Filtrez partokenTransfer pour isoler des mouvements de jetons spécifiques.
Entrées d’USDC vers une adresse :
Pagination
Lorsque vous avez plus de transactions que votre limite, utilisez lepaginationToken de la réponse pour récupérer la page suivante. Le jeton est une simple chaîne au format "slot:position" qui indique à l’API où continuer.
Utilisez le jeton de pagination de chaque réponse pour récupérer la page suivante :
Adresses multiples
Vous ne pouvez pas interroger plusieurs adresses dans une seule requête. Chaque requête d’adresse compte comme une requête API distincte et est mesurée en conséquence. Pour récupérer les transactions de plusieurs adresses, interrogez chaque adresse dans la même fenêtre de temps ou de créneaux, puis fusionnez et triez :Bonnes pratiques
Performance. UtiliseztransactionDetails: "signatures" lorsque vous n’avez pas besoin de données transactionnelles complètes. Utilisez des tailles de page raisonnables pour de meilleurs temps de réponse, et filtrez par plages horaires ou créneaux spécifiques pour des requêtes plus ciblées.
Filtrage. Commencez avec des filtres larges et diminuez progressivement. Utilisez des filtres basés sur le temps pour les workflows d’analytique et de rapport, et combinez plusieurs filtres pour des requêtes précises qui ciblent des types de transactions ou des périodes spécifiques.
Pagination. Stockez les jetons de pagination lorsque vous avez besoin de reprendre des requêtes importantes plus tard. Surveillez la profondeur de pagination pour la planification de performance, et utilisez l’ordre croissant lorsque vous avez besoin de rejouer des événements historiques dans l’ordre chronologique.
Gestion des erreurs. Gérez les limites de taux de manière élégante avec un backoff exponentiel. Validez les adresses avant de faire des requêtes, et mettez en cache les résultats lorsque cela est approprié pour réduire l’utilisation de l’API.
Limitations et cas particuliers
Un petit ensemble d’adresses route vers l’archivage hérité, est limité à la solution de contournement de scan de créneaux, ou renvoie vide. La découverte de comptes de jetons avant le créneau 111,491,819 nécessite également une solution de contournement. Développez les sections ci-dessous pour tous les détails.Adresses non prises en charge et spécialement routées
Adresses non prises en charge et spécialement routées
Routées vers l’ancien archivage. Les requêtes pour ces adresses sont routées vers notre ancien système d’archivage.
Solution de contournement du scan de créneaux. Les requêtes pour ces adresses sont redirigées vers notre nouveau système d’archivage, et sont interrogeables via une approche de scan créneau par créneau (maximum 100 créneaux). Cependant, ces données ne sont pas indexées.
Retourne vide (
is_reserved_address). Les requêtes sont transférées vers notre nouveau système d’archivage, cependant les données ne sont pas indexées, et les requêtes retournent vides.Solution de contournement : découverte de comptes de jetons historiques (avant le créneau 111,491,819)
Solution de contournement : découverte de comptes de jetons historiques (avant le créneau 111,491,819)
Pour les adresses avec de l’activité de compte de jetons avant le créneau 111,491,819, le filtre
tokenAccounts ne peut pas déterminer la propriété car le champ owner dans les métadonnées de solde de jetons n’existait pas encore. Pour obtenir des résultats complets, vous pouvez découvrir ces comptes de jetons manuellement en analysant les premières instructions de transaction, puis interroger getTransactionsForAddress en parallèle pour chaque compte.En quoi est-ce différent de getSignaturesForAddress?
Si vous connaissez la méthode standardgetSignaturesForAddress, getTransactionsForAddress réduit les workflows en plusieurs étapes à un seul appel et ajoute le filtrage, le tri et le support des comptes de jetons. Pour une conversion étape par étape du code existant, consultez le guide de migration.
Obtenez des transactions complètes en un seul appel
AvecgetSignaturesForAddress, vous avez besoin de deux étapes :
getTransactionsForAddress, c’est un seul appel :
Obtenez l’historique des jetons en un seul appel
AvecgetSignaturesForAddress, vous devez d’abord appeler getTokenAccountsByOwner puis interroger pour chaque compte de jetons :
getTransactionsForAddress, vous n’avez qu’à définir filters.tokenAccounts :
Capacités supplémentaires
Tri chronologique
Triez les transactions du plus ancien au plus récent avec
sortOrder: 'asc'.Filtrage basé sur le temps
Filtrez par plages horaires à l’aide des filtres
blockTime.Filtrage par statut
Obtenez uniquement les transactions réussies ou échouées avec le filtre
status.Pagination simplifiée
Utilisez
paginationToken au lieu de before/until.Étapes suivantes
Guide d'indexation
Utilisez getTransactionsForAddress pour le remplissage rétroactif et la synchronisation d’un index Solana.
getTransfersByAddress
Historique analysé, axé uniquement sur les transferts pour les paiements et la réconciliation.
Référence API
Schéma complet de requête et de réponse pour getTransactionsForAddress.
Vue d'ensemble des données historiques
Comparez toutes les méthodes de données historiques de Solana.