Originally published at https://tekmag.thsite.top/stellar-protocol-28-adapter-upgrade-faster-consensus-and-atomic-smart-contract-upgrades-arrive-september-16/
Stellar Protocol 28, codenamed Adapter, is a network upgrade that ships three protocol changes built for the people writing smart contracts on Stellar, and it adds a consensus-layer fix that helps the network reach agreement faster as it scales. The mainnet upgrade vote is scheduled for September 16, 2026, at 17:00 UTC.
Key Takeaways
- Three changes, two for builders: According to the Stellar Development Foundation, two of the three upgrades in Adapter (CAP-85 and CAP-86) target Soroban smart contract lifecycle management, while the third (CAP-83) strengthens the consensus layer underneath everything.
- Faster consensus under load: CAP-83 lets validators begin voting before a full transaction set arrives and gives them an explicit way to drop a late or invalid set instead of stalling, improving throughput as the network grows.
- Atomic fleet upgrades: CAP-85 introduces an externally managed executable so one update to a shared code reference upgrades every contract that points to it at once, the Stellar equivalent of the beacon proxy pattern.
- Migration-friendly data: CAP-86 adds "sparse" host functions that handle missing or extra fields gracefully, making live contract schema migrations safe and routine.
- A fixed schedule: Stellar Core stable releases were available August 13, 2026, the testnet vote ran August 27, and the mainnet vote is set for September 16, 2026, at 17:00 UTC.
What Protocol 28 "Adapter" Is and When It Lands
Stellar Protocol 28 is a network upgrade the Stellar Development Foundation has codenamed Adapter, and its announcement frames the release as builder-focused: most of what is inside makes life easier for the people writing smart contracts on Stellar, while a behind-the-scenes consensus change helps the network reach agreement faster as it continues to scale. According to the foundation's own introduction to Adapter, Protocol 28 on Stellar, the upgrade continues a steady theme in recent protocol releases: making the network more developer-friendly for real financial applications without compromising the speed and low cost it is known for.
The rollout follows a fixed schedule. According to the same announcement, Stellar Core stable releases were available on August 13, 2026, with additional stable releases for infrastructure and SDKs landing between August 13 and August 21. The testnet upgrade vote ran on August 27, 2026, at 17:00 UTC, and the mainnet upgrade vote is scheduled for September 16, 2026, at 17:00 UTC. That means the mainnet change lands within a month of the stable releases, a tight window for anyone running infrastructure to prepare. Lumen Loop's independent summary of the release confirms the same fixed schedule, with the August stable releases, the August 27 testnet vote, and the September 16 mainnet vote all holding to that timeline.
CAP-83: Faster Consensus Under Load
CAP-83 is a consensus improvement that speeds up the ledger-closing process and keeps it moving when transaction data is slow to reach validators. Every few seconds, validators on the Stellar network agree on the next ledger, and today that process requires validators to receive a full transaction set before they can make progress. According to the CAP-0083 specification, which lets validators vote to drop a transaction set, the change lets validators begin voting before the transaction set has fully arrived, and gives them a clean, explicit way to drop a set that is late or invalid instead of stalling while they wait for it.
In practice, consensus keeps moving even when transaction data is slow to propagate, which improves throughput and helps the network stay smooth at scale and at low cost. The full performance gains are phased in gradually after mainnet, as parallel transaction-set downloading is enabled. One detail operators should note: the change adds a new value type, STELLAR_VALUE_EMPTY_TX_SET, assigned enum value 2 in the protocol. Teams that consume raw ledger data directly will need to handle that new type, and the upgrade guide flags it as a breaking change for raw data consumers. For everyone else, CAP-83 is a behind-the-scenes improvement you benefit from without changing anything.
CAP-85: Atomic Upgrades for Fleets of Contracts
CAP-85 is an upgrade that lets a single change propagate to an entire fleet of contracts at once, rather than forcing an admin to update each instance by hand. Many protocols deploy many copies of the same contract, a fleet that all shares the same underlying Wasm code. When that shared code needs an upgrade, often to ship a security fix, the admin has to update each instance individually. According to the CAP-0085 specification for externally managed contract executables, when a fleet is too large to fit into a single transaction, that one-by-one approach is no longer possible, which leaves a window where some contracts run the new code and some are still on the old.
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. The specification describes this as the Stellar equivalent of the beacon proxy pattern that ecosystems like Ethereum use to manage reusable code through shared references. It is a direct answer to a real operational risk: a partial upgrade that leaves contracts in inconsistent states, which is the kind of failure that matters most when the shared code carries security fixes.
CAP-86: Migration-Friendly Contract Data
CAP-86 is a data-handling change that makes evolving a live contract's data structures safe instead of a source of breakage. As contracts evolve, their data structures often need to change: adding a field, removing an unused one, or extending a shared interface. The standard host functions that read and write these structures reject anything that does not match the exact expected shape, so evolving a deployed contract's data has been hard, and in some known cases has left contracts stuck.
According to the Stellar Development Foundation's breakdown, 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. You get it by rebuilding against an updated SDK, with no changes to how you write contracts, so the change is invisible in your code and lands as a supported migration path in the SDK itself.
Why the Upgrade Schedule and Prep Window Matter
The schedule matters because Adapter touches the parts of the network that operators and data consumers cannot ignore. According to the Protocol 28 upgrade guide, validators, infrastructure operators, SDK users, wallets, exchanges, issuers, and ramps each have specific preparation steps to complete before the mainnet vote. The guide is where the foundation has consolidated the full timeline, release links, and those preparation instructions, so teams that run infrastructure or build on Stellar treat it as the single source of truth for getting ready.
The window between the August stable releases and the September 16 mainnet vote is deliberately short. That is the operating constraint every operator has to plan against: the code is available and testable, but the time to update infrastructure, rebuild SDKs, and run the upgrade on testnet first is a matter of weeks, not months. It is the same dynamic the network saw with the way Solana's validator community coordinated a protocol vote on a fixed timeline, where a scheduled governance vote forces every participant to be in place before the clock runs out.
What Adapter Signals for Smart Contracts on Stellar
Read the three changes together and a clear direction shows up. Two of the three upgrades target the contract lifecycle: CAP-85 makes large deployments upgradeable in a single atomic step, and CAP-86 makes live data migrations safe and routine. According to the foundation's framing, that is a deliberate move to make Stellar a more capable platform for real financial applications, reducing the number of contracts you have to deploy, making upgrades atomic and safe, and letting contract data evolve without breaking.
That is the same direction other networks are pushing. As new layers bring tokenized assets on-chain, the pressure to make shared contracts updatable and the data behind them migrable only grows, as we saw in the move to run tokenized stocks and DeFi on a new Ethereum L2. Adapter is Stellar's answer to that pressure, and it lands on a schedule you can mark in the calendar.
If you run anything on Stellar, the concrete next step is the upgrade guide, not the release notes. Pull the preparation steps for your role before the September 16 vote, run the upgrade on testnet, and confirm you are ready, because that is when the mainnet clock starts.
Conclusion
Stellar Protocol 28, Adapter, ships three upgrades: CAP-83 for faster consensus under load, CAP-85 for atomic smart contract fleet upgrades, and CAP-86 for migration-friendly contract data. The mainnet upgrade vote is scheduled for September 16, 2026, at 17:00 UTC, and the preparation window for operators is the weeks between the August stable releases and that vote.
Frequently asked questions
{"@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{"@type": "Question", "name": "What is Stellar Protocol 28, \"Adapter\"?", "acceptedAnswer": {"@type": "Answer", "text": "Stellar Protocol 28, codenamed Adapter, is a network upgrade that ships three changes: CAP-83 for faster consensus under load, CAP-85 for atomic upgrades of fleets of smart contracts, and CAP-86 for migration-friendly contract data. It is a builder-focused release from the Stellar Development Foundation."}}, {"@type": "Question", "name": "When does the Stellar mainnet upgrade vote happen?", "acceptedAnswer": {"@type": "Answer", "text": "The mainnet upgrade vote is scheduled for September 16, 2026, at 17:00 UTC. Stellar Core stable releases were available on August 13, 2026, and the testnet upgrade vote ran on August 27, 2026, ahead of it."}}, {"@type": "Question", "name": "What does CAP-83 change about Stellar's consensus?", "acceptedAnswer": {"@type": "Answer", "text": "CAP-83 lets validators begin voting before a full transaction set arrives and gives them an explicit way to drop a late or invalid transaction set instead of stalling. This improves throughput and keeps consensus moving under load. It also adds a new value type, STELLAR_VALUE_EMPTY_TX_SET, that teams consuming raw ledger data must handle."}}, {"@type": "Question", "name": "How do CAP-85 and CAP-86 help smart contract developers?", "acceptedAnswer": {"@type": "Answer", "text": "CAP-85 introduces an externally managed executable so that one update to a shared code reference upgrades every contract in a fleet atomically, which is Stellar's version of the beacon proxy pattern. CAP-86 adds sparse host functions that handle missing or extra fields gracefully, making live contract data migrations safe and routine. Both land through an updated SDK without changing how you write contracts."}}, {"@type": "Question", "name": "Do I need to change anything to benefit from Protocol 28?", "acceptedAnswer": {"@type": "Answer", "text": "For end users, no. For anyone running a validator, infrastructure, an SDK, a wallet, an exchange, an issuer, a ramp, or a protocol, yes: the Protocol 28 upgrade guide lists specific preparation steps for each. Teams that consume raw ledger data should handle the new STELLAR_VALUE_EMPTY_TX_SET value type introduced by CAP-83."}}]}
What is Stellar Protocol 28, "Adapter"?
Stellar Protocol 28, codenamed Adapter, is a network upgrade that ships three changes: CAP-83 for faster consensus under load, CAP-85 for atomic upgrades of fleets of smart contracts, and CAP-86 for migration-friendly contract data. It is a builder-focused release from the Stellar Development Foundation.
When does the Stellar mainnet upgrade vote happen?
The mainnet upgrade vote is scheduled for September 16, 2026, at 17:00 UTC. Stellar Core stable releases were available on August 13, 2026, and the testnet upgrade vote ran on August 27, 2026, ahead of it.
What does CAP-83 change about Stellar's consensus?
CAP-83 lets validators begin voting before a full transaction set arrives and gives them an explicit way to drop a late or invalid transaction set instead of stalling. This improves throughput and keeps consensus moving under load. It also adds a new value type, STELLAR_VALUE_EMPTY_TX_SET, that teams consuming raw ledger data must handle.
How do CAP-85 and CAP-86 help smart contract developers?
CAP-85 introduces an externally managed executable so that one update to a shared code reference upgrades every contract in a fleet atomically, which is Stellar's version of the beacon proxy pattern. CAP-86 adds sparse host functions that handle missing or extra fields gracefully, making live contract data migrations safe and routine. Both land through an updated SDK without changing how you write contracts.
Do I need to change anything to benefit from Protocol 28?
For end users, no. For anyone running a validator, infrastructure, an SDK, a wallet, an exchange, an issuer, a ramp, or a protocol, yes: the Protocol 28 upgrade guide lists specific preparation steps for each. Teams that consume raw ledger data should handle the new STELLAR_VALUE_EMPTY_TX_SET value type introduced by CAP-83.
References
- Stellar Development Foundation: Introducing Adapter, Protocol 28 on Stellar (August 13, 2026)
- GitHub: CAP-0083, Allow validators to vote to drop the transaction set from the current ledger (status: implemented)
- GitHub: CAP-0085, Externally managed contract executables (status: implemented)
- GitHub: CAP-0086, Migration-friendly contract data
- Stellar Development Foundation: Adapter, Protocol 28 Upgrade Guide (August 13, 2026)
- Lumen Loop: Introducing Adapter, Protocol 28 on Stellar (August 13, 2026)
Top comments (0)