Passer au contenu principal
POST
Le corps de la requête, le schéma de réponse et les exemples de cette page sont générés à partir de la définition OpenAPI. Scan parcourt l’historique d’une adresse, conserve les transactions qui correspondent à vos critères match et analyse uniquement celles-ci. Utilisez-le au lieu de parcourir l’historique des transactions analysées page par page et de le filtrer côté client. Par défaut, chaque élément de data utilise la même structure TransactionResult que celle renvoyée par Parse Transactions. Définissez returnShape pour obtenir uniquement les signatures correspondantes ou seulement leur nombre. La réponse comprend également un résumé scan qui indique jusqu’où l’analyse est allée et pourquoi elle s’est arrêtée.

​
Fonctionnement de Scan

  1. Scan récupère l’historique de l’adresse par pages pouvant contenir jusqu’à 1 000 transactions, dans sortOrder, selon les limites slot, time et de signature que vous définissez.
  2. Il conserve les transactions qui correspondent à tous les critères définis dans match.
  3. Il s’arrête dès que l’une de ces conditions est remplie : limit correspondances trouvées (uniquement avec la structure transactions par défaut), budget.maxScannedTransactions transactions analysées, fin de l’historique ou de la fenêtre, ou limite de temps de la requête atteinte.
Une analyse qui s’arrête prématurément reste un 200. Relancez-la avec le paginationToken renvoyé tant qu’il est présent, même lorsque data est vide.

​
Critères de correspondance

match est obligatoire. Définissez programs, mints ou les deux. Lorsque vous définissez les deux, une transaction doit correspondre aux deux.

​
Correspondance par programme

programs répertorie jusqu’à 20 programmes, chacun une seule fois au maximum. Une transaction correspond lorsqu’elle contient une instruction de l’un de ces programmes, de premier niveau ou interne (CPI), dans la portée scope du programme. Pour chaque programme, vous pouvez affiner la correspondance :
  • instructions : noms d’instructions issus de n’importe quelle version de l’IDL du programme, tels qu’ils sont écrits dans l’IDL ou en snake_case. Un nom introuvable dans les IDL du programme renvoie 400.
  • discriminators : préfixes des données d’instruction, chacun composé de 1 à 8 octets encodés en hexadécimal avec un préfixe 0x facultatif. Utilisez-les pour les programmes sans IDL.
  • Définissez l’une des listes ou les deux. Avec les deux, une instruction correspond lorsqu’elle fait partie des instructions nommées ou lorsque ses données commencent par l’un des discriminateurs. Omettez les deux pour accepter n’importe quelle instruction du programme.
  • Chaque liste accepte au maximum 50 entrées par programme.
Pour confirmer les noms d’instructions décodées d’un programme, utilisez la méthode describeProgram de Parsed Streams.

​
Correspondance par émission

mints répertorie jusqu’à 20 objets de la forme { "mint": "...", "scope": "address" }, chaque émission une seule fois au maximum. Une transaction correspond lorsqu’un de ses soldes de tokens avant ou après la transaction concerne l’une des émissions, dans la portée scope de cette émission. Lorsque vous analysez un portefeuille pour une émission, définissez tokenAccounts sur balanceChanged. Par défaut, l’historique exclut les transactions qui concernent uniquement les comptes de tokens du portefeuille et non le portefeuille lui-même, ce qui inclut de nombreux transferts de tokens entrants.

​
Correspondance avec le SOL natif

Le SOL natif n’a pas de soldes de tokens. Scan établit donc la correspondance à partir des lamports. Utilisez l’émission de SOL natif So11111111111111111111111111111111111111111 (le SOL enveloppé est So11111111111111111111111111111111111111112) :
  • Avec la portée address, une transaction correspond lorsque le nombre de lamports de l’adresse analysée a changé.
  • Avec la portée transaction, elle correspond lorsque le nombre de lamports de n’importe quel compte a changé.
Les frais facturés au payeur ne sont pas pris en compte. Chaque compte est comparé individuellement : les lamports qui quittent un compte puis y reviennent au cours de la même transaction ne sont donc pas pris en compte. La correspondance avec le SOL natif détecte les SOL qu’un programme verse sans instruction de transfert, par exemple lors d’une vente Pump.fun. Elle détecte également les mouvements accessoires, comme les pourboires Jito ainsi que le loyer payé pour des comptes ou remboursé depuis ceux-ci.

​
Portée de la correspondance

Chaque programme et chaque émission accepte une valeur scope : Utilisez la portée transaction lorsque l’adresse analysée figure dans la transaction, mais pas dans l’instruction ou le solde recherché. Par exemple, l’adresse paie uniquement les frais, exécute une transaction multisignature ou est absente d’un CPI d’événement Anchor. L’analyse de l’émission d’un token pour rechercher des transactions qui détiennent également des USDC nécessite la portée transaction sur l’entrée USDC. La propriété du compte de tokens provient de la valeur owner enregistrée sur chaque solde de tokens. Les transactions plus anciennes qui ne l’enregistrent pas correspondent à la portée address uniquement sur address lui-même.

​
Structures de retour

returnShape définit le contenu de la réponse pour les correspondances : signatures et count ignorent limit et rawTransaction. Ils renvoient toutes les correspondances de la plage analysée par une requête. Ils s’arrêtent donc uniquement sur windowEnd, budget ou deadline. Pour compter un historique entier, continuez à appeler l’API avec paginationToken et additionnez les valeurs scan.matchedTransactions. Chaque élément de data avec returnShape: "signatures" se présente comme suit :
Les trois structures ont le même coût, car les crédits dépendent des pages d’historique analysées et non des données renvoyées.

​
Exemples de requêtes

​
Achats et ventes Pump.fun

Analysez l’historique du programme Pump.fun pour rechercher les instructions buy et sell :
Pump.fun comporte également des variantes telles que buy_exact_sol_in, buy_v2 et sell_v2. Répertoriez tous les noms d’instructions que vous souhaitez rechercher.

​
Achats et ventes d’un token

Pour obtenir les échanges Pump.fun d’un token, analysez l’adresse d’émission du token plutôt que le programme. L’historique de l’émission contient uniquement l’activité de ce token, et chaque instruction d’achat ou de vente répertorie l’émission comme compte. Elle correspond donc avec la portée address par défaut :
Pour conserver uniquement les transactions du token qui impliquent également un compte de tokens USDC, ajoutez USDC avec la portée transaction. Avec la portée address par défaut, un solde USDC devrait appartenir à l’adresse d’émission. Aucune transaction ne correspondrait donc :

​
Échanges d’un portefeuille sur deux programmes

Répertoriez plusieurs programmes pour rechercher un appel à l’un d’entre eux. Cette requête renvoie uniquement les signatures des échanges Pump.fun et PumpSwap d’un portefeuille :

​
Activité USDC d’un portefeuille sur une période

Analysez l’historique d’un portefeuille pour rechercher les transactions qui ont concerné des USDC en 2025. tokenAccounts: "balanceChanged" inclut les transferts qui ont concerné uniquement le compte de tokens USDC du portefeuille :
Pour obtenir uniquement le nombre de transactions correspondantes, ajoutez "returnShape": "count".

​
Mouvements de SOL d’un portefeuille

Recherchez dans un portefeuille les transactions qui ont modifié son solde de SOL, au-delà des frais payés, pendant l’année 2025. Cela inclut les SOL qu’un programme a versés sans instruction de transfert :

​
Pagination et motifs d’arrêt

scan.stoppedOn indique pourquoi la requête s’est terminée : scan.scannedThrough fournit le slot et l’heure de bloc de la dernière transaction analysée, afin que vous puissiez rendre compte de la progression dans les historiques volumineux. L’analyse d’une instruction rare peut épuiser son budget sans trouver de correspondance. La réponse contient alors un tableau data vide, mais renvoie tout de même un paginationToken. Poursuivez donc l’analyse :
Cette boucle poursuit l’analyse jusqu’à épuisement de l’historique :
scan-pumpfun-trades.js
Analysez l’adresse la plus précise possible. Chaque transaction de l’historique de l’adresse est décomptée du budget. Moins une adresse comporte de transactions sans rapport, plus chaque requête trouve de correspondances.

​
Crédits

Chaque analyse coûte 10 crédits plus 1 crédit par page d’historique analysée. Une page contient jusqu’à 1 000 transactions. Une analyse avec le budget par défaut de 10 000 transactions coûte donc au maximum 20 crédits. Une page interrompue par l’échéance n’est ni analysée ni facturée. Chaque réponse indique son coût dans scan.creditsCharged. Consultez Crédits pour connaître la tarification des forfaits.

​
Erreurs

Les erreurs au niveau de la requête renvoient un corps JSON avec un message error, tel que {"error": "limit must be between 1 and 100"}. Un corps comportant un champ inconnu, comme includeRawTransaction (utilisez rawTransaction), ou avec mints sous forme de chaînes simples au lieu d’objets { "mint": "..." }, renvoie {"error": "invalid request payload"}.

​
Paramètres de la requête

​
string
requis
Adresse dont l’historique est analysé.
​
object
requis
Critères auxquels une transaction doit correspondre. Définissez programs, mints ou les deux. Lorsque les deux sont définis, une transaction doit correspondre aux deux.
​
array
Programmes à rechercher, 20 au maximum, chacun une seule fois au maximum. Une transaction correspond lorsqu’elle contient une instruction de l’un de ces programmes, de premier niveau ou interne (CPI), dans la portée scope du programme.
​
string
requis
Adresse du programme.
​
array
Noms d’instructions issus de n’importe quelle version de l’IDL du programme, tels qu’ils sont écrits dans l’IDL ou en snake_case. 50 au maximum. Peut être combiné avec discriminators.
​
array
Préfixes des données d’instruction, chacun composé de 1 à 8 octets encodés en hexadécimal avec un préfixe 0x facultatif. 50 au maximum. Peut être combiné avec instructions.
​
string
défaut:"address"
Instructions du programme à prendre en compte. address prend uniquement en compte les instructions contenant un compte qui est address, un compte de tokens appartenant à address ou un compte de tokens dont l’émission est address, ou chaque instruction lorsque address est le programme. transaction prend en compte toute instruction du programme dans la transaction.
  • address
  • transaction
​
array
Émissions à rechercher, 20 au maximum, chacune une seule fois au maximum. Une transaction correspond lorsqu’un de ses soldes de tokens avant ou après la transaction concerne l’une de ces émissions, dans la portée scope de l’émission.
​
string
requis
Adresse d’émission du token. L’émission de SOL natif So11111111111111111111111111111111111111111 établit la correspondance à partir des changements de lamports plutôt que des soldes de tokens, sans prendre en compte les frais.
​
string
défaut:"address"
Soldes de tokens de l’émission à prendre en compte. address prend uniquement en compte les soldes dont le compte de tokens est address ou lui appartient, ou dont l’émission est address. Pour le SOL natif, seuls les changements du nombre de lamports de address sont pris en compte. transaction prend en compte tout solde de l’émission dans la transaction. Pour le SOL natif, tout changement du nombre de lamports d’un compte est pris en compte.
  • address
  • transaction
​
string
défaut:"transactions"
Contenu de la réponse pour les correspondances : transactions (correspondances analysées dans data, jusqu’à limit), signatures (signature, slot, transactionIndex et blockTime par correspondance dans data), ou count (aucun data ; scan.matchedTransactions correspond au nombre de correspondances). signatures et count ignorent limit et rawTransaction.
  • transactions
  • signatures
  • count
​
number
défaut:"100"
Nombre maximal de correspondances à renvoyer avec la structure transactions, de 1 à 100.
​
object
Limites de la quantité d’historique qu’une requête peut analyser.
​
number
défaut:"10000"
Nombre maximal de transactions à analyser dans cette requête, de 1 à 10 000.
​
string
Analyse les transactions antérieures à cette signature.
​
string
Analyse les transactions postérieures à cette signature.
​
string
Curseur renvoyé par une analyse précédente. Sa structure est slot:transactionIndex.
​
string
défaut:"desc"
Ordre dans lequel l’historique est analysé et les correspondances sont renvoyées.
  • asc
  • desc
​
string
défaut:"confirmed"
Niveau d’engagement utilisé pour récupérer l’historique. processed n’est pas pris en charge.
  • confirmed
  • finalized
​
string
défaut:"succeeded"
Résultat d’exécution à inclure. Le filtrage a lieu avant la recherche de correspondances. Les transactions exclues ne sont donc pas décomptées du budget.
  • succeeded
  • failed
  • any
​
string
défaut:"none"
Indique s’il faut inclure les transactions qui référencent uniquement un compte de tokens appartenant à address, et non address lui-même : none les exclut, balanceChanged inclut celles qui modifient le solde du compte de tokens et all les inclut toutes. Utilisez balanceChanged lorsque vous analysez un portefeuille par émission.
  • none
  • balanceChanged
  • all
​
number
Slot minimal auquel la requête peut être évaluée.
​
string
défaut:"none"
Encodage de la transaction Solana d’origine renvoyée sous rawTransaction pour chaque résultat réussi, dans la structure getTransaction. S’applique uniquement à la structure transactions.
  • none
  • json
  • jsonParsed
  • base64
​
object
Limites de comparaison des slots. Chaque limite est facultative.
​
number
Recherche les valeurs supérieures à cette valeur.
​
number
Recherche les valeurs supérieures ou égales à cette valeur.
​
number
Recherche les valeurs inférieures à cette valeur.
​
number
Recherche les valeurs inférieures ou égales à cette valeur.
​
object
Limites de comparaison de l’heure de bloc en secondes Unix. Chaque limite est facultative.
​
number
Recherche les valeurs supérieures à cette valeur.
​
number
Recherche les valeurs supérieures ou égales à cette valeur.
​
number
Recherche les valeurs inférieures à cette valeur.
​
number
Recherche les valeurs inférieures ou égales à cette valeur.

Autorisations

​
api-key
string
query
requis

Corps

application/json

Corps de la requête permettant d'analyser l'historique d'une adresse afin de trouver les transactions correspondantes.

​
address
string
requis

Adresse dont l'historique est analysé.

​
match
object
requis

Critères auxquels une transaction doit correspondre. Définissez programs, mints ou les deux. Lorsque les deux sont définis, une transaction doit correspondre aux deux.

​
returnShape
enum<string>
défaut:transactions

Contenu de la réponse pour les correspondances : transactions (correspondances analysées dans data, jusqu'à limit), signatures (signature, slot, transactionIndex et blockTime pour chaque correspondance dans data) ou count (aucune donnée data ; scan.matchedTransactions correspond au nombre de correspondances). signatures et count ignorent limit et rawTransaction.

Options disponibles:
transactions,
signatures,
count
​
limit
integer
défaut:100

Nombre maximal de correspondances à renvoyer avec le format transactions, de 1 à 100.

Plage requise: 1 <= x <= 100
​
budget
object

Limites du volume d'historique qu'une requête peut analyser.

​
beforeSignature
string

Analyse les transactions antérieures à cette signature.

​
afterSignature
string

Analyse les transactions postérieures à cette signature.

​
paginationToken
string

Curseur renvoyé par une analyse précédente. Son format est slot:transactionIndex.

​
sortOrder
enum<string>
défaut:desc

Ordre dans lequel l'historique est analysé et les correspondances sont renvoyées.

Options disponibles:
asc,
desc
​
commitment
enum<string>
défaut:confirmed

Niveau d'engagement utilisé pour récupérer l'historique. processed n'est pas pris en charge.

Options disponibles:
confirmed,
finalized
​
status
enum<string>
défaut:succeeded

Résultat d'exécution à inclure. Le filtrage est effectué avant la recherche des correspondances ; les transactions exclues ne sont donc pas comptabilisées dans le budget.

Options disponibles:
succeeded,
failed,
any
​
tokenAccounts
enum<string>
défaut:none

Indique s'il faut inclure les transactions qui référencent uniquement un compte de jetons détenu par address, et non address elle-même : none les exclut, balanceChanged inclut celles qui modifient le solde du compte de jetons et all les inclut toutes. Utilisez balanceChanged lorsque vous analysez un portefeuille par émission.

Options disponibles:
none,
balanceChanged,
all
​
minContextSlot
integer

Slot minimal auquel la requête peut être évaluée.

​
rawTransaction
enum<string>
défaut:none

Encodage de la transaction Solana d'origine renvoyée sous rawTransaction pour chaque résultat réussi, au format getTransaction. S'applique uniquement au format transactions.

Options disponibles:
none,
json,
jsonParsed,
base64
​
slot
object

Bornes de comparaison des slots. Chaque borne est facultative.

​
time
object

Bornes de comparaison de l'heure du bloc en secondes Unix. Chaque borne est facultative.

Réponse

Les correspondances au format returnShape demandé et un résumé de l'analyse. Un résultat partiel renvoie toujours un code 200. Continuez avec paginationToken tant qu'un jeton est renvoyé.

Les correspondances au format returnShape demandé et un résumé de l'analyse.

​
data
object

Résultat du parseur par signature.

​
paginationToken
string

Curseur à partir duquel l'analyse suivante continue. Absent lorsque l'analyse a atteint la fin de l'historique ou de la fenêtre.

​
scan
object

Progression de l'analyse et raison de son arrêt.