Pi Network afirma tener 300 aplicaciones en la Mainnet. ¿Cuántas se usan realmente?

Pi Network ha puesto un nuevo recuento de aplicaciones en el centro de su primera cumbre del ecosistema. Se informa de más de 300 aplicaciones de Mainnet junto con una audiencia declarada de más de 60 millones de Pioneros comprometidos, 18,1 millones de personas que superaron las verificaciones de identidad y más de 420.000 nodos. Ninguna de esas cifras mide el uso repetido de una aplicación ni el valor de los bienes y servicios pagados con PI. La cumbre ofrece una nueva razón para examinar qué es una aplicación de Mainnet y qué puede mostrar su registro público.

Pi Network ha dicho que existen más de 300 aplicaciones de Mainnet mientras se prepara para una cumbre de desarrolladores en noviembre, añadiendo un nuevo recuento publicado a sus afirmaciones sobre el tamaño de su ecosistema.

En un anuncio del 15 de octubre, el proyecto programó su primera Cumbre del Ecosistema Pi para el 17 al 19 de noviembre. Dijo que el evento en línea incluiría lanzamientos de plataforma, demostraciones de desarrolladores, exhibiciones de socios y aplicaciones, y detalles de otro hackathon. Su declaración dio el total de 300 aplicaciones, pero no proporcionó un directorio de todas las aplicaciones contadas, el uso por aplicación, los usuarios que pagan o el valor de las transacciones atribuibles a ellos.

La cumbre pone un recuento en la capa de aplicaciones

La declaración de Pi describe una red de distribución existente con más de 60 millones de Pioneros comprometidos, autenticación, pagos y descubrimiento de aplicaciones. Cita por separado más de 18,1 millones de usuarios totalmente verificados con KYC y más de 420.000 nodos. Esas medidas tienen unidades diferentes. Un nodo es un participante de la infraestructura, un usuario verificado es una persona que superó un proceso declarado, y una aplicación de Mainnet es software asociado con la red en vivo. Ninguno de los tres es automáticamente un cliente que paga de uno de los otros dos.

El anuncio ofrece un objetivo de auditoría oportuno. Un recuento de más de 300 es lo suficientemente grande como para examinar categorías, pero la declaración pública no proporciona un inventario con marca de tiempo y una definición consistente para la inclusión. Las aplicaciones podrían aceptar pagos en PI, usar autenticación sin pagos, proporcionar información, alojar un juego o conectarse a herramientas de desarrollo. Un directorio de aplicaciones actual podría mostrar solo un subconjunto seleccionado. Informar de las 300 como 300 negocios activos añadiría hechos que el proyecto no reclamó.

Esto es distinto del reciente calendario de protocolo de la red. Un artículo sobre el Protocolo 28 examinó la preparación de los nodos antes de la activación planificada de Mainnet del 16 de octubre. Nombró actualizaciones de contratos y manejo de datos de transacciones como cambios técnicos. El nuevo anuncio de la cumbre trata sobre el inventario de aplicaciones y lo que los desarrolladores han construido. Una actualización exitosa de nodos no establece que una aplicación listada tenga clientes que pagan.

También es diferente del embudo de KYC. Un análisis previo del backlog de verificación de Pi separó a los usuarios autorizados para progresar de las billeteras que realmente gastaron PI. El recuento de aplicaciones añade otra etapa: debe haber software disponible, accesible y que valga la pena volver a usar. Despejar un cuello de botella de identidad y añadir una aplicación son ambos eventos observables. Una transacción de un usuario activo es un tercer evento, que requiere un registro separado.

El programa de la cumbre podría mejorar la evidencia. Pi promete demostraciones de herramientas de desarrollo específicas y aplicaciones de socios. Una demostración puede mostrar que una función se ejecuta, mientras que pagos repetidos durante semanas mostrarían un uso continuo. El anuncio no se compromete a publicar la retención a nivel de aplicación ni los recibos de comerciantes durante el evento. Un inventario de aplicaciones y ejemplos de pagos reproducibles permitirían a los lectores evaluar el recuento antes de cualquier total promocional posterior.

El despliegue en Mainnet y el listado en el directorio son puertas separadas

La guía de lanzamiento para desarrolladores de Pi describe cómo un creador pasa de Testnet a Mainnet. El desarrollador crea una aplicación Mainnet separada en el portal, verifica su URL, conecta una billetera de aplicación y completa una lista de verificación. Una billetera multifirma entrante para pagos de usuario a aplicación requiere una solicitud y revisión. Los pagos de aplicación a usuario están disponibles solo para aplicaciones Testnet y aplicaciones Mainnet seleccionadas según la redacción actual de la guía. Por lo tanto, la decisión de un desarrollador de crear una entrada en Mainnet no significa que todas las posibles rutas de pago estén activas.

Las reglas de listado en el directorio imponen otra puerta. Para aparecer en la Interfaz del Ecosistema Mainnet curada de Pi Browser, se espera que una aplicación sea funcional, integre la autenticación de Pi, cumpla con los requisitos de identidad para su desarrollador y siga las políticas sobre transacciones y experiencia de usuario. Una aplicación puede existir en Mainnet sin ser aceptada en ese listado curado. La propia actualización anterior de Pi sobre aplicaciones añadidas dice que la lista no incluye todas las aplicaciones Mainnet o listas para Mainnet y que los directorios de terceros pueden mostrar más.

Esa diferencia proporciona una forma directa de probar el número de la cumbre. Si Pi dice que hay más de 300 aplicaciones Mainnet, ¿significa entradas en el portal con una configuración Mainnet activa, aplicaciones con billeteras aprobadas, aplicaciones listadas en el navegador, o un conjunto más amplio que incluye servicios autoalojados? El anuncio de octubre no lo dice. Un reportero no puede sustituir el recuento visible del navegador por la cifra del proyecto sin antes demostrar que ambos aplican la misma regla de inclusión.

La distinción no es una acusación de que la cifra sea falsa. Los directorios de productos a menudo seleccionan un conjunto más pequeño que el universo total de software implementado. Pi describe explícitamente esa práctica. El problema periodístico es la reproducibilidad. Una lista fechada con identificadores de aplicaciones, estado y capacidades de pago permitiría a un lector independiente replicar el total. Sin ella, el recuento sigue siendo una cifra reportada por la empresa, útil como afirmación sobre la escala pero débil como medida del uso continuo.

Una aplicación podría cumplir con los requisitos de calidad y políticas y aun así recibir poco tráfico. A la inversa, una aplicación independiente no listada podría atraer usuarios. La inclusión en el directorio es una decisión de selección; el tráfico y las transacciones son registros de comportamiento. La función de staking del directorio de Pi añade otra complicación: los Pioneros y las empresas pueden apostar PI para mejorar la posición de una aplicación en la Interfaz del Ecosistema. Pi dijo que la apuesta puede aumentar la exposición y las impresiones, con potencial tráfico de usuarios. Una clasificación más alta en el directorio es en parte función de la promoción apostada y no puede por sí sola verificar la demanda orgánica.

El anuncio de staking identifica aplicaciones Mainnet, aplicaciones de App Studio y servicios como intercambios centralizados entre las categorías del directorio. Esta mezcla significa que un analista debe filtrar la interfaz antes de tratar cada mosaico como una aplicación Mainnet. También dificulta la comparación entre categorías: un enlace a un exchange, un experimento de creador y una aplicación con una billetera Mainnet aprobada pueden mostrarse cerca unos de otros mientras sirven a propósitos diferentes.

La capacidad de pago es una medida más estrecha que la existencia de la aplicación

Pi añadió soporte de App Studio para aplicaciones Mainnet y pagos en la aplicación en vivo en marzo. Su declaración del Día Pi dijo que cuatro aplicaciones de App Studio habían sido invitadas a hacer la transición a Mainnet e integrar pagos reales en PI. La misma publicación explicó las interacciones de pago persistentes, que pueden dejar una función comprada activa más allá de una sola sesión. Cuatro es un recuento de aplicaciones de App Studio invitadas en ese momento, no el número total de aplicaciones Mainnet en toda la red.

Una actualización anterior de App Studio de enero describió la integración de pagos con tokens de prueba. Permitía a los creadores experimentar sin mover PI real entre usuarios y aplicaciones. Comparar un prototipo de pago de prueba con una compra Mainnet completada confundiría la actividad simulada con la económicamente significativa. Para octubre, las herramientas de App Studio se habían ampliado, pero el anuncio de la cumbre no informó el número de pagos reales realizados a través de sus productos.

La ruta de pago Mainnet es observable en principio. Un usuario autoriza una transferencia, la aplicación procesa la devolución de llamada y un libro mayor registra la transacción PI liquidada. La cadena pública puede revelar un pago a una billetera conocida, pero una dirección de billetera por sí sola puede pertenecer a un desarrollador, un exchange, una prueba interna o un usuario común. Para medir la demanda del consumidor, el operador de la aplicación necesitaría identificar su dirección de recepción de producción y divulgar lo suficiente sobre su servicio para distinguir las ventas de autotransferencias, incentivos o movimiento repetido de las mismas monedas.

Un recuento de tarifas o pagos puede inducir a error en cualquier dirección. Una aplicación podría ganar unos pocos pedidos grandes de comerciantes, mientras que otra ejecuta miles de pequeñas acciones pagadas. El PI bruto transferido no es ingreso neto si los usuarios reciben reembolsos o recompensas. Una aplicación con suscripciones podría tener una fuerte retención y menos transferencias individuales. Carteras pagadoras recurrentes, compradores distintos, compras completadas y el período medido harían más sólida la comparación. El proyecto no publicó estos cuatro campos para sus más de 300 aplicaciones en el anuncio de la cumbre.

La biblioteca de pagos de Pi promete una integración rápida para desarrolladores que usan pilas web compatibles. Su guía para desarrolladores de enero describió una forma de añadir funcionalidad de pago en menos de diez minutos. Integrar el código es un hito técnico, no evidencia de que los clientes posteriormente compraran un servicio. La distinción es visible en muchas redes de pago: aceptar un instrumento y generar comercio son resultados diferentes.

Algunas aplicaciones pueden ser valiosas sin cobrar PI. Una utilidad puede usar la autenticación de Pi para servir a usuarios verificados, proporcionar información o conectar a Pioneros con actividad externa. La cumbre podría razonablemente mostrar dicho software. Sería inexacto tratar la ausencia de un pago en cada aplicación como prueba de que la aplicación no tiene usuarios. La métrica correcta debe coincidir con el producto: sesiones repetidas para una herramienta gratuita, pedidos completados para un comerciante, implementaciones activas para un servicio de desarrollador o conversiones pagadas para una aplicación cuyo modelo de negocio las requiera.

Una auditoría debe mantener cuatro denominadores separados

Las cifras publicadas pueden colocarse en una tabla de medición simple sin dividir cantidades dispares. Los más de 60 millones de Pioneros comprometidos de Pi describen la audiencia más amplia que afirma tener. Sus más de 18,1 millones de usuarios verificados describen a personas que pasan KYC. Sus más de 300 aplicaciones de Mainnet describen software. Sus más de 420.000 nodos describen infraestructura de red. Una ratio de adopción válida requeriría el número de usuarios distintos de una aplicación especificada durante un período definido, dividido por una población elegible claramente definida. Pi no proporcionó ese numerador en el anuncio.

Dividir 18,1 millones de personas verificadas entre 300 aplicaciones daría aproximadamente 60.333 personas por aplicación bajo el supuesto artificial de una asignación uniforme. La aritmética utiliza los mínimos redondeados del proyecto y no es una medida de la audiencia de ninguna aplicación. La misma persona puede usar múltiples aplicaciones o ninguna, y una aplicación puede atraer a un grupo mucho más pequeño que el promedio teórico. Informar el cociente como "usuarios por aplicación" sería un error numérico, no un análisis original. El hallazgo significativo es que ningún puente publicado conecta el grupo de usuarios reportado con la actividad de la aplicación.

Un método mejor solicitaría una exportación fechada del inventario de más de 300 aplicaciones y etiquetaría cada entrada por etapa. Para cada una, registrar si tiene una URL funcional, autenticación Pi, aprobación de cartera Mainnet, una dirección de pago divulgada, pagos PI completados durante una ventana especificada y una medida de usuarios recurrentes distintos. Los operadores podrían negarse a divulgar información privada de clientes; los recuentos agregados y las transacciones públicas aún podrían permitir una verificación útil. El ejercicio expondría la brecha entre el alcance posible y el uso real del servicio sin asumir que todas las aplicaciones son idénticas.

El inventario debe marcar si la aplicación está curada en Pi Browser o autoalojada a través de SoloHost. Pi dice que SoloHost permite a los desarrolladores lanzar aplicaciones de IA autoalojadas, y su anuncio de octubre agrupa ese producto con su plataforma de desarrollador. Un servicio que se ejecuta en un nodo puede ser una aplicación en el sentido ordinario del software sin ser una aplicación web con una cartera de pago Mainnet. Combinar esas categorías puede ser defendible si Pi dice cómo las cuenta. Hasta entonces, una auditoría independiente debería preservar sus estados separados.

Las reglas del directorio de Pi ofrecen otra verificación. Requieren transacciones solo de Pi para las aplicaciones que buscan la lista relevante de Mainnet, mientras que el proyecto ha discutido por separado un posible rol de stablecoin en otra parte de su ecosistema. La función OUSD documentó que no se había especificado ninguna integración de pago lanzada ni mecanismo de demanda de tokens. Un cambio futuro en las reglas de listado de aplicaciones o una excepción limitada requeriría una actualización de política fechada. El anuncio de la cumbre en sí no revisa la página actual del directorio ni convierte a OUSD en un método de pago de aplicaciones existente.

Cinco aplicaciones listadas muestran lo que el recuento principal oculta

Una actualización anterior de Pi ofrece un pequeño ejemplo con nombre de cómo el proyecto selecciona aplicaciones. Anunció cinco adiciones a la Interfaz del Ecosistema Mainnet, incluido un juego de serpientes, aplicaciones de comercio electrónico y servicios de información sobre el token PI. Pi dijo que esas cinco pasaron las verificaciones de calidad, funciones completas, utilidad y cumplimiento de políticas. El ejemplo prueba que el directorio curado puede admitir diferentes tipos de software. No revela con qué frecuencia se abrió cada una ni cuánto gastó alguien en ellas.

Clasificar los cinco por su función declarada es más útil que tratar su inclusión como un único resultado económico. Un juego puede registrar sesiones frecuentes pero pocos pagos. Un sitio de información puede leerse sin ninguna transferencia de tokens. Una aplicación de comercio podría mostrar pedidos brutos, pedidos reembolsados, recibos de comerciantes y compradores recurrentes. Incluso dentro del grupo pequeño, no hay una única métrica que convierta el recuento de cinco en demanda de PI. El ejemplo muestra por qué el inventario más amplio de más de 300 necesita tipos de aplicaciones antes de que se pueda interpretar un número agregado de uso.

Pi advirtió explícitamente en esa actualización que su listado de Mainnet omitía muchas aplicaciones de terceros. Una aplicación rechazada o no enviada no es necesariamente inutilizable. El proyecto distingue la selección de directorio de la disponibilidad más amplia, y los directorios externos pueden mostrar más candidatos. Una instantánea independiente del navegador podría, por lo tanto, establecer el recuento de mosaicos visibles en una fecha, pero no puede confirmar el número total de aplicaciones activas. Conciliar los dos requeriría el inventario del portal para desarrolladores o una metodología publicada por Pi.

La cuestión de qué califica como listo para Mainnet complica aún más una auditoría. Un desarrollador puede preparar una billetera y una URL mientras espera la aprobación de los pagos entrantes; una aplicación puede ejecutar un servicio que no requiere pagos en absoluto. El proyecto podría contar una configuración funcional de Mainnet antes de que un curador la liste. Un campo de estado para aprobaciones de pago, último acceso exitoso y despliegue en producción haría visibles estas distinciones sin publicar datos privados de los clientes. Pi no ha proporcionado esa tabla campo por campo con su lanzamiento de la cumbre de octubre.

Hay una línea de tiempo útil en el material oficial. El lanzamiento de App Studio en enero comenzó con interacciones de pago con Test-Pi. La actualización de marzo invitó a cuatro creaciones seleccionadas hacia la capacidad de pago en Mainnet. Más tarde, la documentación para desarrolladores amplió lo que los constructores podían hacer con almacenamiento local, compartir archivos y datos de staking específicos de la aplicación. El anuncio de la cumbre de octubre presenta más de 300 aplicaciones en Mainnet. Los endpoints describen poblaciones diferentes, por lo que restar cuatro de 300 no calcularía el número de nuevas aplicaciones de pago. Una línea de tiempo limpia preserva lo que cada cifra contaba en el momento en que se publicó.

Una cobertura anterior del primer año de red abierta de Pi describió App Studio entre los principales productos públicos del proyecto. La afirmación de octubre se refiere a un inventario posterior. Cualquier comparación con el primer año debe usar la misma definición de aplicación y evitar importar un total anterior de KYC o migración al presente. Una retrospectiva puede establecer cuándo apareció una característica; no llena la serie faltante de usuarios activos de octubre.

El mejor argumento a favor de Pi se trata de una audiencia lista

Pi ha reunido verificaciones de identidad, billeteras, una ruta de descubrimiento basada en navegador, herramientas de pago de aplicaciones y una gran base de participantes declarada. Un desarrollador que construye un producto útil puede potencialmente distribuirlo a través de canales existentes en lugar de adquirir cada usuario de forma independiente. Más de 300 aplicaciones en Mainnet reportadas pueden significar que muchos equipos ya han hecho el trabajo de preparar software para la red en vivo. La cumbre promete mostrar sus productos y lanzar herramientas adicionales. Ninguno de esos hechos debería borrarse simplemente porque faltan cifras públicas de retención.

El caso escéptico es igualmente concreto. La distribución no obliga a un usuario a volver a una aplicación. KYC verifica la identidad del titular de una cuenta bajo el proceso del proyecto; no muestra que esa persona tenga PI discrecional, necesite un producto dado o complete una compra. Las clasificaciones de directorio pueden reflejar staking para promoción. Las herramientas de creación de aplicaciones pueden elevar los recuentos de experimentos más rápidamente que los recuentos de negocios con clientes recurrentes. Estas son razones para solicitar registros de uso, no razones para asumir que las aplicaciones han fallado.

Una cobertura anterior de la economía de App Studio examinó los costos que enfrentan los creadores y señaló que las presentaciones de hackathon no son lo mismo que los productos activos. La cumbre actual presenta otro hackathon y más características para desarrolladores. Un recuento de presentaciones después del evento mediría la participación en ese concurso. La proporción que luego llega a Mainnet, permanece en línea y recibe usuarios recurrentes mediría un resultado más exigente.

Un operador podría hacer medible el caso positivo publicando un informe de cohorte. Identifique las aplicaciones listadas antes de una fecha elegida, luego divulgue cuántas siguen funcionando 30 y 90 días después y cuántas tienen usuarios distintos que regresan o pagan. Un informe comparable un trimestre después revelaría si las nuevas herramientas para desarrolladores ayudan a las aplicaciones a retener usuarios, no solo a lanzarse. Pi no ha prometido tal informe para noviembre. La ausencia de una promesa debe declararse claramente, sin convertir una solicitud de informe en un entregable anunciado.

Existen límites prácticos para la observación independiente. Pi Browser puede requerir una cuenta, KYC o permisos de la aplicación. Las etiquetas de las billeteras no siempre son públicas. Un explorador de bloques puede mostrar transacciones sin mostrar por qué ocurrieron. Un reportero externo puede verificar aplicaciones nombradas, contratos públicos y transacciones de ejemplo, pero no puede inferir cada sesión privada de usuario a partir de una cadena. Por lo tanto, una auditoría completa puede permanecer parcialmente dependiente de las divulgaciones de desarrolladores y proyectos. La separación más importante es entre lo que se reprodujo de forma independiente y lo que Pi o un equipo de aplicación informaron.

Una posible muestra de auditoría podría comenzar con las cinco aplicaciones que el propio proyecto nombró en su actualización anterior. Un reportero registraría si cada URL carga ahora, si el inicio de sesión funciona, si la función ofrecida se puede completar y si se solicita un pago. Una segunda pasada después de 30 días verificaría si las mismas funciones siguen operando. Eso sería una prueba directa de disponibilidad para cinco aplicaciones nombradas, no una estimación para las 300. Ampliar la muestra requiere un marco de muestreo completo, que la publicación cumbre no proporciona.

Para una aplicación que afirma tener ventas, el operador podría divulgar una dirección de billetera y un período durante el cual se usó exclusivamente para recibos de producción. Un reportero podría entonces calcular remitentes distintos y el total de PI recibido del libro mayor, mientras declara que los depósitos de intercambio, las transferencias de desarrolladores y los reembolsos aún pueden distorsionar esos recuentos. Una transferencia bancaria o de intercambio no se puede asignar a una compra de cliente sin evidencia adicional. Para un servicio gratuito, el operador podría divulgar agregados de usuarios activos y retención que preservan la privacidad. Diferentes métodos, etiquetados honestamente, son preferibles a una única puntuación de "adopción" no respaldada.

El modelo de negocio de la aplicación también determina si PI está involucrado en absoluto. Las herramientas de desarrollo de Pi ofrecen inicio de sesión, descubrimiento y pagos como capacidades separables. Un creador puede usar las dos primeras sin la tercera. La afirmación "más de 300 aplicaciones" podría ser completamente precisa mientras solo un subconjunto tiene una billetera de pago aprobada para transferencias reales. La invitación de Pi en marzo a cuatro creaciones de App Studio demuestra una ruta de aprobación más estrecha para una categoría, pero no dice nada concluyente sobre cuántas aplicaciones codificadas de forma independiente aceptan pagos hoy.

Noviembre puede revelar productos, pero no años de retención

El evento del 17 al 19 de noviembre está programado como una cumbre en línea, no como una fecha en la que se garantice que cada función anunciada entre en producción. Pi dice que proporcionará actualizaciones de la plataforma, demostraciones de desarrolladores, exhibiciones de socios y aplicaciones, y más información sobre un hackathon. Una presentación puede demostrar una herramienta funcionando en un entorno controlado. Una herramienta implementada y una aplicación que la usa con clientes son etapas posteriores y verificables por separado.

Si una aplicación nombrada publica una dirección de billetera de producción y muestra una transacción que un lector puede reproducir, el artículo puede establecer una capacidad particular. Si publica un mes de datos de billeteras pagadoras distintas con reembolsos y pruebas excluidas, el artículo puede discutir el uso. Si solo ofrece una demostración en video, el artículo debería llamarlo demostración. Estas clasificaciones son informes de productos ordinarios, no un estándar especial impuesto a Pi.

El anuncio del proyecto no informa una fecha de lanzamiento común para las más de 300 aplicaciones, su tiempo de actividad o la proporción que acepta pagos PI. Sí nombra las fechas de la cumbre y los temas que pretende cubrir. La próxima agenda publicada y las aplicaciones específicas seleccionadas para demostraciones son los documentos inmediatos que pueden reducir la brecha entre la afirmación de 300 aplicaciones y el uso observable.

Qué observar

• Inventario de aplicaciones: Una lista de Pi con fecha que define qué aplicaciones componen el total reportado de más de 300.
• Estado de producción: Aplicaciones nombradas con URL de Mainnet funcionales, carteras aprobadas y transacciones en vivo reproducibles.
• Uso repetido: Divulgaciones del desarrollador o de la red sobre usuarios recurrentes distintos durante un período específico de 30 o 90 días.
• Pagos: Compras de PI completadas separadas de acciones de Testnet, incentivos, reembolsos y transferencias internas.
• Lanzamientos de la cumbre: La agenda del 17 al 19 de noviembre, herramientas implementadas y reglas del hackathon, cada una con un estado fechado.

Preguntas frecuentes