📖 PoR sans illusions : ce qu’il confirme réellement et où son utilité s’arrête
Gardez le repère : le PoR n’a de sens qu’avec réserves ≥ passifs + méthodologie claire + mises à jour régulières.
Proof of Reserves (PoR) est une preuve cryptographique qu’un exchange (ou un autre dépositaire) contrôle un volume suffisant d’actifs on-chain pour couvrir les soldes des clients à la date du snapshot. En pratique, le PoR répond à la question « les actifs existent-ils », mais ne répond pas à lui seul à « quel est le montant complet des dettes ».
Objectif : expliquer comment fonctionne le PoR, en quoi il diffère d’un audit financier, comment vérifier soi-même réserves et passifs, et quels signes indiquent le plus souvent un rapport vitrine.
Règle : si le rapport ne contient pas de passifs vérifiables ou si vous ne pouvez pas confirmer l’inclusion de votre solde, la valeur de ce PoR tombe au niveau d’une « démonstration de portefeuilles ».
Les exchanges cassent plus souvent non pas à cause des « nouvelles », mais à cause d’un manque de liquidité qui reste longtemps invisible pour les utilisateurs. Le PoR n’est donc utile qu’avec une lecture critique : passifs, couverture des actifs et méthodologie comptent davantage que de « beaux » chiffres.
🧩 Ce qu’est Proof of Reserves et pourquoi l’utilisateur en a besoin
Vous comprendrez ce que le PoR confirme techniquement, où il est impuissant et comment tirer un bénéfice pratique d’un rapport.
Proof of Reserves (PoR) est une preuve cryptographique qu’un exchange (ou un autre dépositaire) contrôle assez d’actifs on-chain pour couvrir les soldes des clients à la date du snapshot.
Le PoR est apparu comme réponse aux crises de confiance : le marché avait besoin de preuves vérifiables plutôt que de déclarations. La plupart des implémentations utilisent des arbres de Merkle (structures de hachage) permettant à l’utilisateur de confirmer que son solde est inclus dans le snapshot global des passifs sans révéler les données des autres.
| Ce que le PoR apporte | Ce que le PoR ne prouve pas |
|---|---|
| Visibilité on-chain des réserves : adresses et montants peuvent être vérifiés dans la blockchain | Solvabilité complète : dettes off-chain et obligations envers des contreparties peuvent rester cachées |
| Possibilité de vérifier l’inclusion du solde (Merkle-proof) si l’implémentation est correcte | État après le snapshot : demain, les réserves et les risques peuvent changer |
| Rapidité : les rapports peuvent être publiés régulièrement, pas seulement une fois par an | Qualité de la méthodologie : sans règles et périmètre clairs, le PoR devient facilement une vitrine |
Repère : une vérification honnête minimale revient toujours à comparer
réserves ≥ passifs. Si les passifs ne sont pas vérifiables, la confiance repose sur des déclarations, pas sur des faits.
Ce que cela donne en pratique
- Transparence : vous voyez les réserves dans la blockchain et pouvez vérifier adresses et montants.
- Vérifiabilité : avec un Merkle-proof, vous pouvez confirmer que votre solde est pris en compte dans le snapshot.
- Discipline de la plateforme : des rapports réguliers augmentent le coût des manœuvres et rendent un déficit caché plus difficile.
- Signal précoce : le PoR aide à comparer les plateformes par niveau de transparence sans attendre un audit.
Le PoR est un outil de contrôle utile, mais sa valeur dépend des passifs, de la méthodologie et de la régularité des mises à jour, pas d’un seul chiffre de « réserves ».
🛠️ Comment fonctionne Proof of Reserves : étapes du rapport et points de contrôle
Décomposons le PoR en éléments vérifiables : ce que l’exchange publie, ce que fixe la racine Merkle et où votre solde est vérifié.
Le PoR relie les réserves on-chain et le snapshot des passifs afin que l’utilisateur puisse confirmer l’inclusion de son solde. Le critère de base est réserves ≥ passifs à la date du snapshot.
Trois éléments sans lesquels le PoR ne fonctionne pas
Réserves — actifs sur des adresses on-chain publiées et contrôlées par la plateforme.
Passifs — total des soldes clients (liabilities) au moment du snapshot.
Arbre de Merkle — structure de hachage qui fixe l’ensemble des passifs et permet une preuve d’inclusion sans révéler les données des autres.
-
Publication des adresses de réserve. La plateforme montre les portefeuilles de garde (BTC/ETH/USDT, etc.).
À vérifier : le périmètre est expliqué, les adresses ne sont pas choisies à la carte, les montants se vérifient facilement dans la blockchain. -
Preuve de contrôle des adresses. Un message est signé avec les clés privées des portefeuilles.
À vérifier : il existe des signatures et une instruction de vérification claire, pas une « liste d’adresses à croire ». -
Snapshot des passifs et racine Merkle. Les soldes sont transformés en hachages et agrégés dans la racine Merkle (hachage racine du snapshot).
À vérifier : la racine Merkle est publiée, la date/heure du snapshot est indiquée clairement, la méthodologie de calcul des liabilities est décrite. -
Merkle-proof pour l’utilisateur. Le client reçoit une preuve du chemin jusqu’à la racine et confirme l’inclusion de son solde.
À vérifier : l’outil/script fonctionne, le résultat correspond à la racine Merkle, le solde est reflété correctement. -
Vérification de la couverture. On compare les réserves sur les adresses et les passifs du snapshot.
À vérifier : les liabilities sont indiquées en chiffre, la couverture est calculée de façon transparente, les exceptions et hypothèses ne sont pas cachées.
Mini-checklist PoR : (1) adresses + signatures de contrôle, (2) racine Merkle + date du snapshot, (3) Merkle-proof fonctionnel, (4) passifs publiés et règles de calcul.
AUP : pourquoi ce n’est pas un « audit complet » ?
zk/PoL : pourquoi les ajouter au PoR ?
Le PoR n’est utile que comme ensemble d’artefacts vérifiables — contrôle des adresses, racine Merkle, Merkle-proof et passifs transparents, ramenés au critère réserves ≥ passifs.
⚖️ PoR vs audit : différence avec une vérification complète de solvabilité
Le PoR montre la couverture par actifs on-chain à la date du snapshot, tandis qu’un audit évalue la résistance de l’entreprise à toutes les dettes et risques.
Proof of Reserves est une vérification ponctuelle : la plateforme démontre le contrôle des actifs on-chain et les compare aux passifs clients à la date du snapshot. C’est utile comme signal de transparence, mais cela ne revient pas par définition à une évaluation de santé financière.
Un audit de solvabilité (solvency audit — capacité à couvrir toutes les dettes) regarde plus large : crypto et fiat, obligations externes, prêts et garanties, risques conditionnels et hors bilan. Il est généralement réalisé selon les normes IFRS/GAAP (normes de reporting financier), nécessite un accès aux données internes et implique la responsabilité de l’auditeur sur les conclusions.
Frontière clé : le PoR répond à « les actifs on-chain suffisent-ils maintenant aux soldes clients », l’audit à « cette couverture n’est-elle pas absorbée par dettes, garanties et obligations off-chain ».
| Paramètre | Audit traditionnel | Proof of Reserves |
|---|---|---|
| Périmètre | Tous les actifs et passifs (on-chain + off-chain) | Réserves on-chain + passifs clients |
| Fréquence | Généralement annuelle | Plus fréquente qu’un audit (selon la politique de la plateforme) |
| Vérifiabilité | Confiance dans le rapport et les conclusions de l’auditeur | Vérification d’artefacts (adresses, signatures, Merkle) |
| Coût/vitesse | Cher et lent | Moins cher et plus rapide |
| Risques off-chain | Pris en compte (dettes, garanties, obligations conditionnelles) | Restent généralement hors du rapport |
Important : même un PoR « idéal » ne prouve pas la solvabilité si l’entreprise a des dettes externes, garanties ou obligations invisibles dans la blockchain et non publiées dans le rapport.
Le PoR est un outil de contrôle de transparence (actifs vs soldes clients), tandis que l’audit vérifie la solvabilité dans son ensemble. La fiabilité commence lorsque le PoR est complété par une méthodologie claire et une évaluation indépendante des risques.
Passifs : sans le second chiffre, le PoR ne fonctionne pas
Regardez le PoR uniquement comme une équation : réserves ≥ passifs à la date du snapshot — sinon c’est une vitrine.
Proof of Reserves répond à la question «y a-t-il des actifs ?» — mais la seconde question compte davantage pour l’utilisateur : «suffisent-ils pour payer tout le monde ?». Cette seconde question correspond aux liabilities (passifs) — la somme des soldes clientsque la plateforme doit couvrir.
Si les passifs ne sont pas publiés ou ne peuvent pas être vérifiés, vous ne comprenez pas si les réserves couvrent la dette réelle — même si les portefeuilles on-chain semblent « gros ».
Publier la liste complète des comptes est impossible : cela violerait la confidentialité. Un format « honnête » ressemble donc à ceci : la plateforme montre le montant agrégé des passifs et donne un moyen de vérifier que votre solde est inclus dans le snapshot (en général via Merkle-proof).
- Total liabilities : un chiffre clair par actif (ou une liste explicite d’actifs, sans « etc. » flou).
- Date et heure du snapshot : pour rattacher la comparaison à un moment précis.
- Méthodologie de calcul : ce qui est inclus/exclu (spot, sous-comptes, comptes internes).
- Vérification : Merkle-proof fonctionnel (ou équivalent), pas « nous avons calculé comme ça ».
Nuance sur marge et prêts : dans le trading à levier, certains utilisateurs peuvent avoir un solde négatif. La méthodologie doit expliquer comment c’est pris en compte, sinon les liabilities peuvent facilement être « embellies » sur le papier.
Sans passifs démontrables, le PoR devient une démonstration de portefeuilles — aucune conclusion sur la couverture.
Signaux d’alerte : quand le PoR est une vitrine, pas une vérification
6 contrôles rapides pour distinguer en une minute une « preuve de couverture » d’une belle vitrine de réserves.
Filtre rapide (15 secondes) : un rapport ne peut être considéré comme « fonctionnel » que s’il contient :
- liabilities en chiffre (par actifs/liste explicite d’actifs — sans « etc. » vague) ;
- date/heure du snapshot + liste des adresses de réserve avec preuve de contrôle ;
- vérification d’inclusion (Merkle-proof ou équivalent) pour votre solde ;
- méthodologie: ce qui est inclus/exclu et comment marge, prêts et soldes négatifs sont traités.
Tous les PoR ne sont pas aussi utiles. Ci-dessous, les contournements typiques du sens après lesquels il vaut mieux lire le rapport comme du marketing, pas comme preuve de couverture.
« Réserves seulement » sans passifs
- Ce qui ne va pas : les adresses et montants existent, mais la dette envers les clients n’est ni publiée ni démontrée.
- Norme : liabilities en chiffre + règles de périmètre (spot/sous-comptes/comptes internes) et de comptabilisation.
Couverture partielle des actifs
- Ce qui ne va pas : 1–2 monnaies sont vérifiées, le reste reste « hors champ » — cela crée un effet de transparence.
- Norme : liste explicite d’actifs/réseaux + part de couverture pour voir exactement ce qui a été vérifié.
Pas de vérification utilisateur
- Ce qui ne va pas : vous ne pouvez pas confirmer que votre solde est inclus dans le snapshot.
- Norme : Merkle-proof (ou équivalent) + instruction claire de vérification + résultat reproductible.
Méthodologie floue
- Ce qui ne va pas : on ne sait pas quels portefeuilles ont été inclus ni comment marge, prêts et soldes négatifs ont été comptés.
- Norme : hypothèses et exclusions écrites explicitement ; règles de calcul des liabilities vérifiables.
Action ponctuelle au lieu d’une pratique
- Ce qui ne va pas : le rapport est apparu « pendant la panique » puis n’est plus mis à jour pendant des mois.
- Norme : publication régulière + méthodologie comparable d’un rapport à l’autre (historique visible).
Auditeur faible ou opaque
- Ce qui ne va pas : format « étapes vérifiées » sans limites claires ni responsabilité sur les conclusions.
- Norme : qui a vérifié, quoi exactement, et quelles limites sont indiquées directement dans le document.
Un PoR solide, c’est
Comment vérifier le PoR soi-même : 7 étapes sans « magie »
En 2–3 minutes, distinguez une couverture vérifiable à la date du snapshot d’une « vitrine » avec portefeuilles et chiffres.
Minimum pour conclure : il y a liabilities et il y a vérification (Merkle-proof ou équivalent). Sans l’un de ces points, le PoR reste une déclaration.
- Ouvrez la page PoR/Transparency. Cherchez la section officielle sur le site de l’exchange, pas des résumés.
- Vérifiez date et heure du snapshot. Sans elles, le rapport ne peut pas être comparé correctement à l’on-chain.
- Clarifiez le périmètre. Il doit y avoir une liste explicite d’actifs/réseaux (sans « etc. » vague).
- Ouvrez les adresses de réserve. Les adresses doivent être publiques pour pouvoir les vérifier dans un explorateur.
- Comparez les soldes des adresses. Pour les actifs clés, comparez les montants on-chain aux chiffres du rapport à la date du snapshot.
- Trouvez liabilities et couverture. Le rapport doit contenir des chiffres et une règle de comparaison :
réserves ≥ passifs. -
Vérifiez l’inclusion de votre solde. Utilisez Merkle-proof (ou équivalent) et assurez-vous que votre compte est pris en compte.
En plus : regardez la régularité des publications et la clarté de la méthodologie (ce qui est inclus/exclu, comment marge et prêts sont traités).
S’il n’y a pas de liabilities ou pas de vérification d’inclusion du solde, ce n’est pas une preuve de couverture.
Une vérification PoR fonctionnelle = date + adresses + liabilities + votre Merkle-proof. Le reste est un bonus, pas la base de confiance.
Exemples de PoR : éventail d’approches et différences typiques
Beaucoup ont « un PoR ». L’essentiel est le format : périmètre des actifs, liabilities démontrables et vérification réelle pour l’utilisateur.
🏛️ Grandes CEX et « PoR partiel »
Elles commencent souvent par 1–2 actifs : cela semble « transparent », mais l’image globale peut rester hors champ.
- Publient : adresses de réserve + date du snapshot + rapport par actifs séparés.
- Où est la vitrine : pas de liabilities en chiffre ou périmètre actifs/réseaux incomplet.
- À vérifier : liste des actifs et part de couverture + existence des liabilities et façon dont elles sont confirmées.
Point clé : de « grands portefeuilles » sans liabilities démontrables sont une démonstration, pas une vérification.
🗓️ Exchanges avec mises à jour régulières
La valeur n’est pas dans un chiffre isolé, mais dans la répétabilité : même méthodologie et mises à jour planifiées.
- Publient : rapports sur actifs clés + outil de vérification (Merkle-proof/équivalent).
- Où est la vitrine : méthodologie des liabilities vague (marge/prêts/soldes négatifs non expliqués).
- À vérifier : si la vérification Merkle est reproductible + s’il y a des signatures de contrôle des adresses + des exclusions claires.
Point clé : la régularité ne fonctionne qu’avec une méthodologie claire — sinon c’est une « vitrine en série ».
🧷 Approche « liabilities-first »
Mettre l’accent sur les passifs est un signal fort, mais ne suffit pas si le « set de réserves » n’est publié que partiellement.
- Publient : règles de calcul des liabilities + confirmation de l’exhaustivité (cas limites inclus).
- Où est la vitrine : les liabilities semblent solides, mais les reserves par actifs/réseaux ne sont pas entièrement couvertes.
- À vérifier : le lien liabilities ↔ reserves pour chaque actif et la protection contre les manœuvres à la date du snapshot.
Point clé : des liabilities solides sans reserve set complet ne répondent pas à « y aura-t-il assez pour payer ? ».
🧾 Stablecoins et attestations de réserves
Souvent, il s’agit d’une attestation comptable « réserves ≥ émission », pas d’une vérification on-chain utilisateur.
- Publient : rapport de couverture + composition des réserves + date/période.
- Où est la vitrine : faible vérifiabilité on-chain par l’utilisateur et beaucoup d’hypothèses dans la méthodologie.
- À vérifier : fréquence des rapports + liquidité/qualité de la composition + limites de vérification directement dans le document.
Point clé : une attestation est utile, mais ce n’est pas un Merkle-PoR : la confiance dépend de la qualité du rapport et de ses limites.
🧭 Critères d’un PoR de qualité : distinguer transparence et vitrine
Vérifiez 6 points : si le rapport en rate au moins 2, mieux vaut considérer le PoR comme une vitrine, pas comme preuve de couverture.
Filtre rapide : s’il n’y a pas de liabilities en chiffre et aucun moyen de confirmer l’inclusion de votre solde (Merkle-proof/équivalent), c’est une « démonstration de portefeuilles », pas un PoR vérifiable.
Checklist qualité du rapport :
- Couverture : pour chaque actif clé, le rapport montre réserves ≥ passifs + coefficient à la date/heure du snapshot.
- Passifs : liabilities publiées en chiffre et confirmables (Merkle-proof/zk/contrôle externe), pas « nous avons calculé ainsi ».
- Réserves : le reserve set (adresses) est publié et le contrôle prouvé par signature ; pas de « portefeuilles choisis » sans périmètre.
- Méthodologie : ce qui est inclus/exclu (spot, marge, prêts, sous-comptes, soldes négatifs) et règles de calcul du total.
- Régularité : historique des publications et comparabilité des rapports, pas un unique « snapshot de confiance ».
- Confidentialité : vérification de votre solde sans révéler les données des autres (Merkle/zk) + résultat reproductible.
Un PoR solide, c’est passifs + vérifiabilité + méthodologie + régularité, pas un « joli chiffre de réserves ».
Limites du PoR : quels risques restent même avec un bon rapport
Le PoR est une vérification à la date du snapshot. Il aide à filtrer une transparence faible, mais ne remplace pas la solvabilité « dans son ensemble ».
- Snapshot dans le temps : le rapport fixe « l’état actuel », mais ne garantit pas que la couverture sera conservée demain. La valeur vient de mises à jour régulières et d’une méthodologie comparable d’un rapport à l’autre.
- Risques off-chain : crédits, garanties, procédures judiciaires et obligations envers des contreparties peuvent être hors rapport — le PoR ne montre pas cela par définition.
- Manœuvres autour de la date du snapshot : avec un contrôle faible, des « renflouements » temporaires de réserves pour la vérification sont possibles. Seules une méthodologie transparente et l’observation des mouvements avant/après la date réduisent le risque.
- Qualité de mise en œuvre : si ce qui est inclus/exclu n’est pas clair (marge, prêts, soldes négatifs, sous-comptes), les chiffres peuvent être « améliorés » sans mensonge direct — simplement par les hypothèses.
- Faux sentiment de sécurité : le PoR est une couche de contrôle, pas une assurance. Il ne protège pas des hacks, erreurs de gestion et incidents opérationnels.
Comment le lire pratiquement : traitez le PoR comme un filtre de qualité de transparence, pas comme une « permission de tout garder sur l’exchange ».
- Regardez la tendance : régularité, historique des publications, mêmes règles de calcul.
- Cherchez les limites : ce qui n’est exactement pas couvert par le rapport (actifs, réseaux, types de comptes).
- Vérifiez le contexte : réputation, incidents, vitesse de communication sur les risques.
Tant que les actifs sont sur un exchange, vous dépendez de ses processus et contrôles. Le PoR réduit le risque de manque de fonds caché, mais n’annule pas le principe
Un PoR solide aide à vérifier la couverture à la date du snapshot, mais ne ferme pas les dettes off-chain, les « manœuvres » ni les risques d’exécution — utilisez-le comme outil de contrôle, pas comme garantie.
Questions fréquentes sur le PoR : comment lire les rapports
Réponses rapides pour distinguer un PoR vérifiable d’une vitrine : ce qui est normal et ce qu’il faut vérifier à la main.
Que sont les Agreed-Upon Procedures (AUP) et pourquoi ce n’est pas un « audit complet » ?
Pourquoi ajouter zk-SNARK et Proof of Liabilities (PoL) à Proof of Reserves ?
Comment vérifier que mes fonds sont inclus dans le PoR ?
Pourquoi faut-il les passifs si les adresses de réserve sont visibles ?
Peut-on faire confiance au PoR sans auditeur ?
Que faire si un exchange ne publie pas de PoR ?
Conclusion finale : utiliser le PoR dans la gestion du risque
Le PoR n’est pas une garantie, mais un signal de qualité vérifiable. Utilisez-le comme filtre d’exchanges et règle de limites de garde.
Proof of Reserves est une vérification à la date du snapshot : il montre les réserves on-chain et la couverture déclarée des passifs clients. La valeur pratique apparaît seulement lorsqu’il est possible de confirmer les passifs (pas seulement voir des portefeuilles) et de comprendre la méthodologie de calcul : ce qui est inclus, ce qui est exclu et comment les cas limites sont traités.
En même temps, le PoR ne ferme pas les risques off-chain : dettes, garanties, procédures judiciaires et erreurs de gestion peuvent exister parallèlement à un rapport « idéal ». Le modèle pratique est donc simple : gardez sur l’exchange uniquement des montants opérationnels, choisissez des plateformes avec mises à jour régulières et vérification reproductible (Merkle/équivalent), et considérez toute formulation floue du rapport comme une réduction de votre limite de confiance.
Essentiel : le PoR ne devient protecteur que lorsqu’il est vérifiable : passifs, méthodologie et régularité comptent davantage que n’importe quelle « coche » dans un communiqué.