Firmware à 0 % de frais de dev : ce que « sans frais de dev » signifie vraiment

« 0 % dev fee » est la phrase la plus citée dans le marketing des firmwares de minage — et l’une des moins examinées. Presque tous les firmwares aftermarket revendiquent quelque part sur leur page tarifaire une voie sans frais. Lisez l’astérisque et le portrait change : le zéro ne s’applique en général que si vous dirigez votre hashrate vers leur pool. Voici un regard honnête sur le fonctionnement réel des dev fees, sur ce que les chiffres signifient vraiment (en fourchettes, pas les chiffres uniques soigneusement répétés partout), et sur la façon de distinguer un véritable modèle de don d’un prélèvement discret — en lisant le code source plutôt qu’en se fiant au badge.

Ce qu’est vraiment un dev fee (et comment le prélèvement discret s’opère)

Lorsque vous flashez un firmware personnalisé sur un Antminer, vous confiez le code d’autrui pour communiquer avec vos hashboards, gérer votre connexion au pool et soumettre vos shares. Un dev fee est la façon dont la plupart des auteurs de firmwares aftermarket se font rémunérer pour ce travail : pendant un petit pourcentage du temps, votre mineur mine pour eux plutôt que pour vous.

Mécaniquement, c’est en général l’une de deux méthodes. La plus courante est la redirection de pool : pendant environ 2–3 % du temps, le firmware remplace silencieusement votre pool configuré par l’adresse du pool du développeur, mine quelques shares là-bas, puis revient. Vous ne le voyez jamais dans le tableau de bord de votre propre pool, car ces shares n’ont jamais été soumis sous votre compte. La seconde méthode est le minage de fee en tâche de fond — une file de travail à faible priorité qui prélève un pourcentage avant même que vos shares ne quittent l’appareil. Dans les deux cas, le calcul est le même : un dev fee de 2.5% sur un mineur qui gagne l’équivalent de $5/day en Bitcoin représente environ $0.12/day, soit à peu près $45/year, par machine. Exploitez un rack et la somme s’accumule.

Rien de tout cela n’est intrinsèquement louche. Le firmware est un travail difficile, ingrat, 24 h sur 24, et le dev fee est le moteur qui le finance. Soyons clairs d’emblée : les firmwares qui facturent un fee ont mérité ce droit. Braiins, VNish et Luxor ont chacun passé des années à bâtir des outils dont des millions de mineurs dépendent aujourd’hui. Le problème n’est pas qu’un fee existe — c’est qu’il est souvent obfusqué, et que le « 0 % » marketing est fréquemment conditionné au pool d’une façon que personne ne lit. Mettons les vrais chiffres sur la table.

Le tableau honnête des dev fees (en fourchettes, pas en chiffres fixes)

Vous verrez des chiffres uniques répétés partout sur Internet — « BraiinsOS est à 2 % », « VNish est à 3 % ». Ce sont des simplifications. Les vrais fees sont des fourchettes qui varient selon le modèle de mineur, la version du firmware et le pool que vous utilisez. Voici la version ancrée dans les faits, recoupée avec notre matrice de fonctionnalités des firmwares :

Deux points méritent d’être dits clairement. Premièrement, le stock firmware Bitmain est aussi à « 0 % » — mais il est fermé, chargé de télémétrie, et vous empêche d’ajuster votre propre matériel, ce qui est précisément la raison d’être d’une industrie aftermarket. Un fee à 0 % sur un firmware que vous ne contrôlez pas n’est guère une aubaine. Deuxièmement, ces fees de 2–2.8% sont le prix d’une ingénierie véritablement excellente. Nous détaillons la comparaison fonctionnalité par fonctionnalité dans notre comparaison de firmwares — c’est la matrice à lire si vous voulez peser les fees face aux fonctionnalités (qualité de l’autotuning, support Stratum, couverture des modèles) plutôt que de courir après le chiffre le plus bas isolément.

Deux frais distincts, et pourquoi le « 0 % » est mal lu

C’est ici que l’affirmation la plus répandue du sujet dérape. On lit partout que Braiins OS serait « à 0 % si vous minez sur Braiins Pool ». C’est faux — mais il existe bel et bien un zéro tout près, et il appartient à un autre frais. Les éditeurs de firmware prélèvent des frais de développement, en redirigeant une part de votre puissance de calcul. Les pools prélèvent des frais de pool sur vos revenus. Ce sont deux lignes distinctes, et le remboursement que tout le monde répète ne s’applique qu’à la seconde :

• Braiins OS → le zéro, ce sont les frais de pool, pas les frais de développement. La page du fournisseur énonce les deux clairement. Les frais de développement : « Lorsque vous utilisez Braiins OS, nous prélevons un dev fee de 2 à 2,5 % (selon le modèle de matériel) en dirigeant ce pourcentage de votre puissance de calcul vers notre pool. » Cela s’applique quel que soit le pool visé. Les frais de pool sont l’autre ligne : « Lorsque vous minez sur Braiins Pool avec Braiins OS, vous obtenez un taux effectif de 0 % de frais de pool au lieu des 2,5 % standards. Les frais sont d’abord perçus, puis un remboursement est appliqué… Si toute votre flotte tourne sous Braiins OS, vous recevez un remboursement intégral de 100 % des frais de pool. » Deux frais; le remboursement annule le second et laisse le premier intact. Ce remboursement à 100 % est un avantage réel et documenté, sans équivalent chez DCENT_OS — ce n’est simplement pas un dev fee à 0 %. (Vérifié — braiins.com/os-firmware, 2026-08-20.)
• LuxOS → la même structure à deux frais. luxor.tech/mining/firmware annonce « 0% Pool Fees »; les frais de développement de 2,8 % sont publiés séparément, dans docs.luxor.tech. Miner sur Luxor Pool porte sur les frais de pool. Aucune exemption des frais de développement n’est documentée : la lecture prudente reste 2,8 % publiés, sans zéro côté opérateur. (Vérifié — docs.luxor.tech, 2026-08-20.)
• VNish → 1,8 à 2,8 %, sans zéro lié à un pool. VNish publie une seule fourchette et l’applique quel que soit le pool; il n’y a donc pas de second frais à démêler. (Vérifié — FAQ vnish.io, 2026-08-20.)
• Awesome Miner → 2,8 % sur tout le matériel actuel. Un palier à 1,8 % existe, mais uniquement pour trois familles anciennes (S9/S9i/S9j, T9+, L3+/L3++). Sur tout S17, S19, S21, T17, T19 ou T21, le chiffre est 2,8 %, déterminé par le modèle et non choisi par vous. (Vérifié — tableau des modèles du fournisseur, 2026-08-20.)
• Hiveon → aucun chiffre publié. Un taux de 3 % circule largement; nous n’avons pas pu le rattacher à Hiveon. À traiter comme Inconnu plutôt qu’à répéter. (Inconnu — aucun chiffre sur hiveon.com ni dans sa base de connaissances, 2026-08-20.)

Les deux entreprises énoncent leurs conditions sur leurs propres pages; la confusion naît en aval, dans la façon dont les deux frais sont répétés comme un seul. Ce que la distinction change, c’est l’arithmétique. Sur Braiins Pool avec Braiins OS, vous payez les frais de développement de 2 à 2,5 % et, dans les faits, aucuns frais de pool. Sur n’importe quel autre pool, vous payez ces mêmes frais de développement plus les frais de ce pool. Le remboursement vaut de l’argent réel — ce n’est simplement pas le dev fee qui tombe à zéro, et toute comparaison qui les confond vous donnera le mauvais chiffre.

Deux réserves honnêtes, avant qu’on lise ceci comme un argumentaire de vente. ePIC UMC OS prélève 1,5 %, réduit depuis un taux plus élevé le 2026-01-26, et c’est moins que les 2 % auxquels DCENT_OS livre son don optionnel. Pour un opérateur qui n’ouvre jamais le réglage, ePIC coûte moins cher. Nous ne prenons l’avantage qu’une fois le réglage utilisé — DCENT_OS offre un préréglage 0 % en un clic et un interrupteur dans ses propres paramètres; ePIC, non. Et Braiins comme ePIC facturent une licence forfaitaire plutôt que de prélever du hashrate, ce que DCENT_OS ne propose pas et que les opérateurs institutionnels préfèrent souvent pour leur comptabilité. Là où un concurrent est réellement meilleur, c’est ce que le tableau doit dire.

Reste un coût qu’aucun tableau de frais n’affiche : la destination de vos shares. Choisir son propre pool est l’un des rares leviers qu’un mineur individuel possède sur la décentralisation de Bitcoin, et une structure de frais qui pousse une flotte entière vers un seul pool mérite d’être pesée face au pourcentage qu’elle fait économiser. C’est un arbitrage, pas une accusation — et c’est précisément la raison pour laquelle nous nous en préoccupons.

Pourquoi les outils de piratage « NoDevFee » sont une mauvaise idée

Cherchez « remove dev fee » et vous trouverez une véritable industrie artisanale d’« NoDevFee » outils — chargeurs, binaires patchés et astuces de redirection DNS qui promettent d’éliminer le fee des firmwares fermés. Passez votre chemin. Voici la réalité d’ingénierie honnête :

• Vous exécutez un binaire inconnu en root sur une machine qui imprime de l’argent. Pour « retirer » un fee d’un firmware fermé, ces outils patchent ou remplacent le composant même qui contrôle vos hashboards et vos identifiants de pool. Vous n’avez aucun moyen d’auditer ce qu’ils ont changé d’autre. Le résultat le plus souvent rapporté sur le terrain est que le fee est redirigé vers l’auteur de l’outil plutôt que supprimé — vous n’avez pas tué le prélèvement, vous avez seulement changé qui vous siphonne.
• Cela peut bricker votre mineur. Patcher un firmware que vous ne pouvez pas lire est exactement le type d’opération qui se termine par une carte de contrôle morte et une session de récupération sur SD-card — si vous avez la chance que la récupération soit même possible.
• C’est une impasse de confiance. Toute la raison de s’inquiéter d’un fee de 2.5%, c’est que vous ne voulez pas qu’un inconnu prélève une part de votre hashrate. Résoudre cela en exécutant le correctif non audité d’un autre inconnu n’est pas une solution. C’est le même problème sous un autre chapeau.

La réponse propre à « je ne veux pas payer de dev fee » n’a jamais été un outil de piratage. C’est un firmware honnête par conception — où la logique du fee est ouverte, le défaut est zéro, et vous pouvez le vérifier vous-même plutôt que de faire confiance à la parole de quiconque, y compris la nôtre.

Don, pas détournement : le modèle DCENT_OS

DCENT_OS — le micrologiciel open source de D-Central pour certains Antminer — est conçu sans frais de développement obligatoires. Cette affirmation doit être vérifiée contre la source, la provenance du binaire et la configuration de la build testée; elle ne constitue ni un audit indépendant ni une promesse de préparation à la production.

Ce qu’il y a, c’est un champ de don optionnel et transparent dans le tableau de bord — un pourcentage configurable que vous pouvez régler vous-même si vous souhaitez soutenir le projet. Il est activé à 2 % par défaut — nous sommes directs là-dessus — et vous pouvez le régler à zéro. À 2 %, votre mineur passe 72 secondes de chaque heure sur le pool de D-Central et les 3 528 autres sur le vôtre, avec un badge « DONATING » affiché tout du long. Réglez-le à zéro et 100 % de votre hashrate vous revient. Si vous jugez que le firmware a mérité quelques sats, vous pouvez fixer une contribution et suivre exactement où elle va. Voilà la distinction qui compte : c’est un don, pas un détournement. Le montant vous appartient, et rien n’est caché — le mécanisme de dev fee est ouvert et auditable dans le code source, là où la plupart des firmwares l’obfusquent.

Les firmwares qui facturent 2–2,8 % financent une véritable ingénierie, et D-Central s’appuie sur le chemin tracé par Braiins, VNish et Luxor. Le modèle sans frais obligatoires est un autre compromis, pas une supériorité morale. Des artéfacts signés existent pour les voies exactes S9 XIL et S19j Pro XIL, mais leurs preuves d’installation restent incomplètes. Ils sont expérimentaux, sous garde et non prêts pour la production. Consultez la page DCENT_OS et le registre de preuves avant tout téléchargement.

Comment vérifier un dev fee en open source

Voici la compétence pratique qui rend tout ce qui précède secondaire : lorsque le firmware est open-source, vous n’avez pas à croire l’affirmation sur le fee — vous pouvez la vérifier. C’est le vrai argument en faveur du firmware ouvert, et il dépasse tout pourcentage isolé. Un prélèvement que l’on peut lire est un prélèvement qui ne peut se cacher.

Si vous savez lire le code source (ou suivre quelqu’un qui le sait), voici à peu près à quoi ressemble l’audit d’un fee :

1. Trouvez le code de connexion au pool. Tout dev fee qui fonctionne par redirection doit, à un moment donné, remplacer l’URL de pool que vous avez configurée par une autre. Parcourez le code source pour la logique de connexion pool/stratum et cherchez toute adresse qui n’est pas celle que vous avez définie. Dans un firmware honnête, il n’y a qu’un seul endroit où votre pool est configuré.
2. Cherchez la logique de découpage temporel ou de file de travail. Le minage de fee fonctionne en allouant un pourcentage des cycles de travail ailleurs. Recherchez des constantes de pourcentage, des minuteries, ou une source de travail secondaire alimentant le soumetteur de shares. Un « 0.025 » codé en dur près de la boucle de minage raconte sa propre histoire.
3. Vérifiez la valeur par défaut du champ de don et son câblage. Dans un firmware avec une contribution configurable, lisez la valeur par défaut dans la source plutôt que sur la page marketing, et suivez où une valeur non nulle envoie les shares. Faites-le d’abord sur nous : DCENT_OS livre cette valeur par défaut à 2 %, activée, routée vers une URL de pool imprimée dans le même fichier, et GET /api/donation/info est volontairement non authentifié pour que vous puissiez vérifier l’adresse de paiement on-chain. La valeur que vous fixez doit être la seule en jeu.
4. Privilégiez les builds reproductibles. L’étalon-or, c’est de pouvoir compiler le firmware vous-même à partir du code source et d’obtenir un binaire qui correspond à ce qui est distribué — ainsi vous savez que le code en exécution est celui que vous avez lu. Les builds Buildroot reproductibles sont l’intention de conception de DCENT_OS; traitez « vous pouvez le vérifier vous-même » comme la barre à exiger de tout firmware ouvert.

Avec un firmware fermé (stock, VNish, LuxOS, ou les composants fermés de BraiinsOS+), vous ne pouvez tout simplement pas le faire — vous faites confiance au badge et à la marque. Ce n’est pas toujours une erreur; la confiance est une chose raisonnable à accorder à un développeur au long parcours. Mais « davantage d’options pleinement auditables », c’est, à notre avis, la même chose que « davantage de décentralisation ». Plus il y a de mineurs qui peuvent vérifier leur propre pile logicielle, plus il devient difficile pour quiconque — y compris nous — de les siphonner en silence. C’est le principe qui mérite d’être optimisé, et il se situe un cran au-dessus de tout chiffre de dev fee : il s’agit de posséder la boîte que vous faites tourner, le même instinct de sauvegarde de votre souveraineté qui sous-tend tout, de l’exécution de votre propre nœud au maintien de votre propre infrastructure résiliente.

Alors, quel firmware devriez-vous réellement utiliser?

Honnêtement? Pour une flotte de production aujourd’hui, les options matures et éprouvées au combat sont celles qui facturent un fee — et ce fee vous achète des années d’affinage de l’autotuning et un large support de modèles. Ne choisissez pas un firmware sur le seul dev fee; choisissez-le sur le portrait d’ensemble. Si vous voulez peser les fees face aux fonctionnalités côte à côte, la matrice complète de comparaison des firmwares détaille chaque colonne — dev fee, statut open-source, support Stratum et modèles supportés — pour que vous puissiez décider avec les astérisques bien visibles.

DCENT_OS vise une pile de micrologiciel contrôlable par l’opérateur et sans frais obligatoires. Le daemon, le tableau de bord et l’intégration Buildroot sont publics sous GPL-3.0; une image Antminer complète exige aussi des entrées de démarrage fabricant documentées mais non redistribuées. Les artéfacts actuels restent sous garde. Vérifiez le modèle, la carte et les preuves avant de conclure qu’une build est installable.

Foire aux questions