Pi Network moved its mainnet ledger from Protocol 27 to Protocol 28 on October 16, according to public records from its Horizon interface. The change is visible between two consecutive ledgers, providing a direct record of activation rather than relying only on a software release or an upgrade announcement.
Ledger 29,247,354 closed at 17:01:25 UTC with protocol version 27. The next ledger, 29,247,355, closed five seconds later at 17:01:30 UTC with version 28. The records establish when the network began closing ledgers under the newer protocol.
That is a narrower and more useful finding than assuming every feature mentioned in discussions about the upgrade is now available to users. A protocol version identifies rules in use by the network; individual applications and services still need separate evidence of deployment.
The activation did not change every ledger setting
The two boundary records show the same headline values for the base fee, base reserve and maximum transaction-set size. Both list a base fee of 100,000 stroops, a base reserve of 4,900,000 stroops and a maximum transaction-set size of 1,000.
Those unchanged fields do not support a claim that activation immediately cut the network’s base fee or raised that transaction-set limit. They also do not establish that every internal behavior remained identical: the protocol version changed, while these particular settings did not.
That distinction matters when upgrades are promoted through broad descriptions of faster or cheaper transactions. A claim about capacity, fees or execution needs evidence relevant to that specific measure. The appearance of a new version number alone is insufficient.
A software release and an activated protocol are different events
Node software can support a newer protocol before the network begins using it. Operators may need updated binaries in advance so that their nodes can follow the chain when the activation occurs. A download becoming available is therefore not the same event as the first ledger closed under the new rules.
Here, the consecutive records provide an observable boundary. They establish the transition at a particular time without requiring an inference from the date of a release tag or a discussion of an expected deadline.
The first Protocol 28 ledger records two successful and five failed transactions, with two operations. Those counts describe that ledger only. They are not a network-wide success rate, and failed transactions in a closing ledger do not by themselves establish that the chain halted.
What users can conclude
The verified development is that Protocol 28 became active on mainnet. The boundary records do not establish the launch of a new exchange, a new application or a change in the market price of PI. Those would be separate developments requiring their own records.
For node operators, software compatibility and the ability to remain synchronized are practical concerns around any protocol transition. For application users, the relevant follow-up is whether the services they use document changes that affect their transactions.
The activation gives both groups a concrete starting point: October 16 at 17:01:30 UTC. Claims about what became possible after that time should be checked against the relevant software documentation and live service behavior.