Hard fork BNB Chain Jenner le 8 décembre 2026 : Payment Lane, CAS20 et qui doit mettre à jour

Le prochain hard fork de BNB Chain, baptisé Jenner, s’active sur le mainnet de BNB Smart Chain (BSC) le mardi 8 décembre 2026 à 02:30:00 UTC. La date vient de la version 1.8.2 du client bsc, publiée sur GitHub le 3 novembre, qui cale le basculement sur l’horodatage Unix 1796697000. La mise à jour est obligatoire pour les opérateurs de nœuds. Les détenteurs de BNB et des tokens de la chaîne n’ont rien à faire.

Jenner ajoute une voie réservée aux paiements, un standard natif pour les tokens conformes et un moyen pour les smart contracts de lire l’heure du bloc en millisecondes. La vitesse des blocs ne change pas.

Date du hard fork BNB Chain et heures locales

À Paris et à Rome, le fork tombe à 03:30 (CET), à Lagos à 03:30 (WAT), à Johannesburg à 04:30 et à Nairobi à 05:30 (EAT). Londres et Accra l’ont à 02:30. BNB Chain a publié une heure, pas une hauteur de bloc : le numéro exact du bloc ne sera connu que lorsque la chaîne atteindra cet horodatage.

Le test grandeur nature est fait. Jenner a été activé sur Chapel, le testnet de BSC, le 29 octobre 2026 à 02:30 UTC avec le client v1.8.1, selon la page officielle des versions, l’annonce de la documentation et les notes du client Reth. L’article de blog de BNB Chain du 22 octobre donnait le 28 octobre à la place ; nous suivons les registres de versions. Cet article laissait la date du mainnet pour plus tard, et la v1.8.2 l’a fournie.

Ce que change Jenner : Payment Lane, CAS20 et heure en millisecondes

Le fork lui-même est défini dans le BEP-718 et active trois propositions. Dans le dépôt des BEP, les trois portaient encore le statut Draft (brouillon) le 7 novembre, alors que le code client qui les exécute est déjà livré.

Le BEP-703, la Payment Lane, met de côté 5 % du gas de chaque bloc pour les paiements par défaut. La gouvernance peut relever cette part, mais jamais au-delà de 10 %, un plafond inscrit dans le protocole. Deux types de transactions y ont droit : les simples transferts de BNB d’un montant non nul vers un compte ordinaire (sans code de contrat), et les transactions envoyées à des contrats figurant sur une liste de paiement que tient la gouvernance. Cette liste démarre vide. Le BEP dit que l’intention est de commencer par USDT et USDC, mais chaque contrat doit encore être approuvé par la gouvernance : les transferts de stablecoins ne bénéficient donc d’aucun espace réservé dès le premier jour.

Les paiements peuvent déborder des 5 % quand il reste de la place. L’inverse n’est pas vrai : le gas que la voie n’utilise pas reste inemployé et n’est pas redistribué aux autres transactions. Et la voie protège les paiements en tant que groupe, pas un paiement en particulier.

Le BEP-702 crée CAS20, un Compliant Asset Standard (standard d’actifs conformes) intégré au protocole, destiné aux stablecoins et aux actifs réels tokenisés. Un token CAS20 n’est pas un contrat déployé mais un precompile à état exécuté par le nœud, qui garde l’interface BEP-20 familière pour les portefeuilles. Les émetteurs disposent de rôles distincts pour créer (mint), détruire (burn), suspendre et saisir, ainsi que de listes d’autorisation et de listes de blocage tenues dans un registre de politiques partagé. Le blog de BNB Chain ajoute que ces contrôles ne rendent pas, à eux seuls, un token conforme sur le plan juridique.

Jenner ne livre que la capacité technique. La création de tokens et l’écriture dans le registre de politiques exigent un interrupteur séparé, actionné par un administrateur que nomme la gouvernance, et le blog qualifie cette étape de « bientôt disponible » sans donner de date.

Le BEP-706 ajoute un precompile à l’adresse 0x70 qui renvoie l’heure du bloc courant en millisecondes, pour un coût de 20 gas. block.timestamp reste en secondes : les contrats existants se comportent donc comme avant, et seuls ceux qui appellent la nouvelle adresse voient l’horloge plus fine. Le BEP vise notamment les cotations à expiration inférieure à la seconde, les clôtures d’enchères et les contrôles de fraîcheur des flux de prix.

La version 1.8.2 embarque aussi les changements du BEP-675 pour les constructeurs de blocs MEV, livrés une première fois dans la v1.8.1 : enchères de blocs envoyées en gRPC sous forme binaire, rejet des enchères dont la racine d’état est vide, et bannissements de constructeurs qui survivent à un redémarrage du nœud. Ce sont des changements du client, pas des règles du hard fork : ils s’appliquent dès qu’un nœud exécute la nouvelle version. La documentation indique un drapeau, --mev.grpc.disable, pour désactiver le service gRPC, qui écoute par défaut sur le port 8552.

Qui doit agir avant le 8 décembre

La version désigne son public : opérateurs de nœuds du mainnet, constructeurs MEV et opérateurs de nœuds sentry. Le travail se répartit selon le rôle.

• Les validateurs et autres opérateurs de nœuds remplacent le binaire par bsc v1.8.2 (basé sur geth) ou par BSC-Reth v0.1.4, puis redémarrent avant 02:30 UTC le 8 décembre. Quiconque tourne encore sous v1.7.x ou v1.8.0-alpha doit d’abord lire les notes des versions v1.8.0-alpha et v1.8.1, car certains champs de configuration ont été supprimés.
• Les constructeurs MEV doivent laisser de la place au gas que réserve la Payment Lane quand ils remplissent les blocs, et vérifier leurs outils d’enchères par rapport à l’interface gRPC.
• Les développeurs d’applications qui simulent des appels sur BSC-Reth doivent vérifier le changement de RPC décrit plus bas, et tester le precompile en millisecondes si leurs contrats comptent l’utiliser.
• Les équipes de paiement doivent vérifier quels transferts comptent comme des paiements : les simples transferts de BNB oui, les transferts de tokens seulement une fois leur contrat voté sur la liste.
• Les détenteurs n’ont rien à faire. Aucune source officielle ne leur demande de déplacer, d’échanger ou de « mettre à niveau » des tokens, et un message qui le fait doit être traité comme une arnaque probable.

Nous n’avons trouvé aucun avis de plateforme d’échange au sujet de Jenner au 7 novembre : on ignore donc encore si une plateforme suspendra les dépôts ou les retraits sur BSC autour du fork.

Le client Reth : v0.1.4 pour le fork, puis un correctif

BSC-Reth, le client en Rust, a sa propre ligne de versions. La version 0.1.3, sortie le 16 octobre, embarquait Jenner pour Chapel. La version 0.1.4, publiée le 3 novembre en même temps que bsc v1.8.2, fixe l’horodatage du mainnet et est marquée obligatoire pour les opérateurs du mainnet.

Un second build a suivi. La v0.1.4-hotfix est sortie à 02:53 UTC le 6 novembre avec le correctif amont de Reth pour un calcul erroné de la racine d’état dans certaines conditions du trie. Elle n’exige ni migration de base de données ni hard fork, et BNB Chain recommande de l’installer au plus vite sur le mainnet et le testnet. Le compte rendu de Crypto Briefing du 6 novembre traite les deux builds comme une seule version ; les pages GitHub les séparent. Notre article sur le bug de Reth qui pouvait donner aux nœuds une racine d’état erronée traite ce correctif chez Base, BNB Chain et Tempo.

Un changement de RPC de Reth, introduit dans la v0.1.3, s’applique dès la mise à niveau d’un nœud, avant le fork : dans eth_call, eth_estimateGas, debug_traceCall et eth_simulateV1, un blockOverrides.prevRandao fourni doit encoder le reste en millisecondes (de 0 à 999) sous forme hexadécimale de 32 octets. Surcharger uniquement le champ de l’heure remet ce reste à zéro.

De Lorentz à Jenner : hard forks de BSC et temps de bloc

Trois forks ont ramené le temps de bloc de BSC de 3 secondes à 0,45 seconde entre avril 2025 et janvier 2026. Avec plus de deux blocs par seconde, une horloge qui compte en secondes entières ne distingue plus deux blocs voisins : c’est le vide que comble le BEP-706.

Jenner n’a pas de lien avec la Layer 1 distincte à blocs de 200 ms que BNB Chain prépare pour 2027, toujours sur un devnet privé.

Pourquoi cela compte pour les lecteurs en Europe et en Afrique

La Payment Lane vise les petits transferts, là où les frais de gas et la congestion pèsent le plus. Un simple transfert de BNB entre deux portefeuilles y est éligible dès le fork. Les transferts de stablecoins, que beaucoup de lecteurs en Europe et en Afrique utilisent pour payer, n’y gagnent rien tant que la gouvernance n’a pas listé leurs contrats.

CAS20 donne aux émetteurs des outils on-chain pour geler, saisir ou restreindre des tokens. Aucun émetteur, en Europe ou ailleurs, n’a annoncé de token CAS20.

Ce que l’on ignore encore

BNB Chain n’a pas dit quand la création de tokens CAS20 sera activée, qui détiendra ce rôle d’administrateur, ni quand USDT, USDC ou tout autre contrat rejoindra la liste de la Payment Lane. Les pages officielles de Jenner ne listent aucun changement pour opBNB. Les prochains points à surveiller sont un avis de plateforme d’échange, les propositions de gouvernance sur la liste de la voie, et le bloc d’activation le 8 décembre.