Stellar is preparing for its next major network upgrade, Protocol 28, which is also called Adapter. This upgrade mainly targets developers and infrastructure operators, and two out of three major changes are aimed at making Soroban smart contracts easier to build, upgrade, and maintain. There’s also a change to how the network reaches consensus, meant to help Stellar keep scaling up without slowing down.
Protocol 28 brings in three major changes: CAP-83, CAP-85, and CAP-86. CAP-83 speeds up network consensus when transaction data is slow to spread. One thing Adapter does not appear to include is contract-based authentication for classic Stellar accounts, which the Stellar Development Foundation flagged in June as coming in Protocol 28. CAP-85 introduces a way to upgrade groups of smart contracts all at once, and CAP-86 adds new tools to make migrating contract data easier. Stellar also frames the pair as reducing the number of contracts developers need to deploy in the first place. The upgrade rolls out in stages. Testnet vote is set for August 27, 2026, and the Mainnet vote on September 16, 2026.
CAP-83: Faster Consensus Under Network Load
The first main update in Adapter, CAP-83, aims to boost consensus performance when the network is busy. Usually, Stellar validators agree on the next ledger every few seconds, but the current process forces them to get the full transaction set before moving forward. Those transaction sets need to move across the network, and if there’s a slowdown, consensus can get stuck. CAP-83 changes things by letting validators start voting even if they haven’t received the full transaction set yet. It also gives them a clear way to drop any transaction set that arrives late or is invalid.
The idea is to keep slow-moving transaction data from stopping consensus. Stellar says this should increase throughput and keep the network running smoothly at scale, all while keeping costs down. These performance gains won’t show up overnight. The improvements begin gradually after Mainnet, as parallel transaction-set downloading turns on. Most users and developers won’t need to do anything, the change happens behind the scenes. But teams working directly with raw ledger data should check the breaking changes section of the upgrade guide. There’s a new value type involved, so those systems may need adjustments as Protocol 28 comes in.
CAP-85: Atomic Upgrades for Contract Fleets
CAP-85 focuses on a problem for projects that run lots of contracts. Some protocols deploy large fleets of identical contracts. If the shared code needs an update, admins often have to upgrade each contract one by one. That’s risky. If you can’t upgrade the whole fleet in a single transaction, some contracts might run new code while others stick with the old version. For a while, the protocol’s contracts aren’t on the same page.
Adapter, through CAP-85, introduces an externally managed executable. Contracts can now point to a shared, updateable code reference, controlled by another contract. Instead of updating every single contract, admins just update the reference. This means you can upgrade the entire fleet at once, no matter the size. The upgrade details compare this to the beacon proxy pattern familiar to developers on other blockchains. For projects with big deployments, this makes upgrades both safer and simpler. It eliminates the worry of partial upgrades leaving different versions running.
CAP-86: Easier Contract Data Migrations
CAP-86 tackles another problem that pops up as smart contracts change: migrating data. As contracts evolve, developers might need to tweak data structures, adding a field, dropping an unused one, or expanding an interface. Current standard host functions block data that doesn’t fit the expected structure exactly. That can turn live contract upgrades into a real problem, and sometimes leaves contracts stuck.
CAP-86 brings in sparse host functions, which handle missing or extra fields more flexibly. Developers now get a supported way to migrate contract data from one version to another over time. The point is to make contract upgrades routine, not a major source of risk. All developers need to do is rebuild their contracts with the new SDK. Stellar also recommends checking the migration guides when Protocol 28 SDK versions ship.
Stellar Protocol 28, Adapter, is on the way.
This upgrade introduces enhancements that make it easier to write smart contracts on Stellar, as well as a change under the hood that helps the network reach consensus faster as it continues to scale.
What this upgrade includes ⤵️ pic.twitter.com/OOSCA6i8Mp
— Build on Stellar (@BuildOnStellar) August 13, 2026
Protocol 28 Rollout Dates and What to Update
Protocol 28 will follow a set schedule. Stellar Core’s stable release landed on August 13, 2026, followed by more infrastructure and SDK releases between August 13 and August 21. The Testnet upgrade vote is set for August 27, 2026, at 1700 UTC. Mainnet’s vote comes on September 16, 2026, at 1700 UTC. Developers using SDK integrations should update their SDK before August 27 for Testnet and before September 16 for Mainnet. The guide includes preparation instructions for validators, infrastructure operators, SDK users, wallets, exchanges, issuers, ramps, and protocols.
