Stellar Protocol Upgrades 2025–2026: Whisk to Protocol 29

How a Stellar upgrade works

Stellar changes its rules through Core Advancement Proposals (CAPs). Once a CAP is implemented in stellar-core, SDF publishes an upgrade guide, infrastructure releases ship, and validators vote at a scheduled time, testnet first and mainnet a few weeks later. A CAP is marked Final once validators have adopted it on the network.

There are no hard forks in the Ethereum sense and no miners. Each validator is configured to vote for a protocol version at a set time; if enough of the network agrees, the ledger at that point is closed under the new rules. Nodes running software that does not understand the new version stop following the network, which is why every upgrade guide carries a deadline for Core, Horizon, RPC and SDK upgrades. Recent mainnet votes have been scheduled for 17:00 UTC, with testnet upgrades usually two to three weeks earlier; the Protocol 24 repair went from testnet to mainnet in a day.

Two consequences matter for users. New smart-contract features are generally opt-in: a deployed contract keeps running unchanged, and its authors only gain new host functions by rebuilding against the new Soroban SDK. And network-wide parameters such as resource limits and fee rates are changed by separate validator votes, not only by protocol upgrades.

The timeline at a glance

Seven mainnet upgrades landed between 3 September 2025 and 1 October 2026: Protocol 23 Whisk, the Protocol 24 stability fix, Protocol 25 X-Ray, Protocol 26 Yardstick, Protocol 27 Zipper, Protocol 28 Adapter and Protocol 29. Each row below lists the mainnet date and the CAPs it activated.

Protocol	Mainnet	Headline CAPs
23 "Whisk"	3 Sep 2025	CAP-62, 63, 65, 66, 67, 68, 69, 70: live-state split, parallel execution, module cache, in-memory reads, unified events
24	22 Oct 2025	CAP-76: repair of the P23 state-archival bug
25 "X-Ray"	22 Jan 2026	CAP-74 (BN254), CAP-75 (Poseidon hashes)
26 "Yardstick"	6 May 2026	CAP-73, 77, 78, 79, 80, 82: SAC trustlines, entry freezing, TTL control, ZK and 256-bit maths
27 "Zipper"	8 Jul 2026	CAP-71: authentication delegation, address-bound credentials
28 "Adapter"	16 Sep 2026	CAP-83, 85, 86: empty tx sets, shared contract executables, map helpers
29	1 Oct 2026	Security and stability release (see below)

Protocol 23 "Whisk" and the Protocol 24 fix

Whisk was the biggest smart-contract upgrade since Soroban launched. It let validators execute contract transactions in parallel, kept live contract state in memory, cached compiled Wasm, and made classic and Soroban asset events identical. Seven weeks later a bug in its archival code forced Protocol 24, a repair release.

SDF's announcement summarises Whisk's eight CAPs. The ones with visible effects:

• CAP-63, parallel scheduling. Contract transactions had been applied one at a time on a single CPU core. Transaction sets can now be split into stages of independent clusters run on multiple threads, with bounded apply time.
• CAP-65, reusable module cache. Wasm is parsed, validated and translated once and kept, so, in SDF's words, "user fees will be lower due to the elimination of parsing, validation, and translation costs".
• CAP-62 and CAP-66, state. Archived and live state now live in separate structures; live Soroban entries are held in validator memory, removing the read-bytes fee for live state; and archived entries are restored automatically when a transaction touches them, rather than needing a separate restore step.
• CAP-67, unified events. Classic payments now emit the same transfer, mint, burn and clawback events as the Stellar Asset Contract, so one event stream tracks every asset movement.
• CAP-70, configurable timing. Ledger close time and consensus timeouts became network settings, with "no immediate effect" but room to shorten block times later.

On 9 October 2025 SDF disclosed that the new eviction code had archived some entries using an older historical state rather than the latest one. CAP-76 gives a concrete example: a contract that held 10 XLM, spent 9, and was then archived could be restored with 10 XLM. On mainnet 478 entries were affected; 84 had been restored to the live ledger (77 of them actually modified) and 394 had never been restored. Tier 1 validators paused eviction and shipped a patch that rejected any transaction touching the corrupted keys. Protocol 24, voted on 22 October 2025, reset the 394 unrestored entries to their correct state and adjusted the fee pool for unintended burns. About 47 million other entries were unaffected.

Protocols 25 and 26: cryptography and asset plumbing

Protocol 25 (January 2026) added host functions for the BN254 curve and Poseidon hashes, the building blocks of zero-knowledge proofs. Protocol 26 (May 2026) went further on ZK, made ledger-entry freezing a protocol feature, and let contracts create trustlines and new accounts through the Stellar Asset Contract.

Protocol 25, named X-Ray, contained two CAPs: CAP-74 for BN254 elliptic-curve operations and CAP-75 for Poseidon and Poseidon2 permutations. Neither changes anything for a wallet user; both make verifying ZK proofs on-chain practical.

Protocol 26, Yardstick, is the one most developers will meet:

• CAP-73, SAC trustlines and account creation. The Stellar Asset Contract gains a trust function that creates a trustline for a G-account from inside a contract call, and an XLM transfer to a non-existent G-address now creates the account, provided it covers the 1 XLM minimum balance. Before this, a contract could not create a missing trustline and pay into it in one transaction. The account holder must still authorise the trustline. This is covered in how assets are issued on Stellar.
• CAP-77, freezing ledger entries. After the P23 incident, the corrupted keys had been blocked by a custom Core build that only worked once every Tier 1 validator ran it. CAP-77 makes a frozen-key list part of network configuration, set by validator vote and visible on-chain. The CAP notes it could also be used for entries "known to be hacked", which is a real governance power to be aware of.
• CAP-78, 79, 80 and 82. Finer TTL extension controls, muxed-address conversion, nine more BN254 functions, and checked 256-bit arithmetic that returns an error on overflow instead of trapping.

Protocols 27, 28 and 29

Protocol 27 (July 2026) reworked how smart-contract accounts delegate signing. Protocol 28 (September 2026) let validators close a ledger with an empty transaction set to reduce close-time variance, and let many contracts share one upgradable executable. Protocol 29 (October 2026) is a security and stability release.

Protocol 27, Zipper, implemented CAP-71. Smart-contract accounts could already delegate authentication to other addresses, but simulation could not see through the delegation, so wallets had to build payloads by hand. CAP-71 adds host functions and a credential type that bundle delegated signers into one authorisation entry, plus address-bound credentials that stop a signature for one account being replayed for another that shares a key. SDF expects it to make "social recovery, delegated signing keys, modular multisig" practical. The old credential type stayed valid until Protocol 28.

Protocol 28, Adapter, contained three CAPs. CAP-83 lets validators vote to drop the transaction set from the ledger being agreed, which SDF says makes "ledgers close faster and reduce close time variance"; validators now need synchronised clocks. CAP-85 adds a contract executable that points to an entry managed by another contract, so a protocol running a "fleet" of identical contracts can upgrade them all atomically, Stellar's equivalent of the beacon-proxy pattern. CAP-86 adds helpers for symbol-keyed maps.

Protocol 29 was not on SDF's Software Versions page when we checked, but Horizon reported mainnet ledgers closing under protocol 29 on 2 October 2026. The stellar-core v29.0.0 release notes, published on 1 October, list changes including "Improve DEX offer crossing accuracy", "Don't count pool hops against limit", a lower maximum network message size and several fixes to how nodes handle peer messages. stellar-core's disclosure policy publishes security details 30 days after a fixing release, so expect a fuller account in early November.

What changed for users and developers

For users, the visible changes are lower and steadier contract fees, automatic restoration of archived contract data, and wallets that can create trustlines inside one transaction. For developers, the list is longer: parallel-safe scheduling, ZK primitives, delegated authentication, fleet upgrades, and SDK upgrades before every vote.

Change	Users	Developers
Module cache, in-memory state (P23)	Cheaper contract calls	Lower resource fees; no read-bytes fee for live state
Auto-restore (P23)	Fewer "archived entry" failures	No separate restore transaction
Unified events (P23)	Better history in wallets and explorers	One event stream for classic and Soroban
SAC trust (P26)	One-step onboarding to new assets	Contracts can create trustlines and fund new accounts
Entry freezing (P26)	Faster incident response, by validator vote	A network-level power over specific ledger keys
Delegated auth (P27)	Better smart wallets	New credential types; migration from the old one
Shared executables (P28)	Fleet-wide fixes land at once	Atomic upgrades; also a single point of control

The upgrades also carry costs that rarely make the announcement. Each one forces SDK and infrastructure upgrades on a deadline: Protocol 27's guide folded @stellar/stellar-base into @stellar/stellar-sdk, and older SDKs cannot decode data from newer protocols. Features like shared executables and entry freezing concentrate power, so it is worth asking any protocol you use whether it relies on them and who controls the switch. For fee mechanics after these changes, see Stellar fees explained; for auditing questions, see smart contract audits.

The takeaway

Stellar's 2025–2026 upgrades turned Soroban from a working contract platform into a faster, cheaper and more capable one, and the P23 archival bug showed that the process also carries risk. The bug was caught, contained and repaired within two weeks, by an upgrade that only touched entries nobody had yet restored. In 2026 feature upgrades have arrived every two to four months, with security releases in between; the useful habit is reading the CAPs, not just the headlines. For how all this fits into the wider ecosystem, see our Stellar DeFi guide.

Sources: Stellar developer docs, Software Versions (as of 1 October 2026); stellar-protocol CAP index and CAP-62 to CAP-86; SDF upgrade guides for Protocols 23, 26, 27 and 28 and the post on state-archival inconsistencies; stellar.org protocol-upgrades page; stellar-core GitHub release notes (v27.0.0, v28.0.0, v29.0.0) and security disclosure policy; Horizon mainnet ledger data, 2 October 2026.