Stellar Bell Upgrade Goes Live on Testnet Ahead of Mainnet Vote

The Stellar Bell upgrade, also known as Protocol 30, activated on the Stellar testnet on November 3, 2026, at 17:00 UTC after validators approved the change. The mainnet validator vote is set for November 23, 2026, at the same time. The upgrade focuses on three core protocol amendments that add muxed contract addresses, optional post-quantum signature support inside Soroban contracts, and millisecond-resolution ledger close times.

Technical changes introduced in the Stellar Bell upgrade

Protocol 30 implements CAP-84, CAP-87, and CAP-88. The most visible addition is muxed contract addresses in a new W-prefixed strkey format. One Soroban smart contract can now serve multiple customers by attaching a 64-bit identifier to each transfer. The identifier appears in ledger events, allowing exchanges and custodians to route funds without creating separate contracts for each client. Existing M-address muxed accounts remain supported, but the new W format extends the same concept to contracts.

The upgrade also adds optional ML-DSA post-quantum signature verification inside smart contracts. Network-level signatures stay on Ed25519, so no changes to consensus or account creation are required. The millisecond closeTime field becomes available for ledger metadata while the existing whole-second value continues unchanged. These elements form prerequisites for later work on faster ledger times and quantum-resistant account signatures.

Stellar Core v30.0.0 and the JavaScript SDK v17.3.0 contain the necessary updates. Developers must update XDR definitions in any custom ledger decoders. Contracts deployed before the upgrade continue to function without modification because the new features are opt-in.

Preparation steps for wallets, exchanges, and infrastructure

Operators running validators, indexers, and custody systems need to deploy the Protocol 30 releases before the mainnet vote. Systems that parse addresses or store transaction data must recognize the W address type and avoid rejecting it during validation. Failure to update can cause display or routing errors once the protocol activates on mainnet.

Teams that maintain custom SDK integrations should review the official upgrade guide for XDR changes and event format adjustments. The Stellar Development Foundation has published test vectors and sample transactions that cover muxed contract transfers. Exchanges testing deposit and withdrawal flows on testnet can verify that 64-bit identifiers arrive correctly in ledger events.

No fee schedule or consensus rule changes accompany the upgrade. Validators continue to follow the same approval thresholds used in prior protocol votes. Developers are advised to monitor the #protocol-next channel on Discord for any schedule adjustments before the November 23 mainnet vote.

Background and planned next steps

Stellar has supported muxed accounts since earlier protocol versions. Protocol 30 extends that capability to smart contracts, addressing a scaling requirement reported by businesses that custody assets for many end users. The post-quantum and timing features lay groundwork for future upgrades without altering current security or performance characteristics.

If validators approve the mainnet vote, activation follows the standard 24-hour window after the threshold is reached. The Stellar Development Foundation has stated that the upgrade prepares smart accounts for larger-scale commercial use while beginning work on quantum-safe signatures and faster ledger intervals. Teams planning production deployments are encouraged to complete testnet validation of the new address format and signature options ahead of the vote.