Vérifier si votre pool paie équitablement : une méthode de 30 jours à réaliser soi-même

Tôt ou tard, chaque mineur se pose la même question. Les revenus ont baissé alors que la difficulté est restée stable, ou le tableau de bord du pool affiche un hashrate inférieur à celui rapporté par la machine, ou la semaine s'est terminée avec 82 % de chance et le chat parle déjà de vol.

Une partie de cette question a une réponse. Une autre n'en a pas, et aucun travail de tableur n'y changera rien. Les données de bloc, l'attribution du coinbase et vos propres transactions de paiement sont publiques. Ce qui se passe à l'intérieur du pool entre le share que vous avez soumis et votre solde n'est visible qu'à travers les rapports du pool lui-même.

POOL BTC n'est pas un pool. Nous comparons les conditions des autres et calculons ce qu'elles coûtent à un mineur, donc ce qui suit est une procédure, pas une accusation. Appliquez-la à vos propres chiffres.

Que pouvez-vous vraiment vérifier, et qu'est-ce qui ne pourra jamais l'être ?

Vous pouvez vérifier intégralement tout ce qui est inscrit sur la blockchain ou mesuré par votre propre matériel : les blocs trouvés par le pool, les frais contenus dans ces blocs, les montants arrivés sur votre adresse, votre hashrate et votre taux de rejet. Tout ce qui est interne au pool, de la comptabilité des shares à la fenêtre PPLNS, n'existe pour vous que sous forme de rapport.

La conclusion honnête de ce tableau est la suivante : un mineur ne peut pas prouver une fraude. Un mineur peut se prouver à lui-même qu'aucun écart n'existe, et si un écart existe, le localiser et le présenter à l'opérateur sous forme de calcul.

Pourquoi le tableau de bord du pool affiche-t-il un hashrate inférieur à celui de votre ASIC ?

Parce qu'ils mesurent des choses différentes. Votre machine indique la vitesse de hachage instantanée. Le pool estime votre hashrate a posteriori, à partir des shares acceptés sur une fenêtre de moyenne. Ils ne peuvent pas coïncider par construction, puisque le pool ne compte que ce qui lui est parvenu et a passé la validation.

Quatre raisons ordinaires expliquent cet écart :

1. Fenêtre de moyenne. Un chiffre à cinq minutes varie de dizaines de pour cent, un chiffre sur 24 heures est lissé. Comparez toujours jour à jour, jamais instantané à journalier.
2. Variance des shares. Trouver un share est un processus aléatoire, et les fenêtres courtes contiennent un vrai bruit statistique.
3. Shares rejetés et obsolètes. Ils sortent de la comptabilité, donc votre hashrate effectif se situe en dessous du nominal.
4. Latence réseau. Plus le serveur stratum est éloigné et plus la liaison est mauvaise, plus le travail arrive déjà obsolète.

Certains pools publient ce qu'ils considèrent comme un taux de rejet normal. Les chiffres publiés ne concordent pas entre eux, et il n'existe aucune norme sectorielle.

Source : pages d'assistance d'AntPool, ViaBTC et F2Pool, vérifiées le 09.09.2026. Ces pages renvoient une erreur 403 aux requêtes automatisées, donc les citations proviennent d'extraits de recherche sur ces mêmes URL plutôt que du corps de la page. Cela vaut la peine de les ouvrir à la main si la formulation exacte compte pour vous.

L'écart entre 0.5 % et 3 % a un sens pratique : ce qui est "normal" pour votre pool est défini par votre pool, pas par le secteur. Un seuil d'alerte raisonnable est un écart persistant supérieur à 5 % sur le chiffre journalier que votre taux de rejet n'explique pas.

Comment calculer les gains attendus et les comparer aux gains réels ?

Prenez votre part du hashrate réseau, multipliez-la par la récompense de bloc effective et par le nombre de blocs par jour. Une seule formule couvre tous les schémas. Ce qui change d'un schéma à l'autre, c'est la marge dont dispose le crédit réel pour s'écarter de cette ligne : presque aucune en FPPS, visible en PPLNS.

\`\`\`

miner share = miner hashrate / network hashrate

reward_eff = 3.125 BTC × (1 + transaction fee share)

BTC per day = miner share × 144 × reward_eff × (1 - pool fee)

\`\`\`

À partir de l'instantané réseau du 09.09.2026 : hashrate réseau 943.73 EH/s, part des frais de transaction sur les 4320 derniers blocs 0.669%, donc reward_eff = 3.125 × 1.00669 = 3.1459 BTC. La difficulté à la même date était de 127,450,789,715,843.1 (mempool.space, consulté le 09.09.2026).

FPPS et PPS+ : le crédit quotidien doit être stable

En FPPS, le pool paie un taux fixe par share soumis, frais de transaction inclus, qu'il ait trouvé un bloc ce jour-là ou non. Votre crédit quotidien devrait donc suivre de près la ligne calculée. Un lundi qui paie la moitié d'un mardi à hashrate identique n'est pas une variance normale du schéma en FPPS, c'est un point à éclaircir.

Le PPS+ fonctionne de la même façon pour la subvention, mais répartit les frais de transaction en fonction des blocs réellement trouvés, donc un écart modeste d'un jour à l'autre est normal. Ce que ces schémas donnent en dollars à hashrate identique est détaillé dans l'article sur FPPS, PPS+, PPLNS et SOLO.

PPLNS : ne comparer que sur une longue fenêtre

Le PPLNS vous verse une part des blocs réellement trouvés par le pool. Pas de bloc, rien à répartir, et le chiffre quotidien varie fortement. Les comparaisons n'ont de sens que sur un mois au minimum, et un trimestre est préférable. Vos premiers jours sur un nouveau pool PPLNS ressemblent presque toujours à un sous-paiement, car la fenêtre ne s'est pas encore remplie de vos shares.

La comparaison elle-même :

1. Enregistrez votre hashrate quotidien depuis le tableau de bord du pool pour chaque jour de la période.
2. Enregistrez le hashrate réseau et la part des frais de transaction pour chacune de ces dates, pas une seule valeur pour tout le mois. Entre le 29.08 et le 09.09.2026, le réseau est passé de 896.89 à 943.73 EH/s, soit +5.2 %, et quiconque n'a pas changé de matériel a perdu exactement cela.
3. Calculez l'espérance pour chaque jour et additionnez-la.
4. Additionnez les crédits réels de ces mêmes jours d'après le rapport du pool.
5. Comparez les deux totaux et exprimez l'écart en pourcentage.
6. Séparément, additionnez ce qui est réellement arrivé sur votre portefeuille et comparez-le à ce qui est sorti de votre solde de pool. Ce sont deux vérifications différentes : le crédit et la livraison.

Testez vos propres chiffres dans la calculatrice de minage, vérifiez les délais de paiement par pool sur la page des délais de paiement, et découvrez comment nous construisons nos propres estimations dans la méthodologie.

Qu'est-ce que la chance du pool, et une chance faible prouve-t-elle une triche ?

La chance est le rapport entre les blocs réellement trouvés et le nombre attendu d'après le hashrate du pool sur une période. À 100 %, le pool a trouvé exactement ce que prédisait la statistique. C'est une variable aléatoire, donc une semaine à 80 % ou à 130 % relève d'une dispersion ordinaire et ne prouve rien.

Ce que la plupart des débats oublient : en FPPS et PPS, la chance ne touche absolument pas votre paiement. Le pool verse un taux et absorbe lui-même les mauvaises séries, ce qui est précisément ce qu'achète la commission plus élevée par rapport au PPLNS. Demander un recalcul après une semaine de malchance en FPPS n'a pas de sens, puisque cette semaine a déjà été payée au taux de la formule.

En PPLNS et TIDES, la chance se répercute directement : pas de bloc, pas de répartition. Une chance faible réduit alors réellement vos revenus, mais c'est une propriété du schéma et non une action de l'opérateur. Jugez cela sur un trimestre, et seulement lorsque la part de blocs du pool dans les tableaux publics reste stable.

Trois points à vérifier avant de tirer des conclusions d'un chiffre de chance :

1. La fenêtre : par round, par jour, ou en moyenne glissante sur 30 jours. Des fenêtres différentes racontent des histoires différentes sur les mêmes données.
2. Si la chance est calculée par nombre de blocs ou par shares de round. La seconde est plus stable.
3. Si le nombre de blocs dans le rapport du pool correspond à celui attribué par les explorateurs publics.

Une référence toute prête du type "voici à quoi ressemble la chance hebdomadaire d'un grand pool" n'est pas quelque chose que nous pouvons vous fournir, et il vaut la peine de savoir pourquoi d'emblée. Aucune des sources vérifiées ne publie de série de chance hebdomadaire ou mensuelle réelle sur les douze derniers mois avec une méthodologie déclarée. Voici ce qui existe réellement au 2026-09-11 :

1. F2Pool affiche des widgets de chance sur 3, 7, 30 et 90 jours sur sa page de statistiques, et tient un journal séparé des blocs trouvés avec la chance de chacun. Ce sont des fenêtres glissantes à l'instant présent, pas une archive des semaines de l'an dernier. Le pool indique la méthode dans son centre d'aide : blocs réellement trouvés divisés par le nombre théoriquement attendu d'après le hashrate du pool.
2. ViaBTC explique la même formule sur son blog avec un seul exemple chiffré : une chance sur sept jours de 92.17 % le 2024-05-07. Il n'y a pas là de série publiée en continu, c'est une illustration de la méthode.
3. Antpool ne tient aucune page publique dédiée à la chance sur ses ressources officielles.
4. Braiins publie une répartition historique mois par mois du hashrate entre pools remontant à 2012, mais il s'agit de parts de puissance, pas de chance.
5. Des trackers indépendants comme soloblocks.io et blocksrace.com calculent la chance avec la même formule sur des fenêtres courtes, de quelques heures à 30 jours. Le premier déclare ouvertement n'avoir encore accumulé aucune donnée annuelle : le service tourne depuis mars 2026.

La conclusion pratique est simple. Ne comparez pas votre pool à une "norme" du secteur qui n'est pas accessible publiquement, mais à son propre chiffre sur une longue fenêtre : regardez la chance sur 90 jours là où le pool la publie, et croisez le nombre de blocs avec les tableaux d'explorateurs publics. C'est exactement pourquoi la section suivante traite des blocs plutôt que de la chance.

Comment confirmer qu'un pool trouve réellement des blocs ?

Grâce à la transaction coinbase. Chaque bloc en contient une, et les pools y placent une balise textuelle et l'adresse de récompense. Les explorateurs regroupent ces balises dans des tableaux d'attribution, ce qui permet à n'importe qui de compter les blocs d'un pool donné sans le moindre accès à son tableau de bord.

La procédure :

1. Ouvrez le tableau des pools sur mempool.space pour les fenêtres d'une semaine et d'un mois.
2. Trouvez votre pool et notez son nombre de blocs et sa part.
3. Comparez cette part à ce que le pool affirme sur son propre hashrate sur son site.
4. Prenez deux blocs précis du rapport du pool lui-même et recherchez-les par hauteur. Le coinbase devrait porter le tag de ce pool.
5. Si le pool n'apparaît jamais dans les tableaux publics, demandez au support pourquoi. "Nous ne taguons pas notre coinbase" est une réponse vérifiable. "Information commercialement sensible" ne l'est pas.

Voici la répartition selon mempool.space au 11.09.2026 :

La fenêtre hebdomadaire couvre 1026 blocs, la fenêtre mensuelle 4497. Source pour les deux : API Mining Pools de mempool.space, consultée le 11.09.2026.

Une mise en garde méthodologique. La part de blocs est un indicateur du hashrate, pas une mesure directe, donc il faut lire ensemble les colonnes hebdomadaire et mensuelle. Un écart d'un ou deux points entre elles, comme pour SECPOOL et NiceHash ci-dessus, relève d'une variance ordinaire sur de petits effectifs plutôt que d'un pool gagnant ou perdant des machines. Qui assemble réellement le contenu d'un bloc, et pourquoi c'est une question à part, est traité dans l'article sur Stratum V2.

Où vont les frais de transaction d'un bloc en FPPS ?

Dans une implémentation FPPS correcte, ces frais entrent dans votre taux. Le pool moyenne la part des frais sur les blocs récents, l'ajoute à la subvention, puis prélève sa propre commission sur le total. C'est toute la différence avec le PPS simple, où vous n'êtes payé que sur la subvention et où les frais restent au pool.

À l'heure actuelle, le montant est faible. Selon mempool.space, les frais de transaction représentaient 0.66 % des récompenses de bloc sur les 4320 derniers blocs le 08.09.2026 et 0.669 % le 09.09.2026, tandis qu'une fenêtre de 144 blocs donnait 0.57 %. Sur le dernier mois, la fourchette se situe entre 0.66 et 0.73 %, un marché des frais calme, sans événement type Ordinals ou Runes.

Des agrégateurs différents produisent des chiffres différents à partir de la même chaîne, et c'est une question de méthodologie, pas d'erreur. Début septembre 2026, les métriques quotidiennes de Glassnode et Newhedge affichaient 0.40-0.56 % contre 0.66-0.70 % pour mempool.space sur 4320 blocs. Donc lorsque vous soulevez un écart auprès d'un pool, précisez la source, la fenêtre et la date, sinon vous discuterez de chiffres calculés selon des règles différentes.

Les marchés de frais calmes ne durent pas éternellement. Le 20.04.2024, le lendemain du halving et du lancement de Runes, les frais ont atteint 73.8-75 % des revenus des mineurs selon la méthodologie, et le 08.05.2023, au pic des Ordinals, 40.8-42.59 % pour la journée. Les jours comme ceux-là, l'écart entre FPPS et PPS cesse d'être théorique, ce qui est un bon moment pour relire ce que dit la documentation de votre pool sur les frais de transaction.

Ce qu'il faut vérifier ici :

1. Quel schéma la documentation nomme réellement : FPPS, PPS+ ou PPS. Un mot d'écart dans le texte, des points de pourcentage d'écart dans l'argent.
2. Si le pool publie la fenêtre sur laquelle il moyenne la part des frais.
3. Si la composante frais de votre crédit correspond à la part de frais publique pour ces dates, au moins en ordre de grandeur.

Qu'est-ce qui est déduit en plus de la commission du pool ?

Quatre mécanismes : les frais de réseau sur la transaction de paiement, le seuil minimal de paiement, l'arrondi sur les crédits, et l'écart sur toute conversion. Aucun d'eux n'est de la triche, tous sont documentés au moins par certains pools, et ensemble ils expliquent la plupart des cas où le montant reçu est inférieur à ce qui était attendu.

Les frais de retrait fixes méritent une remarque à part, car ils se transforment en pourcentage qui dépend du montant. Kryptex App facture 0.00003 BTC on-chain pour un minimum de 0.00025 BTC, soit 12 % du plus petit retrait possible et 0.3 % sur un retrait de 0.01 BTC. Le Lightning sur le même service coûte 2 % avec un minimum de 0.00001 BTC : moins cher en valeur absolue, plus cher en taux.

Le temps que votre argent passe sur le solde de l'opérateur relève d'un calcul simple. Avec les paramètres réseau du 09.09.2026 :

Il s'agit d'un calcul d'espérance basé sur un hashrate réseau de 943.73 EH/s et une récompense effective de 3.1459 BTC, pas de données de pool. La variance de PPLNS et TIDES n'y est pas intégrée.

Pour F2Pool et ViaBTC, la règle existe bel et bien dans le centre d'aide officiel, et elle est favorable au mineur.

F2Pool indique sur sa page d'aide qu'il ne facture aucun frais de transaction pour le versement des revenus de minage une fois que le solde dépasse le seuil minimal. Ce seuil pour le BTC est de 0.005 BTC selon le propre tableau du pool et il est ajustable par l'utilisateur. Le cas à part est un retrait manuel sous ce seuil : il est disponible à partir de 10 % de la valeur par défaut, soit à partir de 0.0005 BTC, il passe uniquement par Lightning, et là les frais de 0.000001 BTC sont payés par le mineur. Le pool détaille la règle inverse pour ETHW et ALEO, qui ne s'applique pas au bitcoin.

ViaBTC le formule de façon encore plus claire : le centre d'aide décrit le retrait automatique au-dessus du minimum comme entièrement gratuit, et une annonce dans la même section indique que le pool continue de couvrir tous les frais de transaction. Le minimum de retrait automatique en BTC est de 0.001 BTC. Le seul point flou est le Normal Transfer manuel : la FAQ officielle reconnaît que ses frais fluctuent avec la congestion du réseau, mais la page ne dit pas qui les paie. Nous ne devinerons pas à la place du pool, donc vérifiez le montant sur l'écran de retrait avant de confirmer.

Trois liens permettent de vérifier tout cela : l'article d'aide de F2Pool sur les frais de paiement, la page de ViaBTC sur la configuration du retrait automatique et la FAQ de ViaBTC sur les dépôts et retraits. Consultés le 2026-09-11.

Quels écarts sont réellement préoccupants ?

Celles que la variance n'explique pas et que le temps n'efface pas. Une mauvaise semaine isolée en PPLNS, un déficit quotidien de 3 % en FPPS, une baisse de cinq minutes du hashrate sur le tableau de bord : du bruit. Un déficit qui persiste sur un mois après avoir recalculé l'espérance avec les bons paramètres réseau pour chaque date : un signal.

Cette dernière ligne mérite d'être prise au sérieux à elle seule. Ce qu'il advient d'un solde lorsqu'un pool s'arrête complètement est traité séparément dans l'article sur la fermeture d'un pool.

La check-list de 30 jours

Cette séquence couvre tout ce qui précède et ne nécessite rien de plus qu'un accès à vos machines, à votre compte de pool et à un navigateur.

1. Jour 0. Enregistrez les données de départ : modèle et nombre de machines, hashrate nominal, schéma de paiement, commission déclarée, seuil de paiement, adresse de paiement. Faites une capture d'écran de la page tarifaire plutôt que de recopier le chiffre. Les pages changent discrètement.
2. Jour 0. Mettez en place un enregistrement local du hashrate depuis les machines elles-mêmes. Sans cela, vous comparerez des données du pool à des données du pool. La supervision et les alertes minimales viables sont traitées dans un article à part.
3. Quotidien. Notez quatre chiffres : hashrate quotidien selon vos machines, hashrate quotidien selon le tableau de bord, le crédit du jour, le taux de rejet.
4. Quotidien. Enregistrez le hashrate réseau et la part des frais de transaction pour cette même date. Un seul instantané pour tout le mois faussera le résultat : le réseau a gagné 5.2 % en onze jours fin août 2026.
5. Hebdomadaire. Comparez le nombre de blocs du pool dans les tableaux publics avec celui de son propre rapport.
6. Hebdomadaire. Vérifiez chaque paiement reçu dans un explorateur : montant de la transaction, montant débité du solde, frais de réseau, et qui les a payés.
7. Jour 30. Additionnez les espérances quotidiennes et les crédits réels, puis exprimez l'écart en pourcentage.
8. Jour 30. Calculez séparément la différence entre ce qui a été crédité et ce qui est arrivé sur votre portefeuille. Tout ce qui a disparu entre ces deux chiffres devrait s'expliquer par le seuil, les frais de réseau ou une conversion.
9. Jour 30. Évaluez le pourcentage selon votre schéma. En FPPS, un écart mensuel supérieur à 10 % nécessite une explication. En PPLNS, étendez la fenêtre à un trimestre avant de conclure quoi que ce soit.
10. Jour 30. Si l'écart y résiste, passez à la section suivante plutôt qu'à un salon de discussion.

Que faire quand l'écart tient la route

Ouvrez un ticket de support composé de chiffres, de dates et d'une seule question. Pas de la phrase "vous me volez". Un opérateur qui répond à ce type de demande vous répondra, et un opérateur qui ignore un calcul écrit sur 30 jours vous a déjà dit quelque chose.

Ce qu'il faut joindre :

1. La période de comparaison avec des dates exactes, plus votre identifiant de connexion ou les ID de vos workers.
2. Un tableau quotidien : votre hashrate, le hashrate du tableau de bord, le crédit, le taux de rejet.
3. Le calcul de l'espérance avec la formule et la source des paramètres réseau pour chaque date.
4. L'écart total en BTC et en pourcentage.
5. La liste des transactions de paiement avec les hachages et les montants.
6. Une question précise. Par exemple : qu'est-ce qui explique l'écart entre les gains crédités et attendus sur cette période, à ce hashrate, sous ce schéma.

Lisez ensuite la réponse. Un décompte détaillé de vos chiffres, un renvoi vers une règle documentée, ou un incident reconnu avec un recalcul sont tous des résultats acceptables. Un discours générique sur la volatilité et la variance du réseau, sans le moindre chiffre en réponse à un tableau qui en est plein, est un mauvais signe, en particulier la deuxième fois.

Quand changer de pool est la bonne décision :

1. L'écart s'est maintenu sur 30 jours et est resté inexpliqué après deux demandes.
2. Les retards de paiement sont devenus systématiques.
3. Le pool a cessé d'apparaître dans les tableaux publics de blocs, ou sa part diverge fortement de ce qu'il annonce.
4. Les conditions ont changé rétroactivement sans préavis.

Changer coûte de l'argent : quelques heures d'arrêt, une fenêtre PPLNS perdue sur l'ancien pool, et un solde sous le seuil qui pourrait tout simplement y rester. La règle selon laquelle un solde sous le seuil s'accumule au lieu d'expirer est confirmée officiellement pour F2Pool, ViaBTC et Luxor. Pour les autres pools, nous n'avons trouvé aucune déclaration explicite dans un sens ou dans l'autre, donc traitez-le comme une question ouverte avant de partir. Garder un pool de secours configuré dans les emplacements de l'ASIC transforme le changement en quelques minutes de travail, ce qui est traité dans l'article sur le failover. Comparez les conditions avant de migrer dans le tableau comparatif des pools.

Ce que cette méthode ne fait pas

Elle ne prouve pas de fraude et ne remplace pas un audit. Elle vous dit s'il existe un écart entre ce que vous pouvez calculer vous-même et ce qui vous a été crédité. Tout ce qui vient après relève d'une conversation avec un opérateur, pas d'une affaire judiciaire.

Encore non confirmé dans nos propres données au 2026-09-11 :

1. Les taux de commission exacts chez AntPool, Binance Pool, Foundry USA et Braiins. Les pages officielles ne se chargent pas, ne publient pas de chiffre, ou se contredisent avec d'autres sources.
2. Les frais de retrait et la règle du "qui paie les frais de réseau" chez F2Pool et ViaBTC.
3. Les taux d'écart d'autoconversion chez EMCD et Kryptex.
4. Le seuil de paiement d'Ocean : le chiffre de 0.01048576 BTC provient d'avis secondaires et n'a pas été confirmé directement par la documentation officielle.
5. Le hashprice exact en direct à la date de publication. Lire le chiffre directement sur l'index Luxor n'a pas fonctionné : la page se rend via un script et le cache sert des valeurs manifestement obsolètes. Selon des republications datées des données Hashrate Index pour le 2026-09-05 et le 2026-09-08, le hashprice s'est maintenu autour de 39 à 40 USD par PH/s et par jour, soit environ 0.039 à 0.040 USD par TH/s. Un avis daté du 2026-09-06 le situe plutôt au milieu de la trentaine, ce qui ne concorde pas avec les trois autres sources. Cela suffit pour s'orienter, mais pour un calcul de fermeture, vérifiez vous-même la valeur le jour où vous faites les calculs. Pour contexte, selon les bilans mensuels publiés par Luxor, le plus bas sur six mois est de 27.74 USD par PH/s et par jour le 2026-06-06 et le plus haut de 40.02 USD le 2026-08-27.

La version courte

Les blocs, les frais qu'ils contiennent, les transactions de paiement et votre propre hashrate sont vérifiables. L'intérieur d'une fenêtre PPLNS et la capacité réelle d'un pool ne le sont pas, et la part de blocs de l'explorateur n'est qu'un indicateur approché de cette dernière.

Calculez votre espérance à partir des paramètres réseau de chaque date plutôt que d'un instantané vieux d'un mois. En FPPS, la ligne de crédit devrait être stable, en PPLNS jugez sur un trimestre, et en FPPS la chance n'a rien à voir avec votre paiement.

Cherchez d'abord l'argent manquant du côté des déductions. Les seuils, les frais de réseau, les minimums de retrait distincts et les écarts de conversion expliquent la plupart des cas où "il est arrivé moins que prévu". Ce n'est que lorsqu'un écart résiste à 30 jours et à un recalcul que vous devriez ouvrir un ticket, et alors ouvrez-le avec un tableau.