Pi Network afirma ter 300 apps na Mainnet. Quantos estão realmente sendo usados?

A Pi Network colocou uma nova contagem de aplicativos no centro de sua primeira cúpula do ecossistema. Mais de 300 aplicativos da Mainnet são relatados ao lado de uma audiência alegada de mais de 60 milhões de Pioneiros engajados, 18,1 milhões de pessoas que passaram por verificações de identidade e mais de 420.000 nós. Nenhuma dessas figuras mede o uso repetido de um aplicativo ou o valor de bens e serviços pagos com PI. A cúpula fornece uma nova razão para examinar o que é um aplicativo da Mainnet e o que seu registro público pode mostrar.

A Pi Network disse que existem mais de 300 aplicativos da Mainnet enquanto se prepara para uma cúpula de desenvolvedores em novembro, adicionando uma nova contagem publicada às suas alegações sobre o tamanho de seu ecossistema.

Em um anúncio de 15 de outubro, o projeto agendou sua primeira Cúpula do Ecossistema Pi para 17 a 19 de novembro. Disse que o evento online incluiria lançamentos de plataforma, demonstrações de desenvolvedores, vitrines de parceiros e aplicativos, e detalhes de outro hackathon. Sua declaração deu o total de 300 aplicativos, mas não forneceu um diretório de todos os aplicativos contados, uso por aplicativo, usuários pagantes ou valor de transação atribuível a eles.

A cúpula coloca uma contagem na camada de aplicativos

A declaração da Pi descreve uma rede de distribuição existente com mais de 60 milhões de Pioneiros engajados, autenticação, pagamentos e descoberta de aplicativos. Ela cita separadamente mais de 18,1 milhões de usuários totalmente verificados por KYC e mais de 420.000 nós. Essas medidas têm unidades diferentes. Um nó é um participante de infraestrutura, um usuário verificado é uma pessoa que passou por um processo declarado, e um aplicativo da Mainnet é um software associado à rede ativa. Nenhum dos três é automaticamente um cliente pagante de um dos outros dois.

O anúncio oferece um alvo de auditoria oportuno. Uma contagem de mais de 300 é grande o suficiente para examinar categorias, mas a declaração pública não fornece um inventário com carimbo de data/hora e uma definição consistente para inclusão. Os aplicativos podem aceitar pagamentos em PI, usar autenticação sem pagamentos, fornecer informações, hospedar um jogo ou conectar-se a ferramentas de desenvolvedor. Um diretório de aplicativos atual pode exibir apenas um subconjunto selecionado. Relatar os 300 como 300 negócios ativos adicionaria fatos que o projeto não reivindicou.

Isso é distinto do cronograma de protocolo recente da rede. Uma reportagem sobre o Protocolo 28 examinou a prontidão dos nós antes da ativação planejada da Mainnet em 16 de outubro. Ela nomeou atualizações de contrato e manuseio de dados de transação como mudanças técnicas. O novo anúncio da cúpula é sobre o inventário de aplicativos e o que os desenvolvedores construíram. Uma atualização de nó bem-sucedida não estabelece que um aplicativo listado tenha clientes pagantes.

Também é diferente do funil de KYC. Uma análise anterior do backlog de verificação da Pi separou usuários liberados para progredir de carteiras que realmente gastaram PI. A contagem de aplicativos adiciona outro estágio: deve haver software disponível, acessível e que valha a pena retornar. Limpar um gargalo de identidade e adicionar um aplicativo são ambos eventos observáveis. Uma transação de um usuário ativo é um terceiro evento, exigindo um registro separado.

O programa da cúpula poderia melhorar as evidências. A Pi promete demonstrações de ferramentas específicas de desenvolvedores e aplicativos de parceiros. Uma demonstração pode mostrar que um recurso funciona, enquanto pagamentos repetidos ao longo de semanas mostrariam uso contínuo. O anúncio não se compromete a publicar retenção por aplicativo ou recibos de comerciantes durante o evento. Um inventário de aplicativos e exemplos de pagamento reproduzíveis permitiriam aos leitores avaliar a contagem antes de qualquer total promocional subsequente.

Implantação na Mainnet e listagem no diretório são etapas separadas

O guia de lançamento para desenvolvedores da Pi descreve como um criador passa da Testnet para a Mainnet. O desenvolvedor cria um aplicativo Mainnet separado no portal, verifica sua URL, conecta uma carteira de aplicativo e completa uma lista de verificação. Uma carteira multifirma de entrada para pagamentos de usuário para aplicativo exige uma solicitação e revisão. Pagamentos de aplicativo para usuário estão disponíveis apenas para aplicativos Testnet e aplicativos Mainnet selecionados, conforme a redação atual do guia. A decisão de um desenvolvedor de criar uma entrada na Mainnet, portanto, não significa que todos os caminhos de pagamento possíveis estejam ativos.

As regras de listagem no diretório impõem outra etapa. Para aparecer na Interface Curada do Ecossistema Mainnet do Pi Browser, espera-se que um aplicativo seja funcional, integre a autenticação Pi, atenda aos requisitos de identidade de seu desenvolvedor e siga as políticas de transações e experiência do usuário. Um aplicativo pode existir na Mainnet sem ser aceito nessa listagem curada. A própria atualização anterior da Pi sobre aplicativos adicionados afirma que a lista não inclui todos os aplicativos Mainnet ou prontos para Mainnet e que diretórios de terceiros podem mostrar mais.

Essa diferença fornece uma maneira direta de testar o número da cúpula. Se a Pi diz que há mais de 300 aplicativos Mainnet, isso significa entradas no portal com uma configuração Mainnet ativa, aplicativos com carteiras aprovadas, aplicativos listados no navegador ou um conjunto mais amplo, incluindo serviços auto-hospedados? O anúncio de outubro não diz. Um repórter não pode substituir a contagem visível no navegador pela cifra do projeto sem antes mostrar que ambos aplicam a mesma regra de inclusão.

A distinção não é uma acusação de que a cifra seja falsa. Diretórios de produtos frequentemente selecionam um conjunto menor do que o universo total de software implantado. A Pi descreve explicitamente essa prática. A questão jornalística é a reprodutibilidade. Uma lista datada com identificadores de aplicativos, status e capacidades de pagamento permitiria a um leitor independente replicar o total. Sem isso, a contagem permanece uma cifra relatada pela empresa, útil como uma afirmação sobre escala, mas fraca como medida de uso contínuo.

Um aplicativo pode satisfazer requisitos de qualidade e política e ainda assim ter pouco tráfego. Por outro lado, um aplicativo independente não listado pode atrair usuários. A inclusão no diretório é uma decisão de triagem; tráfego e transações são registros comportamentais. O recurso de staking no diretório da Pi adiciona outra complicação: Pioneiros e empresas podem apostar PI para melhorar a posição de um aplicativo na Interface do Ecossistema. A Pi disse que o staking pode aumentar a exposição e as impressões, com potencial tráfego de usuários. Uma classificação mais alta no diretório é parcialmente função de promoção apostada e não pode, por si só, verificar a demanda orgânica.

O anúncio de staking identifica aplicativos Mainnet, aplicativos App Studio e serviços como exchanges centralizadas entre as categorias do diretório. Essa mistura significa que um analista deve filtrar a interface antes de tratar cada bloco como um aplicativo Mainnet. Também torna difícil a comparação entre categorias: um link de exchange, um experimento de criador e um aplicativo com uma carteira Mainnet aprovada podem ser exibidos próximos uns dos outros, embora sirvam a propósitos diferentes.

A capacidade de pagamento é uma medida mais restrita do que a existência do aplicativo

A Pi adicionou suporte do App Studio para aplicativos Mainnet e pagamentos ao vivo dentro do aplicativo em março. Sua declaração do Pi Day disse que quatro aplicativos App Studio foram convidados a fazer a transição para a Mainnet e integrar pagamentos reais em PI. O mesmo comunicado explicou interações de pagamento persistentes, que podem manter um recurso comprado ativo além de uma única sessão. Quatro é uma contagem de aplicativos App Studio convidados naquele momento, não o número total de aplicativos Mainnet em toda a rede.

Uma atualização anterior do App Studio em janeiro descreveu a integração de pagamento com token de teste. Ela permitia que criadores experimentassem sem mover PI real entre usuários e aplicativos. Comparar um protótipo de pagamento de teste com uma compra concluída na Mainnet confundiria atividade simulada e economicamente significativa. Em outubro, as ferramentas do App Studio haviam se expandido, mas o anúncio da cúpula não informou o número de pagamentos reais feitos por meio de seus produtos.

O caminho de pagamento na Mainnet é observável em princípio. Um usuário autoriza uma transferência, o aplicativo processa o callback e um ledger registra a transação em PI liquidada. A cadeia pública pode revelar um pagamento para uma carteira conhecida, mas um endereço de carteira por si só pode pertencer a um desenvolvedor, exchange, teste interno ou usuário comum. Para medir a demanda do consumidor, o operador do aplicativo precisaria identificar seu endereço de recebimento de produção e divulgar o suficiente sobre seu serviço para distinguir vendas de autotransferências, incentivos ou movimentação repetida das mesmas moedas.

Uma contagem de taxas ou pagamentos pode enganar em qualquer direção. Um aplicativo pode ganhar alguns pedidos grandes de comerciantes, enquanto outro executa milhares de pequenas ações pagas. O PI bruto transferido não é receita líquida se os usuários receberem reembolsos ou recompensas. Um aplicativo com assinaturas pode ter forte retenção e menos transferências individuais. Carteiras pagantes recorrentes, compradores distintos, compras concluídas e o período medido tornariam a comparação mais forte. O projeto não publicou esses quatro campos para seus mais de 300 aplicativos no lançamento da cúpula.

A biblioteca de pagamentos da Pi promete uma integração rápida para desenvolvedores que usam pilhas web suportadas. Seu guia para desenvolvedores de janeiro descreveu uma maneira de adicionar funcionalidade de pagamento em menos de dez minutos. Integrar o código é um marco técnico, não evidência de que os clientes subsequentemente compraram um serviço. A distinção é visível em muitas redes de pagamento: aceitar um instrumento e gerar comércio são resultados diferentes.

Alguns aplicativos podem ser valiosos sem cobrar PI. Um utilitário pode usar a autenticação Pi para servir usuários verificados, fornecer informações ou conectar Pioneiros a atividades externas. A cúpula poderia razoavelmente exibir tais softwares. Seria impreciso tratar a ausência de um pagamento em cada aplicativo como prova de que o aplicativo não tem usuários. A métrica correta deve corresponder ao produto: sessões repetidas para uma ferramenta gratuita, pedidos concluídos para um comerciante, implantações ativas para um serviço de desenvolvedor ou conversões pagas para um aplicativo cujo modelo de negócios as exija.

Uma auditoria deve manter quatro denominadores separados

Os números publicados podem ser colocados em uma tabela de medição simples sem dividir quantidades diferentes. Os mais de 60 milhões de Pioneiros engajados da Pi descrevem o público mais amplo que ela reivindica. Seus mais de 18,1 milhões de usuários verificados descrevem pessoas que passaram pelo KYC. Seus mais de 300 aplicativos da Mainnet descrevem software. Seus mais de 420.000 nós descrevem infraestrutura de rede. Uma taxa de adoção válida exigiria o número de usuários distintos de um aplicativo especificado durante um período definido, dividido por uma população elegível claramente definida. A Pi não forneceu esse numerador no anúncio.

Dividir 18,1 milhões de pessoas verificadas por 300 aplicativos daria aproximadamente 60.333 pessoas por aplicativo sob a suposição artificial de uma alocação uniforme. A aritmética usa os mínimos arredondados do projeto e não é uma medida do público de qualquer aplicativo. A mesma pessoa pode usar vários aplicativos ou nenhum, e um aplicativo pode atrair um grupo muito menor que a média teórica. Relatar o quociente como “usuários por aplicativo” seria um erro numérico, não uma análise original. A descoberta significativa é que nenhuma ponte publicada conecta o pool de usuários relatado à atividade do aplicativo.

Um método melhor solicitaria uma exportação datada do inventário de mais de 300 aplicativos e rotularia cada entrada por estágio. Para cada um, registrar se ele tem uma URL funcional, autenticação Pi, aprovação de carteira Mainnet, um endereço de pagamento divulgado, pagamentos PI concluídos durante uma janela especificada e uma medida de usuários recorrentes distintos. Os operadores podem se recusar a divulgar informações privadas de clientes; contagens agregadas e transações públicas ainda poderiam permitir uma verificação útil. O exercício exporia a lacuna entre o alcance possível e o uso real do serviço sem assumir que todos os aplicativos são idênticos.

O inventário deve marcar se o aplicativo é curado no Pi Browser ou auto-hospedado através do SoloHost. A Pi diz que o SoloHost permite que desenvolvedores lancem aplicativos de IA auto-hospedados, e seu anúncio de outubro agrupa esse produto com sua plataforma de desenvolvedor. Um serviço em execução em um nó pode ser um aplicativo no sentido comum de software sem ser um aplicativo web com uma carteira de pagamento Mainnet. Combinar essas categorias pode ser defensável se a Pi disser como as conta. Até então, uma auditoria independente deve preservar seus status separados.

As regras de diretório da Pi oferecem outra verificação. Elas exigem transações somente Pi para aplicativos que buscam a listagem relevante na Mainnet, enquanto o projeto discutiu separadamente um potencial papel de stablecoin em outro lugar em seu ecossistema. O recurso OUSD documentou que nenhuma integração de pagamento lançada ou mecanismo de demanda de token havia sido especificado. Uma futura mudança nas regras de listagem de aplicativos ou uma exceção estreita exigiria uma atualização de política datada. O anúncio da cúpula em si não revisa a página atual do diretório nem torna o OUSD um método de pagamento de aplicativo existente.

Cinco aplicativos listados mostram o que a contagem principal oculta

Uma atualização anterior da Pi oferece um pequeno exemplo nomeado de como o projeto seleciona aplicativos. Ela anunciou cinco adições à Interface do Ecossistema Mainnet, incluindo um jogo de cobra, aplicativos de comércio eletrônico e serviços de informação sobre o token PI. A Pi disse que esses cinco passaram por verificações de qualidade, funções completas, utilidade e conformidade com políticas. O exemplo prova que o diretório curado pode admitir diferentes tipos de software. Ele não revela com que frequência cada um foi aberto ou quanto alguém gastou neles.

Classificar os cinco por sua função declarada é mais útil do que tratar sua inclusão como um único resultado econômico. Um jogo pode registrar sessões frequentes, mas poucos pagamentos. Um site de informações pode ser lido sem qualquer transferência de tokens. Um aplicativo de comércio pode mostrar pedidos brutos, pedidos reembolsados, recibos de comerciantes e compradores recorrentes. Mesmo dentro do pequeno grupo, não há uma única métrica que transforme a contagem de cinco em demanda por PI. O exemplo mostra por que o inventário maior de mais de 300 precisa de tipos de aplicativos antes que um número agregado de uso possa ser interpretado.

A Pi alertou explicitamente naquela atualização que sua listagem na Mainnet omitia muitos aplicativos de terceiros. Um aplicativo rejeitado ou não enviado não é necessariamente inutilizável. O projeto distingue a seleção do diretório da disponibilidade mais ampla, e diretórios externos podem mostrar mais candidatos. Um instantâneo independente do navegador poderia, portanto, estabelecer a contagem de blocos visíveis em uma data, mas não pode confirmar o número total de aplicativos ativos. Conciliar os dois exigiria o inventário do portal do desenvolvedor ou uma metodologia publicada pela Pi.

A questão do que qualifica como pronto para a Mainnet complica ainda mais uma auditoria. Um desenvolvedor pode preparar uma carteira e URL enquanto aguarda a aprovação de pagamentos recebidos; um aplicativo pode executar um serviço que não requer pagamentos. O projeto poderia contar uma configuração funcional da Mainnet antes que um curador a liste. Um campo de status para aprovações de pagamento, último acesso bem-sucedido e implantação em produção tornaria essas distinções visíveis sem publicar dados privados dos clientes. A Pi não forneceu essa tabela campo por campo com seu lançamento na cúpula de outubro.

Há uma linha do tempo útil no material oficial. O lançamento do App Studio em janeiro começou com interações de pagamento Test-Pi. A atualização de março convidou quatro criações selecionadas para a capacidade de pagamento na Mainnet. A documentação posterior para desenvolvedores expandiu o que os construtores podiam fazer com armazenamento local, compartilhamento de arquivos e dados de staking específicos do aplicativo. O anúncio da cúpula de outubro apresenta mais de 300 aplicativos na Mainnet. Os endpoints descrevem populações diferentes, então subtrair quatro de 300 não calcularia o número de novos aplicativos pagos. Uma linha do tempo limpa preserva o que cada número contava no momento em que foi publicado.

A cobertura anterior do primeiro ano de rede aberta da Pi descreveu o App Studio entre os principais produtos públicos do projeto. A alegação de outubro diz respeito a um inventário posterior. Qualquer comparação com o primeiro ano deve usar a mesma definição de aplicativo e evitar importar um total mais antigo de KYC ou migração para o presente. Uma retrospectiva pode estabelecer quando um recurso apareceu; ela não preenche a série ausente de usuários ativos de outubro.

O melhor argumento para a Pi é sobre um público pronto

A Pi reuniu verificações de identidade, carteiras, um caminho de descoberta baseado em navegador, ferramentas de pagamento de aplicativos e uma grande base de participantes alegada. Um desenvolvedor que constrói um produto útil pode potencialmente distribuí-lo por canais existentes em vez de adquirir cada usuário independentemente. Mais de 300 aplicativos na Mainnet relatados podem significar que muitas equipes já fizeram o trabalho de preparar software para a rede ativa. A cúpula promete mostrar seus produtos e lançar ferramentas adicionais. Nenhum desses fatos deve ser apagado apenas porque faltam números públicos de retenção.

O caso cético é igualmente concreto. A distribuição não obriga um usuário a retornar a um aplicativo. O KYC verifica a identidade do titular da conta sob o processo do projeto; ele não mostra que essa pessoa tem PI discricionário, precisa de um determinado produto ou conclui uma compra. As classificações de diretório podem refletir staking para promoção. Ferramentas de criação de aplicativos podem aumentar contagens de experimentos mais rapidamente do que contagens de negócios com clientes recorrentes. Essas são razões para solicitar registros de uso, não razões para presumir que os aplicativos falharam.

A cobertura anterior da economia do App Studio examinou os custos enfrentados pelos criadores e apontou que inscrições em hackathons não são o mesmo que produtos ativos. A cúpula atual introduz outro hackathon e mais recursos para desenvolvedores. Uma contagem de inscrições após o evento mediria a participação nesse concurso. A parcela que posteriormente chega à Mainnet, permanece online e recebe usuários recorrentes mediria um resultado mais exigente.

Um operador poderia tornar o caso positivo mensurável publicando um relatório de coorte. Identifique os aplicativos listados antes de uma data escolhida e, em seguida, divulgue quantos ainda funcionam 30 e 90 dias depois e quantos têm usuários distintos que retornam ou pagam. Um relatório comparável um trimestre depois revelaria se as novas ferramentas para desenvolvedores ajudam os aplicativos a reter usuários, não apenas a serem lançados. A Pi não prometeu tal relatório para novembro. A ausência de uma promessa deve ser declarada claramente, sem converter um pedido de relatório em um entregável anunciado.

Existem limites práticos para a observação independente. O Pi Browser pode exigir uma conta, KYC ou permissões de aplicativo. Os rótulos de carteira nem sempre são públicos. Um explorador de blocos pode mostrar transações sem mostrar por que ocorreram. Um repórter externo pode verificar aplicativos nomeados, contratos públicos e transações de exemplo, mas não pode inferir cada sessão privada de usuário a partir de uma cadeia. Uma auditoria completa pode, portanto, permanecer parcialmente dependente de divulgações de desenvolvedores e projetos. A separação mais importante é entre o que foi reproduzido independentemente e o que a Pi ou uma equipe de aplicativo relatou.

Uma possível amostra de auditoria poderia começar com os cinco aplicativos que o próprio projeto nomeou em sua atualização anterior. Um repórter registraria se cada URL carrega agora, se o login funciona, se a função oferecida pode ser concluída e se um pagamento é solicitado. Uma segunda passagem após 30 dias verificaria se as mesmas funções ainda operam. Isso seria um teste direto de disponibilidade para cinco aplicativos nomeados, não uma estimativa para todos os 300. Expandir a amostra requer uma estrutura de amostragem completa, que a postagem da cúpula não fornece.

Para um aplicativo que reivindica vendas, o operador poderia divulgar um endereço de carteira e um período durante o qual foi usado exclusivamente para recibos de produção. Um repórter poderia então calcular remetentes distintos e total de PI recebido do livro-razão, enquanto declara que depósitos de exchange, transferências de desenvolvedores e reembolsos ainda podem distorcer essas contagens. Uma transferência bancária ou de exchange não pode ser atribuída a uma compra de cliente sem evidências adicionais. Para um serviço gratuito, o operador pode divulgar agregados de usuários ativos e retenção que preservam a privacidade. Métodos diferentes, rotulados honestamente, são preferíveis a uma única pontuação de "adoção" não suportada.

O modelo de negócios do aplicativo também determina se o PI está envolvido. As ferramentas de desenvolvedor da Pi oferecem login, descoberta e pagamentos como capacidades separáveis. Um criador pode usar as duas primeiras sem a terceira. A afirmação "mais de 300 aplicativos" pode ser totalmente precisa enquanto apenas um subconjunto tem uma carteira de pagamento aprovada para transferências reais. O convite da Pi em março para quatro criações do App Studio demonstra um caminho de aprovação mais restrito para uma categoria, mas não diz nada conclusivo sobre quantos aplicativos codificados independentemente aceitam pagamentos hoje.

Novembro pode revelar produtos, mas não anos de retenção

O evento de 17 a 19 de novembro está agendado como uma cúpula online, não uma data em que todos os recursos anunciados têm garantia de entrar em produção. A Pi diz que fornecerá atualizações da plataforma, demonstrações de desenvolvedores, vitrines de parceiros e aplicativos, e mais informações sobre um hackathon. Uma apresentação pode demonstrar uma ferramenta funcionando em um ambiente controlado. Uma ferramenta implantada e um aplicativo usando-a com clientes são estágios posteriores e verificáveis separadamente.

Se um aplicativo nomeado publicar um endereço de carteira de produção e mostrar uma transação que um leitor pode reproduzir, o artigo pode estabelecer uma capacidade específica. Se ele liberar um mês de dados distintos de carteiras pagantes com reembolsos e testes excluídos, o artigo pode discutir o uso. Se oferecer apenas uma demonstração em vídeo, o artigo deve chamá-la de demonstração. Essas classificações são reportagens comuns de produtos, não um padrão especial imposto à Pi.

O anúncio do projeto não relata uma data de lançamento comum para os mais de 300 aplicativos, seu tempo de atividade ou a parcela que aceita pagamentos em PI. Ele nomeia as datas da cúpula e os assuntos que pretende cobrir. A próxima agenda publicada e os aplicativos específicos selecionados para demonstrações são os documentos imediatos que podem reduzir a lacuna entre a afirmação de 300 aplicativos e o uso observável.

O que observar

• Inventário de aplicativos: Uma lista datada do Pi que define quais aplicativos compõem o total relatado de mais de 300.
• Status de produção: Aplicativos nomeados com URLs funcionais da Mainnet, carteiras aprovadas e transações ao vivo reproduzíveis.
• Uso repetido: Divulgações de desenvolvedores ou da rede sobre usuários recorrentes distintos em um período especificado de 30 ou 90 dias.
• Pagamentos: Compras de PI concluídas separadas de ações na Testnet, incentivos, reembolsos e transferências internas.
• Lançamentos da Cúpula: A agenda de 17 a 19 de novembro, ferramentas implantadas e regras do hackathon, cada uma com um status datado.

Perguntas frequentes