Uma mesa de trading que não te deve história nenhuma

A maior parte do software de trading retail é ruim porque quem o constrói está vendendo histórias: a IA que vence o mercado, o indicador secreto, a vantagem proprietária. A maior parte do software de trading institucional é ruim porque foi desgastado por uma década de pedidos de feature e agora faz tudo mal feito.

A inite.fund senta no meio. Nem retail, nem institucional. Sem vender história. Passamos 18 meses construindo, quebrando e reconstruindo; estas são as cinco restrições às quais sempre voltamos.

1. A metodologia precisa se defender sem a gente na sala

Se um método precisa que a gente explique em retrospecto por que funcionou, não é método - é narrativa. Já tiramos várias features que performavam lindamente em backtest mas não cabiam em duas frases de explicação.

Teste: peça ao Claude para ler o código no repositório. Se a estratégia não pode ser resumida para alguém que nunca a viu, não é uma estratégia.

Aprendemos isso da forma dolorosa com uma política de saída em Q-learning para os sleeves de trading. Ela aprendeu. Funcionou em backtest. A gente não conseguiu explicar para si mesmo por que ela escolhia certos timings de saída. Deletamos e voltamos para regras fixas. Regras fixas vão mais rápido para produção, debugam mais rápido, falham de forma mais previsível.

2. A trilha de auditoria vem antes da feature

Cada mudança de estado escreve uma linha. Trocas de modo entram no mode_history. Fluxos de capital têm um audit_ref que os torna idempotentes. Cada chamada de tool MCP bate no audit_log antes de retornar. Cada operação tem sua própria state machine de projeto, replicável a partir do disco.

Isso não é paranoia. É que software financeiro falha de forma estranha. Quando algo está errado às 03:14 de um domingo, a pergunta nunca é “o que o código deveria fazer” - é “o que o código fez de verdade”. Sem logs, você reconstrói por teorias. Teorias perdem para logs.

A trilha de auditoria também destrava o MCP. O Claude chama set_mode, o audit_log diz “via mcp:user#7”, você relê depois e sabe exatamente quem e como. A mesma trilha, seja você apertando um botão ou digitando uma frase.

3. Por usuário é a unidade de raio de impacto

A versão antiga da inite.fund tinha um único “trading user” global - chaves em settings compartilhadas, acessíveis a qualquer admin. Reescrevemos isso neste trimestre.

Agora cada estratégia pertence a exatamente um usuário. Long sleeves, contas de trading, entradas no cofre, tokens - tudo por usuário. Se um usuário é comprometido, você revoga o token dele e rotaciona as chaves de exchange. As estratégias dele entram em modo degradado. Os outros usuários nem percebem.

Isso custa mais código que o modelo global. Compensa na primeira vez que você precisa embarcar um terceiro operador sem ter que rotacionar as chaves de todo mundo.

4. Tempo real é uma feature; frescor é orçamento

Dados em tempo real custam caro. Bater na exchange a cada tick custa caro. Fazer SSR de uma página de marketing a cada request custa caro. Então definimos um orçamento de frescor por superfície e projetamos para ele.

• O dashboard do cockpit faz SSE com tick de 5-15s. De graça.
• O site de marketing renderiza por SSR com cache de borda de 30s. Na prática, de graça.
• Cards de OG (link previews em Twitter / Discord) são renderizados sob demanda a partir do product API, cacheados por 5 minutos pela plataforma de embed de qualquer jeito.
• As ferramentas MCP buscam estado fresco a cada chamada. Como são uns ~20 chamadas/dia por usuário, frescor aqui é essencialmente de graça.

Não existe uma promessa global de “tempo real” - existe um orçamento de frescor por superfície. “AUM atualizado há 10 segundos” em /strategies significa exatamente isso; o dashboard tica mais rápido, a imagem de OG tica mais devagar.

5. Construa o que dois operadores querem

A decisão de design mais difícil neste tipo de software é para quem é. Um usuário retail quer chat-bots e emojis. Um hedge fund quer ganchos de compliance e FIX. Pegamos o meio: alguém que tocaria uma alocação pequena na mão se o software não existisse, que sabe ler código, e que se importa mais em não perder dinheiro do que em ficar rico rápido.

Isso decide o resto do design:

• Acesso apenas por convite. Sem cadastro de autoatendimento. Onboarding é uma conversa.
• Cofre criptografado para chaves de exchange, texto plano aparece uma única vez. Mesmo modelo da Stripe para restricted keys; mesma intuição.
• MCP primeiro, dashboard depois. O dashboard existe para monitoramento + ação de emergência. A maior parte das edições passa pelo Claude.
• Skills em markdown puro, não um sistema de plugin fechado. Você lê. Você forka. Você nos proíbe de atualizar se quiser.

O que a gente nunca vai fazer

• Prometer retorno. Qualquer número que publicamos é track record, não previsão.
• Caixa-preta com seu dinheiro. A stack inteira é auditável; o código é interno, mas a metodologia está neste blog.
• Vender pelo FOMO. Apenas por convite, taxa de onboarding limitada, sem cadastro público. Se você está em dúvida, espere. A mesa vai estar aqui mês que vem.
• Operar seu dinheiro sem suas chaves. Cada estratégia lê do seu cofre. Custódia não é nosso negócio.

O que a gente sempre vai fazer

Construir software que respeita o operador. Rodar uma metodologia que não precisa de narrativa para se defender. Abrir arquitetura suficiente para provar que não estamos vendendo magia. Embarcar um usuário por vez e passar pelo onboarding na mão até os atritos sumirem.

O resto é execução.

• inite team