Stellar Protocol 27 "Zipper": What Developers Need to Prepare Before the July Mainnet Vote

Stellar Protocol 27, codenamed "Zipper," is the next major network upgrade. SDF published the developer preparation guide on June 4, 2026, and the testnet is already running the new protocol. The mainnet validator vote is expected in July. If you have an application on Stellar, here is what you need to know and do before that vote happens.

What Is Protocol 27

Protocol upgrades on Stellar happen through validator consensus. A supermajority of validators must vote to adopt a new protocol version before it goes live on mainnet. Protocol 27 follows the Protocol 22 "Yardstick" upgrade pattern, which went through testnet validation before a mainnet vote.

Each protocol upgrade can introduce new transaction types, change fee structures, modify resource limits, or alter how the ledger processes operations. "Zipper" focuses on several areas that directly affect how developers build and deploy applications.

Key Changes in Protocol 27

1. Soroban Resource Model Updates

Protocol 27 adjusts the resource pricing model for Soroban smart contracts:

Resource	Protocol 26	Protocol 27	Impact
CPU instructions limit	100M per tx	150M per tx	Larger contracts can execute
Read bytes limit	200KB per tx	300KB per tx	More state access per call
Write bytes limit	65KB per tx	100KB per tx	Larger state mutations
Events size limit	8KB per tx	16KB per tx	Richer event data

These changes mean contracts that were hitting resource limits can now execute. If you were splitting operations across multiple transactions to stay under limits, you may be able to consolidate.

2. State Archival Improvements

State archival determines how long contract data persists on the network. Protocol 27 introduces:

Cheaper TTL extensions: Extending the time-to-live of persistent storage entries costs less

Batch TTL operations: Extend TTL for multiple keys in a single operation

Archival status queries: New RPC method to check if entries are archived

// New in Protocol 27: batch TTL extension
const tx = new StellarSdk.TransactionBuilder(account, { fee: '100' })
  .addOperation(StellarSdk.Operation.extendFootprintTtl({
    ledgersToExtend: 500000,
    // Can now include multiple keys in one operation
  }))
  .setTimeout(30)
  .build();

3. Transaction Throughput

Protocol 27 increases the per-ledger transaction capacity:

Classic transactions: From 100 to 150 per ledger

Soroban transactions: From 20 to 30 per ledger

Effective TPS increase: ~50% more throughput at the consensus level

This is part of SDF's roadmap toward 5,000 TPS. Each protocol upgrade incrementally raises the ceiling while validators confirm network stability.

4. Fee Market Adjustments

The fee market for Soroban transactions gets a smoother surge pricing curve:

Fees increase more gradually under load (less spiking)

Minimum fees for resource-heavy transactions decrease slightly

Fee estimation via simulateTransaction becomes more accurate

SDK Changes You Need to Make

JavaScript SDK

Update to the latest version:

npm install @stellar/stellar-sdk@latest

Key changes:

New extendFootprintTtl options for batch operations

Updated resource estimation in simulateTransaction responses

New fields in transaction result metadata

Python SDK

pip install stellar-sdk --upgrade

Breaking Changes

Change	What Breaks	Fix
Resource limit increases	Nothing (limits go up)	No action needed
Fee estimation changes	Hardcoded fee values	Use `simulateTransaction` instead
New result metadata fields	Strict parsers may fail	Update parsing logic
TTL extension API	Old single-key API still works	Optional: migrate to batch API

Testing on Testnet

The testnet is already running Protocol 27. Test your application now:

const TESTNET_HORIZON = 'https://horizon-testnet.stellar.org';
const TESTNET_RPC = 'https://soroban-testnet.stellar.org';

// Verify protocol version
const res = await fetch(`${TESTNET_HORIZON}/ledgers?limit=1&order=desc`);
const ledger = (await res.json())._embedded.records[0];
console.log('Protocol version:', ledger.protocol_version);
// Should show 27 on testnet

What to Test

Transaction submission: Ensure your transactions still succeed

Fee estimation: Verify simulateTransaction returns correct fees

Resource usage: Check if your contracts use the new resource limits

Event parsing: Verify your event listeners handle any new fields

Error handling: Test failure modes with the new protocol behavior

Timeline

Date	Event
June 4, 2026	SDF publishes Protocol 27 developer guide
June 2026	Testnet running Protocol 27
July 2026 (expected)	Mainnet validator vote
After vote	Protocol 27 live on mainnet

What Happens During the Vote

SDF proposes the upgrade to validators

Validators review and signal readiness

A supermajority (67%+) must vote yes

Once approved, the upgrade activates at the next ledger boundary

All nodes must be running compatible software

If you run a Stellar Core validator or Horizon node, you must upgrade your software before the vote. Running outdated software after the vote will cause your node to fall out of sync.

Impact on LumenQuery Users

If you are using LumenQuery's Horizon API or Soroban RPC:

No action required for most users: LumenQuery will upgrade infrastructure before the mainnet vote

New resource limits: Your contracts may be able to do more per transaction

Fee changes: If you hardcode fees, switch to dynamic estimation

New RPC methods: Will be available through LumenQuery's RPC gateway after upgrade

Checklist Before the Vote

[ ] Update Stellar SDK to latest version

[ ] Test application on testnet with Protocol 27

[ ] Replace any hardcoded fee values with dynamic estimation

[ ] Update transaction result parsers for new metadata fields

[ ] If running a node: upgrade Stellar Core and Horizon

[ ] Review Soroban contracts for resource limit changes

[ ] Test TTL extension operations if using state archival

*Stay ahead of protocol upgrades. LumenQuery manages infrastructure upgrades so you can focus on your application. Start free.*