Acabei de ver um amigo a desabafar sobre a cadeia do jogo web3 que está a jogar: a emissão (inflação) está a ser forte demais, a pool está quase a ficar seca… fiquei com pena.

No fundo, o modelo económico do jogo é uma gangorra entre “produção” e “consumo”. Se há demasiada produção e pouco consumo, o valor na pool acaba por ser diluído e, depois, toda a gente percebe que os tokens na mão não compram praticamente nada e vai-se embora. Eu antes vi um protocolo cujo whitepaper estava bastante bem escrito: falava de “consumir com lock”, “combinar e destruir”, etc. Só que, na primeira semana após o lançamento, a quantidade produzida já ultrapassou as expectativas em dobro; a porta da destruição (burn) ainda ficava a bloquear de forma terrível. No fim, acabou por não dar em nada, ficou por aqui. Fico a pensar: quando foi desenhada a economia, ninguém calculou isto?

Recentemente, alguns ferramentas de dados on-chain têm sido criticadas por serem “atrasadas” e “fáceis de induzir em erro”, mas eu acho que os dados on-chain para chain games são particularmente difíceis de fazer. Só olhar para o volume de transações não mostra quando é que a inflação vai colapsar; é preciso cruzar com a frequência de interações com contratos e com a taxa de entrada dos endereços de destruição. Mas muitas destas ferramentas atrasam-se nas atualizações: quando finalmente percebes que a pool está mal, já pode ser tarde demais para sair a tempo.

Enfim, na parte de chain games eu não falo muito, mas sempre que vejo projectos a tratarem “crescimento composto” como se fosse uma cura para tudo, dá-me logo cabo do juízo. A combinação modular até parece bonita, mas se o modelo económico não for sólido, até a realidade dos “panos de cores” rebenta e fica difícil de lidar.