Stellar Bell Upgrade Adds W Addresses And Post-Quantum Checks

Stellar's next protocol upgrade has a name, a vote date and a long list of things developers must check first. The Stellar Bell upgrade is not a small patch. Bell, also called Protocol 30, was laid out by the Stellar Development Foundation on October 20. Validators vote on it twice, once on testnet and once on mainnet. Nothing goes live until the second vote passes.

Three changes in the Stellar Bell upgrade

Bell bundles three proposals. Each one is tied to a numbered improvement proposal, or CAP, in Stellar's public process.

CAP-84 lets one smart contract serve many customers. Exchanges and ramps already use muxed accounts on classic Stellar, where one account carries an ID so each customer gets a deposit address. Smart accounts had no such feature, so a business holding customer balances needed one contract per customer. Under CAP-84 a contract address can carry a 64-bit ID in a new format that starts with the letter W.

The foundation's own description of CAP-84 and its new W address format. Source: Stellar, Introducing Bell, Protocol 30.

CAP-87 gives smart contracts a way to verify ML-DSA signatures, one of the post-quantum standards NIST finalized in 2024. Verifying one takes much more computation than an Ed25519 check, so Stellar Core does the work instead of contract code. Ordinary transaction signing is untouched and remains Ed25519. The foundation says a native post-quantum signer for classic accounts would need a later protocol change.

Faster ledgers need a millisecond clock

CAP-88 is the quietest of the three. Today Stellar records each ledger's close time in whole seconds, so the network cannot aim for anything under one second between ledgers. Bell moves the ledger to a millisecond clock. That does not speed anything up by itself, and the foundation says as much in its FAQ.

The context is September's Adapter upgrade, Protocol 28, which cut mainnet close times from about 5.7 seconds to 5. The foundation says the Stellar Core team is already testing shorter close times on experimental branches that rely on CAP-88.

What operators have to do before November

The Stellar Bell upgrade changes the format of the ledger header. The upgrade guide calls an SDK update not optional this cycle, because an older SDK may fail to decode Protocol 30 ledgers. Anyone who reads raw ledger data without an SDK, such as an indexer or explorer, has to update XDR definitions. The old closeTime field keeps reporting whole seconds.

Wallets and exchanges have a second job. Their code must accept the new W address type wherever it validates, shows or stores addresses. Existing Soroban contracts keep working, and developers only need a matching Stellar CLI when they rebuild against the new SDK to use ML-DSA verification.

The rollout timeline from the announcement, which the foundation marks as subject to change. Source: Stellar Development Foundation.

Stellar Core v30.0.0 went stable on October 16, and the rest of the releases follow through October 23. After that, validators get two chances to vote. Testnet goes first on November 3. Mainnet follows on November 23, and both votes open at 1700 UTC.

The foundation warns the schedule could still move. Anyone who misses the software update could end up out of step with everybody else. For the Stellar Bell upgrade, those two votes decide what ships.