Protocol 28 is the version Pi ledgers are closing on
Pi Horizon still lists current protocol version 28. The first Protocol 28 ledger closed at 17:01:30 UTC on October 16, with the base fee and reserve unchanged.
Protocol 28 is the version Pi's public Horizon API is closing ledgers on. At 07:40:15 UTC on October 17, 2026, the root document at api.mainnet.minepi.com listed current_protocol_version, core_supported_protocol_version and supported_protocol_version at 28. history_latest_ledger was 29257900, closed at that same timestamp, on horizon_version 28.0.1-a70eb47f76985d372de3e59f4d75c7f8542752f7 and core_version stellar-core 28.0.1 (947aad8413c189d85504acf72207e85eeda9b021). The node-status page in the Pi Core Team repository does not describe an upgrade still in progress. It prints the ledger version from stellar-core's local info port and current_protocol_version from Horizon. The states it defines are catching up, syncing, synced or not running.
The chain's version field moved later than the software tag. Image organization-mainnet-v1.0-p28.0.1 was published on September 23, 2026. Ledger 29247354, the last to record protocol_version 27, closed at 17:01:25 UTC on October 16. Ledger 29247355, the first to record protocol_version 28, closed five seconds later, at 17:01:30 UTC. That is 23 days after the image was published. The root document does not mark the work complete. The status is the integer 28 on that ledger and on the three protocol fields.
What the boundary ledgers recorded
The last protocol-27 ledger carried six failed transactions and zero successful ones. The first Protocol 28 ledger carried two successful transactions, five failed transactions and two operations: a payment of 40.67 in the native asset, and one claim of a claimable balance. The claim record does not state an amount. Closes on either side of the boundary stayed five seconds apart, so those failures are not a halt. Horizon published no result code for them.
The header figures desks watch did not move with the version integer. Both boundary ledgers record base_fee_in_stroops of 100,000, base_reserve_in_stroops of 4,900,000, max_tx_set_size of 1,000 and total_coins of 100,000,000,000.0000000. Ledger 29257825, closed at 07:34:00 UTC on October 17, still showed those four figures, with protocol_version 28, three successful transactions and zero failed. An operator looking for a fee cut, a reserve change or a larger transaction set will not find it on the ledger that first recorded Protocol 28, or on that later morning ledger.
What the node image changed
The September 23 release notes are a binary swap. They move stellar-core from v27.1.0 to v28.0.1 and Horizon from v27.0.0 to v28.0.1. They say the release needs no data migration, no pg_upgrade and no schema work on first boot, and that a restart usually completes in under five minutes. They do not list application-layer features, and they do not give operators a calendar deadline.
"Pins match upstream stellar/quickstart's latest images.json. Build toolchains are unchanged: core still builds with clang-20/libc++-20 on ubuntu:24.04 and horizon on golang:1.25 (go.mod requires go 1.25)."
Piotr Bedlechowicz authored that September 1, 2026 commit. His GitHub profile lists no title. The commit pins v28.0.0. The tag operators are told to run, organization-mainnet-v1.0-p28.0.1, was published September 23 and pins v28.0.1. Protocol 28 in this repository is an upstream Stellar pin, not a separate machine the notes describe.
How operators should read the fields
The public Horizon queried here is already on those v28.0.1 binaries. Its horizon_version and core_version strings match the tag, and core_supported_protocol_version matches current_protocol_version at 28. The node-status note tells operators to read the same fields locally, from stellar-core on port 11626 and from Horizon on port 8000, rather than from a banner. A container still on organization-mainnet-v1.0-p27.1.0 is the gap those notes were written to close. The public root publishes no peer census.
A version integer often rewrites less than the label implies. Solana's 4,096-byte transactions are opt-in to send and leave older history in place. Polymarket's Protocol V2 will not auto-convert existing positions. Pi's notes are the same kind of negative: no schema migration. U.S. Bank's USBDC on Stellar uses the stellar-core family this image pins, so a custodian's question is which build is in the container.
What to check on the next ledger
The next reading is mechanical. If a later ledger changes base_fee_in_stroops, base_reserve_in_stroops or max_tx_set_size, that is a parameter change the first Protocol 28 ledger did not carry. If core_supported_protocol_version on the public Horizon rises above current_protocol_version, the binary is ahead of the chain again, which is where this image sat from September 23 until 17:01:30 UTC on October 16. The reverse, a current version above what the binary supports, would mean that deployment cannot follow the tip. Until one of those fields moves, Protocol 28 is a version integer on a chain that did not retune its fee, its reserve or its transaction-set cap in the ledger that first recorded it.
This article is informational analysis only and is not financial, investment, or trading advice. Cryptocurrencies are highly volatile and can lose substantial value rapidly. Past performance and historical patterns do not guarantee future results. Do your own research and consult a regulated financial adviser before making any investment decision.
Reporting by Karthik Subramanian. Filed 17 October 2026, 16:20 GMT.
Digital Assets Correspondent
Karthik Subramanian is a founder, writer, and technology consultant with nine years in the crypto ecosystem.
