Introducing Adapter, Protocol 28 on Stellar

The next upgrade to the Stellar network, Protocol 28—Adapter—is on its way. It's a builder-focused release: most of what's inside makes life easier for the people writing smart contracts on Stellar, while a change under the hood helps the network reach consensus faster as it continues to scale.

Here's what's in Adapter, why it matters, and what happens next.

Faster consensus, even under load (CAP-83)

Every few seconds, validators on the Stellar network agree on the next ledger. Today, part of that process requires validators to receive a full transaction set before they can make progress—and sharing those transaction sets across the network takes time.

CAP-83 lets validators begin voting before the transaction set has fully arrived, and gives them a clean, explicit way to drop a transaction set that is late or invalid instead of stalling while they wait for it. In practice that means consensus keeps moving even when transaction data is slow to propagate, which will improve throughput and help keep the network running smoothly at scale and at low cost. The full performance gains will be phased in after mainnet as parallel transaction-set downloading is gradually enabled.

Why you should care: This is a behind-the-scenes improvement—you don't need to change anything to benefit from it as it rolls out—but it's foundational. A faster, more resilient consensus process is what lets Stellar keep growing without getting slower. (Teams that consume raw ledger data directly should see the “Breaking changes” section of the upgrade guide, as the change adds a new value type they'll want to handle.)

Atomic upgrades for fleets of contracts (CAP-85)

Many protocols deploy lots of copies of the same contract—a “fleet” that all share the same underlying code. When that shared code needs an upgrade (say, to ship a security fix), the admin has to update each instance one by one. For large fleets, that can't be done in a single transaction, which leaves a window where some contracts are running the new code and some are still on the old code.

CAP-85 introduces an externally managed executable: contracts can point to a shared, updatable code reference owned by another contract. Update that one reference, and every contract that points to it upgrades at once—atomically, no matter how large the fleet.

Why you should care: This is the Stellar equivalent of the “beacon proxy” pattern developers know from other chains. It makes managing large deployments dramatically safer and less error-prone, and it removes the risk of a partial upgrade leaving contracts in inconsistent states.

Migration-friendly contract data (CAP-86)

As contracts evolve, their data structures often need to change—adding a field, removing an unused one, or extending a shared interface. Today the standard host functions that read and write these structures reject anything that doesn't match the exact expected shape, which makes evolving a live contract's data surprisingly hard and, in some known cases, has left contracts stuck.

CAP-86 adds new “sparse” host functions that handle missing or extra fields gracefully instead of failing. That gives developers a standard, supported way to migrate contract data to a new schema over time.

Why you should care: If you maintain contracts that you expect to upgrade over their lifetime, this makes schema changes safe and routine instead of a source of breakage. You'll get it by rebuilding against an updated SDK—no changes to how you write contracts. When the Protocol-28 versions of your SDK is out, make sure to check out the migration docs for more details.

Adapter is, above all, a release for builders. Two of its three changes (CAP-85, CAP-86) are aimed squarely at making Soroban smart contracts easier to build, upgrade, and scale—reducing the number of contracts you have to deploy, making upgrades atomic and safe, and letting contract data evolve without breaking. The third (CAP-83) strengthens the consensus layer everything else rests on.

Taken together, they continue a steady theme in recent protocol upgrades: making Stellar a more capable, more developer-friendly platform for real financial applications, without compromising the speed and low cost the network is known for.

Protocol 28 rolls out on a fixed schedule. The high-level milestones:

August 13, 2026 — Stellar Core stable release available.

August 13-21, 2026 — Additional stable releases (infrastructure and SDKs) available.

August 27, 2026, 1700 UTC — Testnet upgrade vote.

September 16, 2026, 1700 UTC — Mainnet upgrade vote.

If you run infrastructure, a validator, or build on Stellar, there are steps you'll need to take to be ready. Everything you need—the full timeline, release links, and preparation instructions for validators, infrastructure operators, SDK users, wallets, exchanges, issuers, ramps, and protocols—is in the Protocol 28 Upgrade Guide.

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