Deux « forks » de Bitcoin sont prévus en août : tout ce qu'il faut savoir

L’une est une proposition de soft fork appelée BIP-110. L’autre est un hard fork prévu, appelé eCash, soutenu par Paul Sztorc, l’architecte de Drivechain. Ils partagent un calendrier quelque peu similaire. En revanche, ils ne partagent ni le même mécanisme, ni le même objectif, ni le même profil de risque. Voici une analyse complète de ce que chacun d’entre eux représente, de la manière dont l’histoire du Bitcoin éclaire la suite des événements, et de ce que les détenteurs devraient réellement faire.

Les « soft forks » et les « hard forks », expliqués simplement

Les règles du Bitcoin peuvent évoluer de deux manières structurellement différentes. Un « soft fork » renforce les règles existantes. Il est rétrocompatible, ce qui signifie que les nœuds qui ne se mettent pas à jour peuvent toujours considérer les nouveaux blocs comme valides, même si les nouvelles règles rejettent certaines transactions que les anciennes auraient acceptées. Les soft forks s’activent lorsqu’une partie suffisante du réseau les adopte, et dans le cas d’une activation « propre », la chaîne reste unifiée. Un hard fork assouplit ou modifie les règles d’une manière qui n’est pas rétrocompatible. Les nœuds qui ne se mettent pas à jour rejetteront les blocs provenant des nœuds qui l’ont fait, et vice versa. Si le réseau ne progresse pas de manière unifiée, il se scinde en deux chaînes distinctes avec deux actifs distincts. La scission de Bitcoin Cash (BCH) en 2017 en est l’exemple le plus flagrant. Ethereum Classic (ETC), né de la scission DAO de 2016, en est un autre.

C’est cette distinction qui explique pourquoi le BIP-110 reste techniquement un « soft fork », même s’il comporte un risque réel de scission, et pourquoi eCash est un « hard fork » de par sa conception, et non par accident.

BIP-110 : ce qu’il change réellement

Le BIP-110, également appelé « Reduced Data Temporary Softfork », a été rédigé par Dathon Ohm. Il cible le type d’intégration de données utilisé par les Ordinals, les inscriptions et les jetons de type BRC-20. L’ensemble de règles comprend plusieurs restrictions spécifiques. Les nouvelles scriptPubKeys supérieures à 34 octets deviennent invalides, à l’exception des sorties OP_RETURN pouvant atteindre 83 octets. Les insertions de données et les éléments de témoin supérieurs à 256 octets deviennent invalides. L’utilisation de versions de témoin ou de Tapleaf non définies est bloquée. Les annexes Taproot et les blocs de contrôle surdimensionnés sont restreints, tout comme certains opcodes Tapscript tels que OP_SUCCESS, OP_IF et OP_NOTIF.

La proposition prévoit une clause de maintien des droits acquis pour les UTXO créés avant l’activation ; ainsi, les pièces déjà existantes peuvent toujours être transférées selon les anciennes règles. Elle est également conçue pour être temporaire. La durée active (active_duration) inscrite dans la spécification est d’environ un an ; elle expire automatiquement plutôt que de devenir une partie permanente des règles de consensus de Bitcoin.

L’activation utilise un déploiement BIP9 modifié avec un seuil de signalisation de 55 %, bien supérieur au seuil de 95 % utilisé lors des précédentes fourches douces, mais nécessitant tout de même une large adhésion des mineurs. Il n’y a pas de délai d’expiration basé sur le temps. La spécification fixe une hauteur d’activation maximale aux alentours du 1er septembre 2026 et prévoit une fenêtre de signalisation obligatoire juste avant le verrouillage, qui devrait débuter vers le bloc 961 632, soit environ le 8 août. Les blocs qui n’émettent pas de signal pendant cette fenêtre seront rejetés par les nœuds chargés de faire respecter la règle, ce qui garantit le verrouillage au plus tard au bloc 963 648 et l’activation de la règle au bloc 965 664, selon le texte même de la proposition.

Le paradoxe de la signalisation

C’est là que les choses deviennent déroutantes pour quiconque suit les chiffres. Le taux de signalisation des mineurs publics pour le BIP-110 est resté faible. Les données de BGeometrics indiquaient un taux de signalisation quotidien compris entre 2 % et 3 % début juin. Le taux de signalement cumulé s’élevait à environ 0,42 % au 2 juillet, sur les 9 066 blocs suivis depuis le 1er mai. Au cours des derniers jours, il a augmenté pour atteindre un taux global de 0,83 %. Les chiffres au niveau des nœuds présentent également des résultats incohérents.

Selon les premières estimations, le taux de signalisation des nœuds accessibles avoisinerait les 2,38 %, tandis qu’une autre mesure, utilisant une définition plus large de « tous les nœuds connus », situerait ce chiffre entre 14 % et 23 %. Certains ont fait valoir que le nombre de nœuds publics peut être gonflé par la méthodologie de mesure, voire par des duplications de type Sybil peu coûteuses, et qu’il ne reflète de toute façon pas nécessairement le poids économique réel.

Un faible taux de signalisation ne signifie pas un faible risque. Le risque de scission ne se résume pas au pourcentage actuel. Il s’agit de savoir ce qui se passera si les mineurs, les plateformes d’échange, les portefeuilles et les grands détenteurs sont en désaccord lorsque la période de signalisation obligatoire arrivera effectivement en août. Plusieurs observateurs estiment que le BIP-110 est un soft fork présentant un risque élevé de scission temporaire ou persistante de la chaîne, précisément parce qu’il est contesté. C’est là le paradoxe : le soutien visible semble faible, mais le mécanisme crée néanmoins un véritable événement de coordination susceptible d’entraîner des perturbations.

Le sentiment sur X montre que le débat suit des lignes de fracture familières. Les partisans, qui utilisent souvent le logiciel Knots, présentent le BIP-110 comme une correction des incitations faussées par les précédents changements de politique de relais, et s’appuient sur des simulations suggérant que les règles pourraient filtrer une part significative des transactions non monétaires tout en préservant tous les cas d’utilisation financiers connus. Luke Dashjr l’a défendu en le présentant comme une restauration du protocole plutôt que comme une nouvelle forme de censure. Les détracteurs rétorquent que le filtrage au niveau des politiques n’a pas sa place dans le consensus, que le seuil bas augmente les risques de scission d’une manière que les soft forks précédents avaient évitée, et que le BIP-110 crée un précédent pour de futurs changements controversés. Il convient de noter que la publication d’un BIP dans le référentiel des BIP de Bitcoin constitue une étape d’archivage et non la preuve d’un accord au sein de l’écosystème, une distinction que le référentiel lui-même précise explicitement.

eCash : une chaîne distincte et délibérée

Le projet eCash de Paul Sztorc ne cherche pas à modifier Bitcoin de l’intérieur. Il consiste à construire une nouvelle chaîne qui existera, que l’infrastructure existante de Bitcoin la reconnaisse ou non. La scission est prévue au bloc 964 000 de Bitcoin, ce qui correspondrait, selon les estimations, au 21 août vers 15 h 00 UTC. Les détenteurs actuels de bitcoins recevraient un solde eCash équivalent à ce moment-là, et un outil de séparation des cryptomonnaies serait prévu pour distinguer les deux actifs par la suite. L’ajout principal de la chaîne est la fonctionnalité Drivechain, basée sur les BIP-300 et BIP-301. Le BIP-300 décrit les dépôts fiduciaires de hashrate, tandis que le BIP-301 décrit le minage fusionné aveugle, des mécanismes qui permettent à des sidechains de type Bitcoin de fonctionner avec un modèle de sécurité différent. Les documents liés au lancement font état de plusieurs sidechains prévues pour être actives ou proposées au moment de l’activation.

Comme eCash n’a pas besoin de l’approbation de Bitcoin pour exister, la véritable question qui se pose n’est pas de savoir s’il sera lancé. Il s’agit plutôt de savoir si les plateformes d’échange le référenceront, si les portefeuilles développeront des outils sécurisés autour de celui-ci, et s’il suscitera une participation suffisante pour avoir un impact une fois qu’il sera opérationnel.

Comment les portefeuilles et les plateformes d’échange ont géré les forks passés

Bitcoin a déjà connu des scissions controversées, et l’historique offre une vision assez claire de la manière dont les principaux prestataires de services ont tendance à réagir. Lors des précédents événements de fork, les utilisateurs de portefeuilles étaient généralement informés que leurs cryptomonnaies d’origine resteraient en sécurité, mais qu’il fallait faire preuve de prudence avant de transférer des actifs sur des chaînes concurrentes. L’une des principales préoccupations est le risque de « replay », c’est-à-dire qu’une transaction effectuée sur une chaîne puisse être copiée sur une autre si la scission ne bénéficiait pas de protections adéquates. Une fois que la protection contre le « replay » a été mise en place lors des scissions précédentes et que le réseau concurrent a fait preuve d’une stabilité suffisante, certains prestataires ont ajouté la prise en charge, tandis que d’autres sont restés en retrait.

Les grandes plateformes d’échange ont généralement adopté une approche plus prudente. Plutôt que de reconnaître immédiatement les deux branches d’une scission, elles ont suspendu les dépôts et les retraits, observé quelle chaîne attirait le plus de puissance de hachage et de confirmations, et attendu des signes indiquant que le réseau ne subissait pas de réorganisations majeures. Dans certains cas, la prise en charge de la chaîne la plus faible n’est intervenue que plus tard, et parfois uniquement sous forme de retrait plutôt que de négociation complète.

Cette tendance générale se retrouve à travers plusieurs cycles de fork. Suspendre d’abord les opérations. Laisser émerger une chaîne dominante. Rétablir les services de manière sélective une fois que les risques de replay et de réorganisation s’estompent. Les chaînes minoritaires, lorsqu’elles sont prises en charge, ont tendance à arriver tardivement, avec des fonctionnalités limitées et sans garantie d’un soutien à long terme de la part des plateformes d’échange.

Pourquoi le contexte de 2026 est différent

Les « guerres de fork » de 2017 se sont déroulées sur un marché presque exclusivement composé d’investisseurs particuliers et de détenteurs en auto-custode. Ce n’est plus le cas aujourd’hui. L’IBIT, le fonds négocié en bourse (ETF) Ishares Bitcoin Trust de Blackrock, affichait 44,95 milliards de dollars d’actifs nets au 2 juillet 2026. Strategy a déclaré détenir 847 363 bitcoins au 5 juin.

Le prospectus de l’IBIT déposé auprès de la SEC précise que le trust renoncera de manière permanente et irrévocable à tout droit accessoire sur les actifs issus d’un fork ou d’un airdrop, à moins qu’une future modification de la réglementation de la SEC n’en dispose autrement. Cela signifie qu’une grande partie de l’exposition institutionnelle au bitcoin ne sera structurellement pas affectée par l’une ou l’autre de ces bifurcations, quoi qu’il arrive sur la chaîne. Coinbase a également indiqué que son produit de conservation prend historiquement en charge davantage d’actifs issus de bifurcations que sa plateforme d’échange grand public, ce qui signifie que la gestion institutionnelle et grand public d’un même événement peut diverger dans la pratique.

Dans le cas du BIP-110, cette couche institutionnelle augmente les enjeux d’une scission désordonnée au-delà des seuls portefeuilles grand public, touchant la tarification des ETF, les attestations de conservation, ainsi que les opérations de création et de rachat. Pour eCash, c’est la dynamique inverse qui s’applique. Si une grande partie des bitcoins est détenue sous forme de « wrappers » qui, de par leur nature, ne peuvent pas passer par le nouvel actif, eCash pourrait être lancé avec une participation économique moins dynamique que celle qu’aurait connue une bifurcation axée sur les particuliers en 2017.

Ce que les détenteurs en auto-conservation devraient réellement faire

Pour le BIP-110, il n’y a pas de nouvel actif à réclamer dans le cadre d’une activation sans heurts ; les risques pertinents sont donc la compatibilité et la confusion au niveau du règlement si la fenêtre d’août se déroule de manière chaotique. Les détenteurs utilisant des constructions Taproot spécialisées ou des portefeuilles Miniscript devraient vérifier la compatibilité avant la fenêtre de signalisation obligatoire.

Pour l’eCash, la conservation en auto-garde avant le snapshot est le seul moyen fiable de préserver la possibilité de détenir le nouvel actif, car les bourses et les enveloppes d’ETF pourraient choisir de ne pas le créditer du tout. Toute personne envisageant de réclamer cet actif devrait attendre la prise en charge vérifiée par les portefeuilles et la confirmation de la protection contre la relecture, plutôt que de se précipiter dès le premier jour, en suivant la même prudence que celle dont ont fait preuve de nombreuses entreprises en 2017.

Que va-t-il se passer ensuite ?

Les classifications de base ne font pas l’objet de contestation. Le BIP-110 est un soft fork. L’eCash est un hard fork prévu. Ce qui reste incertain, au 6 juillet 2026, c’est l’aspect opérationnel : le niveau de signalisation du BIP-110 restera-t-il faible jusqu’en août ? Des pools de minage ou des plateformes d’échange majeurs changeront-ils de position ? L’eCash sera-t-il lancé avec une protection contre la relecture vérifiable ? Et quels dépositaires ou « wrappers » choisiront de prendre en charge, d’ignorer ou de rejeter légalement les conséquences de l’un ou l’autre de ces événements ?