Protocol upgrade
Track the complete record of all Pi Network protocol upgrades.
Pi Network's Mainnet protocol version does not update automatically, nor is it a one-time operation. Each upgrade follows a fixed process: first, a deadline for node software updates, followed by the actual switch of the Mainnet on-chain protocol version. There is usually a gap of several days to several weeks between these two events.
This page compiles the upgrade patterns and mechanisms observed by OrbitWatch during its tracking from V21 to V28.
Two Phases of the Upgrade Process
Each Pi Network protocol upgrade is divided into two independent phases:
Phase One: Node Software Update The official announcement sets a node deadline, requiring all node operators to complete software updates within the specified period. For nodes using Pi Desktop (Windows/macOS), this process is automatic—the software automatically pulls the new Docker image and switches to running the new container. The completion of the node software update does not mean the Mainnet protocol version has switched.
Phase Two: Mainnet Protocol Version Switch The Mainnet's protocol_version will only officially switch after a sufficient proportion of nodes have completed their software updates. Pi Network adopts the Stellar Consensus Protocol (SCP), where nodes reach consensus through mutually trusted quorum slices—this mechanism dictates that the protocol version cannot be forcibly switched by a single node; it requires the entire network to be ready.
The usual observed sequence is:
Node Deadline
↓ (a few days later)
Testnet 2 switches to the new version first
↓ (a few more days later)
Mainnet protocol_version officially switches
Testnet 2 switching first is a signal of successful technical verification, with the Mainnet following closely.
Complete Timeline of Past Upgrades
OrbitWatch has tracked a complete record of each upgrade starting from V21:
Version Node Deadline Mainnet Switch Date Gap Key Content
V21 — 2026/4/29 — Infrastructure (before OrbitWatch launch)
V22 2026/4/27 2026/4/30 3 days PiRC1 framework effective
V23 2026/5/19 2026/5/22 3 days Full Soroban smart contract support
V24 2026/6/2 2026/6/5 3 days Automatic migration system optimization, node stability
V25 2026/6/18 2026/7/22 34 days BN254 encryption, Poseidon hash
V26 2026/8/11 2026/8/14 3 days Contract security, state management, interoperability enhancement
V27 2026/9/15 2026/9/22 7 days Improved Smart Contract Authentication capabilities
V28 2026/10/13 2026/10/16 — Transaction data delay processing, batch upgrade smart contract groups (scheduled, not yet occurred)
The three upgrades from V22 to V24 followed a very consistent pattern: the Mainnet switch was completed within 3 days after the node deadline. V26 also continued this rhythm.
V25 is currently the only clear exception. Nearly two weeks after the deadline, the node software automatically pulled the v25 container (around 6/27-6/28); the actual switch of the Mainnet protocol version was only completed on the officially announced scheduled date (7/22), a full 34 days after the deadline. The official blog on 7/15 explained that v25 introduced BN254 encryption and Poseidon hash, making it a technically more complex upgrade than previous ones.
When the V26 deadline (8/11) was announced, the official team unusually published a separate announcement on X, characterizing V26 as a “major milestone” and explaining that improvements included contract security, state management, interoperability, and encryption-related capabilities, while also calling V27 the “final planned upgrade.” V26 ultimately completed its Mainnet switch within 3 days after the deadline, returning to the previous normal rhythm.
Before the V27 deadline (9/15) was confirmed, the node side had already taken action: a corresponding release (organization-mainnet-v1.0-p27.1.0) had been published on GitHub, and Testnet 1 was confirmed to have switched to v27. The node documentation initially only provided the deadline without technical explanations; it wasn't until 8/21 that the official team formally posted within the Pi App, adding specific details: Protocol 27 brings more flexible and secure mechanisms for smart contract authentication, allowing accounts and applications to authorize transactions in more advanced ways, continuing Pi's work to expand smart contract capabilities. OrbitWatch observed the Mainnet officially switching to v27 via the Horizon API on 9/22, 7 days after the deadline, a slightly longer gap than the 3-day pattern of V22-V24 and V26, but significantly shorter than V25's 34 days. On 9/25, the official team formally confirmed the completion of the V27 Mainnet upgrade on X, consistent with OrbitWatch's observations.
It's also worth noting that the V24 node deadline was postponed twice: originally scheduled for 5/25 → 5/31 → finally set for 6/2. Deadline adjustments are not uncommon during Pi's upgrade process, and OrbitWatch observed these changes directly from the official node upgrade documentation each time, rather than through formal announcements.
Planning did not stop at V27. The official team previously referred to V27 as the “final planned upgrade,” and the node upgrade path later showed a step from 27.1 → 28.x, but without a deadline or technical details, only marked TBD. On 9/25, in the same announcement confirming V27's completion, the official team simultaneously announced that Testnet had been upgraded to Protocol 28 and released the full schedule: node deadline 10/13, Mainnet target date 10/16. The official team explained that V28 improves how the network handles transaction data delays and allows developers to upgrade an entire group of smart contracts at once, enabling safer changes to stored data during application evolution.
Why Do Delays Sometimes Occur?
According to OrbitWatch's observations, at least two factors influence the length of the time gap:
Technical Complexity. V23 introduced full Soroban smart contract support, and V25 introduced BN254 encryption and Poseidon hash—upgrades involving new protocol-level capabilities like these require more time for verification than simple infrastructure enhancements (e.g., V24, V26).
Node Readiness Rate. The official team issues reminders after the deadline, indicating that not all nodes complete updates by the deadline. The Mainnet switch requires waiting for a sufficient proportion of nodes to be ready, a proportion that has not been publicly disclosed by the official team.
Important Premise: The above are possible reasons inferred from observations; the official team has not provided specific technical explanations for any delays. OrbitWatch refrains from further speculation on uncertain parts.
What Do Node Operators Need to Do?
For node operators using Pi Desktop (Windows/macOS): Software updates are usually automatic and do not require manual intervention. You can use the docker images command to check the version of the currently running container and confirm if the new image has been pulled.
Version updates for the Pi Node software itself (e.g., 0.6.0, 0.6.1, 0.6.2, 0.6.3) are separate from protocol version upgrades. The former is a functional update to the node application, while the latter is a switch of the on-chain protocol version; the two do not interfere with each other.
How to Confirm the Current Mainnet Protocol Version?
The most direct way is to query the Horizon API:
https://api.mainnet.minepi.com/ledgers?order=desc&limit=1
The protocol_version field in the returned result indicates the current protocol version running on the Mainnet.
You can also directly check the Pi Network Block Explorer: 👉 blockexplorer.minepi.com
OrbitWatch's Horizon API monitoring automatically checks every 15 minutes and will publish an update article immediately after a protocol version switch.
Upgrade Tracking Record for Each Version
| Version | Key Content | Status | OrbitWatch Tracking Article |
|---|---|---|---|
| V21→V22 | PiRC1 framework effective | ✓ Completed | Node running v22, but chain still v21 · V22 Confirmed Switch |
| V22→V23 | Full Soroban smart contract support | ✓ Completed | V23 Deadline Update · Testnet 2 Switched · V23 Confirmed Switch |
| V23→V24 | Automatic migration system optimization, node stability | ✓ Completed | V24 Deadline Update · Testnet 2 Switched · V24 Confirmed Switch |
| V24→V25 | BN254 encryption, Poseidon hash (basis for zero-knowledge applications) | ✓ Completed | V25 Upgrade Announcement · Deadline Observation · Nodes Ready · Official Announcement 7/22 · V25 Confirmed Switch |
| V25→V26 | Contract security, state management, interoperability enhancement | ✓ Completed | Official Confirms V26: major milestone · Nodes and Testnet2 Ready, Mainnet still v25 · V26 Confirmed Switch |
| V26→V27 | Improved Smart Contract Authentication capabilities | ✓ Completed | GitHub release and Testnet 1 switch, deadline confirmed 9/15 · Nodes ready, Testnet2/Mainnet still pending · V27 Confirmed Switch |
| V27→V28 | Transaction data delay processing, batch upgrade smart contract groups, safer stored data changes | Officially announced, node deadline 10/13, Mainnet target 10/16 | Official Confirms V27 Completion, Simultaneously Announces V28 |
Data sources: Pi Network Horizon API (api.mainnet.minepi.com), Pi Network Block Explorer, direct observation of Pi Network node interface, Pi Network official announcements, Pi Network node upgrade documentation. All analysis does not constitute investment advice. OrbitWatch is an independent Pi Network ecosystem observer and is not affiliated with the official Pi Network team.
Key Points
- •Pi Network protocol upgrades are a two-phase process: first, a deadline for node software updates, followed by the actual Mainnet protocol version switch, typically with a gap of several days to weeks.
- •The Mainnet switch, based on Stellar Consensus Protocol, requires a sufficient proportion of nodes to be updated and is usually preceded by a Testnet 2 switch as a technical validation signal.
- •Observed delays in Mainnet switching (e.g., V25's 34-day gap) are attributed to factors like technical complexity of the upgrade and the overall node readiness rate.