Stellar puts its Bell Protocol 30 to a validator vote
Stellar's Bell Protocol 30 is a validator vote on November 3 and November 23. CAP-84, CAP-87 and CAP-88 cover W addresses, ML-DSA checks and the ledger clock.
Protocol 30, the Stellar upgrade named Bell, is on a validator ballot and still ahead of mainnet. The Stellar Development Foundation published the package on October 20, 2026. CAP-84 adds a customer identifier to a contract address, CAP-87 lets a contract check an ML-DSA signature while network signatures stay on Ed25519, and CAP-88 stores close time in milliseconds while any faster close waits on a later change.
The testnet vote is set for November 3, 2026 at 1700 UTC and the mainnet vote for November 23, 2026 at 1700 UTC, and both dates are subject to change. Stellar Core v30.0.0 has been available since October 16, 2026, and the upgrade guide pinned Software Development Kit (SDK) builds on October 23, 2026. On the digital-assets desk, Base replaced Flashblocks with canonical 200 millisecond blocks, a close-time cut that CAP-88 only prepares. The November 23 arming command goes out later on the usual validator channels.
What the three proposals change
Custodians already separate deposits on one classic account with an M-address identifier. A smart account lacked that tag, so the working pattern was one contract per customer. CAP-84 adds a 64-bit identifier, encoded as a W strkey, the SC_ADDRESS_TYPE_MUXED_CONTRACT type in Stellar Ecosystem Proposal 23.
"It's an upside-down M. We considered reusing M, but decided it was better to have a distinct type so developers always know what they're working with."
Jake Urban, Senior Engineering Manager (Wallet) at the Stellar Development Foundation, gave that reason in the October 20 announcement. A payment to a W address still settles in the same contract, and the identifier rides in the to_muxed_id field already used for muxed accounts under CAP-67. A plain Address rejects W, MuxedAddress accepts both, and the muxed form is barred as a storage key.
CAP-87 is the first on-chain piece of the Quantum Preparedness Plan. In 2024 the US National Institute of Standards and Technology finalized post-quantum standards, and ML-DSA is what a contract can require before a spend. Stellar Core verifies it for Soroban through verify_sig_ml_dsa_44, verify_sig_ml_dsa_65 and verify_sig_ml_dsa_87, implementing FIPS 204. Network transaction signatures stay on Ed25519 until a later protocol change.
Millisecond timing under CAP-88 is what a faster close needs. In September, Adapter, Protocol 28, cut mainnet close times from about 5.7 seconds to five seconds. Whole-second timestamps bottom out at a one-second gap, and the core team is testing faster closes on experimental branches.
What integrators install before each vote
The upgrade guide treats the SDK bump as required, because an older kit can fail to decode Protocol 30 ledgers after the header change. New kits carry updated External Data Representation (XDR) definitions and a W parser, and application code still has to accept W on each transfer destination. The transaction changes are additive, so existing payments keep their shape.
JavaScript SDK v17.3.0 covers W addresses, while v16.4.0 decodes Protocol 30 ledgers and leaves W to the 17.x line. Go sits at v0.8.0 and the Soroban Rust SDK sits at 30.0.0-rc.1 with a stable build due before the mainnet vote, and a rebuild that calls the new host functions needs a command-line release the guide still lists as pending. Horizon, the remote procedure call server and Galexie are pinned at v30.0.0 beside Core.
After the upgrade, every header carries STELLAR_VALUE_SIGNED_MS or STELLAR_VALUE_EMPTY_TX_SET_MS, and older decoders fail on those arms. The closeTime field stays in whole seconds, rounded down from the millisecond value, so time bounds, minimum sequence age, claimable-balance predicates and the Soroban timestamp keep whole-second meaning. Consecutive ledgers can share one whole second, so any contract that reads the timestamp needs a review.
Wallets, issuers and ramps add W destinations before the mainnet vote, and exchanges and custodians add withdrawals to muxed contract addresses. Contracts compiled earlier keep working and gain the ML-DSA host functions only after the upgrade. Testnet integrations move before November 3, 2026, and mainnet integrations move before November 23, 2026.
What the votes leave in place
Hedera kept its network MCP on testnet while mainnet moved, the same two-step shape Stellar is running. THORChain v3.21 halted the network while venues paused deposits, which is what follows when a decoder rejects the new header and a venue stops routing.
If both votes pass, the week after is an integration week: closes stay on the Protocol 28 pace, and network transaction signatures stay on Ed25519. The November 3, 2026 testnet vote is the first check on whether validators arm the release. Operators compare notes in the #protocol-next channel of the Stellar Developer Discord.
This article is informational analysis only and is not financial, investment, or trading advice. Cryptocurrencies are highly volatile and can lose substantial value rapidly. Past performance and historical patterns do not guarantee future results. Do your own research and consult a regulated financial adviser before making any investment decision.
Reporting by Karthik Subramanian. Filed 2 November 2026, 19:46 GMT.
Digital Assets Correspondent
Karthik Subramanian is a founder, writer, and technology consultant with nine years in the crypto ecosystem.
