Pi Network Protocol 27 on September 15: What Our Measurement on Mainnet and Testnet Shows

The Pi mainnet is running on protocol 26 on September 2, 2026. The first testnet has been on protocol 27 since August 20; the second testnet is still on 26 today. Specialist media name September 15, 2026 as the target date for moving the mainnet to protocol 27. We measured these three states ourselves this morning, and together they give a more precise picture than the date reports do.

For you one question matters above all: do you have to do anything? If you run a Pi node, the answer is yes, because at the previous jump nodes without a current version lost their connection to the mainnet. If you only hold Pi in the app, the answer is no, at any rate not for your balance. What you can check in either case, and how to read the network state yourself in a minute, is set out further down.

What protocol 27 changes at Pi Network and who is affected by the switch

Protocol 27 is the next version level of the Pi blockchain. According to the account by crypto.news, it brings more flexible procedures for authenticating smart contracts, a reworked RPC server infrastructure, liquidity pools on the automated market maker principle and an integrated order book. The specialist outlet names September 15, 2026 as the target for the mainnet and reports that the rollout on the first testnet began on August 21.

Three groups are affected, and they are affected to very different degrees. Node operators have to bring their software up to the matching level, otherwise the mainnet will no longer accept them. Developers building applications on Pi get new building blocks and have to check whether their code still works with the changed authentication rules. And the large majority, who merely hold Pi, have nothing to do with the process technically. Their balance hangs on a passphrase and on the chain, not on the version number of the node software.

How the previous jump played out is something we described when the deadline for protocol 26 on August 11 expired. This article picks up there and measures what actually happened at the time.

Protocol upgrade, node and ledger: the three terms in one sentence each

A protocol upgrade is the move of a blockchain to a new set of shared rules by which all participating computers verify transactions and close blocks. A node is a computer that runs these rules, writes along with the chain and helps to agree with the others on the next state. A ledger is at Pi what elsewhere is called a block: the consecutively numbered unit in which a batch of transactions is finally recorded.

The decisive point for this article: every closed ledger carries the number of the protocol version under which it came about. That makes the change not only announceable but determinable after the fact to the second. That is exactly what we did.

Our measurement of September 2: mainnet on protocol 26, testnet 1 on protocol 27

cryptoticker.io collected this data itself on September 2, 2026. The public interfaces of the three Pi networks were queried between 9:51 and 9:53 UTC.

The mainnet reports protocol 26 both as the current and as the highest supported version. The chain has therefore not stopped at an old level although it could already go further; the software running there simply does not yet know protocol 27. The jump requires a new software version on the nodes, and that has to be distributed beforehand.

Seven protocol jumps in five months: the measured dates of the Pi mainnet

We narrowed down the ledger history of the mainnet step by step and determined for each version level the first ledger that carries it. The result is a timeline that appears in no announcement in this form.

Two things stand out here. First, the Pi mainnet worked through seven version levels within barely five months, which is a very high pace for a productive chain. Second, the gap between the levels is irregular and fluctuates between two weeks and a month and a half. Anyone wanting to derive a fixed rhythm from the series will not find one. From August 13 to September 15 would be 33 days, which lies within the range observed so far but confirms no pattern.

No network halt at the last switches: what the ledger cadence shows

This is where the most reassuring finding for holders lies. We read out the gaps between the individual ledgers around the two most recent jumps, eight ledgers before and eight after in each case. At the move to protocol 25 on July 22 and at the move to protocol 26 on August 13, the largest measured gap was six seconds and the smallest five. Over a larger window of 10,000 ledgers between September 1 at 19:19 UTC and September 2 at 9:51 UTC, we arrive at an average of 5.23 seconds per ledger.

In plain terms: at neither switch did the chain stand still for a single second. The jump happened in ongoing operation, the ledger before it still carried the old version number, the ledger five seconds later the new one. That is remarkable, because it is by no means the normal case. At the Mesa hard fork of Mina, for instance, the network expressly stands still for a window of several hours, transactions included. Anyone expecting something like that at Pi is, on the experience so far, expecting the wrong thing.

One qualification belongs with this: two switches without interruption yield no guarantee for the third. According to the reporting, protocol 27 brings considerably more with it than its predecessors, among other things a trading function. It remains possible that a different approach is taken here. What has been measured so far is the opposite.

Protocol 26 took effect two days after the node deadline

The deadline for node operators at the previous jump fell on August 11; anyone who had not updated by then lost, according to the reporting, the connection to the mainnet until the update was made good. Our measurement dates the actual activation of protocol 26 to August 13, 16:51:43 UTC, ledger 28,187,462.

A good two days therefore lay between the deadline and the jump. That is no contradiction but the logical order: first a sufficient majority of the nodes has to run the new software, after which the chain can switch over. For you as a node operator, however, this means something concrete. The stated deadline is the date by which you have to be ready, and not the date on which something visibly changes. Anyone waiting on the cut-off day for an event in order to act then has already missed the moment.

A second time reference fits the picture: the post on node version 0.6.2 appeared on August 14 in the official Pi blog, one day after the measured activation.

Testnet 2 is still running on protocol 26: what that means for September 15

This is the finding we consider the most important, and it can be stated in one sentence: 13 days before the reported target date, the second test level is still on the old protocol version.

Pi operates two testnets. Testnet 1 is the first level on which developers and node operators try out a new version. Testnet 2 is the level before the mainnet on that path and closer to its conditions. According to the reporting, a run through both testnets was envisaged before the mainnet follows. Our query of September 2 shows protocol 27 for testnet 1, but for testnet 2 still protocol 26 and the same node software that also runs on the mainnet.

No failure can be derived from this, and we do not claim one. A good two weeks remain for the second test level, and if it is brought up promptly the target date is still reachable. It does mean, though, that the intermediate step the schedule provides for had not been taken at the time of our measurement. Anyone treating September 15 as settled should know this. As an early indicator this value serves well, because it can be retrieved free of charge at any time, and how that works is set out further down.

Where the September 15 date comes from and what the Pi blog says

September 15 is currently widely reported as the target date. We looked into what it rests on, and the finding deserves a careful formulation.

On the front page of the official Pi blog we found no post on September 2 that names protocol 26 or protocol 27 by name. The most recent post visible there on a protocol version dates from July 15, 2026 and announces protocol v25. It names July 22 as the date and calls on node operators to bring their node to v25 at the next opportunity in order to stay connected to the network. In substance it was about BN254 cryptography and Poseidon hashing, that is, building blocks for zero-knowledge applications.

For our purposes this post is doubly valuable. It is the only case in our measurement window in which a date stood publicly in advance, and it therefore allows a test of our method: July 22 was announced, and we measured July 22, 12:54:56 UTC. The measurement matches the announcement to the day. Conversely, though, the finding also means that September 15 was not, at the time of our check, secured in the same way as July 22 was back then. Whether it was proclaimed elsewhere, for instance in one of the in-app channels, we could not verify from outside. We therefore say only what we have seen, and we attribute an intention to no one.

What node operators should do now in concrete terms

If you run a Pi node, a manageable preparation follows from what has been measured.

1. Keep a current version. At the previous jump the deadline was two days before activation. Anyone who had already updated the node before the announced date was on the safe side without missing anything.
2. Watch the official channel, not the date reports. Before protocol v25 the announcement came a week before the jump. A comparable lead time would be the most usable signal this time too.
3. Keep an eye on testnet 2. If this level jumps to protocol 27, that is a strong indication that the mainnet will follow next. If it stays put, the date will probably shift.
4. Check your own reachability. The blog post on node version 0.6.2 of August 14 names an automatic port setup and a port checker as new features. Anyone familiar with connection problems should go through this before rather than after the switch.

The pattern, incidentally, is not specific to Pi. At other networks too, updating in good time decides whether a node keeps running; we described this most recently at the Alpenglow activation at Solana. Anyone running several nodes would sensibly stagger the update instead of restarting them all at the same time.

What Pi holders without a node need to check: passphrase, app version, custody

For the large majority the rule is: at a protocol change there is nothing to do. Your balance lies on the chain and hangs on your passphrase. The version number of the node software changes nothing about that, and there is no exchange, no registration and no cut-off date you could miss.

Three things are nevertheless worth a look, and that independently of the date. First, the passphrase. This sentence of words is the only access to your balance, it cannot be reset, and it does not belong in a photo, a notes app or a cloud. If you want to look into the differences between the forms of custody, the designs are set side by side in our comparison of software wallets.

Second, the app version. When new network functions arrive, an update of the application often follows, and outdated versions then display errors that are none.

Third, and this is the most important point: around every announced switch, attempted fraud accumulates. The pattern is always the same. Someone gets in touch as support, speaks of a necessary confirmation, a migration or a bonus, and wants to see the passphrase. There is no legitimate process in which anyone needs your passphrase. No protocol upgrade in the world demands it, because the chain knows nothing of you and your app. Whoever asks for it wants your balance.

And because the question comes up regularly at Pi: where and whether Pi can be traded at all is an entirely different matter from the protocol state, and the answer depends on the trading venue in question and on its authorization. If you are looking into that, it is worth a glance beforehand at which venues operate under regulation at all; our overview of crypto exchanges ranks the providers by authorization, fees and payout routes.

How to measure the network state yourself in a minute

You do not have to take any of this on trust. The interfaces our figures come from are public, need no registration and answer immediately. Call up the root address of the respective interface in your browser and look in the response for the field for the current protocol version. For the mainnet that is api.mainnet.minepi.com, for the testnets api.testnet.minepi.com and api.testnet2.minepi.com.

Four values are of interest. The current protocol version tells you which level the network is on. The highest supported version tells you whether the running software could already do more. The version of the node software reveals which software state is distributed. And the number of the last closed ledger with its timestamp shows whether the chain is currently running; if the time stands still for more than half a minute, something is going on.

On the day of the switch that is the fastest honest information you can get. This information manages without an intermediary, and it is not to be confused with what is claimed about it on social networks.

How we measured and what we could not measure

The method in one sentence: we queried the public interfaces of the three Pi networks on September 2, 2026 between 9:51 and 9:53 UTC and narrowed down the time of each version change to the individual ledger by successively halving the search range over the ledger history.

Objects checked: three networks, seven narrowed-down change times on the mainnet, one narrowed-down change time on testnet 1, two windows with 17 individually retrieved ledgers each for the cadence measurement, and one window over 10,000 ledgers for the average. In total around 200 individual queries. Each change time was additionally cross-checked against the preceding ledger, which in each case still carries the old version number.

What we could not check we name individually:

• The number of active nodes and how many of them are current. This information does not emerge from the public interfaces. The order of magnitude of around 421,000 active nodes named in the reporting comes from crypto.news and has not been re-measured by us.
• Whether September 15 is officially confirmed. We could only check publicly accessible pages. In-app announcements cannot be viewed from outside.
• Whether the switch takes place with or without interruption. We know the behavior of the last two jumps, not that of the coming one.
• What protocol 27 changes technically in detail. The list of functions comes from the reporting, not from our own examination of the code.

What we also did not do: no extrapolation, no statement on the price and no statement about individual addresses or accounts. Deliberately, nowhere in this article is there a euro or dollar figure, because none of them follows from our measurement.

Frequently asked questions about protocol 27 and the Pi node

As a pure Pi holder, do I have to do anything by September 15?

No. There is no exchange and no deadline for balances. Your holding hangs on your passphrase and remains untouched by this.

Does my node really lose the connection if I do not update?

At the previous jump that was the case according to the reporting, until the update was made good. A permanent loss of balance is not associated with it.

Does the chain stand still during the switch?

At the two jumps we measured in July and August it did not; there the cadence of five to six seconds per ledger continued unchanged. For the coming jump that is no assurance.

How do I recognize that the switch has taken place?

By the current protocol version that the public interface of the mainnet outputs. If it jumps from 26 to 27, it has happened.

Is September 15 a fixed date?

It is reported as a target date. At the time of our measurement the second test level was still on the old version, which makes a postponement possible.

Checking the Pi protocol 27 switch: what you take away from this

1. If you run a node, bring it up to date before the deadline and do not wait for a visible event. At the previous jump the deadline was two days before activation. If you also want to trade your Pi beyond that, you should clarify beforehand which venues offer this under regulation at all; our overview of crypto exchanges sorts them by authorization and cost.
2. If you only hold, do nothing and give your passphrase to no one. Around every switch, requests aimed at exactly that accumulate. How the various forms of custody differ is set out in our comparison of software wallets.
3. Check the network state yourself instead of believing date reports. The public interface answers the question in seconds and costs nothing. If you take the opportunity to reconsider your custody in general, the comparison of hardware wallets helps with placing it.

(As of September 2, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)