Stellar (XLM) Validators Must Adopt Bell Protocol 30 by November 23

Stellar Pins Bell to November 23

Node operators, wallet developers and exchange engineering teams running Stellar (XLM) infrastructure are the parties the newly published upgrade schedule binds. Stellar (XLM) released its Bell upgrade guide on October 20, and the document sets two dates that matter: a testnet upgrade on November 3 and the mainnet activation, decided by a final validator vote, on November 23. Stable versions of the infrastructure and SDK packages the protocol change requires began rolling out on October 16 and will continue shipping through October 23, 2026, so the preparation window is already open. The upgrade guide on the project's developer blog walks through what each participant has to ship, and the announcement on X from Stellar's official account confirms the same timeline. The stakes for infrastructure teams are concrete: any wallet, exchange or node that fails to update its SDK by November 23 will lose the ability to recognize new ledger blocks, which in practice means dropping off the live network. Retail holders sit outside that obligation entirely. Coins remain in place, no manual exchange or asset migration is required, and no action is requested from anyone holding Stellar (XLM) in a personal wallet. The release notes frame Bell, the codename for Protocol 30, as a package built to make smart accounts deployable by businesses at scale, to begin work on quantum-safe signatures and to move ledger timing to a finer resolution, three changes aimed at simplifying how large fintech platforms and custodial services integrate with the network. The announcement carried no XLM price guidance, and none is required for a hard fork that leaves balances untouched; what it does touch is the token's utility, because the package changes who can build on the network cheaply and at what volume.

@StellarOrg · X post

Announcement on X.

View on X

CAP-84, CAP-88 and CAP-87

The Bell package bundles three core advancement proposals, each removing a specific architectural barrier for commercial users. CAP-84 introduces W-addresses, a multiplexing scheme for smart contracts under which a bank or exchange can manage the balances of millions of customers through one contract instead of provisioning a separate wallet for every user; that multiplexing design is what makes custodial service at scale possible on a single contract. CAP-88 moves the system clock from seconds to milliseconds, an engineering step the release notes position as the foundation for sub-second ledger closing in a future release. CAP-87 writes support for the ML-DSA post-quantum signature standard directly into Stellar (XLM) Core, extending quantum-resistant protection to Soroban smart contracts without adding transaction cost, a change that hardens private key security at the protocol level rather than at the wallet level. The commercial logic ties these pieces together. Simpler custodial models cut the cost for fintech platforms of operating on the network, and the upgrade guide links that cost reduction to higher transaction volume and organic demand for XLM as the fee asset, the same rails that carry its PayFi payments use cases; readers who want the mechanics can consult our guide to crypto network fees. Quantum readiness and sub-second settlement are, in the release notes' framing, baseline requirements for real-world asset tokenization, the sector Stellar is strategically targeting; the network's tokenized RWA footprint and its role in a $30 trillion tokenization service give that target measurable context, and the recent activation of Chainlink Data Streams points in the same direction. For long-term holders, the guide adds one further assurance: because the transition to the new protocol is strictly mandatory for every node operator, unofficial forks or coin splits will not occur.

Our reading is that Bell is less a market catalyst than an infrastructure readiness test, and the binding constraint sits with exchanges and wallets rather than with holders. The mandatory design eliminates split risk, removing the uncertainty that usually surrounds a hard fork, but it also means network reliability through November 23 depends on third parties shipping SDK updates on time. Tokenized instruments such as xStocks and the broader real-world asset buildout give Stellar a demand story that quantum-safe signatures and faster ledgers are meant to underwrite; whether that converts into sustained fee demand for XLM will show up in transaction volume after activation. The outstanding action remains with infrastructure operators: SDK updates before November 23, and a validator vote still to be cast.