Skip to content
Blockchain Posts

protocol

Stellar Zipper (Protocol 27) activates on mainnet, ships Soroban auth delegation

Protocol 27 lands on Stellar mainnet on July 10, adding CAP-0071-01 authentication delegation for Soroban custom accounts and CAP-0071-02 address-bound credentials.

by 4 min read
protocolstellarsorobaninfrastructure

Stellar activated Protocol 27, codenamed Zipper, on mainnet on July 10, 2026, two days after validators voted the upgrade in. The release ships two Soroban authorization changes bundled under CAP-0071: CAP-0071-01, first-class authentication delegation for custom (smart contract) accounts, and CAP-0071-02, address-bound Soroban credentials that close a cross-account signature-replay window. The change lives in stellar-core v27.0.0; the developer-facing walkthrough is on the Stellar Foundation blog.

What activated

Zipper is a protocol-level change, not a client change: validators voted the network from Protocol 26 to Protocol 27 at the target ledger, and stellar-core binaries running v27.0.0 or later kept producing blocks. The upgrade advances a single CAP, CAP-0071, whose owner is Dmytro Kozhevin (@dmkozh). CAP-0071 is split into two sub-CAPs shipping together because they reuse the same authorization payload format while solving distinct protocol problems.

CAP-0071-01 — authentication delegation for custom accounts

Prior to Zipper, a Soroban custom account that wanted to defer signature checks to another address had to structure the deferral itself, one authorization entry per delegated signer. CAP-0071-01 makes delegation a protocol primitive.

Two new host functions land:

  • delegate_account_auth — called inside a custom account's __check_auth function, triggers the authentication check on a specified delegate address, reusing the same signature payload and authorization context as the primary account.
  • get_delegated_signers_for_current_auth_check — standardized read of the delegated signer chain for the auth check in progress.

A new credential type carries the payload: SorobanAddressCredentialsWithDelegates, which the CAP describes as bundling all delegated signers and their (potentially nested) signatures into a single authorization entry. The stated payoff is a reduction in transaction size and simpler simulation — every delegate no longer needs a separate authorization entry.

The mechanism is aimed at wallet designs where a smart-account owner wants to grant a hardware key, a session key, or a co-signer scoped authority without deploying a per-delegate account contract.

CAP-0071-02 — address-bound Soroban credentials

The second sub-CAP adds SOROBAN_CREDENTIALS_ADDRESS_V2, a Soroban credential variant whose signature payload explicitly includes the signer's address. Prior to Zipper, two accounts that shared a private key (deliberately or by operational accident — key reuse across custody stacks, multisig testing artifacts, HD-wallet path collisions) could see a signature on one account replayed against the other. The V2 payload binds the signature to the address, closing that narrow but reachable path.

The XDR envelope also gains ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS, distinguishing the new authorization envelope from the legacy path so callers can't mismatch by accident.

Release timeline

- stellar-core v27.0.0 tagged   : June 5, 2026 (protocol 27, CAP-0071 support)
- RPC and Galexie releases      : June 10, 2026
- SDK updates                   : June 5–11, 2026
- Horizon release               : June 12, 2026
- Testnet upgrade               : June 18, 2026
- Mainnet validator vote        : July 8, 2026
- Mainnet activation            : July 10, 2026
- CAP-0071                      : "Accepted"
- Sub-CAPs                      : CAP-0071-01, CAP-0071-02
- New host functions            : delegate_account_auth,
                                  get_delegated_signers_for_current_auth_check
- New credential types          : SorobanAddressCredentialsWithDelegates,
                                  SOROBAN_CREDENTIALS_ADDRESS_V2
- New envelope type             : ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS
- Reference: CAP-0071           : github.com/stellar/stellar-protocol
                                  /blob/master/core/cap-0071.md

Rate source for the version numbers and dates is the CAP text, the stellar-core v27.0.0 release, and the Stellar Foundation's upgrade guide.

What Zipper actually changes for developers

Two concrete deltas for anyone writing Soroban contracts today:

  1. Custom-account authors can stop hand-rolling delegation. The delegate-signer chain is a first-class type; simulation, fee estimation, and transaction size no longer scale with the number of delegated signers the way they did when each signer needed its own authorization entry.
  2. Any Soroban integrator that mints or reuses keys across accounts should target SOROBAN_CREDENTIALS_ADDRESS_V2 going forward. The pre-Zipper ADDRESS credential is not deprecated in the CAP text, but its lack of an address-bound payload is now an explicit protocol footnote rather than an oversight.

Custody stacks, wallet-as-a-service backends, and any deployment that scripts multisig test artifacts with shared private material are the specific integrations most exposed if they stay on the legacy credential type.

Pattern context — a busy protocol-upgrade week

Zipper lands in the same seven-day window as two other protocol releases we've covered on this site:

Three networks, three different kinds of upgrade — a scheduled hard fork on an EVM L2, a forced version bump after a consensus bug, and a scheduled Soroban authorization overhaul — inside a week. The pattern to watch is not the upgrades themselves but the auth-primitive layer each is shipping: Osaka opcodes on the EVM side, THORChain router V6 as the sole authorized cross-chain contract, and Zipper's delegated-and-address-bound credential model on Soroban. Each is a protocol-level admission that account authorization is the surface most integrators get wrong on their own.

Related stories