Stellar Development Foundation Sets Operator Software Requirements for Bell Protocol 30 Vote on November 24

Three Workloads Before Activation

The Stellar (XLM) Development Foundation has refreshed its Bell upgrade guide to set out, operator by operator, which software the network needs before the Bell Protocol 30 upgrade goes to a vote, and the update places a distinct workload on exchanges, wallets and services that read ledger data directly. The guide, updated on October 23, pairs infrastructure and developer tooling with supported versions and tells every operator to test its own integration environment, a step the foundation keeps separate from validator voting itself. Testnet voting is scheduled for November 4 and mainnet voting for November 24, though both dates can change and applying the upgrade depends on validator approval. The move addresses a practical gap: validator approval decides whether protocol 30 activates, but the day-to-day software an exchange or wallet runs decides whether its users notice the change at all. The guide itself changes nothing on the network; it translates the proposal into a per-service checklist of software and data formats.

For the parties downstream of the change, the guide draws three lines of responsibility. Exchanges and custodians running hot wallet infrastructure have to confirm they can send withdrawals to the new W-format contract addresses. Wallets and asset issuers must verify the features that accept address input and process transfer records. Services that read ledger data directly, including indexers, explorers and analytics tools, face a separate obligation: protocol 30 introduces a new value format into ledger headers, and a decoder still built on the existing XDR definitions may fail to read ledger data after activation. XDR is the format the Stellar network uses to represent transactions and ledger data, which is why the foundation asks affected teams to refresh their definitions before the vote rather than after.

W Addresses and XDR Decoders

The most visible change is the contract address format beginning with 'W'. Each smart contract address carries a 64-bit identifier, so a single contract can separate deposits arriving from many different customers. SDK updates make the new addresses readable, but application code that checks, displays or stores a wallet address, or that reads a transfer destination, has to accept the W format as well. Wallet software, including hardware wallet displays, falls in that group, while existing smart contracts keep working after the upgrade and adopting the new contract features stays each developer's choice.

The foundation's required versions are stellar-core v30.0.0, Horizon, RPC and Galexie at v30.0.0, the JavaScript SDK at v17.3.0 and the Go SDK at v0.8.0. The 16.x maintenance release v16.4.0 can read the new ledger but does not handle W addresses, so any service that needs W support must be on v17.3.0. Horizon and the RPC endpoint expose the ledger to applications, so their v30.0.0 alignment matters for services that query the chain through those APIs rather than parsing raw XDR. Soroban Rust SDK 30.0.0-rc.1 also made the list, with a stable version due before the mainnet vote, and the Stellar (XLM) CLI build for protocol 30 was still pending when the guide was refreshed. Beyond addressing, Bell carries ML-DSA signature verification for smart contracts and millisecond-level ledger time recording. Network transaction signatures remain on Ed25519, and the timestamp change alone does not shorten the interval between ledger creations. The two preparations are independent: passing a transfer test says nothing about whether a decoder survives the new ledger headers.

Read against the release notes themselves, protocol 30 is additive: existing contracts run through activation and taking up the new features is a developer choice. The live risk sits off-chain, in code the protocol change never touches, so a decoder or an address validator that has not moved by the November 24 vote is the failure mode to watch, not the validator count. The W-address scheme, which lets a single contract tell apart deposits from many customers, points at the custody and exchange corridor that carries TradFi settlement onto Stellar (XLM), the same lane as the first institutional repo settled on Stellar and the DTCC's $30 trillion tokenization service with the network set for 2027. The pending Stellar CLI build and the unreleased stable Soroban SDK leave operators a closing window that ends at the mainnet vote, and services that migrate only after activation will read a ledger their tools were never built to parse.