The Stellar Development Foundation released Stellar Core 28.0.0 on August 13. The software contains three changes for consensus and Soroban contracts: an explicit way to discard an unavailable transaction set, one-step upgrades for fleets of contracts, and more flexible contract-data migrations.

This is not a mainnet activation. Validators are due to vote on testnet on August 27 and on mainnet on September 16. The gap between available code and a network-wide protocol therefore still contains two observable milestones — plus operational work for infrastructure teams.

What actually shipped

The Stellar Core 28.0.0 release is stable software published at 20:05 UTC on August 13. Its release notes tie Protocol 28, named Adapter, directly to CAP-83, CAP-85 and CAP-86.

Stellar’s official upgrade guide sets an August 13–21 window for the remaining infrastructure components and developer kits. It asks testnet integrations to update before August 27 and mainnet integrations before September 16.

That distinction matters. August 27 at 17:00 UTC is the testnet upgrade vote. The mainnet vote is scheduled for September 16 at 17:00 UTC. A scheduled vote is not guaranteed adoption: validators must be ready and accept the new protocol version.

CAP-83: progress without waiting forever for a transaction set

Stellar validators agree on the next ledger and the transaction set to apply to it. CAP-83 lets them begin parts of the ballot before receiving that entire set. If the set arrives too late or is invalid, validators can vote to drop it and finalise an empty ledger instead of remaining stuck.

The proposal introduces a new value named `STELLAR_VALUE_EMPTY_TX_SET`. Indexers, analytics pipelines and other systems that consume raw ledger data need to recognise it and treat the corresponding transaction set as empty. Ordinary SDK-based integrations do not face the same change.

Stellar expects the mechanism to improve consensus throughput and consistency when transaction data is slow to propagate. The caveat is material: parallel transaction-set downloading, which is meant to produce the full gain, will initially be disabled by default and enabled gradually. Code and simulations support the engineering claim, but mainnet measurements do not yet prove it.

The CAP also documents an attack path. A malicious validator could propose a bad transaction-set hash and push the network toward an empty ledger after a delay. The design retains the original value and its signature so operators can identify the proposer. It does not remove the need to monitor validator behaviour.

CAP-85: one reference to upgrade a fleet

Protocols often deploy many instances of the same contract. Until now, a large Soroban “fleet” had to be upgraded one instance at a time when its shared code changed. That creates a window in which some instances run old code while others run the new version.

CAP-85 adds an executable reference managed by another contract. Every instance that points to that reference can switch to new code in one atomic update. Stellar compares the design to the beacon-proxy pattern used in the Ethereum ecosystem.

The benefit is concrete for security patches: an atomic operation lowers the chance of missing one instance or leaving incompatible versions live together. The same mechanism also concentrates upgrade power. GatherHub infers that safety will depend on who controls the reference, how authorisation works, whether changes are delayed, and whether users can inspect new code before the switch.

Atomicity does not make an upgrade correct. It can spread a defective binary just as efficiently as a fix. Teams still need audits, tests, access controls and recovery procedures suited to their architecture.

CAP-86: evolving data without freezing a contract

Contract data structures change over time: a field is added, another is retired, or an interface evolves. Soroban’s current host functions expect an exact match between anticipated keys and received data. CAP-86 says this rigidity has left some contracts unusable after an update.

Two new “sparse” functions will handle missing or extra fields in a controlled way. A developer could gradually migrate a structure by adding an optional field before removing its predecessor. Existing functions remain unchanged; adoption is opt-in and requires rebuilding against a compatible SDK.

Flexibility removes an operational obstacle, not migration risk. A missing field can now be represented without automatically trapping the call, but the contract must still define what that absence means. Stellar’s guide therefore asks teams to review breaking changes and test their dependencies before the votes.

GatherHub’s Smart contracts course explains why contract code and contract state are separate layers. Protocol 28 touches both: CAP-85 changes how shared code can be referenced, while CAP-86 changes how data can evolve.

Who needs to act before the votes

Operators of Stellar Core, Horizon, RPC and Galexie need to install compatible releases as they become available. Validators must also arm their nodes before the planned September 16 mainnet vote. The official guide sets the corresponding preparation date at September 9, 17:00 UTC.

Protocol 28 requires validators to synchronise their clocks through NTP. Without that synchronisation, the new mechanism intended to shorten ledger-close times and reduce variance can instead degrade network performance.

Wallets, exchanges, issuers and on/off-ramps will mainly need current SDKs and infrastructure. Raw-data consumers must inspect the new ledger value. Contract teams that want external executable references or sparse migration functions will have to adopt those mechanisms explicitly.

Why this matters now

Adapter does not promise a new consumer-facing application. It addresses a less visible but more structural problem: how financial infrastructure can evolve without stalling consensus, splitting a fleet across incompatible contract versions, or locking data into one permanent schema.

The software release makes the deadline real for operators. It does not prove validator adoption, throughput gains, or the safety of contracts that use the new capabilities. Two secondary reports — Crypto Economy and CoinGabbar — correctly corroborate the official schedule. The technical claims in this article remain grounded in Stellar’s documents and the CAP specifications.

What to watch

The first check is whether the promised components and SDKs arrive by August 21. The August 27 testnet vote should then show whether validators accept Protocol 28 and whether applications work in that environment.

Ahead of September 16, the signals are validator readiness, clock synchronisation and any corrective releases. After a successful mainnet vote, useful evidence will include the actual pace of parallel-downloading activation, observed ledger-close times and incidents involving shared contract references. Until that vote, Protocol 28 is published software and a planned network upgrade — not yet mainnet’s operating rule.

Sources consulted