The Stellar Development Foundation released a revised Bell upgrade guide on October 23 detailing the exact software releases that operators must install before validators vote on Protocol 30. The update supplies concrete version numbers for core components and software development kits as the network approaches testnet and mainnet decisions in November.

Protocol 30, also known as Bell, introduces several protocol-level changes that affect address formats, ledger data structures and contract capabilities. Applications that process payments, maintain customer records or parse raw ledger entries will need to accommodate the new specifications once the upgrade activates.

Software Versions Required for Compatibility

The foundation’s checklist specifies Stellar Core, Horizon, RPC and Galexie version 30.0.0. For application developers, the JavaScript SDK must reach version 17.3.0 and the Go SDK version 0.8.0. The Soroban Rust SDK remains at release-candidate stage 30.0.0-rc.1, with a stable build expected before the mainnet vote. The Protocol 30 release of the Stellar command-line interface is still pending.

These version sequences differ between core infrastructure and SDKs. Operators are advised to evaluate only the components their systems actually use rather than treat the list as a universal minimum. JavaScript SDK 16.4.0 can already decode the revised ledger format yet lacks support for the new address type; only 17.3.0 handles both requirements.

New Contract Addresses and Ledger Format Changes

Under Bell, smart-contract addresses can begin with the letter W and optionally embed a 64-bit customer identifier. This structure permits a single contract to accept payments on behalf of multiple end users while recording which customer each payment concerns. The capability extends an existing pattern already available for classic Stellar accounts and may simplify shared-account designs used by custody services.

Supporting the new address requires more than installing an updated library. Validation rules, storage schemas and customer-matching logic inside wallets and exchanges must be adjusted to recognize and process the additional identifier.

Protocol 30 also revises the ledger header format. Services that decode raw ledger data—indexers, block explorers and certain analytics platforms—will encounter failures if they continue to rely on older definitions. Compatibility work therefore extends beyond teams that intend to use the new address feature.

Additional Protocol Features

Bell adds the ability to verify ML-DSA signatures inside smart contracts. The change supplies a building block for developers who wish to construct custom accounts with post-quantum authorization. Ordinary network transaction signatures continue to use Ed25519; the upgrade does not alter the cryptographic scheme used for ledger consensus.

Ledger close times will be recorded with millisecond precision. The foundation states that this adjustment removes a technical obstacle to faster ledger intervals in future upgrades but does not itself accelerate the current close schedule. Applications that assume consecutive ledgers must carry distinct whole-second timestamps will need to revise that logic.

Voting Schedule and Activation Conditions

Testnet validators are scheduled to vote on November 3. The mainnet vote is set for November 23. Both votes are timed for 17:00 UTC. The foundation notes that the dates remain subject to change. Protocol 30 will activate only if the required validator majority approves the upgrade.

Until the votes conclude and the new protocol is live, operators retain a window to complete testing and deployment of the listed software versions. The updated guide provides tracking links for community-maintained tools so teams can monitor progress on any remaining releases.