Foundation news
Stellar Zipper, Protocol 27 Upgrade Guide
Author
Stellar Development Foundation
Publishing date
This guide is designed to help businesses and developers prepare for Zipper, Protocol 27, by providing key dates and release information.
Stay up to date on any and all Zipper-related announcements on the Stellar Developer Discord, where the ecosystem coordinates and shares information about the upgrade.
Key dates
- June 5: Stellar Core stable release
- June 10: RPC and Galexie releases
- June 5-11: SDK releases
- June 12: Horizon release
- June 18, 2026: Testnet upgrade
- July 8, 2026: Mainnet upgrade vote
Protocol 27 releases
Below are up-to-date links to all available releases relevant to Protocol 27. Please make sure to upgrade your Stellar integration before the upgrades to prevent breakage! In general, check release notes for specific instructions and requirements, and unless otherwise indicated, opt for the “Latest Release.”
Stellar infrastructure
SDKs
What’s New in Zipper
The following is a brief summary of what’s included in Protocol 27.
Authentication delegation for custom accounts (CAP-0071-01)
What it does. Adds a first-class protocol mechanism for custom (smart contract) accounts to delegate their authentication logic to other addresses. Two new host functions are introduced: delegate_account_auth, which may be called inside a custom account’s __check_auth function to delegate authentication to a specified address, and get_delegated_signers_for_current_auth_check, which returns the list of delegated signer addresses populated in the current authorization entry.
A new credential type, SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES, allows all delegated signers and their (potentially nested) signatures to be bundled into a single authorization entry. This eliminates the need for a separate authorization entry per delegated signer, reducing transaction size and simplifying simulation. Delegation can be nested recursively, so any account—including ones with delegated signers of their own—can serve as a delegate.
The signature payload for this credential type uses a new ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS envelope, which explicitly binds the payload to the top-level account address, preventing cross-account signature replay.
Why it matters. The underlying capability—delegating authentication from a custom account to another address—already existed in the protocol, but only as an accidental side effect of the authorization framework design. In practice it was difficult to use: simulation required manually constructing inner authorization payloads and running multiple simulation passes; every delegated signer required its own authorization entry with its own nonce, increasing transaction cost; and forwarding authorization context to delegates bloated transaction size unnecessarily. Zipper makes delegation a proper, first-class feature that is dramatically simpler to implement correctly.
Who should care. Soroban developers building smart accounts—wallets, multisig schemes, account abstraction—will see the most direct benefit. Delegation goes from being a fragile workaround to a supported, efficient pattern. Transaction sizes shrink, simulation simplifies, and the boilerplate around payload construction largely disappears.
Developers following the broader account abstraction roadmap should also pay attention. CAP-0071-01 is explicitly foundational to CAP-0072, which adds contract-based authentication to classic Stellar (G-) accounts. The delegation mechanism introduced here is the same one that more visible features in future protocols will depend on.
End users and wallet holders benefit indirectly: cheaper transactions and more flexible account designs (social recovery, delegated signing keys, modular multisig) become practical to build.
Address-bound Soroban address credentials (CAP-0071-02)
What it does. Introduces SOROBAN_CREDENTIALS_ADDRESS_V2, a new credential type that uses the same ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS signature payload introduced in CAP-0071-01. Unlike the existing SOROBAN_CREDENTIALS_ADDRESS, the new payload explicitly includes the signer’s address, preventing replay attacks between accounts that share private keys when the invocation payload does not otherwise bind the signer address.
Clients have some time to adopt the new credential type after the Protocol 27 upgrade; there is no requirement to migrate immediately. The existing SOROBAN_CREDENTIALS_ADDRESS type remains valid until the Protocol 28 upgrade.
Why it matters. The existing credential type is safe for the vast majority of use cases—the vulnerability it closes is narrow, requiring both shared private keys across accounts and an invocation payload that doesn’t bind the signer address. This CAP closes that gap in a non-disruptive way, offering a migration path rather than forcing an immediate switch.
Who should care. Developers building applications where multiple accounts may share keys, or who want to adopt a more conservative security posture, should plan to migrate to SOROBAN_CREDENTIALS_ADDRESS_V2 after the Protocol 27 upgrade. For everyone else, this is a low-urgency improvement to be aware of.
Breaking Changes
CAP-0071-01 introduces two new host functions—delegate_account_auth and get_delegated_signers_for_current_auth_check—and a new credential type, SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES. These are additive changes; existing contracts and credential types remain valid.
CAP-0071-02 introduces SOROBAN_CREDENTIALS_ADDRESS_V2, a new credential type that uses an address-bound signature payload. The existing SOROBAN_CREDENTIALS_ADDRESS credential type remains valid for now, but you should start updating dependencies and use the appropriate wrappers to prepare. AddressV2 will replace V1 in Protocol 28, so you have until that upgrade to complete this migration.
@stellar/stellar-base is consolidating into @stellar/stellar-sdk, so it’s one package going forward. Anyone importing stellar-base directly should switch those imports to @stellar/stellar-sdk.
Changelog
- June 4, 2026: Initial draft published.