Stellar Protocol 30 “Bell”: mainnet vote on 23 November 2026, testnet on 3 November

Stellar validators are scheduled to vote on Protocol 30, code-named Bell, on 23 November 2026 at 17:00 UTC (18:00 in Paris and Rome). A rehearsal vote on the Stellar testnet comes first, on 3 November 2026 at 17:00 UTC. The Stellar Development Foundation (SDF), which coordinates the upgrade, gives both dates in its Bell upgrade guide, last updated on 20 October, and calls the timeline “subject to change” in its announcement.

Bell is an upgrade for developers and infrastructure, not a token event for Stellar XLM holders. It bundles three Core Advancement Proposals (CAPs): muxed contract addresses with a new address format starting with W, post-quantum signature checks inside smart contracts, and ledger close times recorded to the millisecond. Nobody holding XLM is asked to swap, migrate or claim anything.

Stellar Protocol 30 timeline: from Core v30 to the mainnet vote

The software came out before the votes. Stellar Core v30.0.0, the node software validators run, was released as a stable version on 16 October 2026. Stable releases for the rest of the infrastructure and for the SDKs followed between 16 and 23 October, and the guide expects every component to be available by 23 October.

Stellar does not switch protocols at a fixed block height. Validators arm their nodes with an upgrade time and vote; if enough of them agree, the network moves to the new version. The SDF publishes the vote times only, not the exact moment Protocol 30 rules take effect after a successful vote. Status updates go to the #protocol-next channel of the Stellar Developer Discord, and the guide reminds operators that testing their own integrations before each vote is their job.

What changes in Bell: three CAPs

CAP-84: muxed contract addresses, the new W format

A contract address can now be paired with a 64-bit ID. One smart account can then hold the funds of many customers, each with an ID, without a separate contract per customer. On a transfer through the Stellar Asset Contract, the ID is recorded in the to_muxed_id field of the event. The text form uses a new Strkey prefix, W, allocated in SEP-23. Classic Stellar already had muxed account addresses starting with M; W brings the idea to contracts.

The scope is narrow on purpose. Only destinations can carry the ID, and only the transfer function accepts them for now; mint and transfer_from were left for later. A contract function that expects a plain address rejects a W address, so developers who want to receive them have to declare the muxed type.

This is the change most likely to show up in an app. Any software that checks whether an address is valid has to accept W addresses, or users will see a correct address refused.

CAP-87: post-quantum signatures, but only inside contracts

CAP-87 adds three host functions to Soroban, Stellar’s smart contract platform, to verify ML-DSA signatures at the ML-DSA-44, ML-DSA-65 and ML-DSA-87 security levels. ML-DSA is the post-quantum signature scheme standardised by the US NIST as FIPS 204. A custom contract account can therefore require a quantum-safe signature before it moves funds. The SDF calls this the first onchain piece of its Quantum Preparedness Plan.

The limits matter, and the Foundation spells them out: Bell does not make Stellar post-quantum. Transaction signatures and account master keys stay on Ed25519, an elliptic-curve scheme that a large enough quantum computer could in theory break. A native quantum-safe signer for classic accounts is left to a future protocol. Bell gives contract builders a tool; an ordinary wallet signs exactly as before.

CAP-88: ledger close times in milliseconds

Each ledger will carry a close time in milliseconds, through two new value types in the ledger header. The old closeTime field still reports whole seconds, rounded down. Transaction time bounds, claimable balance conditions and the timestamp Soroban contracts read also stay in whole seconds. The visible effect is that two ledgers may now close within the same second, so code should not assume that “one ledger later” means “at least one second later”.

The aim is speed later, not now. According to the SDF announcement, Protocol 28 “Adapter” brought mainnet close times down from about 5.7 seconds to 5 seconds in September. Bell does not push below 5 seconds by itself. It removes the one-ledger-per-second floor so that future upgrades can.

Who must act before the Stellar Bell upgrade

The guide splits the work by audience. For SDK users it is blunt: the upgrade “is not optional this cycle”, with deadlines of 3 November for testnet integrations and 23 November for mainnet. Older SDKs may fail to decode Protocol 30 ledgers.

• Apps that handle addresses must accept the W variant in their own code; the updated SDK parses it, but validation logic written by the app does not change by itself.
• Operators of Stellar Core, Horizon, RPC and Galexie install the Protocol 30 releases, published as Docker images, Debian packages and source.
• Indexers, block explorers, analytics tools and custom XDR decoders must update their XDR definitions before the upgrade, or decoding of the new ledger header will fail.
• Validators run Stellar Core v30.0.0; the arming command for the 23 November vote is shared through validator channels beforehand.
• Wallets, on- and off-ramps and asset issuers move to the latest SDK before the mainnet vote and handle W addresses in validation, display, storage and transfer logic.
• Exchanges and custodians upgrade SDKs and infrastructure and support withdrawals to muxed contract addresses. The SDF also suggests they weigh W addresses against M addresses for customer deposits.

Contract teams get a lighter list. Existing contracts keep working unchanged. Muxed addresses and ML-DSA checks are opt-in after a rebuild against the Protocol 30 Soroban SDK, and the SDF asks teams to review any assumption their code makes about ledger timestamps.

What XLM holders need to do

Nothing, as far as the Foundation’s documents go. Neither the guide nor the announcement describes any step for holders: no token swap, no new address, no migration. CryptoTicker reads the upgrade the same way and adds that old addresses stay valid and nobody has to move XLM.

What a holder may notice is indirect. A wallet or exchange that has not updated could refuse a W address, or pause Stellar deposits and withdrawals around the vote. No exchange maintenance window had been announced as of 23 October. Our guide to crypto wallets explains the difference between a custodial account, where the platform handles upgrades, and a self-custody wallet, where updating the app is up to you.

Stellar upgrade history: Yardstick, Adapter, then Bell

Bell keeps the gap Stellar has used this year: 20 days between the testnet step and the mainnet vote. Protocol 26 “Yardstick” reached testnet on 16 April 2026 and went to a mainnet vote on 6 May, both at 17:00 UTC, according to the SDF guide for that upgrade. It added, among other changes, a way for validators to freeze compromised ledger entries (CAP-77), checked 256-bit arithmetic (CAP-82), more BN254 cryptography functions (CAP-80) and Stellar Asset Contract improvements (CAP-73).

The Adapter (Protocol 28) guide set a testnet vote on 27 August and a mainnet vote on 16 September 2026 at 17:00 UTC. Its CAP-83 added an empty-ledger value type, and the guide presented the release as a step to make ledgers close faster and with less variance.

More on the network itself, its consensus model and the XLM token is on our Stellar (XLM) page.

Meridian in Lisbon, then the testnet vote

The calendar puts Bell right after the ecosystem’s main gathering. Meridian 2026, Stellar’s conference in Lisbon, runs on 28 and 29 October, between the end of the release window and the 3 November testnet vote.

The quantum part feeds a debate well beyond Stellar. Nine crypto firms launched a Quantum Alliance in October to agree on what “quantum-resistant” should mean. Stellar starts in the contract layer and leaves the base account model for later, so builders can test post-quantum accounts without every user changing keys.

What is not known yet

The exact moment the new rules take effect after the 23 November vote has not been published. Nobody can say before the vote whether validators will agree on the first attempt, and the SDF may still move the dates. Exchange-specific plans, including any pause of XLM transfers, had not been announced as of 23 October 2026. The next fixed date is the testnet vote on 3 November at 17:00 UTC.