Vou começar com uma observação um pouco “contra-intuitiva”: se você olhar para os Pixels apenas como um jogo de farming e o PIXEL só como um “token de jogo único”, você naturalmente vai focar em preço, desbloqueio, e sentimentos — mas quanto mais eu olho, mais acho que a equipe do Pixels realmente quer fazer não apenas um jogo mais parecido com Web3, mas sim transformar a “operação de jogos” em um negócio que pode ser quantificado, reutilizado e replicado em mais jogos.
Essa frase soa meio vazia, então vou colocar de uma forma mais direta: o que eles estão fazendo com o Stacked é mais como um “motor de LiveOps com recompensas”, não um app de recompensas para os jogadores tirarem vantagem. Essa diferença muda muita coisa: quem realmente paga, para onde o dinheiro vai, como evitar que estúdios e bots tirem vantagem, e se o PIXEL realmente pode ficar preso a um único jogo.
Eu costumava ter uma certa resistência aos quatro termos “sistema de recompensas”. Você entende o porquê: na história dos jogos Web3, “sistema de recompensas” normalmente significa aquele kit com três peças — entra o pessoal que faz “bot/golpe”, vira fazenda, a economia é esvaziada. Então o time do projeto começa a usar regras mais complexas para tampar brechas. No fim, vira uma espécie de rede de remendos. Quanto mais remendos, mais o jogador comum é tratado como variável e a experiência piora; e os bots acabam “jogando” para explorar falhas de regra, ficando até mais eficientes. Então, você me pede para acreditar num novo app de rewards? Pra ser sincero, é difícil.
Mas tem um ponto na narrativa da Stacked que eu não consigo simplesmente varrer para debaixo do tapete: não é um conceito “que ainda está no deck”, é um sistema que já rodou de verdade no ambiente de produção da Pixels — e o âncora oficial é bem claro: na ecossistema da Pixels, ela processou 200M+ de rewards, abrangeu milhões de jogadores e gerou resultados em nível de receita 25M+. Você pode não gostar dessa forma de jogar, mas pelo menos não é “contar história”; é “apresentar contabilidade”. Para alguém como eu, que foi moído por whitepapers e ganhou PTSD, essa frase é o bastante: Built in production, not in a deck.
Em seguida, quero desmontar isso de forma mais concreta: se a Stacked realmente for, como eles dizem, uma “rewarded LiveOps engine + AI game economist”, então, no fundo, ela resolve dois dos problemas mais caros e mais difíceis do crescimento tradicional dos jogos. Primeiro: fazer o dinheiro ir para “jogadores reais”, e não para o pagamento de plataforma e para canais de compra. Segundo: transformar a operação de “achismo” em “experimento”, de “ver relatórios” para “mudar a ação no mesmo dia”.
Primeiro, vamos falar do primeiro problema: eu sempre achei que “comprar aquisição” é um buraco negro na indústria de jogos. Muitos estúdios gastam orçamentos de dois dígitos à frente e, no fim, quanto fica com os jogadores, quem realmente está disposto a jogar a longo prazo e qual evento gera recompra... tudo isso é bem nebuloso. Você já viu os backends de anúncios de jogos tradicionais para celular: dá para rastrear, mas é difícil fechar o ciclo; dá para atribuir, mas muitas vezes chega tarde. Aí todo mundo acaba usando orçamentos maiores para comprar um “crescimento mais previsível”, e o custo é que o ROI fica menos bonito.
A lógica de “redirect ad spend” da Stacked faz essa inversão: em vez de você dar dinheiro primeiro para a plataforma e deixar a plataforma distribuir o tráfego para você, você investe o orçamento de recompensa diretamente nos jogadores — e ainda exige que o efeito desse dinheiro possa ser quantificado: quanto melhora retenção, quanto melhora conversão em pagamento, quanto muda LTV. Isso parece transformar “orçamento de compra de mídia” em “orçamento de experimentos de recompensa controlável”. Não é só um bordão de marketing; eu entendo como uma lógica financeira mais “hardcore”: você não está apostando na qualidade do tráfego do canal; você está rodando um conjunto de experimentos de recompensa para filtrar o público que realmente vai ficar — e ajustar o orçamento em tempo real quando houver vazamento.
Aqui vem o segundo problema: como fazer isso em tempo real? Como transformar isso em experimentos?
Esse é justamente o valor do que a Stacked enfatiza com AI game economist — não é aquele trabalho leve de “IA para escrever anúncio” ou “IA para fazer pôster”, mas sim transformar as partes mais difíceis e mais lentas da operação em um loop de “insight para ação”. Muitos times de jogos não têm falta de dados; eles só não têm a capacidade de transformar leitura de dados em “julgamento executável” e, imediatamente, em parâmetros de uma nova rodada de evento.
Vou usar um cenário bem direto: se você perceber que um certo cohort (por exemplo, novos usuários) perde muita retenção de D3 a D7, a abordagem tradicional costuma ser: o time de dados puxa relatórios → faz reunião e discute → chuta causas → tenta no próximo update ou no próximo evento. Quando você termina de testar, talvez já tenham passado uma semana ou duas — e durante esse tempo o orçamento queimado e os jogadores perdidos não voltam mais.
E a “ambição” desse motor da Stacked é: você pode perguntar diretamente no sistema, como se estivesse perguntando a alguém que entende economia de jogos e dados comportamentais — por que whales caem mais rápido de D3 para D7? O que os nossos usuários mais fiéis fazem antes do dia 30? Quais mecânicas têm forte correlação com retenção de longo prazo? E aí não é só entregar uma “explicação”; o mais importante é mostrar onde o orçamento de recompensa pode estar vazando, quais experimentos valem mais a pena rodar em seguida, como desenhar o limiar de recompensas, como fazer filtragem anti-fraude, como usar o menor orçamento para maximizar incremento. No fim, você configura experimentos e coloca no ar no mesmo sistema, sem precisar “esperar”, sem precisar “no próximo update”. Insight to action, no waiting.
Você diria que isso soa um pouco como “hack/cheat”? Sim. Por isso eu me importo mais com o porquê de conseguir rodar. A resposta nem é tão misteriosa: a Pixels não começou essa história do zero para um; ela foi forçada a nascer usando ambientes reais de confronto. Se você já passou por qualquer sistema com recompensas, sabe o quão forte é o lado “adversarial”: robôs, scripts, estúdios, fazendas, bots… isso não é evento raro, é rotina. Se você não tiver anti-fraude, anti-bot e uma muralha de dados comportamentais, seu sistema de recompensas vira uma “carne fácil” e cedo ou tarde alguém vai arrebentar por completo.
Esse é o principal evidência de que eu considero que a Stacked “não é um app genérico de rewards”: o moat (muralha) dela não é design de UI, nem truques de eventos. É a soma de três capacidades duras — sistemas de anti-fraude e anti-bot; dados comportamentais escaláveis; e experiência de design de recompensa para longo prazo (eu prefiro chamar de “reward design wisdom”, ou seja, intuição e metodologia que vêm de tropeços na prática). Muitos times conseguem fazer uma cadeia de missões, uma tabela de ranking e até um quest board, mas pouquíssimos conseguem fazer um sistema de recompensas que “continua vivo” num ambiente de confronto real. A Stacked diz que já conseguiu, e que isso roda em produção; por isso ela se parece mais com infraestrutura do que com um recurso pontual.
Até aqui, você pode perguntar: o que isso tem a ver com PIXEL? Essa é exatamente a parte que eu tenho acompanhado mais de perto recentemente.
Hoje eu tenho mais tendência a ver a PIXEL como uma das “unidades de combustível/liquidação” dentro do motor da Stacked, e não como a moeda de rewards de um único jogo na Pixels. Colocando de forma bem direta: quando você transforma o sistema de recompensas em um motor LiveOps B2B, você naturalmente precisa de uma moeda de recompensa e fidelidade que atravesse jogos e experiências — para carregar o fluxo de valor do usuário entre diferentes jogos. A explicação oficial é “token utility expansion”: a PIXEL saindo de token de single-game para virar moeda de rewards cross-ecosystem. Eu acho esse rumo importante, mas é preciso cuidado na forma: não é promessa e não é algo que “vai acontecer agora”; é mais uma inevitabilidade estrutural. Quando mais jogos conectam ao mesmo rewarded LiveOps engine, as recompensas não podem ficar para sempre presas a um único título.
Eu digo “inevitabilidade estrutural” porque o lado da demanda vai empurrar: mais jogos = mais cenários de recompensa = uma demanda maior. Pense assim: se a Stacked realmente conectar estúdios externos também (e ela já deixou claro o movimento de “now opening to external studios”), então o prato do orçamento de recompensas não é mais o orçamento operacional de um único jogo, e sim o orçamento de crescimento de vários estúdios. Quanto maior esse prato, mais precisa de uma unidade de recompensa que possa ser reutilizada entre cenários, gerida com precisão e ainda fique profundamente acoplada ao sistema de anti-fraude. O papel da PIXEL aqui sai de “moeda emitida dentro do jogo” e vira “tickets/unidade genérica de fidelidade dentro do motor de recompensas”. Isso é o que eu entendo por “expansão do papel”: de token de jogo único, expandir para rewards / loyalty currency / combustível da reward layer entre jogos.
Mas eu também não vou começar a “dar sinal de compra” só com base nessa narrativa. É porque é bem prático: qualquer história de “expansão com monetização” que não chegue a um caminho real de uso, a um caminho de orçamento e a um caminho de anti-fraude, vira só mais uma bolha. Então eu prefiro colocar os critérios em três pontos bem específicos e mais fáceis de verificar:
Primeiro: existe um sinal real de que “orçamento de estúdio externo” está sendo conectado a esse sistema? Note que eu disse orçamento, não pôster de parceria. Parceria não é transação de fluxo, não é retenção a longo prazo e não é aumento de LTV. O sinal verdadeiro deveria ser: alguns eventos/tarefas/mecânicas de recompensa foram desenhados claramente para jogos externos, e dá para ver a lógica de medição e atribuição (por exemplo, um framework de experimento para aumento de retenção e aumento de receita), e não apenas uma cópia do modelo de tarefas da Pixels.
Segundo: a capacidade de anti-fraude e do sistema de dados comportamentais vai continuar sendo a “base padrão”, e não ser diluída por uma expansão externa? Muitos sistemas, quando aumentam escala, acabam sacrificando segurança e rigor de controle de risco — principalmente quando diferentes estúdios não concordam sobre a qualidade dos jogadores e sobre a intensidade do confronto. A vantagem atual da Stacked vem justamente de ser “battle-tested”: vem de ter sido martelada por jogadores reais e por ambientes de confronto da Pixels. Se no futuro ela integrar mais jogos, se esse controle de risco consegue ser replicado em escala, isso vai determinar se ela é infraestrutura.
Terceiro: o AI game economist consegue mostrar em mais cenários a capacidade de “experimentos executáveis”, e não só de ser um “gerador de relatórios”? Eu tenho medo desse tipo de ferramenta em que “a análise com IA fica linda, mas não dá para colocar em prática”. A diferença real deveria ser: você faz uma pergunta, e ela não te dá só uma conclusão — ela também gera um plano de experimento para o próximo passo e consegue colocar isso no ar no mesmo sistema. Em outras palavras, a IA não deve parar na camada de insights; ela precisa atravessar as camadas de ação: direcionamento de anúncios, recompensas, anti-fraude e controle de orçamento.
Olha, eu falei de tanta coisa, mas no fundo eu venho evitando discutir preço. Não é porque eu não me importo; é porque se você tratar a Stacked como uma operação de infraestrutura B2B, a fonte do valor não é uma variável de curto prazo como “a febre do jogo”, e sim uma variável de longo prazo como “capacidade de crescimento repetível”. A lógica comercial de infraestrutura é mais parecida com SaaS: você oferece para o estúdio um ROI quantificável, e só aí o estúdio continua comprando; você consegue redirect do orçamento de aquisição para o jogador e ainda torna isso auditável, atribuído — só então fundos acham que não é uma compra de uma vez só.
E tem ainda um ponto que é fácil ignorar: quando a Stacked é definida como “infraestrutura”, o perfil de risco muda também. O risco de um jogo único está mais em ciclo de conteúdo, envelhecimento de mecânicas e concorrentes roubando usuários. O risco de infraestrutura está mais na velocidade de expansão, no custo de combate e na capacidade de continuar entregando ROI quantificável. Qual eu prefiro? Eu prefiro a segunda, porque pelo menos existe a chance de “dá para colocar as contas no papel”.
No fim, quero resumir com uma frase: se a história da Pixels for apenas “um jogo Web3 de sucesso”, ela vai acabar sendo colocado na prateleira da narrativa de jogos para comparação. Mas se a Stacked for de fato “rewarded LiveOps engine + AI game economist”, e se ela já tiver gerado resultados concretos em ambiente de produção — 200M+ rewards, milhões de players, receita 25M+ — então ela parece muito mais estar pegando o sistema de recompensas, que é o mais fácil de dar errado no Web3, e transformando em uma ferramenta de crescimento que estúdios tradicionais também topam usar. A expansão do papel da PIXEL deixa de ser só “parece bom” e vira um caminho mais parecido com expansão comercial: mais jogos conectados → mais orçamento entrando → mais cenários de recompensa surgindo → maior base de demanda.
Eu não vou tratar isso como um tema de curto prazo que explode de uma noite para outra, mas como uma direção estrutural que vale acompanhar continuamente: entra algum novo studio? O loop de experimento está rodando? A muralha de proteção anti-fraude já foi provada como replicável em escala? Enquanto essas três coisas puderem ser vistas gradualmente na cadeia ou no lado do produto, minha confiança nessa narrativa só vai ficando mais firme.