Bell, Protocol 30 Upgrade Guide

Last updated: October 20, 2026

This guide is designed to help businesses and developers prepare for Bell, Protocol 30, with key dates, release information, preparation steps, and a summary of breaking changes. This guide is informational. Operators are responsible for testing their own integrations before each vote.

You can read all about what's included in Bell in the announcement blog, and stay up to date on any and all Bell-related announcements on the Stellar Developer Discord, where the ecosystem coordinates and shares information about the upgrade in the #protocol-next channel.

Key dates

• October 16, 2026—Stellar Core v30.0.0 stable release available.
• October 16-23, 2026—Additional stable releases (infrastructure and SDKs) available.
• November 3, 2026, 1700 UTC—Testnet upgrade vote.
• November 23, 2026, 1700 UTC—Mainnet upgrade vote.

If you use a Stellar SDK

Upgrade to the latest version of the relevant Stellar SDK.

• For your Testnet integration, upgrade before November 3, 2026.
• For your Mainnet integration, upgrade before November 23, 2026.

The SDK upgrade is not optional this cycle. Protocol 30 changes the ledger header format (CAP-88), and an older SDK may fail to decode Protocol 30 ledgers. The Protocol 30 SDKs carry the updated XDR definitions, plus support for the new muxed contract address type and its W strkey (CAP-84).

If your application handles addresses, the SDK upgrade is step one of two. The SDK gives you a parser for W addresses; your own code has to accept them. Add the W address variant to your type checks wherever you validate, display or store addresses, and wherever you read the destination of a transfer event. See Breaking changes below.

If you build Stellar smart contracts (Soroban), nothing needs to change: existing contracts keep working after the upgrade. When you rebuild against the Protocol 30 Soroban SDK, for example to use the ML-DSA verification functions (CAP-87), you'll also need a Stellar CLI at a matching version or later.

A reminder unrelated to Protocol 30: since Protocol 27 (CAP-71-02), SOROBAN_CREDENTIALS_ADDRESS_V2 is the recommended credential type for Soroban address authorization. The original SOROBAN_CREDENTIALS_ADDRESS still works and has no deprecation date, but a future protocol may retire it. If your wallet or signing library still uses the original type, migrate at your convenience.

If you run Stellar infrastructure (Stellar Core, Horizon, RPC, Galexie)

Install the Protocol 30 releases once they are available (rolling out from October 16, 2026, with all components available by October 23, 2026).

• If you use Docker images, pull the Protocol 30 builds from the Docker registry.
• If you build from source or use our Debian packages, update your stellar-core, stellar-horizon, stellar-rpc, and stellar-galexie binaries to the Protocol 30 builds.

Ubuntu: We will publish images for Ubuntu 24.04 and Ubuntu 22.04. To build from source, refer to the installation instructions; package-based installation is described in the Stellar documentation.

Docker: We will publish the Stellar Core Docker images for Protocol 30; Docker-based installation is described in the Stellar documentation.

If you consume raw ledger data (for example, via Galexie, an indexer, a block explorer, an analytics pipeline, or a custom XDR decoder), you must update your XDR definitions before the upgrade. Read the CAP-88 note under Breaking changes: from the first ledger after the upgrade, ledger headers carry a new value type, and decoders built against older XDR will fail on it.

If you run a validator

Install Stellar Core v30.0.0, released October 16, 2026. The arming command for the November 23 mainnet upgrade vote will be shared with validators through the usual validator channels ahead of the vote.

If you operate a wallet, exchange, issuer, on/off-ramp, or protocol

• Wallets, ramps, and issuers: Upgrade to the latest SDK version (see above) before the Mainnet vote. Then account for the new W address type: after the upgrade, a muxed contract address can be used as the destination of a mint or transfer event. Add it to your address validation, display and storage, and to any logic that reads where a transfer went.
• Exchanges and custodians: Upgrade any SDKs and infrastructure you run before the relevant vote, and add support for withdrawing to muxed contract addresses (the W address type). If you use muxed Stellar accounts (the M address type) for deposits, consider whether muxed contract addresses can better suit your needs.
• Protocols and smart contract teams: CAP-87 (ML-DSA signature verification) and CAP-84 (muxed contract addresses as a transfer destination) are opt-in features you adopt when you rebuild against the updated Soroban SDK. Existing contracts keep working unchanged. If your contract accepts addresses from users, for example a token or a payment contract, decide whether it should accept the muxed variant: a function declared with a plain Address rejects a W address, and one declared with MuxedAddress accepts both. Contracts that read the ledger timestamp should review the CAP-88 note: consecutive ledgers may now report the same whole-second timestamp.

Bell, Protocol 30 is not expected to introduce backwards incompatibility at the transaction level. All changes are additive. Two of them require downstream action: CAP-84 for anything that handles addresses, and an XDR update for anything that decodes raw ledger data. That update covers both CAP-84, since the new address type appears in transactions and therefore in ledger meta, and CAP-88, which changes the ledger header. Upgrading your SDK is required in every case.

CAP-84 (muxed contract addresses): Adds a new SCAddress variant, SC_ADDRESS_TYPE_MUXED_CONTRACT (a contract ID plus a 64-bit multiplexing ID), with a new strkey prefix W, defined in SEP-23.

Every application that validates, displays, stores or routes addresses must handle the new variant and prefix. The Protocol 30 SDK gives you the parser; adding the W variant to your own type checks is the engineering work.

• Where it shows up: the to argument of the Stellar Asset Contract transfer function; any user-supplied address field in a wallet, exchange, ramp or explorer; and ledger meta, which the CAP-84 XDR update covers.
• Events: transfer and mint events carry the ID in the existing to_muxed_id field, exactly as for muxed accounts (CAP-67). Consumers that already handle muxed accounts need no new logic.
• Rules carried over from muxed accounts: a muxed contract address cannot be used in a contract storage key, and a function that declares a plain Address argument rejects one.

CAP-88 (millisecond-resolution close times): Introduces two new StellarValue types, STELLAR_VALUE_SIGNED_MS and STELLAR_VALUE_EMPTY_TX_SET_MS, and a new TimePointMs typedef. From the ledger immediately after the upgrade, every ledger carries one of the new types; the old whole-second types are no longer produced.

Every consumer that decodes StellarValue, LedgerHeader, LedgerCloseMeta, or SCP history (indexers, explorers, analytics pipelines, custom tooling) must update to the Protocol 30 XDR definitions, or decoding will fail on unknown union arms.

Beyond the schema update, no semantic change is required: the existing whole-second closeTime field is unchanged and equals the millisecond value rounded down. Transaction time bounds, minSeqAge, claimable balance predicates, Soroban ledger_timestamp, and upgrade scheduling all keep whole-second semantics. One assumption weakens: consecutive ledgers can now close within the same whole second, so “one ledger later” no longer implies “at least one second later.” No action is needed for normal SDK-based integrations beyond the SDK bump.

CAP-87 (ML-DSA host functions): Adds three Soroban host functions, verify_sig_ml_dsa_44, verify_sig_ml_dsa_65, and verify_sig_ml_dsa_87, implementing FIPS 204 signature verification, plus new ContractCostType entries for metering. No backwards incompatibilities. Contracts compiled against an earlier protocol cannot import these functions until the upgrade. Note the scope: this enables post-quantum signature verification inside smart contracts (for example, custom accounts). Network-level transaction signatures remain Ed25519.

Below are links to the releases relevant to Protocol 30. Please check each release's notes for specific instructions and requirements, and unless otherwise indicated, opt for the “Latest Release.”

Stellar infrastructure

• Stellar Core
• Horizon
• RPC
• Galexie
• Stellar CLI

SDKs

• Rust SDK (Soroban)
• JavaScript SDK
• Go SDK
• Java
• Python
• iOS
• PHP
• C# .NET
• Flutter
• Elixir

Note that some SDKs listed are community-maintained; check each repository for Protocol 30 compatibility and release timing.

• October 20, 2026—Initial guide published.

To stay up to date on any and all Bell-related announcements, join the Stellar Developer Discord, where the ecosystem coordinates the upgrade in the #protocol-next channel.