Só acredito a meias que bastam dois repositórios do GitHub para transformar um computador comum numa estação de investigação como um terminal Bloomberg. Com REA e Kronos, mais o Claude Code a servir de cola, o resultado montado até funciona: por um lado, recolhe cotações, calcula fatores e faz backtests; por outro, deixa o modelo ler comunicados, escrever relatórios diários e gerar hipóteses de negociação. À primeira vista, parece mesmo credível. Mas, no trabalho de montar tudo, o mais difícil nunca é o código: são as fontes de dados e a latência. O código pode ser complementado com repositórios de código aberto e o Claude Code; os dados, porém, têm de ser ligados um a um. As APIs gratuitas de cotações impõem frequentemente limites de pedidos — por exemplo, permitem apenas alguns pedidos por minuto — e os dados de ações podem ter um atraso de 15 minutos. Para obter um livro de ofertas Level 2 em tempo real e transações tick a tick, as mensalidades podem variar entre algumas centenas e alguns milhares de dólares. Os dados alternativos, a análise de notícias e comunicados e a sincronização de fusos horários são ainda problemas ocultos. Já vi um caso típico deste tipo de montagem: usar uma interface gratuita para obter dados diários e fazer backtests, com uma curva de rendibilidade anualizada muito bonita; mas, assim que se passa para uma conta de simulação, percebe-se que os sinais chegam dezenas de segundos depois das transações reais e que o slippage consome mais de metade dos ganhos. Por isso, a ideia de «transformar um computador comum num terminal Bloomberg» só se aplica ao fluxo de investigação. Em termos de qualidade dos dados e latência de execução, ainda fica muito aquém de um terminal a sério.

Há bastante tempo que acompanho as guildas de jogos blockchain e, por mais sofisticado que seja o modelo económico on-chain, no fim de contas tudo depende da retenção de jogadores reais. Nem as ferramentas mais poderosas conseguem salvar um jogo que ninguém joga. Por exemplo, há projetos com um TVL e um volume de transações de NFT muito elevados, mas apenas algumas centenas de utilizadores ativos por dia. A produção obtida através de farming supera o consumo a longo prazo e, quando há menos jogadores novos, tanto o preço do token como as receitas da guilda desabam. Em contrapartida, nos jogos com uma retenção estável, mesmo que as ferramentas sejam rudimentares, as guildas conseguem crescer gradualmente graças a uma produção estável e à atividade dos jogadores. As ferramentas podem aumentar a eficiência da recolha de dados, do cálculo de rendimentos e da monitorização de endereços, mas não podem criar diversão e retenção do nada. Vou guardar esta conclusão e voltar amanhã para a validar: usar durante uma semana a mesma stack — REA + Kronos + Claude Code —, registar a taxa de falhas das fontes de dados, a latência de ponta a ponta e as diferenças entre os sinais e a avaliação humana; depois, comparar esses resultados com a retenção no dia seguinte, a retenção aos 7 dias e os pagamentos reais nos jogos das guildas, para perceber afinal se as ferramentas melhoraram a estação de investigação ou se são as fontes de dados e a retenção que determinam o limite.