The Stellar Development Foundation confirmed that Protocol 30, codenamed Bell, has been activated on the network’s testnet. Validators approved the upgrade on November 3 at 17:00 UTC, allowing developers and infrastructure operators to test the changes before a separate mainnet vote scheduled for November 23 at the same hour.

Bell introduces three protocol changes designed to expand smart contract capabilities, add post-quantum signature options inside contracts, and prepare the network for potentially faster ledger processing. The mainnet activation remains subject to validator approval and is not automatic.

Muxed Contract Addresses for Multi-Customer Smart Accounts

CAP-84 adds muxed contract addresses that let a single smart contract manage balances for many customers. Each address includes a 64-bit identifier so exchanges, custodians and payment providers can distinguish individual users without deploying a separate contract for every client.

Previously, Stellar supported muxed accounts for standard accounts, which begin with the letter M. Smart accounts lacked an equivalent feature, requiring separate contracts to track customer funds. The new addresses begin with the letter W. When tokens move to a W address, the funds reach the underlying contract while the customer identifier is recorded in the transfer event.

Wallet providers, exchanges and applications that process Stellar addresses must update their software to recognize the new format before mainnet activation.

Post-Quantum Signature Verification Inside Smart Contracts

CAP-87 enables verification of ML-DSA signatures within the Soroban smart contract environment. ML-DSA is a post-quantum digital signature algorithm standardized by the US National Institute of Standards and Technology in 2024.

Developers can now build smart accounts that require ML-DSA signatures for transaction authorization, offering a path toward quantum-resistant spending controls. Verification occurs through Stellar Core because the checks demand more computational resources than conventional signatures. Protocol 30 supports three verification functions matching different security levels of the algorithm.

Network-level transaction signatures continue to use Ed25519. The foundation described the feature as the first on-chain component of its Quantum Preparedness Plan, with broader network signature changes reserved for a future upgrade.

Millisecond Ledger Timing Prepares for Future Speed Gains

CAP-88 changes how the network records ledger closing times, shifting from whole-second timestamps to millisecond resolution. The previous system limited the network’s ability to target intervals shorter than one second.

The change does not reduce current ledger closing times. Protocol 28, activated in September, had already lowered typical mainnet closing times from roughly 5.7 seconds to five seconds. CAP-88 removes a technical barrier so that future protocol updates can support more precise intervals. Developers have already begun experiments with faster processing.

The update also introduces a new ledger header format. Applications that decode raw blockchain data, including older SDKs, indexers and analytics services, must update their XDR definitions to handle Protocol 30 ledgers correctly. Existing Soroban contracts can continue operating without modification.

Preparation Requirements and Timeline

Stellar has released Protocol 30-compatible versions of Core, Horizon, RPC and related infrastructure software. Stellar Core v30.0.0 became available on October 16. Compatible SDKs, including JavaScript version 17.3.0 and Go version 0.8.0, followed by October 23, along with a release candidate for the Soroban Rust SDK.

Validators must install Stellar Core v30.0.0 before the mainnet vote. Wallet providers, exchanges and other operators need to confirm support for the new address format and ledger data structures. The foundation has published an upgrade guide outlining the steps for different categories of participants.

The testnet serves as a practice environment with no real-value assets. Success there does not guarantee mainnet adoption. Each network maintains its own identity, and mainnet validators assess the software under live conditions, including readiness of wallets and exchanges. Dates remain subject to change if technical or operational issues arise.

Bell forms part of ongoing work to support business-scale smart accounts and longer-term goals around security and performance. The mainnet vote on November 23 will determine whether the upgrade advances to the production network.