Stellar’s Bell Upgrade Goes Live on Testnet: What Protocol 30 Changes for XLM

Stellar’s Protocol 30 upgrade, Bell, went live on testnet on Nov. 3 after the scheduled validator vote, and the network now has until Nov. 23 at 17:00 UTC to get wallets, exchanges, custodians and indexers ready for the mainnet vote. Bell carries three changes: muxed contract addresses, post-quantum signature verification inside Soroban contracts, and millisecond ledger timestamps. The Stellar Development Foundation (SDF) frames the release as groundwork for business-scale smart accounts. For the desks that settle tokenized funds and stablecoin flows on Stellar, the practical content of the upgrade is narrower, and more consequential, than the framing suggests: two of the three changes alter data formats that outside systems have to parse.

That is the part worth planning around. Protocol upgrades on settlement chains are rarely judged by what they add. They are judged by what breaks when the new code meets old tooling, and Bell moves the ledger header itself.

Three changes, and only three

SDF describes the release in a single sentence on its announcement post : “It’s designed to make smart accounts ready for businesses at scale and start the work on two longer-term goals: quantum-safe signatures and faster ledgers.”

The three proposals behind that sentence are CAP-88 for millisecond ledger timing, CAP-84 for muxed contract addresses, and CAP-87 for ML-DSA signature verification in contracts. There is no fourth item, no fee-market change and no change to how Stellar reaches consensus. Validators vote with the same trusted-validator sets and thresholds they use for transaction sets; XLM holders do not vote.

The release engineering started on Oct. 16, when Stellar Core v30.0.0 shipped as a stable build, followed by Protocol 30 versions of Horizon, RPC, Galexie and the maintained SDKs. The testnet vote followed on Nov. 3, and the mainnet vote is set for Nov. 23, both at 17:00 UTC. SDF says the command validators use to arm their nodes for the mainnet vote will be distributed through validator channels ahead of the date.

Bell is live on Testnet.

Reminder: the Mainnet vote is November 23rd ?

— Stellar (@StellarOrg) November 3, 2026

What muxed contract addresses fix for custodians

Stellar has supported muxed accounts for years. A muxed account is one Stellar account with an identifier attached, so an exchange can hand every customer a distinct deposit address while the funds land in one account and the exchange tracks ownership offchain. It is the standard omnibus model that payment businesses run on.

Smart accounts, which are contracts rather than keypairs, had no equivalent. A contract holding customer balances could not tell incoming payments apart, so the workaround was one contract per customer. SDF’s own description of the limit is blunt: that approach works for ten customers, not for a million. CAP-84 attaches a 64-bit identifier to a contract address and writes it in a new format that begins with W, with the identifier recorded in the transfer event. One contract can now serve 18,446,744,073,709,551,616 distinct identifiers, the full range of a 64-bit field, without deploying a contract per end user.

The naming has a small piece of engineering folklore attached. “It’s an upside-down M,” Jake Urban, SDF’s senior engineering manager for wallets, said of the W prefix. “We considered reusing M, but decided it was better to have a distinct type so developers always know what they’re working with.”

Two operational consequences follow. Wallets, exchanges and custodians have to accept the W address type in validation, display and storage logic, and contract developers who want to receive these payments must use an address parameter that accepts the muxed variant, because a plain address parameter rejects it. Banks and custodians weighing whether to consolidate customer balances into a single smart account now have a supported path, which is precisely the kind of plumbing that institutional tokenization projects ask for before they commit volume.

Quantum-safe, but only inside contracts

CAP-87 adds three host functions to Soroban, the network’s smart-contract environment, that verify ML-DSA signatures at the 44, 65 and 87 parameter sets defined in NIST’s FIPS 204 standard. Verification runs inside Stellar Core rather than in contract code, which keeps the cost of calling it low and means the implementation is written and tested once against the official test vectors instead of by every contract author.

That is a real step, and it is a bounded one. SDF’s own FAQ answers the obvious question directly: “Does Bell make Stellar post-quantum? No. It lets smart contracts verify ML-DSA signatures, so contract accounts can opt into quantum-safe authorization. Network transaction signatures remain Ed25519.” A native post-quantum signer for classic accounts is left to a future protocol change, which means the overwhelming majority of Stellar accounts, the ones that are keypairs rather than contracts, are unaffected today.

The direction of travel is shared across the industry. Starknet’s token holders voted 93.52% in October to explore becoming an independent post-quantum Layer 1, a decision this publication covered at the time . Stellar’s approach is more incremental: ship the verification primitive first, let contract accounts opt in, and leave the account model alone until the standard and the hardware key management that custodians rely on are ready.

The change that will break things

CAP-88 is the one to read twice. It changes the format of the ledger header to carry millisecond timestamps, and SDF says so plainly in its upgrade guide : “Bell changes the format of the ledger header so anything that reads the ledger data needs to understand the format.”

Any consumer that decodes StellarValue, LedgerHeader, LedgerCloseMeta or SCP history has to move to the Protocol 30 XDR definitions or it will fail on unknown union arms. SDF’s instruction to SDK users is not softened by conditional language: “The SDK upgrade is not optional this cycle.” An older SDK may decode a Protocol 30 ledger and get it wrong, or not decode it at all.

There is a subtler break for anything that assumes whole seconds. The existing closeTime field is unchanged and still reports whole seconds, equal to the millisecond value rounded down, and time bounds, claimable balance predicates and contract timestamps keep whole-second semantics. What weakens is the assumption that one ledger equals at least one second. Consecutive ledgers can now close inside the same whole second, so logic built on “one ledger later” meaning “a second later” needs review. For a payments business running time-locked settlement logic, that is a code review, not a configuration change.

Why the clock matters to settlement desks

The September Adapter release, Protocol 28, brought mainnet ledger close times from about 5.7 seconds to 5 seconds, a cut of roughly 12.3%. CAP-88 does not continue that curve. What it removes is the one-second floor that came from whole-second timestamps, which had blocked targets such as 4.5 seconds and made sub-second close times impossible in principle. The arithmetic is straightforward: at a five-second cadence the network produces 17,280 ledgers a day, and at 4.5 seconds it would produce 19,200, about 11% more. Bell makes that arithmetic reachable. It does not perform it.

The commercial logic behind the work is visible in Stellar’s institutional pipeline. The network has been pushed toward regulated asset settlement and tokenized fund infrastructure, a theme this publication has tracked as DTCC’s tokenization service went live with 34 securities and a slate of Wall Street participants. Faster finality and per-customer addressing inside contracts matter to that audience in a way they do not matter to retail traders: they shorten the window in which collateral sits unsettled, and they let one contract hold many clients’ balances without breaking reconciliation.

Neither upgrade nor price is the story yet

XLM has not priced any of this. The token traded at about $0.1657 at 20:16 UTC on Nov. 4, up 2.1% over 24 hours but down 3.9% over seven days and 23.1% over 30 days, against a 30-day range of $0.1621 to $0.2156, according to CoinGecko data. The token sits near the bottom of that range, three weeks before the mainnet vote.

That divergence should not be read as a verdict on Bell. Protocol upgrades rarely move a token’s price on their own, and there is no evidence that the testnet activation or its absence explains XLM’s October drawdown, which coincided with a broad retreat across altcoins after the Binance hack and the midterm election volatility. What the price does show is that the market is not paying for infrastructure in advance. Holders who want the upgrade to matter commercially will have to wait for volume, not for a vote.

What has to happen before Nov. 23

The work splits cleanly by role. Validators install Stellar Core v30.0.0 and wait for the arming command. Exchanges and custodians upgrade SDKs and add support for withdrawing to muxed contract addresses. Wallets and ramps add W addresses to validation, display and storage. Anyone decoding raw ledger data without an SDK, including indexers, explorers and analytics pipelines, updates XDR definitions before the vote. Contract teams do not have to change existing contracts, which keep working after the upgrade, but teams that want the ML-DSA functions must rebuild against the Protocol 30 Soroban SDK and use a matching or newer Stellar CLI.

SDF is explicit that the guide is informational and that operators are responsible for testing their own integrations before each vote. That caveat deserves weight. Bell is a format change on a chain that carries real payment volume, and the failure mode is not a dramatic outage. It is a decoder that returns wrong data, or a deposit address that a wallet refuses to parse, on the first ledger after activation.

The mainnet vote itself can fail or slip; the date is a scheduled vote, not a delivery guarantee. If validators approve, the first Protocol 30 ledger is the moment every integration on the network either understands the new header or does not. Three weeks is enough time to upgrade an SDK. It is not much time to audit settlement logic that assumed one ledger meant one second.

Frequently Asked Questions

Primary sources: the Stellar Development Foundation’s Bell announcement , its Protocol 30 upgrade guide , and the CAP-84, CAP-87 and CAP-88 specifications. Price data: CoinGecko, 20:16 UTC on Nov. 4, 2026.