Stellar infrastructure operators and application developers must update their software before the network’s planned Protocol 30 votes or risk compatibility failures, according to an upgrade guide the Stellar Development Foundation published October 20.
The guide says Bell, the name for Protocol 30, changes the format of Stellar ledger headers and introduces a new contract-address type. Software using older data definitions may therefore fail to decode ledgers after activation. The warning matters for exchanges, custodians, wallets, explorers, indexers and analytics systems that consume Stellar data—not only for validators.
Stellar Core version 30.0.0 became available on October 16. The foundation has scheduled a testnet upgrade vote for November 3 at 17:00 UTC and a mainnet vote for November 23 at 17:00 UTC. Those dates describe planned votes, not completed activations: the protocol changes take effect only if validators approve them.
Two changes require downstream work
Protocol 30 packages three accepted Core Advancement Proposals. CAP-84 creates muxed contract addresses, CAP-87 supplies smart contracts with host functions for verifying ML-DSA signatures, and CAP-88 records ledger close times with millisecond resolution.
The immediate compatibility work centers on CAP-84 and CAP-88. Muxed contract addresses combine a contract identifier with a 64-bit multiplexing identifier and use a new address prefix beginning with “W.” The structure lets one contract distinguish among customers without requiring a separate contract for each user.
Updated Stellar software can parse the address format, but businesses must still adapt their own validation, storage, display and routing logic. Exchanges and custodians must decide how to support withdrawals to the new address type, while wallets, issuers and on-ramps need to recognize it wherever a transfer destination appears.
CAP-88 creates new ledger-value types carrying millisecond timestamps. From the first ledger produced under Protocol 30, raw-data consumers using older definitions will encounter previously unknown data variants. The foundation says applications using current Stellar software-development kits should receive the necessary definitions through an upgrade. Custom decoders and data pipelines need their own updated XDR schemas.
The change does not make Stellar ledgers close faster by itself. Existing whole-second timestamps remain available, while the new field removes a technical constraint that would otherwise prevent future sub-second intervals. It also means two consecutive ledgers could share the same whole-second timestamp, weakening assumptions that another ledger necessarily represents at least one elapsed second.
Post-quantum support has a narrow scope
CAP-87 adds three host functions for verifying different ML-DSA parameter sets inside Soroban smart contracts. That gives contract-account developers a standardized way to experiment with post-quantum authorization without implementing the verification algorithm independently in contract code.
It does not make the Stellar network quantum-resistant. Native transaction signatures remain based on Ed25519, and existing accounts do not automatically gain a new signing method. Contract developers must deliberately adopt the ML-DSA functions after the upgrade, while broader migration of network-level authorization remains future work.
Existing smart contracts are expected to continue operating, according to the foundation. The main operational risk lies with software that handles the new address variant or reads raw ledger structures without updated definitions.
Activation remains ahead
The version 30.0.0 repository release confirms that the three proposals are included in the software. It also raises the minimum peer-overlay version, meaning nodes older than version 29.0.0 can no longer connect to version 30 nodes.
None of these records establishes that Protocol 30 is active on mainnet, that validators will approve it on November 23, or that businesses have completed their upgrades. The next evidence points are the November 3 testnet vote, observed compatibility after testnet activation and the later mainnet vote. Until then, Bell is released software with a scheduled activation process—not a completed network upgrade.
The complete source packet and revision history are retained with the newsroom record.
Automated systems may have assisted with source organization and drafting. Coinburn is accountable for the published text and maintains a revision record.
This article provides news and analysis, not investment, legal or tax advice. Digital assets are volatile and may result in total loss.