Protocolo 27 de Pi Network el 15 de septiembre: qué muestra nuestra medición en mainnet y testnet
La mainnet de Pi está el 2 de septiembre en el protocolo 26, la primera red de pruebas en el 27 y la segunda todavía en el 26. Hemos fechado con precisión de registro los siete saltos de protocolo de los últimos cinco meses y mostramos qué pueden leer en ellos los operadores de nodos y los tenedores.

Contenido de la tabla
Contenido de la tabla
La mainnet de Pi funciona el 2 de septiembre de 2026 con el protocolo 26. La primera red de pruebas está en el protocolo 27 desde el 20 de agosto; la segunda sigue hoy en el 26. Los medios especializados citan el 15 de septiembre de 2026 como fecha objetivo para el paso de la mainnet al protocolo 27. Estos tres estados los hemos medido nosotros mismos esta mañana, y juntos ofrecen una imagen más precisa que la que dan los avisos de calendario.
Para ti importa sobre todo una pregunta: ¿tienes que hacer algo? Si operas un nodo de Pi, la respuesta es sí, porque en el salto anterior los nodos sin una versión actualizada perdieron la conexión con la mainnet. Si solo tienes Pi en la aplicación, la respuesta es no, al menos no para tu saldo. Lo que puedes comprobar en ambos casos, y cómo consultar tú mismo el estado de la red en un minuto, figura más abajo.
Qué cambia el protocolo 27 en Pi Network y a quién afecta la actualización
El protocolo 27 es el siguiente nivel de versión de la cadena de bloques de Pi. Según la exposición de crypto.news, trae procedimientos más flexibles para la autenticación de contratos inteligentes, una infraestructura de servidores RPC revisada, así como reservas de liquidez conforme al principio del creador de mercado automatizado y un libro de órdenes integrado. El medio especializado cita el 15 de septiembre de 2026 como objetivo para la mainnet e informa de que el despliegue en la primera red de pruebas comenzó el 21 de agosto.
Hay tres grupos afectados, y lo están en grados muy distintos. Los operadores de nodos deben poner su software en el nivel adecuado; de lo contrario la mainnet deja de aceptarlos. Los desarrolladores que construyen aplicaciones sobre Pi reciben nuevas piezas y deben comprobar si su código sigue funcionando con las reglas de autenticación modificadas. Y la gran mayoría, que se limita a tener Pi, no tiene técnicamente nada que ver con el proceso. Su saldo depende de una frase de contraseña y de la cadena, no del número de versión del software del nodo.
Cómo transcurrió el salto anterior ya lo describimos cuando venció el plazo del protocolo 26 el 11 de agosto. Este artículo parte de ahí y mide qué ocurrió entonces realmente.
Actualización de protocolo, nodo y registro: los tres conceptos en una frase cada uno
Una actualización de protocolo es el paso de una cadena de bloques a un nuevo conjunto de reglas comunes conforme a las cuales todos los ordenadores participantes verifican transacciones y cierran bloques. Un nodo es un ordenador que ejecuta esas reglas, va escribiendo la cadena y ayuda a acordar con los demás el siguiente estado. Un registro es en Pi lo que en otros sitios se llama bloque: la unidad numerada de forma correlativa en la que un lote de transacciones queda inscrito de manera definitiva.
El punto decisivo para este artículo: cada registro cerrado lleva el número de la versión de protocolo bajo la que nació. Con ello el cambio no solo puede anunciarse, sino determinarse a posteriori al segundo. Eso es exactamente lo que hemos hecho.
Nuestra medición del 2 de septiembre: mainnet en el protocolo 26, testnet 1 en el protocolo 27
Este relevamiento lo realizó cryptoticker.io el 2 de septiembre de 2026. Se consultaron las interfaces públicas de las tres redes de Pi entre las 9:51 y las 9:53 UTC.
| Red | Versión de protocolo | Software del nodo | Último registro observado |
|---|---|---|---|
| Mainnet | 26 | stellar-core 26.1.0 | 28.512.793 a las 9:51:41 UTC |
| Testnet 1 | 27 | v27.1.0 | 26.453.289 a las 9:51:37 UTC |
| Testnet 2 | 26 | stellar-core 26.1.0 | 10.691.583 a las 9:53:24 UTC |
La mainnet declara el protocolo 26 a la vez como versión actual y como versión máxima admitida. La cadena no se ha quedado, por tanto, en un nivel antiguo pudiendo ya ir más lejos; el software que allí funciona sencillamente no conoce todavía el protocolo 27. El salto exige una nueva versión de software en los nodos, y esa versión debe haberse distribuido antes.
Siete saltos de protocolo en cinco meses: las fechas medidas de la mainnet de Pi
Hemos acotado paso a paso el histórico de registros de la mainnet y determinado, para cada nivel de versión, el primer registro que lo lleva. El resultado es una cronología que en esta forma no aparece en ningún anuncio.
| Salto | Primer registro con la nueva versión | Momento (UTC) | Distancia respecto al salto anterior |
|---|---|---|---|
| 19 a 20 | 25.716.716 | 17 de marzo de 2026, 4:29:22 | punto de partida de la serie |
| 20 a 21 | 26.168.108 | 13 de abril de 2026, 19:19:06 | 27 días |
| 21 a 22 | 26.448.657 | 30 de abril de 2026, 23:01:55 | 17 días |
| 22 a 23 | 26.805.815 | 22 de mayo de 2026, 12:11:18 | 21 días |
| 23 a 24 | 27.039.126 | 5 de junio de 2026, 13:52:03 | 14 días |
| 24 a 25 | 27.819.465 | 22 de julio de 2026, 12:54:56 | 47 días |
| 25 a 26 | 28.187.462 | 13 de agosto de 2026, 16:51:43 | 22 días |
Dos cosas llaman la atención. Primero, la mainnet de Pi ha despachado siete niveles de versión en algo menos de cinco meses, lo que constituye un ritmo muy alto para una cadena en producción. Segundo, la distancia entre los niveles es irregular y oscila entre dos semanas y mes y medio. Quien quiera deducir de la serie un ritmo fijo no lo encontrará. Del 13 de agosto al 15 de septiembre serían 33 días, cifra que se sitúa dentro del rango observado hasta ahora pero que no confirma ningún patrón.

Sin parada de la red en las últimas actualizaciones: lo que muestra la cadencia de registros
Aquí está el hallazgo más tranquilizador para quienes solo tienen Pi. Hemos leído las distancias entre los registros en torno a los dos saltos más recientes, ocho registros antes y ocho después en cada caso. En el paso al protocolo 25 el 22 de julio y en el paso al protocolo 26 el 13 de agosto, la mayor distancia medida fue de seis segundos y la menor de cinco. En una ventana más amplia de 10.000 registros, entre el 1 de septiembre a las 19:19 UTC y el 2 de septiembre a las 9:51 UTC, llegamos a una media de 5,23 segundos por registro.
En claro: en ninguna de las dos actualizaciones se detuvo la cadena ni un segundo. El salto se produjo en pleno funcionamiento; el registro anterior llevaba todavía el número de versión antiguo y el registro cinco segundos después, el nuevo. Es notable, porque en absoluto es lo habitual. En el hard fork Mesa de Mina, por ejemplo, la red se detiene expresamente durante una ventana de varias horas, transacciones incluidas. Quien cuente con algo así en Pi cuenta mal, según la experiencia habida hasta ahora.
Cabe una salvedad: de dos actualizaciones sin interrupción no se sigue garantía alguna para la tercera. Según la información publicada, el protocolo 27 trae bastante más que sus predecesores, entre otras cosas una función de negociación. Sigue siendo posible que aquí se proceda de otro modo. Lo medido hasta ahora dice lo contrario.
El protocolo 26 entró en vigor dos días después del plazo para los nodos
En el salto anterior el plazo para los operadores de nodos vencía el 11 de agosto; quien no había actualizado para entonces perdió, según la información publicada, la conexión con la mainnet hasta que recuperó la actualización. Nuestra medición fecha la activación efectiva del protocolo 26 el 13 de agosto, a las 16:51:43 UTC, registro 28.187.462.
Entre el plazo y el salto transcurrieron, pues, algo más de dos días. No es una contradicción, sino el orden lógico: primero una mayoría suficiente de los nodos debe ejecutar el nuevo software y después la cadena puede conmutar. Para ti como operador de nodo, sin embargo, esto significa algo concreto. El plazo señalado es la fecha para la que debes estar listo, y no la fecha en la que algo cambia de forma visible. Quien el día señalado espera un acontecimiento para actuar entonces ya ha dejado pasar el momento.
Una segunda referencia temporal encaja en el cuadro: la entrada sobre la versión de nodo 0.6.2 apareció el 14 de agosto en el blog oficial de Pi, un día después de la activación medida.
La testnet 2 sigue en el protocolo 26: qué significa eso para el 15 de septiembre
Este es el hallazgo que consideramos más importante, y puede decirse en una frase: 13 días antes de la fecha objetivo publicada, el segundo nivel de pruebas sigue en la versión de protocolo antigua.
Pi opera dos redes de pruebas. La testnet 1 es el primer nivel en el que desarrolladores y operadores de nodos prueban una nueva versión. La testnet 2 es el nivel siguiente camino de la mainnet y está más cerca de las condiciones de esta. Según la información publicada, estaba previsto un recorrido por ambas redes de pruebas antes de que siguiera la mainnet. Nuestra consulta del 2 de septiembre muestra el protocolo 27 para la testnet 1, pero para la testnet 2 sigue mostrando el protocolo 26 y el mismo software de nodo que funciona también en la mainnet.
De ahí no cabe deducir un fracaso, y tampoco lo afirmamos. Al segundo nivel de pruebas le quedan casi dos semanas y, si se pone al día con rapidez, la fecha objetivo sigue siendo alcanzable. Pero significa que el paso intermedio que prevé el calendario no estaba dado en el momento de nuestra medición. Quien dé por hecho el 15 de septiembre debería saberlo. Como indicador adelantado este valor sirve bien, porque puede consultarse gratis en cualquier momento, y cómo hacerlo figura más abajo.
De dónde procede la fecha del 15 de septiembre y qué dice el blog de Pi
El 15 de septiembre se publica ahora mismo de forma generalizada como fecha objetivo. Hemos comprobado en qué se apoya, y el hallazgo merece una formulación cuidadosa.
En la portada del blog oficial de Pi no encontramos el 2 de septiembre ninguna entrada que mencione por su nombre el protocolo 26 o el protocolo 27. La entrada más reciente visible allí sobre una versión de protocolo es del 15 de julio de 2026 y anuncia el protocolo v25. Cita como fecha el 22 de julio y pide a los operadores de nodos que lleven su nodo a la v25 en la primera ocasión para seguir conectados a la red. En cuanto al contenido, allí se trataba de criptografía BN254 y de hashing Poseidon, es decir, de piezas para aplicaciones de conocimiento cero.
Para nuestros fines esa entrada es doblemente valiosa. Es el único caso dentro de nuestra ventana de medición en que una fecha figuraba públicamente por adelantado, y permite por ello una prueba de nuestro método: se anunció el 22 de julio y hemos medido el 22 de julio, a las 12:54:56 UTC. La medición coincide con el anuncio hasta el día. A la inversa, el hallazgo significa también que el 15 de septiembre no estaba, en el momento de nuestra comprobación, respaldado por la misma vía que entonces el 22 de julio. Si se proclamó en otro lugar, por ejemplo en alguno de los canales internos de la aplicación, no hemos podido comprobarlo desde fuera. Por eso decimos únicamente lo que hemos visto, y no atribuimos intención a nadie.

Qué deberían hacer ahora en concreto los operadores de nodos
Si operas un nodo de Pi, de lo medido se desprende una preparación abarcable.
- Mantener una versión actualizada. En el salto anterior el plazo iba dos días por delante de la activación. Quien había actualizado el nodo antes de la fecha anunciada estaba del lado seguro sin perderse nada.
- Observar el canal oficial y no los avisos de calendario. Antes del protocolo v25 el anuncio llegó una semana antes del salto. Un preaviso comparable sería también esta vez la señal más aprovechable.
- No perder de vista la testnet 2. Si ese nivel salta al protocolo 27, es un indicio fuerte de que la mainnet seguirá a continuación. Si se queda atrás, la fecha probablemente se desplazará.
- Comprobar la propia accesibilidad. La entrada del blog sobre la versión de nodo 0.6.2, del 14 de agosto, cita como novedad una configuración automática de puertos y un verificador de puertos. Quien conozca problemas de conexión debería repasarlo antes de la actualización y no después.
El patrón, por cierto, no es específico de Pi. También en otras redes la actualización a tiempo decide si un nodo sigue en marcha; lo describimos en último lugar a propósito de la activación de Alpenglow en Solana. Quien opera varios nodos hace bien en escalonar la actualización en vez de reiniciarlos todos a la vez.
Qué deben comprobar los tenedores de Pi sin nodo: frase de contraseña, versión de la aplicación, custodia
Para la gran mayoría rige lo siguiente: en un cambio de protocolo no hay nada que hacer. Tu saldo está en la cadena y depende de tu frase de contraseña. El número de versión del software del nodo no cambia nada de eso, y no hay canje, ni registro, ni fecha límite que pudieras dejar pasar.
Tres cosas merecen aun así una mirada, y con independencia de la fecha. Primero, la frase de contraseña. Esa serie de palabras es el único acceso a tu saldo, no puede restablecerse y no tiene sitio en una foto, en una aplicación de notas ni en una nube. Quien quiera detenerse en las diferencias entre las formas de custodia encontrará los formatos contrapuestos en nuestra comparativa de wallets de software.
Segundo, la versión de la aplicación. Cuando llegan nuevas funciones de red suele seguir una actualización de la aplicación, y las versiones desfasadas muestran entonces errores que no lo son.
Tercero, y este es el punto más importante: en torno a cada actualización anunciada se multiplican los intentos de estafa. El patrón es siempre el mismo. Alguien se presenta como soporte, habla de una confirmación necesaria, de una migración o de una bonificación, y quiere ver la frase de contraseña. No existe ningún proceso legítimo en el que alguien necesite tu frase de contraseña. Ninguna actualización de protocolo del mundo la exige, porque la cadena no sabe nada de ti ni de tu aplicación. Quien la pide va a por tu saldo.
Y como la pregunta surge con regularidad en Pi: dónde y si los Pi pueden negociarse siquiera es un asunto muy distinto del estado del protocolo, y la respuesta depende de la plataforma concreta y de su autorización. Si te ocupas de ello, conviene mirar antes qué plataformas trabajan reguladas; nuestro panorama de los exchanges de criptomonedas ordena a los proveedores por autorización, comisiones y vías de retirada.
Cómo medir tú mismo el estado de la red en un minuto
No tienes por qué creernos nada. Las interfaces de las que proceden nuestras cifras son públicas, no requieren registro y responden de inmediato. Abre en el navegador la dirección raíz de la interfaz correspondiente y busca en la respuesta el campo de la versión de protocolo actual. Para la mainnet es api.mainnet.minepi.com; para las redes de pruebas, api.testnet.minepi.com y api.testnet2.minepi.com.
Interesan cuatro valores. La versión de protocolo actual te dice en qué nivel está la red. La versión máxima admitida te dice si el software en marcha ya podría más. La versión del software del nodo revela qué estado de software se ha distribuido. Y el número del último registro cerrado, con su marca de tiempo, muestra si la cadena está funcionando; si la hora se detiene más de medio minuto, algo está pasando.
El día de la actualización esa es la información honesta más rápida que puedes obtener. Esa información prescinde de intermediarios y no debe confundirse con lo que se afirma al respecto en las redes sociales.
Cómo hemos medido y qué no hemos podido medir
El método en una frase: hemos consultado las interfaces públicas de las tres redes de Pi el 2 de septiembre de 2026 entre las 9:51 y las 9:53 UTC y hemos acotado el momento de cada cambio de versión hasta el registro concreto, dividiendo sucesivamente por la mitad el intervalo de búsqueda sobre el histórico de registros.
Objetos comprobados: tres redes, siete momentos de cambio acotados en la mainnet, un momento de cambio acotado en la testnet 1, dos ventanas con 17 registros consultados uno a uno cada una para la medición de la cadencia, así como una ventana de 10.000 registros para la media. En total, alrededor de 200 consultas individuales. Cada momento de cambio se contrastó además con el registro anterior, que en cada caso lleva todavía el número de versión antiguo.
Lo que no hemos podido comprobar lo señalamos uno por uno:
- El número de nodos activos y cuántos de ellos están actualizados. Ese dato no se desprende de las interfaces públicas. El orden de magnitud de unos 421.000 nodos activos citado en la información publicada procede de crypto.news y no ha sido medido por nosotros.
- Si el 15 de septiembre está confirmado oficialmente. Solo hemos podido comprobar páginas de acceso público. Los anuncios internos de la aplicación no son consultables desde fuera.
- Si la actualización se producirá con o sin interrupción. Conocemos el comportamiento de los dos últimos saltos, no el del próximo.
- Qué cambia el protocolo 27 en detalle a nivel técnico. La enumeración de funciones procede de la información publicada, no de una revisión propia del código.
Tampoco hemos hecho lo siguiente: ninguna extrapolación, ninguna afirmación sobre el precio y ninguna afirmación sobre direcciones o cuentas concretas. En todo el artículo no figura conscientemente ningún importe en euros o dólares, porque ninguno se desprende de nuestra medición.
Preguntas frecuentes sobre el protocolo 27 y el nodo de Pi
Como mero tenedor de Pi, ¿tengo que hacer algo antes del 15 de septiembre?
No. No hay canje ni plazo para los saldos. Tu posición depende de tu frase de contraseña y no se ve afectada.
¿Pierde de verdad mi nodo la conexión si no actualizo?
En el salto anterior así fue, según la información publicada, hasta que se recuperó la actualización. No lleva aparejada una pérdida permanente de saldo.
¿Se detiene la cadena durante la actualización?
En los dos saltos que hemos medido, en julio y en agosto, no; allí la cadencia de cinco a seis segundos por registro continuó sin cambios. Para el salto que viene eso no es una garantía.
¿En qué noto que la actualización ha tenido lugar?
En la versión de protocolo actual que publica la interfaz pública de la mainnet. Si salta de 26 a 27, ya ha ocurrido.
¿Es el 15 de septiembre una fecha firme?
Se publica como fecha objetivo. En el momento de nuestra medición el segundo nivel de pruebas seguía en la versión antigua, lo que hace posible un aplazamiento.
Comprobar la actualización al protocolo 27 de Pi: lo que te llevas de aquí
- Si operas un nodo, ponlo al día antes de la fecha y no esperes a un acontecimiento visible. En el salto anterior el plazo iba dos días por delante de la activación. Si además quieres negociar tus Pi, aclara antes qué plataformas lo ofrecen reguladas; nuestro panorama de los exchanges de criptomonedas las ordena por autorización y costes.
- Si solo tienes Pi, no hagas nada y no des tu frase de contraseña a nadie. En torno a cada actualización se multiplican las solicitudes dirigidas justo a eso. En qué se diferencian las distintas formas de custodia está en nuestra comparativa de wallets de software.
- Comprueba tú mismo el estado de la red en lugar de creer los avisos de calendario. La interfaz pública responde a la pregunta en segundos y no cuesta nada. Si aprovechas la ocasión para replantearte a fondo tu custodia, la comparativa de carteras hardware ayuda a situarla.
(2 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)
Nota de transparencia: Este artículo se elaboró con ayuda de inteligencia artificial y fue revisado por nuestra redacción antes de su publicación. Todas las cifras y afirmaciones se contrastaron con las fuentes primarias enlazadas en el texto. La imagen destacada fue generada con IA.































