Stellar Bell Upgrade Votes November 23: What XLM Holders Do

Two dates now sit on the Stellar calendar. On November 3, 2026, testnet validators vote on Protocol 30, nicknamed Bell. On November 23, 2026, mainnet validators do the same, both votes set for 17:00 UTC according to the Stellar Development Foundation’s Bell upgrade guide.

Headlines are calling it a “quantum-safe” upgrade. That label oversells it a little.

Below is what Bell actually changes, what it leaves alone, and the short list of things an XLM holder should check before late November. If you follow Ethereum’s upgrade cycle too, our note on Ethereum Glamsterdam Hits Hoodi Testnet October 26 covers a similar testnet-first rollout.

What This Covers

• When are the Stellar Protocol 30 votes?
• What does the Bell upgrade change?
• Does Bell make Stellar quantum-safe?
• Do XLM holders need to do anything?
• Who actually has homework before November 23?
• Signals to watch through the vote

When are the Stellar Protocol 30 votes?

The Stellar Protocol 30 testnet vote is scheduled for November 3, 2026 and the mainnet vote for November 23, 2026, both at 17:00 UTC, per the Stellar Development Foundation’s upgrade guide published October 20, 2026 and updated October 23.

The software came first. Stellar Core v30.0.0 shipped as a stable release on October 16, 2026, and the other infrastructure and SDK releases were slotted for October 16 to 23. When I checked the stellar-core v30.0.0 release page on GitHub, it listed the same three proposals the blog describes, so the code and the announcement line up.

One thing to keep in mind: a vote date is not a guaranteed activation date. The foundation’s own announcement marks the schedule as subject to change, and the upgrade only takes effect if validators arm and approve it.

What does the Bell upgrade change?

Stellar’s Bell upgrade bundles three Core Advancement Proposals: CAP-84 adds muxed contract addresses, CAP-87 adds post-quantum signature verification inside smart contracts, and CAP-88 moves ledger close times from whole seconds to milliseconds.

Think of CAP-84 as the contract-side version of the M addresses exchanges already use. A business can run one smart account and still tell which customer each payment belongs to, because the ID is written into the transfer event. The Bell introduction post frames this as making smart accounts usable for businesses at scale without deploying a contract per customer.

CAP-88 is the quiet one. It does not make blocks faster by itself.

What it does is remove a floor. Stellar’s Adapter upgrade (Protocol 28) brought mainnet close times from about 5.7 seconds down to 5 seconds in September 2026, per the foundation, and a whole-second clock would eventually become the bottleneck for going lower. The legacy closeTime field stays, rounded down to the second.

Does Bell make Stellar quantum-safe?

No, the Stellar Bell upgrade does not make the network quantum-safe on its own; it only lets Soroban smart contracts verify ML-DSA signatures, while ordinary Stellar transaction signatures stay Ed25519.

I found that the foundation is unusually direct about this. Its introduction post says Bell “does not make Stellar post-quantum on its own” and that a native post-quantum signer for classic accounts is planned for a future change.

So what is the point? ML-DSA is one of the post-quantum signature schemes NIST finalized in 2024 as FIPS 204. Giving contracts a way to check it now means custom accounts, like a smart wallet with a post-quantum key, can be built before the base layer migrates. The verification runs inside Stellar Core rather than in contract code, which keeps it from being prohibitively expensive.

Here’s where people get tripped up: “quantum features” in a press headline is not the same as “your XLM is now quantum-proof.” It isn’t, and the team doesn’t claim it is.

Do XLM holders need to do anything?

An XLM holder with coins in a self-custody wallet or on an exchange does not need to move funds, swap tokens or change addresses for the Stellar Bell upgrade, because Protocol 30 is additive and existing G addresses keep working.

When I compared the official guide with the third-party coverage, I noticed that the guide never addresses end users directly. Every action item is aimed at SDK users, operators, validators, wallets, exchanges and contract teams. That silence is the answer: nothing breaks for a plain holder.

There are still three small checks worth doing:

• Update your wallet app before November 23. Older builds may not decode Protocol 30 ledgers or recognize a W address.
• Expect possible short deposit or withdrawal pauses on exchanges around the vote. Exchanges often pause a network during upgrades and announce it on their own support pages.
• Do not paste a W address into a wallet or exchange that has not announced W support. Use the G or M address the recipient gives you instead.

Honestly, that’s it. If someone messages you claiming you must “migrate” or “claim” XLM for Bell, treat it as a scam attempt. Our guide on Which Altcoin Wallet Is Actually Secure in 2026? covers the basics of keeping keys away from that kind of request.

Who actually has homework before November 23?

Stellar wallets, exchanges, block explorers and indexers have real work before the November 23, 2026 mainnet vote, because CAP-88 changes the ledger header format and older XDR decoders will fail on the new value types.

The guide puts it bluntly: “The SDK upgrade is not optional this cycle.” The JavaScript SDK line shows why the version matters.

Two details matter for contract teams. A function that takes a plain Address will reject a W address, while one declared with MuxedAddress accepts both. And because ledgers can now close within the same whole second, any contract logic that assumed “next ledger means at least one second passed” needs a second look.

Signals to watch through the vote

The clearest signal is the testnet vote on November 3. A clean testnet activation gives integrators about three weeks to catch decoding bugs before mainnet.

After that, watch the Stellar software versions page. When I checked it on October 26, 2026, it listed Protocol 29 (mainnet October 1, 2026) as the latest entry, with no Protocol 30 row yet. A Protocol 30 row with a mainnet date is the most reliable confirmation that the upgrade went live.

Exchange notices are the third signal. If your exchange posts a “network upgrade support” notice, that tells you the platform tested it. If it stays silent near the date, keep withdrawals small until it confirms.

Bell is one of several protocol changes landing this autumn. The NEAR Issuance Cut to 1.6%: What Stakers Should Know breakdown and the Zcash NU7 Moves Sprout Funds and Cuts Blocks to 25s explainer show how other networks handled their own upgrade windows.

Tips

• Bookmark the official upgrade guide; it has a changelog at the bottom showing what was revised and when.
• If you run a Stellar node or indexer, upgrade before November 3 so you see failures on testnet, not mainnet.
• Keep a note of which of your apps show W addresses correctly after updating. Missing support usually shows up as an ‘invalid address’ error.

Warnings

• A scheduled vote is not a guaranteed activation; validators can delay it, and dates may shift.
• Nobody needs your secret key or seed phrase for this upgrade. Any request for it is fraudulent.
• This article explains a network change and is not investment advice. Protocol upgrades do not reliably move XLM’s price in either direction; make your own decisions.

FAQ

Will the Stellar Bell upgrade change my XLM balance?

No. Stellar Protocol 30 adds a new contract address type, smart-contract signature checks and a millisecond ledger clock. None of the three changes edits existing balances or retires existing G account addresses.

What happens if the November 23 mainnet vote fails?

The upgrade simply does not activate, and the network keeps running Protocol 29 rules. The Stellar Development Foundation describes the published dates as subject to change, so a delayed vote would be announced through its developer blog and validator channels.

Can I send XLM to a W address from an exchange?

Only if the exchange has added W address support. The Bell upgrade guide asks exchanges and custodians to add withdrawals to muxed contract addresses, so until your exchange confirms that, use the G or M address the recipient gives you.

Sources

• Stellar Development Foundation, Bell (Protocol 30) Upgrade Guide
• Stellar Development Foundation, Introducing Bell, Protocol 30 on Stellar
• stellar-core v30.0.0 release notes (GitHub)
• NIST FIPS 204, Module-Lattice-Based Digital Signature Standard

Not investment advice. Dates and software versions are as published by the Stellar Development Foundation on October 20–23, 2026 and may change.