Stellar's Protocol 30 upgrade, codenamed Bell, goes to testnet vote on November 3, 2026 at 1700 UTC, with a mainnet validator vote scheduled for November 23. The package contains three Consensus Amendment Proposals: CAP-84 (muxed contract addresses), CAP-87 (ML-DSA post-quantum signature verifica...
"Built for real-world utility at institutional scale." — Denelle Dixon, CEO, Stellar Development Foundation
Stellar's Protocol 30 upgrade, codenamed Bell, goes to testnet vote on November 3, 2026 at 1700 UTC, with a mainnet validator vote scheduled for November 23. The package contains three Consensus Amendment Proposals: CAP-84 (muxed contract addresses), CAP-87 (ML-DSA post-quantum signature verification), and CAP-88 (millisecond ledger timing). If the vote passes, Stellar becomes the first major payments-focused blockchain to offer NIST-finalized post-quantum signature primitives at the smart-contract layer.
The upgrade arrives as EU financial regulators (EBA, ESMA, EIOPA) warned in September 2026 that quantum computers could compromise blockchain encryption "before the technology becomes commercially viable," citing roughly 6.9 million BTC — approximately $586 billion — as potentially exposed. No major Layer 1 chain has deployed protocol-wide post-quantum signatures for user accounts. Stellar's approach is incremental: CAP-87 lets smart contracts verify ML-DSA signatures while network transaction signatures remain Ed25519. It is a stepping stone, not a full migration. But it is the first concrete shipping code on a chain handling $33.2 billion in quarterly transaction volume.
Bell bundles three CAPs into a single protocol version increment. Stellar Core v30.0.0 shipped on October 16, 2026. The vote mechanism is decentralized: node operators configure a target protocol version and a timestamp; the network advances only once sufficient voting weight converges. November 3 and November 23 are vote windows, not guaranteed activation dates.
The three proposals serve distinct purposes but share a common thread: preparing a payments-focused chain for enterprise-grade operations under evolving security constraints.
CAP-84 introduces a new address type — the "W" address — that allows a single smart contract to serve multiple customers through embedded 64-bit identifiers. The design reuses Stellar's existing muxed-account infrastructure (the "M" address format for muxed accounts) but applies it to contract addresses.
The operational significance is straightforward. Large custodians and payment processors deploying Soroban smart contracts currently need workarounds to attribute incoming funds to individual customers. With W addresses, tokens sent to a muxed contract address generate transfer events that carry the customer-specific multiplexing ID, enabling automated reconciliation without additional on-chain transactions.
According to Jake Urban, Senior Engineering Manager (Wallet) at SDF, the team considered reusing the existing M prefix but opted for a distinct W type for developer clarity. The W format is described as "an upside-down M."
Key constraints: W addresses cannot be used in contract storage keys. Applications must update address validation, display, and storage logic to handle the new variant.
CAP-87 adds three host functions to Stellar's smart contract environment: verify_sig_ml_dsa_44, verify_sig_ml_dsa_65, and verify_sig_ml_dsa_87. These correspond to the three security levels of ML-DSA (Module-Lattice Digital Signature Algorithm), which NIST finalized as FIPS 204 in August 2024.
ML-DSA, based on the CRYSTALS-Dilithium algorithm, is NIST's primary recommended replacement for ECDSA and EdDSA in post-quantum environments. The verification is executed in Stellar Core rather than in contract bytecode, a design choice that avoids the computational overhead of running lattice operations inside a constrained VM.
What CAP-87 does not do is equally important. Network-level transaction signatures remain Ed25519. Stellar's consensus protocol, SCP, continues to use classical cryptography. The post-quantum capability is opt-in at the smart-contract layer only. Custom account contracts can adopt ML-DSA for authorization, meaning enterprise wallets and custodians can begin quantum-safe signing without waiting for a network-wide migration.
SDF's stated goal is full quantum-resistant security by 2027, with enterprise wallets expected to support PQ signing by late 2026. CAP-87 is the foundation for that roadmap.
CAP-88 transitions Stellar's ledger close-time recording from whole-second precision to milliseconds. The change replaces the StellarValue types with millisecond-resolution variants (STELLAR_VALUE_SIGNED_MS and STELLAR_VALUE_EMPTY_TX_SET_MS) and removes the one-ledger-per-second protocol floor.
Current ledger close time on Stellar stands at approximately 5 seconds, down from 5.7 seconds after the Protocol 28 upgrade. CAP-88 does not directly reduce close times further — it removes a technical prerequisite that currently prevents sub-second ledger closure. Future protocol versions can leverage this groundwork.
The breaking change is significant for infrastructure operators: the ledger header format changes, and all XDR decoders for ledger headers, metadata, and SCP history require Protocol 30 definitions. Consecutive ledgers may share the same whole-second timestamp. Transaction time bounds retain whole-second semantics for backward compatibility.
SDF's upgrade guide states plainly: "The SDK upgrade is not optional this cycle."
The timing of CAP-87 reflects a broader industry recalibration around quantum risk.
On September 23, 2026, three EU financial supervisory authorities — EBA, ESMA, and EIOPA — issued a joint risk assessment warning that quantum computing could compromise blockchain cryptographic protections before the technology reaches commercial viability. The report estimated 6.9 million BTC (approximately $586 billion) as potentially vulnerable to quantum key extraction, given that these coins have exposed public keys on-chain.
The core threat vector is "harvest now, decrypt later" (HNDL). Adversaries record exposed public keys and encrypted data today, then decrypt them once a Cryptographically Relevant Quantum Computer (CRQC) becomes available. No CRQC exists in 2026. Expert estimates for arrival vary, with meaningful probability commonly placed in the 2030–2035 window. But the migration cycle for cryptographic infrastructure is measured in years, not months.
U.S. Executive Order 14412, signed June 22, 2026, sets federal migration deadlines: December 31, 2030 for key agreement mechanisms, December 31, 2031 for digital signatures. The European Commission's post-quantum roadmap calls for high-risk use cases to be protected by 2030. In January 2026, Citi published a research note characterizing the situation as a "trillion-dollar security race."
A June 2026 paper titled "Quantum Horizon" published on arXiv evaluated the specific threat to Bitcoin and Ethereum, concluding that the window between quantum capability and cryptographic migration represents the highest-risk period for blockchain assets.
No major Layer 1 chain has deployed protocol-wide post-quantum account signatures as of November 2026.
Bitcoin: BIP-360 (P2QRH) drafts a new SegWit output type that commits to a quantum-resistant public-key hash and accepts PQ signatures. It remains a draft. No activation timeline has been committed.
Ethereum: The Ethereum Foundation established a dedicated Post-Quantum Security Team in January 2026, led by cryptography engineer Thomas Coratger. The roadmap uses account abstraction as the migration mechanism — individual accounts can upgrade to PQ signature schemes without a coordinated hard fork. Target date: 2029.
Quantum Resistant Ledger (QRL): The only chain that has signed every transaction with hash-based post-quantum cryptography since its 2018 launch. It has negligible transaction volume and market capitalization.
StarkWare: Has executed quantum-safe Bitcoin transactions on mainnet using STARK proofs, though this operates at the application layer rather than the consensus layer.
Stellar's CAP-87 occupies a middle position: not a full protocol migration (like QRL), not merely a research team (like Ethereum's), but shipping code that lets contract-layer accounts opt into NIST-finalized PQ signatures. The practical significance depends on adoption by custodians and wallet providers building on Soroban.
The upgrade lands on a network with measurable commercial activity.
| Metric | Value | Period | |--------|-------|--------| | Quarterly transaction volume | $33.2B | Q3 2026 | | Stablecoin transfer volume | $11.4B (ATH) | Q2 2026 | | Tokenized RWAs on network | $3.05B | Q2 2026 | | Average daily transactions | 4.9M (peak: 14.16M) | Q2–Q3 2026 | | Average transaction cost | $0.00012 | October 2026 | | Active validators | 94 | End Q2 2026 | | Tier-1 validators | 21 | End Q2 2026 | | Full validators (with history archives) | 70 | End Q2 2026 | | Network uptime | 99.99% | Q1 2026 | | XLM market cap | ~$5.9B | November 2, 2026 | | XLM price | ~$0.167 | November 2, 2026 | | Circulating supply | 35.25B XLM | November 2026 |
Tier-1 validator membership expanded in Q2 2026 with the addition of MoneyGram, Figure Markets, and Range. Validator count grew from 81 at end of Q4 2025 to 94 at end of Q2 2026 — a 16% increase over two quarters.
The $3.05 billion in tokenized RWAs represents a 100% quarter-over-quarter increase in Q2 2026, according to Nansen's quarterly report. Quarterly transaction volume of $33.2 billion in Q3 reflected a 71% quarter-over-quarter increase.
SDF's upgrade guide identifies mandatory action for multiple ecosystem participants:
SDK operators must upgrade to Protocol 30 SDK versions before the vote dates. Required minimum versions: JavaScript SDK v17.3.0, Go SDK v0.8.0, Rust Soroban SDK 30.0.0-rc.1. Community SDKs for Java, Python, iOS, PHP, C# .NET, Flutter, Elixir, and KMP have tracking issues open.
Infrastructure operators must update Stellar Core, Horizon, RPC, and Galexie to v30.0.0 releases. The XDR definition changes in CAP-88 mean that raw ledger data consumers face breaking changes — older decoders will fail to parse Protocol 30 ledgers.
Wallet and exchange operators must add W-address (muxed contract) support to withdrawal functionality and review address validation logic.
Smart contract teams face no mandatory changes to existing contracts. ML-DSA functions are available optionally by rebuilding against the updated Soroban SDK.
All changes are described as "additive" at the transaction level — backward compatibility is maintained for submitted transactions. The breaking surface is confined to downstream data consumers and address-handling logic.
Bell is not a flashy upgrade. It addresses three operational requirements: multi-tenant smart contract addressing, post-quantum cryptographic readiness, and ledger timing precision. None of these individually transforms Stellar's competitive position. Collectively, they reflect a protocol development philosophy oriented toward institutional requirements and regulatory compliance rather than feature marketing.
The post-quantum component is the most strategically significant. Whether it matters depends on two variables: the timeline for CRQC arrival (uncertain, but regulatory bodies are acting as though it is near-term) and the rate of adoption by Stellar-based custodians and wallet providers. Shipping the primitives is necessary but not sufficient. The migration burden now shifts to the application layer — exactly where Stellar's growing enterprise validator set (MoneyGram, Figure Markets, Range) has operational incentive to act.
The testnet vote on November 3 will provide the first signal of validator consensus.