Transparent.space · Monitoramento de market maker
Uma decisão de penalidade levava vinte minutos cruzando ferramentas.
Desenhei o produto de monitoramento para um operador ver, numa tela, se um market maker estava em conformidade.
Visão geral
Instituições contratam market makers. Depois precisam provar o trabalho.
Instituições de Web3 dependem de market makers para liquidez. Avaliar se esse maker de fato performou é surpreendentemente difícil.
Ferramentas como Dune e DeFiLlama são caras, ficam espalhadas entre produtos e às vezes não indexam o campo exato que o contrato exige. Quando a decisão é uma penalidade contratual, dado parcial não serve.
Problema
O número na tela não era a pergunta que estava sendo feita.
Dois grupos compartilham o dado e querem coisas opostas. Fundos, protocolos e exchanges precisam decidir rápido sem fundo técnico. Os times de market maker precisam provar que cumpriram o SLA.
No meio está uma decisão cara: se um maker sai do contrato, alguém precisa decidir se a penalidade se aplica. Errar custa dinheiro dos dois lados.
Oportunidade
Unificar a checagem, a um preço justo, contra o contrato de verdade.
O product manager tinha anos como analista de dados, então a dor era de quem viveu o problema. O CEO já convivia com ele antes do projeto. Usei esse contexto e depois fiz benchmark de como Dune, DeFiLlama, Bloomberg Terminal, Grafana e Datadog lidam com dado financeiro denso.
A lacuna era consistente: ferramentas caras, dados fragmentados e contratos que não podiam ser indexados como estavam escritos. O produto precisava colocar um contrato personalizado numa plataforma só.
Solução
Responder uma pergunta primeiro: em conformidade, ou não.
Cada decisão da interface mirava o mesmo resultado: reduzir o tempo para verificar um ponto e decidir se a penalidade se aplica.
Experiência central
A tela é construída em torno da penalidade, não do gráfico.
SLA como cumprido ou não cumprido.
“98,7%” não responde a pergunta que importa. A interface trata o SLA como um contrato binário.
Liquidez como comportamento no tempo.
Um pool de US$ 200 mil que caiu 60% numa semana é outra história de um pool estável. Mostrar só o valor atual esconde a decisão.
Contexto que continua ao alcance.
Operadores acompanham vários pools sob contratos personalizados. A barra lateral guarda metadados do contrato e referências. Filtros restringem por pool, período e estado de SLA, então a sessão já começa no recorte certo.
Decisões
Simplificar a tela sem simplificar o modelo só muda a confusão de lugar.
Binário no lugar de uma porcentagem precisa.
Precisão parecia rigor e ainda assim falhava no trabalho. O operador precisava de um veredito que pudesse defender.
Tendência antes do valor atual.
Um número estático parece completo numa revisão com stakeholders. Ele esconde a semana que de fato justifica a penalidade.
Profundidade sob demanda.
Cada métrica tirada da visão principal precisava merecer a volta pelo detalhe. Fluxos com apoio de IA tornaram essa iteração possível num projeto de seis meses. O produto inteiro foi construído com o Cursor.
Os ciclos de design aceleraram cerca de 60% nesse prazo. Isso é efeito de entrega, não métrica de usuário.
Resultados
Checagens mais rápidas, com o cuidado de como foram medidas.
Worldchain e Kraken adquiriram o produto e o operam em produção, com contratos personalizados em vários pools.
Reflexão
O produto responde “em conformidade agora”. Ainda não responde “amanhã”.
A próxima camada é um alerta preditivo antes de um limite estourar, e uma comparação neutra de até três market makers numa visão, sem o viés de ranking que tiramos de propósito.
Em produto institucional, a contenção é a estratégia. Uma UI mais limpa em cima da mesma pilha de métricas só muda a confusão de endereço.