Stellar 28: we read the upgrade, and here is what we found
By Andrés Peña Mellado
Stellar activated version 28 of its protocol on September 16. The documents let us see what changes, what could break, and which risks remain in the hands of those building on the network.
An upgrade announcement usually sends us looking for a date and new features. With Adapter, Stellar's version 28, there is another route: open the proposals and read their warnings.
The Stellar Development Foundation's announcement said the consensus improvement would happen underneath and that nothing needed to change to benefit from it. In the same paragraph, it warns that anyone consuming raw ledger data should review the breaking changes. The caveat was in the announcement.
A CAP, or Core Advancement Proposal, is the document used to propose a change to the Stellar protocol. It has an author, a date, a status, and a link to its public discussion. Adapter brings together three CAPs, with different consequences for those operating infrastructure and those writing contracts.
The upgrade guide published the schedule: a stable Stellar Core release on August 13, the testnet vote on August 27, and the mainnet vote on September 16. Both votes were scheduled for 17:00 UTC. There was more than a month to prepare for the upgrade.
CAP-83: voting before all transactions arrive
Validators can start voting while they receive the transaction set for the next ledger. CAP-83 lets them discard that set during the preparation phase if it takes too long or turns out to be invalid. Consensus can thus move forward when the data is slow to arrive.
The Security Concerns section describes a risk: a malicious validator could introduce invalid hashes and force an empty ledger to close after a delay.
The document also explains how it limits that attack. The attacker must win the leader election. In addition, the discarded value is recorded with its signature, allowing operators to identify the culprit and exclude it from their quorum.
CAP-85: upgrading a fleet of contracts at once
A protocol can deploy many copies of the same contract. If it upgrades them one by one, different code versions coexist for a time.
CAP-85 lets those contracts point to a code reference managed by another contract. Changing that reference upgrades the whole fleet at once. This is a form of the pattern known as a beacon proxy.
That capability requires trust in the administrator. The CAP warns that the administrator can change the executable and gain arbitrary access to the contracts that depend on it.
In its security section, the document advises against inheriting an externally managed implementation without examining that trust. It places the response in documentation and education: the protocol cannot impose trust relationships between contracts.
CAP-86: reading data whose structure has changed
An upgraded contract may need to add or remove fields from its data. Existing functions require the structure to match what is expected; if it changes, a read may fail.
CAP-86 adds functions for creating and unpacking sparse maps that allow missing or additional fields. Its motivation describes contracts that became unusable because of the restrictions of earlier functions.
It also leaves a warning: if a contract used that rejection as validation, its team must revisit that check when adopting the new functions. The previous functions keep their behavior. A protocol upgrade does not make every contract already deployed more permissive.
What changes for operators
CAP-83 introduces the STELLAR_VALUE_EMPTY_TX_SET type, whose txSetHash is 0x0. The guide distinguishes who needs to handle it:
Indexers, Galexie, and analytics systems consuming raw ledger data: recognize the new type and treat those ledgers as empty. Normal SDK-based integrations: this CAP-83 change does not require an adaptation. Custom account contracts: review the authorization context if they need to authorize the creation of contracts with a CAP-85 external reference.
For infrastructure, the guide called for installing the corresponding versions of Stellar Core, Horizon, RPC, and Galexie. It told validators to prepare their vote before September 9, with the upgrade scheduled for the 16th. That was a preparation instruction.
Validator operators must synchronize their clocks using NTP starting with Protocol 28. The feature that reduces ledger close time and its variation depends on that synchronization; without it, performance may deteriorate.
CAP-85 and CAP-86 are capabilities teams can choose to adopt. Teams that want to use them need to review their contracts and the updated SDK; they can remain compatible without adopting those new patterns.
What we can read in the performance figure
On September 16, Chainspect announced an average of more than 211 transactions per second over one hundred consecutive blocks. The announcement coincided with the day mainnet activation was scheduled.
On September 30, Chainspect's dashboard showed 217.4 transactions per second for “Max TPS (100 blocks).” That is the maximum recorded under its hundred-block metric. The number does not attribute the result to CAP-83.
CAP-83's Resource Utilization section expects greater throughput from faster consensus. The guide explains that parallel downloading of transaction sets starts disabled by default and is enabled gradually.
The discussions also leave changes in view
The three CAPs link to four public threads. In the CAP-86 thread, an objection to the function names ended with the choice of sparse_map_*. In the CAP-85 thread, participants discussed the conditions for the external reference and which operations it should allow.
CAP-83 links to two others. The thread on the SKIP value contains a concern about how much time an attacker might make the network lose. The thread on vote validation presents three alternatives and the author's preference for relaxing checks during preparation messages.
When those threads were read on September 30, comments on the first had no replies, and on the second only the author had posted. That difference matters when describing the process: publishing alternatives leaves reasoning available for inspection, even when no conversation appears beneath them.
CAP-83's security section does describe the invalid-hash attack and its mitigations. I see a connection to the concern in the SKIP thread, although the document does not identify that section as a response to the participant. The warning was written down; a reply in the thread does not appear.
What the schedule and the documents let us check
Anyone changing the rules of software other people use must give notice and document its risks. With Adapter, we can check the dates, the proposals, and the caveats before adopting its features. That is the minimum we can ask of an upgrade.
The same Chainspect dashboard recorded 94 validators and a Nakamoto coefficient of 4. That indicator estimates the minimum number of independent validators that would have to collude to compromise the network. It does not identify four specific operators here.
Access to the documents lets us review a change. How much control is distributed among those keeping the network running remains an open question when we read that figure.
