Commission de 1% contre commission de 4% : pourquoi la comparaison des pools sur un seul chiffre s'effondre et comment construire une évaluation à partir de quatre facteurs

TL;DR

La commission du pool est une entrée parmi quatre, et pas la plus lourde. À côté d'elle se trouvent le risque de l'opérateur, la fiabilité de ce que le pool publie sur lui-même, et la liquidité des paiements : dans combien de jours l'argent arrivera dans votre portefeuille et combien sera perdu en chemin. On détaille ci-dessous une méthode qui rassemble ces quatre composantes en un seul chiffre, et on explique où ce chiffre ment.

POOL BTC n'est pas un pool de minage, mais un site indépendant de comparaison de pools. Les évaluations ci-dessous concernent des services tiers, et la méthode est ouverte précisément pour qu'on puisse la contester.

L'idée d'un score multifactoriel n'est pas la nôtre. Minerstat a publié en septembre 2026 une analyse de son opportunity score en quatre composantes (profit, risk, data confidence, liquidity), et c'est ce qui nous a poussés à décrire notre propre approche ouvertement. Nous ne copions pas la formule du concurrent et ne présentons pas ses coefficients comme les nôtres : seule la composition des composantes coïncide, parce qu'elle est évidente pour quiconque a calculé un rendement à la main.

Pourquoi la comparaison des pools sur une seule commission donne-t-elle une réponse incorrecte ?

Parce que la commission ne décrit ni ce qui est réellement partagé, ni si l'argent arrivera. Un pool à 2% en PPLNS et un pool à 4% en FPPS paient pour des choses différentes : dans le second cas, la base inclut les frais de transaction du bloc. De plus, le seuil de paiement, les frais réseau au retrait et la probabilité que l'opérateur change les règles ne sont absolument pas reflétés dans le pourcentage.

Analysons sur des chiffres vérifiés. Chez F2Pool pour le bitcoin coexistent officiellement trois schémas : FPPS 4%, PPS+ 2.5% et PPLNS 2% (aide F2Pool, vérifié le 29.08.2026). Choisir la ligne la moins chère et s'arrêter là ne fonctionne pas, parce que le PPLNS vous crédite les frais de transaction réels des blocs trouvés, tandis que le FPPS les moyenne sur la journée précédente et paie indépendamment de la chance du pool avec les blocs. Ce qui est le plus avantageux dépend de votre horizon et de ce que valent actuellement les frais de transaction.

Or ils valent tantôt presque rien, tantôt plus que la subvention :

En régime calme de septembre 2026, la différence entre « la part des frais est partagée » et « ne l'est pas » représente des fractions de pour cent du revenu, et dans ce contexte la commission affichée est effectivement le facteur principal. Mais le 20 avril 2024, cette même différence valait les trois quarts du revenu journalier. Une méthode qui repose entièrement sur un seul chiffre s'effondre précisément lors de tels jours.

Deuxième chose invisible dans le pourcentage : combien coûte le retrait de l'argent. Chez Luxor, le seuil de paiement est de 0.001 BTC plus des frais réseau de 0.000075 BTC, donc il faut accumuler plus de 0.001075 BTC sur le solde, et les frais réseau sont à la charge de l'utilisateur (documentation Luxor). Chez NiceHash, la commission de service est de 2% au crédit, et le retrait depuis le portefeuille du service est une opération distincte : minimum 0.0005 BTC et une commission à partir de 0.0001 BTC en plus (pages officielles NiceHash, consultées le 02.09.2026). Ce qui est le plus coûteux pour un mineur donné dépend de son hashrate, pas du pourcentage affiché en vitrine.

Une analyse détaillée de tout ce qui est déduit en plus du pourcentage annoncé se trouve dans un article séparé sur le coût réel de la commission du pool. Ce qui compte ici, c'est autre chose : même une commission effective calculée parfaitement reste une composante parmi quatre.

De quelles composantes se compose une évaluation honnête d'un pool ?

De quatre, et elles répondent à quatre questions différentes. Le rendement répond à « combien de BTC par jour ». Le risque de l'opérateur répond à « quelle est la probabilité que ces BTC ne m'arrivent pas ». La fiabilité des données répond à « dans quelle mesure peut-on croire les deux premières évaluations ». La liquidité répond à « quand exactement je verrai l'argent et combien je perdrai au retrait ».

L'ordre ici n'est pas arbitraire. Le rendement est calculé en premier, car sans lui le reste n'a pas de sens, et la fiabilité des données vient en troisième position, mais fonctionne en réalité comme un filtre avant tout le reste : si la commission du pool n'est pas publiée, vous n'avez pas calculé le rendement, vous l'avez deviné.

Notre page méthodologie du classement ne décrit actuellement que la première composante, le calcul du net BTC/day. Nous avons appliqué les trois autres lors de la sélection, mais sans jamais les formaliser, et cet article comble le manque.

Comment calculer la composante de rendement et pourquoi le net BTC/day plutôt que le pourcentage annoncé ?

Parce que le pourcentage de commission est un coefficient à l'intérieur de la formule, pas un résultat. Ce qui intéresse le mineur, c'est le rendement net après commission du pool et après électricité, exprimé en BTC par jour avec son propre hashrate. Un même pool peut être le meilleur pour une ferme à 3 centimes et le pire pour un mineur particulier avec un tarif élevé.

Formule utilisée par POOL BTC :

\`\`\`

net BTC/day = (votre hashrate / hashrate du réseau) × 144 × (subvention + frais moyens du bloc) × (1 - commission du pool) - électricité en BTC

\`\`\`

Ce qui compte dans chaque facteur :

1. Le hashrate du réseau vient d'une API publique et change chaque jour. Au relevé du 29.08.2026 il était de 896.89 EH/s avec une difficulté de 125 807 076 547 197.5, et au relevé du 09.09.2026 déjà de 943.73 EH/s avec une difficulté de 127 450 789 715 843.1 (mempool.space). En onze jours, le réseau a progressé de 5.2%, et tout « tableau de rendement » sans date de relevé est inutile.
2. La subvention est de 3.125 BTC par bloc depuis le halving de 2024. C'est la seule entrée vraiment stable de la formule.
3. Les frais moyens du bloc ne comptent que pour les schémas qui les partagent. FPPS et PPS+ les partagent, le PPS classique paie uniquement sur la subvention. C'est de là que vient l'écart entre commission annoncée et commission effective.
4. L'électricité est convertie en BTC au cours actuel. C'est la seule entrée que vous seul connaissez, et c'est aussi elle qui décide le plus souvent de l'issue de la comparaison.

Ensuite les choses se compliquent. La formule contient « commission du pool », mais on ne peut l'obtenir nulle part pour environ la moitié des grands pools, et c'est déjà la troisième composante, pas la première. La façon dont le schéma de paiement modifie à la fois la variance et le revenu final est détaillée dans l'analyse FPPS et PPLNS.

Pas besoin de calculer cela de tête, c'est à cela que sert le calculateur de paiements : il intègre les paramètres actuels du réseau et votre prix du kilowatt.

Qu'est-ce que le risque de l'opérateur du pool et comment l'évaluer de l'extérieur ?

Le risque de l'opérateur est la probabilité que le rendement calculé ne vous parvienne pas : le pool ferme, change les règles de paiement, se bloque une semaine ou annule votre solde pour un motif formel. On ne le mesure pas avec précision de l'extérieur, mais il a des signes observables, et presque tous se trouvent dans des documents publics que personne ne lit.

Ce qu'on peut réellement vérifier sans avoir d'information privilégiée :

• Les conditions de service concernant le solde et le reliquat non versé. Chez F2Pool, c'est écrit noir sur blanc : si l'adresse de paiement n'est pas définie pendant plus de 90 jours, la récompense « may be treated as a donation », et selon les conditions de service, en l'absence d'adresse valide pendant 6 mois après notification écrite, l'utilisateur perd le droit au montant accumulé. Ce n'est ni un scandale ni un piège, c'est une clause de contrat ordinaire, mais elle mérite d'être lue avant, pas après.
• La custodialité. Un pool qui garde votre solde jusqu'au seuil est, pendant ce temps, votre débiteur. Un pool avec paiement direct sur portefeuille et seuil bas vous garde moins longtemps créancier.
• Le schéma de paiement comme transfert de risque. Dans les schémas type PPS, l'opérateur assume la variance, et c'est confortable tant que l'opérateur reste solvable. En PPLNS, la variance reste chez vous, mais les obligations du pool envers vous sont moindres.
• La concentration du hashrate. Une grande part du réseau signifie une prévisibilité des paiements et, simultanément, un risque systémique pour le bitcoin lui-même. Les deux effets sont réels, et les résumer en une seule évaluation sans réserve serait malhonnête.
• L'historique des incidents et la façon dont le pool en a parlé. Un journal public des pannes pèse plus qu'un joli chiffre d'uptime sans méthode de mesure décrite.
• La juridiction et les exigences de vérification. Elles changent, et changent rétroactivement pour un solde déjà miné.

Comment le hashrate du réseau est-il réparti entre les pools

Il n'existe pas de mesure directe du hashrate d'un pool, donc le secteur calcule la part par blocs trouvés : un explorateur attribue un bloc à un pool via une étiquette dans la transaction coinbase et divise par le nombre total de blocs sur la fenêtre. Ci-dessous les données de mempool.space au 09.09.2026 pour deux fenêtres de moyenne, hebdomadaire et mensuelle. Les parts changent en permanence, et un tel tableau n'est valable qu'accompagné de sa date de relevé.

Source des deux fenêtres : mempool.space Mining Pools API, consulté le 09.09.2026.

Ce qui est utile pour le lecteur dans ce tableau. Le trio de tête détient environ 58% du réseau sur les deux fenêtres, et c'est un cas où la prévisibilité des paiements d'un grand pool et le risque systémique pour le bitcoin augmentent ensemble. Ensuite, la différence entre les fenêtres montre à quel point le chiffre est bruité : chez SECPOOL, la part hebdomadaire est supérieure d'environ un tiers à la mensuelle, et chez NiceHash, les 1.33% hebdomadaires disparaissent carrément du top douze sur la fenêtre mensuelle. Comparer des pools sur une part relevée à des jours différents et avec des fenêtres différentes n'a pas de sens.

Quels pools ont une page de statut publique

Presque aucun. Nous avons vérifié neuf pools au 09.09.2026, et une page de statut complète n'a été trouvée que pour un seul.

C'est plus significatif qu'il n'y paraît. L'uptime annoncé est presque impossible à vérifier de l'extérieur : huit pools sur neuf n'ont ni historique d'incidents ni indicateur de disponibilité mesurable, et la phrase sur les 99.9% dans le marketing reste une affirmation sans moyen de la réfuter. La seule grandeur vérifiable ici n'est pas le pourcentage, mais le fait même qu'une page existe.

À part sur l'uptime comme métrique. Aucun des pools de notre échantillon ne publie d'indicateur de disponibilité mesurable avec une méthode décrite : le chiffre deviendrait un engagement, et il faut le mesurer honnêtement de l'extérieur. C'est pourquoi dans l'évaluation du risque, l'uptime intervient comme un signe observable (y a-t-il une page de statut, y a-t-il plusieurs points d'entrée), pas comme un pourcentage.

Comment savoir dans quelle mesure on peut faire confiance aux chiffres qu'un pool publie sur lui-même ?

Sur un seul critère : le pool a-t-il publié une page avec la commission et le seuil sur son propre site, sans connexion, avec une date. Si la commission n'est connue que par des agrégateurs, vous ne comparez pas le pool, mais le récit qu'en fait un tiers. Cette composante est entièrement vérifiable de l'extérieur et c'est donc la seule qui ne demande pas de croire l'opérateur sur parole.

Voici à quoi cela ressemble en pratique. Lors de la vérification du 29.08.2026, nous avons ouvert manuellement dans le navigateur les pages litigieuses, et voici ce que cela a donné :

De ce tableau découle une conclusion bien plus importante que n'importe quel classement : pour quatre pools de la liste, le chiffre de commission dans toute comparaison, y compris la nôtre, n'est pas un fait mais une rumeur datée. Et si deux pools diffèrent de 0.5 point de pourcentage, et que l'un d'eux n'a pas publié sa commission du tout, cet écart de 0.5 point ne signifie rien.

Échelle simple que nous utilisons :

1. Publié sur la page officielle, accessible sans connexion, avec une date de notre vérification manuelle.
2. Publié, mais incomplet : certains paramètres sont présents, d'autres seulement dans le support ou le chat.
3. Uniquement derrière connexion ou uniquement via des agrégateurs, pas de confirmation officielle.
4. Les sources se contredisent, et la contradiction n'est pas résolue.

Le quatrième niveau se rencontre plus souvent qu'on ne le souhaiterait. Pour EMCD, nous avons un conflit entre deux seuils qui n'est pas résolu depuis août, et la bonne conclusion ici n'est pas « choisissons ce qui ressemble à la vérité », mais « marquons comme non résolu et ne construisons pas de comparaison là-dessus ».

Qu'est-ce que la liquidité des paiements et pourquoi le seuil minimum et la fréquence des paiements comptent-ils plus qu'il n'y paraît ?

La liquidité est la vitesse à laquelle ce qui est miné se transforme en argent sur votre portefeuille. Elle se calcule simplement : diviser le seuil de paiement par votre net BTC/day. Pour une ferme, ce sont des heures, pour un seul ASIC domestique, cela peut être des mois, et pendant tout ce temps le solde reste chez l'opérateur, dont les règles peuvent changer.

Seuils et retenues vérifiés pour plusieurs pools :

Trois choses qui faussent le plus souvent le calcul de liquidité :

Le seuil de crédit et le seuil de retrait ne sont pas la même chose. Chez NiceHash, 0.00001 BTC tombera sur le solde, mais le retrait ne sera possible qu'à partir de 0.0005 BTC, soit cinquante fois plus. Comparer le premier chiffre au seuil d'un pool ordinaire n'a pas de sens.

Une commission de retrait fixe se transforme en un pourcentage qui dépend du montant. Une commission de 0.00003 BTC sur un retrait de 0.00025 BTC représente 12% du montant, mais sur un retrait de 0.01 BTC, 0.3%. La même ligne tarifaire signifie des choses différentes pour un mineur domestique et pour une ferme.

Le reliquat en cas de départ. La règle « le reliquat sous le seuil s'accumule et ne disparaît pas » est confirmée officiellement pour F2Pool, ViaBTC et Luxor. Pour les autres pools, nous n'avons pas trouvé de formulation officielle directe, donc en cas de changement de pool, le reliquat sur l'ancien solde reste une question ouverte, pas une garantie.

Combien de jours faut-il pour atteindre le seuil de paiement

Calculé par espérance mathématique, sans la variance propre à chaque schéma :

\`\`\`

part du mineur = hashrate du mineur / hashrate du réseau

revenu BTC par jour = part du mineur × 144 × récompense_eff

jours avant le seuil = seuil / revenu BTC par jour

\`\`\`

Récompense_eff est la subvention plus les frais moyens du bloc. Au relevé du 09.09.2026, le hashrate du réseau est de 943.73 EH/s, la part des frais de transaction sur les 4320 derniers blocs est de 0.669%, donc récompense_eff = 3.125 × 1.00669 = 3.1459 BTC (mempool.space, consulté le 09.09.2026). Par rapport aux 896.89 EH/s du 29.08.2026, le réseau a augmenté de 5.2%, et le délai d'attente a augmenté exactement d'autant pour tous ceux qui n'ont pas changé de matériel.

Il s'agit de notre calcul selon la formule ci-dessus, pas de données des pools. La variance réelle du PPLNS et du TIDES n'y est pas intégrée, et sur ces schémas la dispersion autour du délai attendu est notable. La conclusion pratique est simple : un ASIC domestique à 100 TH/s attend un seuil de 0.001 BTC environ trois semaines, et pendant tout ce temps l'argent reste chez l'opérateur. Avec un seuil de 0.01 BTC, l'attente dépasse six mois. Vous pouvez saisir votre propre hashrate et votre propre tarif dans le calculateur de paiements.

Comment assembler ces composantes en une seule évaluation, et avec quel poids ?

Par une somme pondérée de quatre scores normalisés, où la fiabilité des données fonctionne aussi comme un filtre d'admission. Les poids ci-dessous sont notre choix et notre responsabilité, pas une norme du secteur : quiconque pense différemment a le droit de fixer les siens et d'obtenir un autre classement des pools. C'est précisément pour cela que les poids sont publiés, et non cachés dans le code.

Ordre du calcul :

1. Calculez le net BTC/day pour chaque pool avec le même hashrate et le même prix de l'électricité. Utiliser des entrées différentes pour des pools différents est l'erreur de comparaison la plus fréquente.
2. Normalisez le rendement sur une échelle de 0 à 100 au sein de l'ensemble comparé : le meilleur pool de l'ensemble obtient 100, le pire 0. L'évaluation est relative, et il faut s'en souvenir à la lecture.
3. Évaluez le risque de l'opérateur selon les signes observables de la section précédente. L'échelle est grossière : 0, 25, 50, 75, 100. La précision ici est trompeuse, et il ne faut pas prétendre que le risque est mesuré au pourcentage près.
4. Évaluez la fiabilité des données selon l'échelle à quatre niveaux et convertissez-la en points : le niveau 1 vaut 100, le niveau 2 vaut 66, le niveau 3 vaut 33, le niveau 4 vaut 0.
5. Calculez la liquidité comme le seuil divisé par votre revenu journalier, et normalisez-la comme le rendement : plus rapide signifie plus haut.
6. Additionnez avec les poids et obtenez le résultat.

Poids proposés :

Une règle stricte s'ajoute à la somme : un pool avec une fiabilité des données de niveau 3 ou 4 ne participe pas au classement. Il apparaît dans la liste avec la mention « données non confirmées » et sans score final. Sinon on obtient une absurdité, où un pool obtient un score élevé pour une jolie commission que personne n'a pu confirmer.

À quoi cela ressemble pour un pool :

\`\`\`

Rendement 82 × 0.50 = 41.0

Risque 75 × 0.20 = 15.0

Fiabilité 100 × 0.20 = 20.0

Liquidité 60 × 0.10 = 6.0

Total 82.0

\`\`\`

Pourquoi nous ne publions pas de tableau de scores finaux pour tous les pools

Parce qu'un tel tableau, valable pour tous les lecteurs, n'existe pas, et sa publication créerait une fausse impression d'objectivité. Les raisons sont concrètes, pas de simples considérations générales.

Premièrement : trois des quatre composantes dépendent d'entrées propres à chacun. Le rendement se calcule avec votre hashrate et votre prix du kilowatt, la liquidité avec votre délai pour atteindre le seuil. Un ASIC domestique à 100 TH/s attend un seuil de 0.001 BTC environ trois semaines, une ferme à 1 PH/s environ deux jours. Un même seuil donne des évaluations différentes à des lecteurs différents, et il n'y a rien à moyenner.

Deuxièmement : la moitié des pools comparés ne passe pas le filtre d'admission. Chez AntPool, Binance Pool, Foundry USA et Luxor, le taux de commission n'est pas officiellement publié, et selon notre propre règle, ils restent sans score final. Un tableau où quatre lignes sur dix sont vides n'est pas un classement.

Troisièmement : les poids sont un choix, pas une grandeur mesurable. Nos 50/20/20/10 reflètent une vision de ce qui compte, et toute autre répartition donnera un autre classement. Le score global d'un pool est toujours une décision d'auteur, pas une propriété du pool.

Comment ajuster les poids pour vous-même. Si vous avez une ou deux machines et que le seuil met des semaines à s'atteindre, augmentez le poids de la liquidité et baissez celui du rendement : un demi pour cent de commission sur un tel volume vaut moins qu'un mois d'attente. Si votre solde contient en permanence une somme notable, augmentez le poids du risque de l'opérateur. Si vous n'êtes absolument pas prêt à vous fier à des chiffres non confirmés, ne traitez pas la fiabilité des données comme un poids mais comme un filtre strict : les pools de niveau 3 et 4 sont simplement exclus de la comparaison.

Dans quels cas l'évaluation composite ment-elle et que faut-il vérifier soi-même ?

Elle ment dans trois situations typiques : quand le moyennage cache un échec sur une composante, quand l'ensemble de pools comparés est choisi de façon à ce que la normalisation déforme le tableau, et quand les chiffres à l'intérieur des composantes proviennent de dates différentes. Le score composite est une synthèse pratique, pas un verdict, et la décision se prend après vérification des sources.

Où cela se casse exactement :

• Le moyennage cache un zéro. Un pool peut obtenir un total correct avec une fiabilité de données nulle, si son rendement sur le papier est le meilleur. C'est précisément pour cela qu'existe la règle d'admission de la section précédente.
• La normalisation dépend de l'ensemble. Le même pool obtiendra 100 pour le rendement dans un groupe de cinq pools chers, et 60 dans un groupe de quinze. Le score est comparable au sein d'un même instantané, pas entre instantanés.
• Les dates divergent. La commission est vérifiée en août, les paramètres du réseau relevés en septembre, le cours du BTC est celui de la veille. Le résultat a l'air d'un chiffre unifié, alors qu'il est assemblé à partir de données de trois jours différents.
• Les poids sont une question de goût. Nos 50/20/20/10 reflètent notre vision de ce qui compte. Les vôtres peuvent être différents, et alors l'ordre des pools changera, et ce ne sera pas la faute de l'arithmétique.
• Le coût du changement n'entre pas dans le score. Chez ViaBTC, la fenêtre PPLNS est décrite comme les 5 derniers rounds de difficulté, chez Ocean le schéma TIDES a une fenêtre de 8 difficultés réseau. Quitter un tel pool annule la position accumulée dans la fenêtre, et une différence d'un point ne compense pas cela.
• Le pool change les conditions à l'intérieur de la fenêtre d'évaluation. La commission et le seuil ne sont pas des constantes, mais des valeurs courantes. Une vérification une fois par mois signifie que vous utilisez un chiffre obsolète pendant un mois.

Ce qu'il faut vérifier soi-même avant de diriger son hashrate :

1. Ouvrez vous-même la page officielle des commissions du pool choisi et assurez-vous de voir le même chiffre que dans la comparaison.
2. Trouvez le seuil de paiement et la règle sur le reliquat sous le seuil. Si la règle n'est pas publiée ouvertement, considérez que vous perdez le reliquat en partant.
3. Lisez la section des conditions de service sur les récompenses non versées et les délais.
4. Vérifiez que le schéma de paiement de votre compte est bien celui de la comparaison. Chez plusieurs pools, le schéma se choisit dans les paramètres et n'est pas le moins cher par défaut.
5. Recalculez le rendement avec votre propre prix de l'électricité, pas avec la moyenne du marché.

Comment utiliser cette méthode en pratique pour choisir un pool ?

Comme un filtre, pas comme un classement. D'abord vous éliminez les pools aux données non confirmées, ensuite vous calculez le rendement avec vos propres entrées, ensuite vous regardez la liquidité pour votre hashrate, et enfin seulement vous comparez les scores finaux des deux ou trois candidats restants. Tout le processus prend une soirée et économise des mois sur un pool mal choisi.

Ordre des actions :

1. Constituez une liste de candidats. Un instantané prêt à l'emploi avec commissions, schémas et seuils se trouve dans les fiches des pools, où l'on voit aussi quels chiffres sont confirmés officiellement et lesquels ne le sont pas.
2. Éliminez tous ceux dont la fiabilité des données est de niveau 3 ou 4. Cela ne veut pas dire que le pool est mauvais, cela veut dire qu'il n'y a rien à comparer.
3. Calculez le net BTC/day dans le calculateur avec votre propre hashrate et votre propre prix du kilowatt. Pas la moyenne, pas le « typique pour la région ».
4. Divisez le seuil de paiement de chaque candidat par le revenu journalier obtenu. Vous obtenez le délai avant le premier paiement en jours. S'il dépasse un mois, la liquidité devient votre facteur principal, pas la commission.
5. Lisez chez les deux finalistes les conditions sur le reliquat et sur la récompense non versée.
6. Fixez vos propres scores et poids. Si deux pools diffèrent de moins de 5 points, la différence est dans la marge d'erreur des données sources, et il vaut mieux choisir selon ce qui n'est pas chiffré : la langue du support, la rapidité de réponse, l'existence d'une page de statut.
7. Notez la date de vérification et revenez-y dans un trimestre. Les commissions et les seuils changent, et une décision prise sur des données de l'année dernière ne vaut pas mieux qu'une décision prise sur des rumeurs.

Cas particulier où la méthode n'est pas nécessaire : si vous envisagez sérieusement le solo-mining, les composantes sont les mêmes, mais les poids sont tout autres, parce que la variance cesse d'être un paramètre et devient l'enjeu principal. Il existe à ce sujet une comparaison entre solo-mining et pool.

En bref

La comparaison sur une seule commission ne fonctionne que sur un marché calme des frais de transaction, et seulement pour un mineur indifférent aux délais de paiement. Dès que des tarifs non divulgués, des seuils de 0.001 BTC et des règles sur le reliquat non versé entrent en jeu, un seul chiffre cesse de décrire la réalité.

Quatre composantes au lieu d'une ne rendent pas l'évaluation précise. Elles la rendent honnête : on voit de quoi elle est composée, quel poids est donné à quoi et où les données manquent tout simplement. Le score d'un pool dont la commission n'est pas publiée n'est pas un score bas, mais une absence de score, et le reconnaître est plus utile que d'insérer dans la formule un chiffre venu d'un agrégateur.