---
title: "Pourquoi un portefeuille affiche-t-il parfois un solde de jetons erroné ?"
description: "Comprenez les écarts de solde entre portefeuilles et indexeurs, l'effet du bloc et de la comptabilité du jeton, et la vérification sûre de l'état on-chain."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Pourquoi un portefeuille affiche-t-il parfois un solde de jetons erroné ?
> À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Les actifs numériques et transactions on-chain peuvent entraîner des pertes irréversibles.
## Réponse directe
Le solde d'un portefeuille est une vue dérivée, pas l'autorité sur la propriété. Il combine souvent lecture RPC, index d'événements, métadonnées, prix, filtre antispam et cache. Chaque couche peut être périmée, viser le mauvais réseau ou contrat, ou mal interpréter le jeton. Une absence n'établit pas une perte ; un chiffre visible ne garantit ni transfert, ni rachat, ni valeur.
Pour un ERC-20 classique, commencez par `balanceOf` pour le compte exact, à un bloc précis de la bonne chaîne. Ce résultat ne représente que des unités selon le contrat. Jetons à rebase, parts de coffre, actifs enveloppés et positions de protocole peuvent exiger une conversion supplémentaire.
## Fonctionnement
L'affichage réunit généralement quatre voies :
- **État du contrat :** le nœud RPC exécute `balanceOf` via `eth_call` au bloc choisi.
- **Index d'événements :** un service parcourt les journaux `Transfer` pour découvrir les jetons et actualiser l'historique.
- **Métadonnées et valorisation :** `decimals`, symbole, listes, taux et prix convertissent l'entier brut.
- **Politique d'interface :** le portefeuille peut masquer le spam, regrouper des comptes, être en retard ou garder un cache.
ERC-20 définit `balanceOf` et impose `Transfer` aux transferts standard. Une base événementielle peut néanmoins omettre ou doubler des journaux, démarrer trop tard, mal traiter une réorganisation ou méconnaître une comptabilité particulière. Les événements prouvent des transitions, pas l'état actuel. Un mauvais `decimals` déforme aussi un entier juste.
Le bloc compte : JSON-RPC accepte `latest`, `safe` et `finalized`, tandis que les fournisseurs peuvent suivre des têtes différentes. EIP-1898 fixe des lectures liées au même hash de bloc et peut exiger un bloc canonique. Sans référence commune, deux lectures valides peuvent décrire des états distincts.
Procédez ainsi :
1. Confirmez réseau et `chainId` ; les soldes source et destination d'un pont sont dans des registres distincts.
2. Obtenez le contrat auprès d'une source fiable ou d'un registre vérifié, jamais par le seul symbole.
3. Vérifiez compte, norme et nature : jeton de base, enveloppé, part de coffre ou reçu.
4. Interrogez `balanceOf` via deux RPC indépendants au même numéro ou hash de bloc ; conservez entier brut et `decimals` séparément.
5. Contrôlez reçu, statut, contrat, journaux et bloc canonique ; comparez l'état avant et après à des blocs explicites.
6. Pour rebase ou parts, utilisez la conversion et le rachat documentés. Dans ERC-4626, `balanceOf` donne les parts ; `convertToAssets` estime les actifs sans garantir le montant exact du rachat.
## Exemple
L'explorateur confirme le transfert à Lina, mais son portefeuille affiche zéro. Deux RPC donnent le même `balanceOf` positif au même bloc finalisé ; reçu et journal sont canoniques et viennent du bon contrat. L'index, le filtre ou le cache est probablement en retard : importer le contrat vérifié ou attendre vaut mieux que renvoyer. Un autre `balanceOf` sur le contrat vérifié distingue les données anciennes d'un actif réel.
À l'inverse, un symbole connu peut afficher un solde alors que `balanceOf` du contrat vérifié vaut zéro : autre contrat homonyme ou ancien réseau. Pour un coffre, les parts peuvent être exactes mais la valeur fausse faute de conversion actuelle.
## Risques et contrôles
- **Mauvaise chaîne ou adresse :** vérifiez `chainId`, compte et contrat complets avant toute correction.
- **RPC obsolète :** comparez des fournisseurs sur un bloc explicite, sans mélanger des `latest` pris à des instants différents.
- **Réorganisation :** traitez les blocs récents comme provisoires et revérifiez le caractère canonique du reçu.
- **Lacune d'index :** rescanner depuis un bloc connu, rapprocher journaux et état, et annuler les blocs orphelins.
- **Comptabilité non standard :** ne reconstituez pas rebase, coffre ou reçu par somme des `Transfer` sans documentation.
- **Erreur de métadonnée ou prix :** séparez unités brutes, quantité et valeur ; le prix ne change pas le solde, `decimals` change l'affichage.
- **Jeton ou interface malveillant :** consulter n'exige aucune autorisation ni signature ; refusez les liens ou transactions de « rafraîchissement ».
Si l'écart persiste, cessez les transferts et gardez réseau, compte, contrat, numéro et hash de bloc, réponses RPC et hash de transaction. Vérifiez support du bloc, mise à niveau, pause, rebase, migration ou finalisation du pont. Utilisez les canaux publics sans révéler phrase de récupération ni clé privée.
Un solde juste ne garantit pas la sortie. Vérifiez restrictions, rachat, liquidité, frais et permissions. Ne faites un petit test qu'après vérification ; augmenter gas ou slippage ne répare pas l'index.
## Idées reçues
- **« L'écran du portefeuille est la blockchain. »** C'est une vue assemblée avec des données on-chain et hors chaîne.
- **« La somme des journaux Transfer donne toujours le solde. »** L'index peut être faux et certains jetons exigent une conversion.
- **« Plus de confirmations rafraîchissent le portefeuille. »** Elles réduisent l'incertitude, sans forcer cache ou indexeur.
- **« Un solde positif est vendable. »** Règles, pauses, limites, liquidité ou contrat malveillant peuvent bloquer la sortie.
- **« Je dois signer pour voir mon solde. »** Une lecture publique n'exige ni approbation, ni signature, ni phrase de récupération.
## Sujets connexes
- [Norme ERC-20](/fr/crypto/erc20/)
- [Nœud RPC](/fr/crypto/rpc-node/)
- [Réorganisation de chaîne](/fr/crypto/chain-reorg/)
- [Jeton à rebase](/fr/crypto/rebasing-token/)
- [Vérification du contrat](/fr/crypto/token-contract-verification/)
## Sources
- [ERC-20 : norme de jeton](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté le 2026-08-21)
- [API JSON-RPC](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consulté le 2026-08-21)
- [EIP-1898 : ajout de blockHash aux méthodes defaultBlock](https://eips.ethereum.org/EIPS/eip-1898) - Ethereum Improvement Proposals (consulté le 2026-08-21)
- [ERC-4626 : coffres tokenisés](https://eips.ethereum.org/EIPS/eip-4626) - Ethereum Improvement Proposals (consulté le 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/token-balance-indexing-risk/index.mdx