Stellar Protocol 27 'Zipper' Is Live: What Authentication Delegation Means for Developers

On July 9, 2026, Stellar validators activated Protocol 27, codenamed "Zipper," on mainnet. The upgrade introduces native authentication delegation at the protocol level, a change that simplifies how wallets, multisig setups, and smart contract accounts interact with the network.

This article covers what changed, why it matters, and how developers should adapt.

Key Takeaways

Protocol 27 "Zipper" went live on Stellar mainnet on July 9, 2026, after a validator vote on July 8.

The primary feature is native authentication delegation: one Stellar account can authorize another to act on its behalf at the protocol level.

A security fix binds signer addresses into credential payloads, preventing replay attacks between accounts that share private keys.

Protocol 27 lays the foundation for Protocol 28, which will introduce contract-based authentication for standard Stellar accounts.

Wallet developers and payment applications should review their transaction signing flows for compatibility.

What Changed in Protocol 27

Protocol 27 introduces two changes to how Stellar handles authentication:

1. Native Authentication Delegation

Before Protocol 27, if Account A wanted Account B to submit transactions on its behalf, the typical approach was to add Account B as a signer on Account A. This worked but had limitations: it required modifying Account A's signer list, managing weight thresholds, and handling cleanup when delegation was no longer needed.

Protocol 27 adds a delegation primitive directly into the transaction envelope. Account A can now create a delegation credential that grants Account B specific transaction-signing authority without modifying signer lists.

Before Protocol 27	After Protocol 27
Add signer to account	Create delegation credential
Manage weight thresholds	Specify delegation scope
Remove signer to revoke	Credential expires or is revoked
Permanent until removed	Time-bounded by design

2. Credential Payload Security Fix

Protocol 27 also fixes a subtle security issue. In previous versions, authentication payloads did not bind the signer's address into the credential. This meant that if two accounts happened to share the same private key (an unusual but possible scenario), a signed payload from one account could theoretically be replayed against the other.

The fix ensures that every credential payload now includes the signer's address, making cross-account replay impossible.

What Authentication Delegation Enables

Social Recovery Wallets

Users can designate trusted contacts as recovery delegates. If a user loses access to their primary key, the recovery delegate can authorize a key rotation transaction. The delegate never gains unrestricted access to funds; their authority is scoped to specific operations.

Simplified Multisig

Traditional multisig on Stellar requires all signers to be added to an account upfront. With delegation, a primary account holder can grant time-limited signing authority to a second party for a specific transaction. This is useful for:

Corporate accounts where different team members need temporary signing authority

Escrow arrangements where a third party needs to release funds under specific conditions

Automated systems that need to act on behalf of a user account

Account Abstraction

Protocol 27 is the first step toward full account abstraction on Stellar. Account abstraction means an account's authentication logic can be defined by a smart contract rather than a fixed set of cryptographic keys. Protocol 28 is expected to complete this by allowing standard Stellar accounts to use contract-based authentication.

Protocol 27: Delegation credentials (foundation)
Protocol 28: Contract-based auth for standard accounts (planned)

Developer Impact

Transaction Envelope Changes

Developers building on the Stellar SDK should be aware that Protocol 27 introduces new fields in the transaction envelope. If you are constructing or parsing raw XDR, your code needs to handle the updated envelope format.

The JS SDK v16 includes support for Protocol 27 transaction formats. If you are using an older SDK version, upgrade before constructing transactions that use delegation.

Wallet Applications

If your application manages Stellar accounts on behalf of users, review how you handle:

Key management: Delegation credentials can reduce the number of scenarios where users need to expose their primary key

Transaction signing flows: Your UI may need to display delegation permissions before users approve

Session management: Time-bounded delegation credentials can replace long-lived API key patterns

Smart Contract Developers

Soroban contract developers do not need to make immediate changes. However, Protocol 28's contract-based authentication will likely require contracts that interact with user accounts to support new authentication flows. Reviewing the Protocol 27 delegation model now will prepare your contracts for the next upgrade.

The Upgrade Process

The Stellar network uses a validator voting mechanism for protocol upgrades. The process for Protocol 27 was:

Development and testing: Protocol 27 was tested on Stellar's testnet for several weeks prior to the mainnet vote

Validator vote: On July 8, 2026, validators voted to adopt Protocol 27

Activation: The upgrade went live on mainnet on July 9, 2026

Compatibility: All nodes running Core v21+ support Protocol 27

No action is required from users or token holders. The upgrade is backward-compatible with existing accounts and transactions that do not use delegation features.

What Comes Next: Protocol 28

Protocol 28 is expected to build on Protocol 27's delegation infrastructure by introducing contract-based authentication for standard Stellar accounts. This would allow:

Custom authentication logic defined in Soroban contracts

Multi-factor authentication at the protocol level

Programmable spending policies (daily limits, approved recipients)

Hardware wallet integration without specialized transaction types

Protocol 28 does not yet have a confirmed timeline. The Stellar Development Foundation (SDF) has indicated it is in active development.

Risks and Considerations

SDK compatibility: Applications using older Stellar SDKs should test against Protocol 27 testnet before relying on delegation features in production

Delegation scope: Developers must carefully define the scope of delegation credentials. Overly broad delegations could expose accounts to unintended operations

Key hygiene: The security fix for shared private keys is important but edge-case. Most applications will not encounter this scenario in practice

How to Test

Developers can test Protocol 27 features on Stellar's testnet:

# Stellar testnet already runs Protocol 27
# Use the testnet Horizon API to test delegation
curl https://horizon-testnet.stellar.org/

The Stellar Laboratory has been updated to support Protocol 27 transaction construction.

Sources: Stellar Foundation blog: Protocol 27 Upgrade Guide, CryptoWisser: Zipper Protocol 27 Is Now Live on Stellar Mainnet, Stellar Developer Documentation

Related Resources

Stellar Horizon API for Developers for endpoint documentation

Soroban RPC API for smart contract interaction

Stellar API Provider Comparison to evaluate infrastructure options