Stellar's Protocol 30 Bell Upgrade Goes Live on Testnet Ahead of November 23 Vote

Bell Goes Live on Testnet

Stellar (XLM) switched its Protocol 30 upgrade, codenamed Bell, live on testnet, and validators are scheduled to vote on bringing it to the mainnet on November 23 at 17:00 UTC. The testnet activation followed a validator vote on November 3 at the same hour, which the Stellar Development Foundation confirmed in its announcement, and activation on the production network depends on approval in the later vote. Bell packages three changes ratified under CAP-84, CAP-87 and CAP-88. Together they cover how smart contracts handle customer addresses, how cryptographic signatures are verified inside contracts and how the blockchain records the moment each ledger closes. In its October 20 developer announcement, the foundation framed the release as groundwork for three things at once: businesses managing customer funds through smart accounts, quantum-resistant security and faster transaction processing in future upgrades. The software side is already in place. Protocol 30-compatible releases of Stellar (XLM) Core, Horizon, RPC and Galexie are published, and the foundation's upgrade guide dated October 23 listed JavaScript SDK v17.3.0 and Go SDK v0.8.0 among the developer releases, alongside a release candidate for the Soroban Rust SDK. Validators have been instructed to install Stellar Core v30.0.0 before the mainnet vote. Exchanges, wallet providers and other infrastructure operators are expected to prepare their integrations for the new address format and ledger data changes ahead of activation. The vote covers one of the most consequential releases the Stellar network has scheduled this year, and the foundation is coordinating preparations through its developer community and validator channels in the run-up to the ballot.

Muxed Addresses and Quantum-Ready Signatures

CAP-84 is the change most exchanges and custodians will feel first. It introduces muxed contract addresses that let a business manage funds belonging to many customers through a single smart contract. Stellar (XLM) already supported muxed accounts, which let exchanges and payment providers receive deposits from different customers into one account while identifying individual users through separate IDs. Smart accounts, which use programmable contracts to control spending permissions, did not have the same capability, so businesses using them generally deployed separate contracts to distinguish customer balances. Under CAP-84, a contract address carries a 64-bit identifier that names the intended customer without a dedicated contract for every user. The new addresses begin with the letter W, distinguishing them from existing muxed account addresses that begin with M. A transfer to one of them reaches the underlying contract while the customer's identifier is recorded in the transfer event. The foundation says exchanges, payment providers and custodians can use the design to manage deposits through smart accounts without deploying individual contracts for potentially millions of users. CAP-87 adds support for verifying ML-DSA signatures inside the Soroban smart contract environment. ML-DSA is the post-quantum digital signature algorithm the US National Institute of Standards and Technology standardized in 2024, and unlike the elliptic-curve schemes Stellar uses today, including Ed25519, it is built to resist attacks from sufficiently powerful quantum computers. Verification runs through Stellar Core because checking ML-DSA signatures requires considerably more computing resources than conventional signatures, and Protocol 30 supports three verification functions matching the algorithm's security levels. The feature is the first onchain component of Stellar's Quantum Preparedness Plan, although network-level transaction signatures stay on Ed25519 until a future upgrade. CAP-88 changes how ledger closing times are recorded, moving from whole seconds to millisecond-resolution timestamps and removing a restriction that stopped the network from targeting intervals shorter than one second. It does not cut closing times immediately; Stellar Core developers are already experimenting with faster processing.

Three Weeks to the Mainnet Vote

Bell lands on a network that has spent recent months stacking integrations: VIA Labs wired Stellar and Ethereum together through a bridge protocol integration in late October, Curve shipped StableSwap on Stellar mainnet in its first non-EVM deployment, and Securitize added the network as its 17th chain for tokenized assets. The same network processed 14.16 million transactions on October 23. Our reading: the vote is the real gate. The code is written, published and running on testnet; what remains is validator consensus and the operator migration it triggers. W-format addresses, ML-DSA spending controls and millisecond timing only matter once the production layer 1 runs them, and exchanges and wallet providers carry the migration work. If validators approve at 17:00 UTC on November 23, Bell becomes the baseline every later Stellar upgrade builds on; if they hold back, the changes stay parked on testnet.