The Stellar Development Foundation has published the rollout schedule and technical requirements for Protocol 28, internally named Adapter, giving infrastructure operators and developers a defined path toward the network’s next upgrade. The transition requires coordinated software updates across Stellar Core, Horizon, RPC, Galexie and supported SDKs before validators consider activating the protocol on Mainnet.
Stellar Core’s stable Protocol 28 release is scheduled for August 13, with additional infrastructure and SDK builds rolling out through August 21. The network has set its Testnet upgrade vote for August 27 at 17:00 UTC and its Mainnet vote for September 16 at the same time. The staged schedule gives ecosystem participants several weeks to verify compatibility before Protocol 28 reaches the production network.
Infrastructure operators face coordinated upgrade window
In its official Protocol 28 upgrade guide, the Stellar Development Foundation instructs operators to install Adapter-compatible releases as they become available. Docker users will need the relevant Protocol 28 images, while organizations running packages or source builds must update their Stellar Core, Horizon, RPC and Galexie binaries. Infrastructure that remains on incompatible software after activation risks falling out of sync with the upgraded network.
SDK users face a comparatively lighter migration. Stellar says most integrations will only require upgrading to the latest relevant SDK before the corresponding Testnet or Mainnet vote. However, teams consuming raw ledger data should review CAP-83, which introduces a new STELLAR_VALUE_EMPTY_TX_SET value requiring handling by indexers, analytics pipelines and other custom tooling. Normal SDK-based integrations are not expected to require changes specifically for that new ledger value.
Validators have an additional operational requirement: after installing the Protocol 28 Stellar Core release, they must configure their nodes for the September 16 activation vote. Adapter also introduces functionality intended to reduce ledger-close variance, making clock synchronization more important. Stellar says validator operators must run NTP synchronization under Protocol 28 because unsynchronized clocks could degrade network performance.
Adapter introduces targeted changes without broad incompatibility
The foundation does not expect Protocol 28 to create general backward incompatibility within Stellar Core. Most changes are additive, although specific downstream systems may need adjustments. CAP-85 introduces externally managed contract executables, while CAP-86 adds sparse-map host functions designed to support migration-friendly contract data. Smart-contract teams can adopt these capabilities through updated Soroban tooling without being forced to use them immediately.
Wallets, exchanges, custodians, issuers and on/off-ramp providers are advised to review their SDK and infrastructure dependencies before the Mainnet vote. Organizations relying on external infrastructure providers should likewise confirm that their vendors are following the rollout. Protocol 28 therefore represents less a single activation event than a coordinated ecosystem migration whose success depends on participants upgrading before validators approve Adapter on Mainnet.