Stellar Protocol 30 (Bell): which SDKs and tools are ready

Documentation-based guide: compiled from each maker's release notes and changelogs on Oct 27, 2026. We did not run any code for it. Versions move fast before an upgrade, so check the linked page before you upgrade.

If you use any Stellar SDK, you have to upgrade it before Protocol 30 (Bell) reaches your network: the Stellar Development Foundation (SDF) says older SDKs may fail to decode Protocol 30 ledgers because the ledger header format changes (CAP-88). The testnet vote is November 3, 2026 and the mainnet vote is November 23, 2026, both at 17:00 UTC Source: SDF Bell upgrade guide. As of Oct 27, the JavaScript, Go, Flutter, iOS/macOS, PHP and Kotlin Multiplatform SDKs have Protocol 30 releases out. The Python, Java, .NET and Elixir SDKs and the Stellar CLI don't yet, and the Soroban Rust SDK is at a release candidate.

This guide goes deeper than our Stellar developer tools page and its smart contracts & SDKs list: what changes, which release you need, and what to check with your RPC provider. It only reports what each maker has published, and it is not a ranking.

Contents

• Quick answer: Protocol 30 readiness by tool
• What changes in Protocol 30?
• SDF-maintained SDKs and the Stellar CLI
• Community SDKs
• Stellar RPC, Horizon and hosted providers
• Do Soroban smart contracts need changes?
• How to choose your upgrade path

Quick answer: Protocol 30 readiness by tool

Status as of Oct 27, 2026, based on each maker's own release notes.

For the community SDKs that haven't shipped yet, SDF's upgrade guide links a Protocol 30 tracking issue in each repo where you can follow release timing.

What changes in Protocol 30?

SDF lists three changes that matter to developers. All are additive at the transaction level, but two of them need work from you Source: SDF Bell upgrade guide:

• CAP-88, millisecond close times. Ledger headers carry new StellarValue types, and from the first ledger after the upgrade the old whole-second types are no longer produced. Anything that decodes ledger headers, LedgerCloseMeta or SCP history with old XDR will fail on the new union arms. The existing whole-second closeTime field stays. One assumption no longer holds: two ledgers in a row can now close within the same second.
• CAP-84, muxed contract addresses. A new address type: a contract ID plus a 64-bit ID, written as a strkey starting with W. It can be the destination of a Stellar Asset Contract transfer or mint. The SDK gives you the parser, but your own address checks, display and storage must accept W addresses.
• CAP-87, ML-DSA verification. Three new Soroban host functions for FIPS 204 post-quantum signature checks inside contracts. Network transaction signatures stay Ed25519.

The short version: upgrading your SDK is required in every case. Wallets, exchanges, ramps and explorers also need W-address handling.

SDF-maintained SDKs and the Stellar CLI

Stellar JS SDK. v17.3.0 adds the W address type (`StrKey` and `Address` helpers) and regenerates the XDR with CAP-84, CAP-87 and CAP-88 enabled Source: js-stellar-sdk changelog. The latest release on npm is 17.4.0, and npm also carries an `lts-16` tag for the 16.x line Source: npm @stellar/stellar-sdk. If you stay on 16.x, SDF says v16.4.0 decodes Protocol 30 ledgers but does not handle W addresses, so a wallet or exchange should move to 17.x.

Go SDK. v0.8.0 is SDF's Protocol 30 release. Its changelog has a useful warning: the generated `GetLcValueSignature()` only reads the old SIGNED arm, so it finds no signature on any ledger after the upgrade. Use the new `StellarValueExt.LedgerCloseValueSignature()` instead Source: go-stellar-sdk changelog.

Soroban Rust SDK. 30.0.0-rc.1 was published on Oct 21 Source: crates.io soroban-sdk. SDF says the stable release comes before the mainnet vote.

Stellar CLI. SDF's guide lists the CLI's Protocol 30 release as pending, and crates.io still shows 28.1.0 as the latest version Source: crates.io stellar-cli. This matters only if you rebuild contracts against the Protocol 30 Soroban SDK: SDF says you then need a CLI at a matching version or later.

Community SDKs

Soneso's four SDKs shipped first. Flutter 3.9.0, iOS/macOS 3.13.0, PHP 1.16.0 and Kotlin Multiplatform 1.15.0 all add the CAP-84 W address type, the CAP-87 cost types and the CAP-88 close-time types. Soneso's changelogs point out a trap for typed languages. In Flutter, the new XDR members are constants rather than Dart enums, so a `switch` that leaves them out gets no analyzer warning and runs no case for them. The iOS/macOS SDK marks the XDR change as breaking, so you need to add cases Source: Flutter SDK changelog Source: iOS/macOS SDK changelog.

Python. py-stellar-base lists CAP-84 support and the removal of `EventInfo.in_successful_contract_call` under "Pending". Its latest release, 16.1.1, doesn't include them yet Source: py-stellar-base changelog.

Java, .NET and Elixir. None of their changelogs has a Protocol 30 entry yet. If you depend on one of them, follow its tracking issue from SDF's guide, and keep the testnet date in mind: Nov 3 is a week away.

Stellar RPC, Horizon and hosted providers

If you run your own nodes, SDF's Protocol 30 builds are Stellar Core v30.0.0, Horizon v30.0.0, RPC v30.0.0 and Galexie v30.0.0 Source: SDF Bell upgrade guide. RPC v30.0.0 has one breaking change: `getEvents` no longer returns the `inSuccessfulContractCall` field, which had been deprecated since Protocol 23 Source: stellar-rpc changelog. Horizon v30.0.0 raises the supported protocol to 30 and adds muxed-contract fields to the `contract_credited` effect Source: Horizon changelog.

If a hosted provider serves your RPC, the upgrade is on their side. Neither QuickNode's Stellar docs nor Validation Cloud's supported-chains page mentions Protocol 30 as of Oct 27, so ask your provider when they move to RPC and Horizon v30. Their published history windows also differ, which matters more day to day:

• QuickNode: Mainnet and Testnet, Horizon REST and Stellar RPC. On Mainnet, Horizon keeps about 90 days and Stellar RPC about 7 days (120,960 ledgers). Archive: no Source: QuickNode Stellar docs.
• Validation Cloud: Mainnet Horizon keeps 90 days and Stellar RPC a 60-day window. A separate Horizon archive endpoint keeps about 12 months, and an RPC v2 beta endpoint keeps full history from 2015. Testnet is also listed Source: Validation Cloud supported chains.

We compare the two side by side in QuickNode vs Validation Cloud. More providers are on our Stellar infrastructure page.

Do Soroban smart contracts need changes?

No. SDF says existing contracts keep working after the upgrade. You only touch them if you want the new features:

• ML-DSA (CAP-87): rebuild against the Protocol 30 Soroban SDK. Contracts built for an earlier protocol can't import these functions until the upgrade.
• Muxed contract addresses (CAP-84): a function argument declared as `Address` rejects a W address, and one declared as `MuxedAddress` accepts both. Token and payment contracts should decide which one they want.
• Timestamps (CAP-88): if your contract assumes the next ledger is at least one second later, check that logic, because two ledgers can now report the same whole-second timestamp.

Source: SDF Bell upgrade guide

How to choose your upgrade path

1. Find your SDK in the table above. If it has a Protocol 30 release, upgrade on testnet before Nov 3 and on mainnet before Nov 23.
2. On JS 16.x? v16.4.0 decodes the new ledgers. Move to 17.x if you handle user-supplied addresses.
3. On Python, Java, .NET or Elixir? Watch the SDK's tracking issue, and test the release on testnet as soon as it lands.
4. Handle addresses? Add the W prefix to validation, display, storage and transfer-destination logic. This is your code, not the SDK's.
5. Decode raw XDR (indexer, explorer, Galexie pipeline)? Update your XDR definitions, or decoding fails from the first Protocol 30 ledger.
6. Self-hosted RPC or Horizon? Install v30.0.0 and remove any reliance on `inSuccessfulContractCall`.
7. Hosted RPC? Ask your provider when it upgrades, and check its history window while you're at it.
8. Contracts? Nothing is required. Rebuild with soroban-sdk 30 only for ML-DSA or muxed addresses, and pair it with a matching Stellar CLI once that ships.

Release status changes daily until the votes. Check each maker's page before you rely on this list.