Stellar’s Bell upgrade has software available, but its network votes are still ahead. As of October 27, 2026, KST, the published schedule calls for a testnet vote on November 3 and a mainnet vote on November 23, both at 17:00 UTC, according to the official upgrade guide. For developers and infrastructure operators, the immediate issue is preparation: a released implementation does not establish that Protocol 30 has been activated.
Three changes, with different purposes
The Stellar Development Foundation’s Bell announcement describes three changes: muxed contract addresses, smart-contract verification of ML-DSA signatures, and millisecond ledger timing. These address separate technical needs. Treating them as a single completed application launch would obscure both their scope and the pending votes.
The Stellar Core v30.0.0 release notes identify the corresponding proposals as CAP-84, CAP-87 and CAP-88. The timing change introduces millisecond-resolution ledger close times. That description concerns how time is represented; the reviewed materials do not establish faster ledger closes or measured production performance gains.
Muxed addresses carry customer identifiers
CAP-84 adds a 64-bit multiplexing identifier to a contract address, allowing one contract to represent multiple off-chain balances. A Stellar Asset Contract transfer event can carry that identifier so an application can distinguish the destination customer. The practical use case is customer routing through a shared contract.
The specification also sets limits. Muxed contract addresses cannot serve as contract storage keys, and a contract expecting an ordinary address may fail when given a muxed address. Supporting the new address form therefore involves more than displaying a different prefix. Applications need to account for where that address can be accepted and how its identifier is used.
The guide tells applications handling addresses to recognize the new W address type. Its assurance that existing Soroban contracts continue to work should be read alongside those interface constraints. Neither document establishes that a particular wallet, exchange or application has completed compatibility work.
ML-DSA stops at the contract boundary
CAP-87 introduces Soroban host functions for ML-DSA-44, ML-DSA-65 and ML-DSA-87. These support smart-contract authentication and verification of ML-DSA-signed attestations. The proposal gives contract developers verification functions; the reviewed evidence does not show applications adopting them.
The boundary matters for descriptions of Bell’s post-quantum features. Stellar’s network transaction signatures remain Ed25519. Contract-level ML-DSA verification does not establish a network-wide migration to post-quantum transaction signing, and the specification should not be read as evidence that such a migration has occurred.
Compatibility work comes before activation evidence
The upgrade guide says SDK updates are required because Protocol 30 changes the ledger-header format; older SDKs may fail to decode its ledgers. It directs infrastructure operators to install Protocol 30 releases and test their integrations before the votes.
Core v30.0.0 was released October 16. Its notes also describe a minimum overlay version that prevents nodes older than v29.0.0 from connecting. Those are software availability and compatibility facts, separate from the outcome of either scheduled vote.
For context on application activity, the reported Ascend and M1X Stellar repo transaction is a separate story; it does not establish Bell readiness. The next evidence to watch is vote outcomes, activation confirmation and demonstrated application compatibility. No independent chain-state check was performed for this report, and the reviewed documents do not quantify operator readiness.
Sources
Investment disclaimer: This article is provided for general information only and does not constitute investment, financial, legal or tax advice. Digital assets are volatile, and all investment decisions and their consequences are your own responsibility.