Stellar Protocol 30 « Bell » : vote sur le mainnet le 23 novembre 2026, testnet le 3 novembre

Les validateurs de Stellar doivent voter sur le Protocol 30, nom de code Bell, le 23 novembre 2026 à 17 h UTC, soit 18 h à Paris (UTC+1). Un vote de répétition sur le testnet Stellar a lieu avant, le 3 novembre 2026 à 17 h UTC (18 h à Paris). La Stellar Development Foundation (SDF), qui coordonne la mise à jour, donne les deux dates dans son guide de la mise à jour Bell, révisé le 20 octobre, et juge le calendrier « sous réserve de modifications » dans son annonce.

Bell est une mise à jour destinée aux développeurs et à l’infrastructure, pas un événement de token pour les détenteurs de Stellar XLM. Elle regroupe trois Core Advancement Proposals (CAP) : des adresses de contrat multiplexées avec un nouveau format commençant par W, la vérification de signatures post-quantiques dans les smart contracts, et des temps de clôture de ledger enregistrés à la milliseconde. Personne n’a besoin d’échanger, de migrer ou de réclamer quoi que ce soit avec ses XLM.

Calendrier du Stellar Protocol 30 : de Core v30 au vote sur le mainnet

Les logiciels sont sortis avant les votes. Stellar Core v30.0.0, le logiciel de nœud qu’utilisent les validateurs, a été publié en version stable le 16 octobre 2026. Les versions stables du reste de l’infrastructure et des SDK ont suivi entre le 16 et le 23 octobre, et le guide prévoit que chaque composant soit disponible au 23 octobre.

Stellar ne change pas de protocole à une hauteur de bloc fixe. Les validateurs programment leurs nœuds avec une heure de mise à jour et votent ; si assez d’entre eux sont d’accord, le réseau passe à la nouvelle version. La SDF ne publie que les heures de vote, pas l’instant exact où les règles du Protocol 30 s’appliquent après un vote réussi. Les points d’étape sont diffusés sur le canal #protocol-next du Discord des développeurs Stellar, et le guide rappelle aux opérateurs qu’il leur revient de tester leurs propres intégrations avant chaque vote.

Ce que change Bell : trois CAP

CAP-84 : adresses de contrat multiplexées, le nouveau format W

Une adresse de contrat peut désormais être associée à un identifiant sur 64 bits. Un même smart account peut alors détenir les fonds de nombreux clients, chacun avec son identifiant, sans contrat distinct par client. Lors d’un transfert via le Stellar Asset Contract, l’identifiant est inscrit dans le champ to_muxed_id de l’événement. La forme texte utilise un nouveau préfixe Strkey, W, alloué dans la SEP-23. Le Stellar classique avait déjà des adresses de compte multiplexées commençant par M ; W étend l’idée aux contrats.

Le périmètre est volontairement étroit. Seules les destinations peuvent porter l’identifiant, et seule la fonction transfer les accepte pour l’instant ; mint et transfer_from sont remises à plus tard. Une fonction de contrat qui attend une adresse simple rejette une adresse W : les développeurs qui veulent en recevoir doivent déclarer le type multiplexé.

C’est le changement le plus susceptible d’apparaître dans une application. Tout logiciel qui vérifie la validité d’une adresse doit accepter les adresses W, faute de quoi les utilisateurs verront refuser une adresse pourtant correcte.

CAP-87 : signatures post-quantiques, mais seulement dans les contrats

CAP-87 ajoute à Soroban, la plateforme de smart contracts de Stellar, trois fonctions hôtes pour vérifier des signatures ML-DSA aux niveaux de sécurité ML-DSA-44, ML-DSA-65 et ML-DSA-87. ML-DSA est le schéma de signature post-quantique normalisé par le NIST américain sous la référence FIPS 204. Un compte de contrat sur mesure peut donc exiger une signature résistante au quantique avant de déplacer des fonds. La SDF y voit la première brique onchain de son Quantum Preparedness Plan.

Les limites comptent, et la fondation les énonce clairement : Bell ne rend pas Stellar post-quantique. Les signatures de transaction et les clés maîtresses des comptes restent en Ed25519, un schéma à courbe elliptique qu’un ordinateur quantique assez puissant pourrait en théorie casser. Un signataire natif résistant au quantique pour les comptes classiques est renvoyé à un futur protocole. Bell donne un outil aux bâtisseurs de contrats ; un portefeuille ordinaire signe exactement comme avant.

CAP-88 : temps de clôture des ledgers en millisecondes

Chaque ledger portera un temps de clôture en millisecondes, via deux nouveaux types de valeur dans l’en-tête du ledger. L’ancien champ closeTime continue d’indiquer des secondes entières, arrondies à l’inférieur. Les bornes de temps des transactions, les conditions des claimable balances et l’horodatage lu par les contrats Soroban restent eux aussi en secondes entières. L’effet visible : deux ledgers peuvent désormais se clôturer dans la même seconde, et le code ne doit pas supposer qu’« un ledger plus tard » signifie « au moins une seconde plus tard ».

L’objectif est la vitesse plus tard, pas maintenant. Selon l’annonce de la SDF, le Protocol 28 « Adapter » a ramené en septembre les temps de clôture du mainnet d’environ 5,7 secondes à 5 secondes. Bell ne descend pas sous 5 secondes à lui seul. Il supprime le plancher d’un ledger par seconde pour que les mises à jour futures puissent le faire.

Qui doit agir avant la mise à jour Stellar Bell

Le guide répartit le travail selon le public. Pour les utilisateurs de SDK, il est net : la mise à jour « n’est pas facultative pour ce cycle », avec des échéances au 3 novembre pour les intégrations sur testnet et au 23 novembre pour le mainnet. Les anciens SDK risquent de ne pas pouvoir décoder les ledgers du Protocol 30.

• Les applications qui manipulent des adresses doivent accepter la variante W dans leur propre code ; le SDK mis à jour la lit, mais la logique de validation écrite par l’application ne change pas toute seule.
• Les opérateurs de Stellar Core, Horizon, RPC et Galexie installent les versions du Protocol 30, publiées sous forme d’images Docker, de paquets Debian et de sources.
• Les indexeurs, explorateurs de blocs, outils d’analyse et décodeurs XDR personnalisés doivent mettre à jour leurs définitions XDR avant la mise à jour, sans quoi le décodage du nouvel en-tête de ledger échouera.
• Les validateurs font tourner Stellar Core v30.0.0 ; la commande d’armement pour le vote du 23 novembre est transmise au préalable par les canaux réservés aux validateurs.
• Les portefeuilles, les passerelles d’entrée et de sortie et les émetteurs d’actifs passent au dernier SDK avant le vote sur le mainnet et gèrent les adresses W dans la validation, l’affichage, le stockage et la logique de transfert.
• Les plateformes d’échange et les dépositaires mettent à niveau leurs SDK et leur infrastructure et prennent en charge les retraits vers des adresses de contrat multiplexées. La SDF leur suggère aussi de comparer les adresses W et M pour les dépôts de clients.

Les équipes de contrats ont une liste plus légère. Les contrats existants continuent de fonctionner sans changement. Les adresses multiplexées et les vérifications ML-DSA sont facultatives après une recompilation avec le SDK Soroban du Protocol 30, et la SDF demande aux équipes de revoir toute hypothèse que leur code fait sur les horodatages de ledger.

Ce que les détenteurs de XLM doivent faire

Rien, d’après les documents de la fondation. Ni le guide ni l’annonce ne décrivent la moindre démarche pour les détenteurs : pas d’échange de token, pas de nouvelle adresse, pas de migration. CryptoTicker lit la mise à jour de la même façon et précise que les anciennes adresses restent valides et que personne n’a à déplacer ses XLM.

Ce qu’un détenteur peut remarquer est indirect. Un portefeuille ou une plateforme qui n’a pas été mis à jour pourrait refuser une adresse W, ou suspendre les dépôts et retraits Stellar autour du vote. Aucune fenêtre de maintenance n’avait été annoncée par les plateformes au 23 octobre. Notre guide des portefeuilles crypto explique la différence entre un compte chez un dépositaire, où la plateforme gère les mises à jour, et un portefeuille en auto-garde, où la mise à jour de l’application vous revient.

Historique des mises à jour de Stellar : Yardstick, Adapter, puis Bell

Bell reprend l’écart que Stellar applique cette année : 20 jours entre l’étape testnet et le vote sur le mainnet. Le Protocol 26 « Yardstick » est arrivé sur le testnet le 16 avril 2026 et a été soumis à un vote sur le mainnet le 6 mai, tous deux à 17 h UTC, selon le guide de la SDF pour cette mise à jour. Il ajoutait, entre autres, un moyen pour les validateurs de geler des entrées de ledger compromises (CAP-77), une arithmétique 256 bits contrôlée (CAP-82), davantage de fonctions cryptographiques BN254 (CAP-80) et des améliorations du Stellar Asset Contract (CAP-73).

Le guide d’Adapter (Protocol 28) fixait un vote testnet au 27 août et un vote mainnet au 16 septembre 2026 à 17 h UTC. Son CAP-83 ajoutait un type de valeur pour les ledgers vides, et le guide présentait cette version comme une étape pour que les ledgers se clôturent plus vite et avec moins de variance.

Pour en savoir plus sur le réseau, son modèle de consensus et le token XLM, consultez notre page Stellar (XLM).

Meridian à Lisbonne, puis le vote sur le testnet

Le calendrier place Bell juste après le grand rendez-vous de l’écosystème. Meridian 2026, la conférence de Stellar à Lisbonne, se tient les 28 et 29 octobre, entre la fin de la fenêtre de publication et le vote testnet du 3 novembre.

Le volet quantique alimente un débat bien plus large que Stellar. Neuf entreprises crypto ont lancé en octobre une Quantum Alliance pour s’accorder sur ce que « résistant au quantique » doit signifier. Stellar commence par la couche des contrats et laisse le modèle de compte de base pour plus tard : les bâtisseurs peuvent ainsi tester des comptes post-quantiques sans que chaque utilisateur change de clés.

Ce que l’on ne sait pas encore

L’instant exact où les nouvelles règles s’appliqueront après le vote du 23 novembre n’a pas été publié. Personne ne peut dire avant le vote si les validateurs s’accorderont du premier coup, et la SDF peut encore décaler les dates. Les plans propres à chaque plateforme, y compris une éventuelle suspension des transferts de XLM, n’avaient pas été annoncés au 23 octobre 2026. La prochaine date ferme est le vote testnet du 3 novembre à 17 h UTC, soit 18 h à Paris.