Passer au contenu principal
L’état historique des comptes est en version bêta. Les paramètres, la tarification, les formats de réponse et la couverture des données peuvent changer.

Qu’est-ce que l’état historique d’un compte ?

Les méthodes RPC Solana standard comme getAccountInfo et getTokenAccountsByOwner renvoient uniquement l’état actuel d’un compte. Les validateurs ne conservent que la dernière version de chaque compte. Chaque écriture remplace donc la précédente. L’historique des transactions ne comble pas cette lacune : getTransaction et getBlock renvoient les instructions, les journaux et les variations de solde, mais pas les données de compte écrites par un programme. Les méthodes de comptes historiques de Helius renvoient les comptes tels qu’ils étaient à un slot passé, ou immédiatement après une transaction précise au sein de ce slot. Comme vous pouvez lire l’état entre deux transactions du même slot, vous pouvez voir exactement ce qu’une transaction a modifié, même lorsqu’un compte fait l’objet de plusieurs écritures dans un seul slot. Utilisez-les pour :
  • Vérifier les soldes de jetons d’un portefeuille à un instant donné, à des fins d’audit, de comptabilité ou de déclaration fiscale
  • Déboguer une transaction en lisant les comptes qu’elle a affectés juste avant et juste après son exécution
  • Lire les comptes d’un protocole, comme des pools, des coffres ou des oracles, à un slot passé sans rejouer vous-même le registre
Ces méthodes RPC sont exclusives à Helius. Elles ne font pas partie du RPC Solana standard.

Quelle méthode utiliser ?

Les deux méthodes acceptent les mêmes trois paramètres : une adresse, un objet de requête qui sélectionne la position dans l’historique et un objet de configuration.

Disponibilité et tarification

  • Offres : offre Business et offres supérieures dans les offres.
  • Coût : 0 crédit par appel pendant la bêta (tarification susceptible de changer).
  • Limites de débit : getHistoricalAccountInfo autorise 100 requêtes par seconde, avec une rafale maximale de 100. getHistoricalTokenAccountsByOwner autorise 10 requêtes par seconde, avec une rafale maximale de 10. Ces limites sont distinctes de la limite de débit RPC de votre offre. Les requêtes qui les dépassent renvoient le code HTTP 429. Consultez les limites de débit.
  • Réseau : Mainnet uniquement. Appelez ces méthodes sur l’endpoint Mainnet standard, https://mainnet.helius-rpc.com, ou sur l’endpoint Gatekeeper, https://beta.helius-rpc.com. Devnet renvoie l’erreur -32601.

Couverture des données

L’historique est disponible à partir du slot 444,959,999 (7 septembre 2026). Il s’agit du dernier slot de l’époque 1029 ; il contient donc l’état au début de l’époque 1030. Les requêtes portant sur des slots antérieurs renvoient l’erreur -32018 (« Historique du compte indisponible »).

Choisir une position dans l’historique

Le deuxième paramètre est un objet de requête avec deux champs facultatifs, slot et transactionIndex : transactionIndex nécessite slot. Les écritures hors transaction, comme les récompenses d’époque, sont appliquées à la fin du slot. Une requête avec transactionIndex ne les inclut jamais, même pour la dernière transaction du slot. Pour les inclure, interrogez slot sans transactionIndex.

Lire l’état avant et après une transaction

Pour examiner les modifications apportées par une transaction, lisez le compte deux fois :
  • Après la transaction : interrogez ses propres slot et transactionIndex.
  • Avant la transaction : interrogez le même slot avec transactionIndex moins 1. Si la transaction est la première de son slot (index 0), interrogez le slot précédent sans transactionIndex.
getTransactionsForAddress renvoie slot et transactionIndex pour chaque transaction. Vous pouvez donc y trouver la position d’une transaction et la transmettre directement à ces méthodes.

Comprendre lastUpdatedAt

Chaque compte renvoyé inclut lastUpdatedAt, la position de l’écriture qui a produit l’état reçu :
  • slot et transactionIndex indiquent la dernière écriture effectuée à la position interrogée ou avant celle-ci. Dans l’exemple ci-dessus, une requête portant sur le slot 445,000,000 a renvoyé l’état écrit en dernier par la transaction à l’index 700 du slot 444,999,837.
  • transactionIndex: null signifie que l’écriture a eu lieu en dehors d’une transaction, comme pour les récompenses d’époque.
  • slot: 444959999 avec transactionIndex: null signifie que le compte n’a pas changé depuis le début de la couverture historique. Cela ne signifie pas que le compte a été écrit dans ce slot.

Signification d’une valeur null

value vaut null lorsque le compte n’existait pas à la position interrogée. Soit il n’avait pas encore été créé, soit il avait été fermé.
  • Une réponse null ne contient pas de lastUpdatedAt. Elle n’indique donc pas quand le compte a été créé ou fermé. Pour trouver ces transactions, utilisez getTransactionsForAddress.
  • Une adresse qui n’a jamais existé renvoie également null, et non une erreur.
  • Un slot antérieur à la couverture historique renvoie l’erreur -32018 pour toutes les adresses, que le compte ait existé ou non.

Remonter l’historique d’un compte

Utilisez lastUpdatedAt comme curseur pour répertorier tous les états qu’un compte a connus, du plus récent au plus ancien. Après chaque lecture, interrogez la position située juste avant l’écriture reçue : Arrêtez-vous lorsque value vaut null. Cela signifie que l’écriture que vous venez de dépasser a créé le compte. Arrêtez-vous également lorsque lastUpdatedAt.slot atteint 444,959,999, le début de la couverture historique.
  • Les comptes actuellement fermés renvoient null au dernier slot. Transmettez une position start correspondant à un moment où le compte existait encore.
  • Les écritures hors transaction passent au slot précédent. Si le même compte a aussi été écrit par une transaction plus tôt dans ce slot, le parcours ignore cet état.
  • Pour parcourir l’historique chronologiquement, répertoriez les transactions du compte de la plus ancienne à la plus récente avec getTransactionsForAddress et sortOrder: "asc". Lisez ensuite l’état aux slot et transactionIndex de chaque transaction.

Contexte de la réponse

context.slot dans chaque réponse correspond au dernier slot que Helius avait indexé au moment de traiter la requête. Ce n’est pas le slot que vous avez interrogé. Utilisez le slot de votre requête, ou lastUpdatedAt, pour interpréter les données reçues.

Paginer de manière cohérente

getHistoricalTokenAccountsByOwner renvoie les résultats une page à la fois. Chaque réponse inclut value.accounts et value.paginationKey.
  • Renvoyez paginationKey dans l’objet de configuration pour récupérer la page suivante.
  • Arrêtez-vous uniquement lorsque paginationKey vaut null. Une page peut être courte, voire vide, tout en étant suivie d’autres résultats.
  • Conservez le même slot pour toutes les pages. Si vous omettez slot, chaque page lit le dernier slot indexé et vos pages peuvent provenir de différents moments.
  • Définissez limit entre 1 et 5 000. La valeur par défaut est 5 000.

Encodages et données analysées

  • Les encodages pris en charge sont base64 (par défaut), base64+zstd et jsonParsed. base58 et binary ne sont pas pris en charge.
  • Les comptes de jetons jsonParsed utilisent le nombre de décimales du mint à la position interrogée. Les montants restent donc corrects même si le mint a changé depuis. Si le mint ne peut pas être lu à cette position, le compte utilise base64 comme solution de repli.
  • dataSlice fonctionne de la même manière que dans getAccountInfo.

Niveau de confirmation

commitment accepte finalized (par défaut) et confirmed. processed n’est pas pris en charge. Un slot plus récent que ce qu’autorise le niveau de confirmation demandé renvoie l’erreur -32004.

Erreurs

Questions fréquentes

Comment obtenir l’état d’un compte Solana à un slot précis ?

Appelez getHistoricalAccountInfo avec l’adresse et { "slot": S }. La méthode renvoie le compte tel qu’il était à la fin du slot S, dans le même format que getAccountInfo.

Puis-je lire un compte entre deux transactions du même slot ?

Oui. Ajoutez transactionIndex à la requête pour obtenir l’état du compte immédiatement après l’exécution de cette transaction. Consultez Lire l’état avant et après une transaction.

Jusqu’où puis-je remonter dans l’historique ?

L’historique commence au slot 444,959,999, le 7 septembre 2026. Les slots antérieurs renvoient l’erreur -32018.

Quelles offres incluent les méthodes de comptes historiques ?

L’offre Business et les offres supérieures. Les appels coûtent 0 crédit pendant la période bêta ; les prix sont susceptibles de changer. Les méthodes sont disponibles uniquement sur Mainnet.

Quelles sont les limites de débit ?

getHistoricalAccountInfo autorise 100 requêtes par seconde et getHistoricalTokenAccountsByOwner en autorise 10 par seconde. Ces deux limites sont distinctes de la limite de débit RPC de votre offre. Consultez Disponibilité et tarification.

Comment obtenir tous les états passés d’un compte ?

Remontez d’une écriture à la précédente à l’aide de lastUpdatedAt. Consultez Remonter l’historique d’un compte.

Ai-je besoin d’un nouveau SDK ?

Non. Il s’agit de méthodes JSON-RPC, vous pouvez donc utiliser n’importe quel client HTTP. Les bibliothèques clientes Solana standard ne les incluent pas. Envoyez donc directement la requête, comme dans les exemples ci-dessus.

Étapes suivantes

getHistoricalAccountInfo

Lisez un compte unique à un slot ou lors d’une transaction passée

getHistoricalTokenAccountsByOwner

Répertoriez les comptes de jetons d’un portefeuille à un slot passé

getTransactionsForAddress

Trouvez le slot et le transactionIndex des transactions que vous souhaitez examiner

Historical data overview

Historique des transactions, transferts et autres méthodes d’archivage