Stellar Announces Protocol 30 Bell Upgrade With Quantum-Safe Signatures and Faster Ledgers
Stellar has introduced Bell, Protocol 30, an upcoming network upgrade focused on business-ready smart accounts, post-quantum cryptography tools, and changes to ledger timing. The Stellar Development Foundation published its upgrade guide on October 20, outlining a November 3 testnet vote and a November 23 mainnet vote, both scheduled for 17:00 UTC. The upgrade is an important development for the Stellar ecosystem, particularly for developers, exchanges, wallets, and businesses operating on the network.
Bell is designed to expand the capabilities available to applications built on Stellar while requiring infrastructure operators to prepare for changes to how ledger data and contract addresses are handled. The foundation describes the changes as additive rather than transaction-level breaking changes, but it warns that SDK and data-decoding updates are required for compatibility.
Stellar Bell Upgrade Targets Smart Accounts and Post-Quantum Security
One of the major additions is CAP-87, which introduces three Soroban host functions for verifying ML-DSA signatures. ML-DSA is a post-quantum digital signature standard specified in FIPS 204, and the new functions will allow smart contracts to verify these signatures. Developers could use the capability to build custom account and authorization systems that incorporate post-quantum cryptography.
However, the distinction between contract-level verification and network-level security is important. Protocol 30 does not replace Stellar’s network transaction signatures with post-quantum signatures. Network-level transaction signatures remain Ed25519, meaning Bell provides developers with additional cryptographic tools rather than a complete transition of the network to quantum-resistant transaction signing.
Another significant change is CAP-84, which introduces muxed contract addresses identified by a new W strkey prefix. These addresses combine a contract ID with a 64-bit multiplexing ID, giving applications another way to identify destinations for transactions. Wallets, exchanges, payment providers, and other services that validate or store Stellar addresses will need to update their systems to recognize the new format.
CAP-88 changes the network’s ledger-close time representation to support millisecond-resolution timestamps. After the upgrade, ledger headers will use new StellarValue types, requiring tools that decode raw ledger data to adopt updated XDR definitions. The existing whole-second close-time field retains its meaning, but consecutive ledgers may now close within the same second.
November 23 Mainnet Vote Puts Preparation in Focus
Stellar Core v30.0.0 became available on October 16, with additional infrastructure and software development kit releases scheduled through October 23. The testnet upgrade vote is set for November 3, followed by the mainnet vote on November 23. These dates give developers and infrastructure operators a defined window to test their integrations before the network transition.
The foundation says upgrading to a Protocol 30-compatible SDK is mandatory for applications using Stellar SDKs. Older versions may fail to decode ledgers after the header-format change. Applications must also update their own address-validation, display, storage, and routing logic to support W addresses; upgrading an SDK alone does not automatically update every application’s handling of addresses.
Infrastructure operators running Stellar Core, Horizon, RPC, or Galexie must install compatible releases. Indexers, block explorers, analytics platforms, and custom tools that decode raw ledger data also need updated XDR definitions. Wallets, exchanges, custodians, issuers, and on- and off-ramp providers should review their integrations before the mainnet vote, particularly if they process contract-address withdrawals, transfers, or mint events.
For Soroban developers, existing smart contracts are expected to continue working without changes. Teams that want to use the new ML-DSA verification functions or accept muxed contract addresses will need to rebuild against the updated SDK and assess whether their contract interfaces support the new address type.
For XLM holders, Bell is primarily a network-infrastructure development rather than a direct change to the token’s economic model. Its longer-term significance will depend on whether developers and businesses adopt the new capabilities and whether the upgrade proceeds successfully. The November 23 mainnet vote is therefore a key milestone, while actual benefits for users will depend on implementation across the ecosystem.
About The Author
