Problema
Instituições tentavam avaliar Market Makers com ferramentas caras e dados espalhados. Quando uma penalidade está em jogo, informação parcial não basta.
Abordagem
SLA binário, liquidity ao longo do tempo, barra lateral e filtros em um dashboard único, com detalhes sob demanda.
Resultado
61→88% de conclusão de tarefas nas rodadas de teste. Segundo os clientes, a verificação caiu de ~20 minutos para menos de 30 segundos.
- 61→88% Conclusão de tarefas
- 20min→<30s Tempo para verificar um dado
- 100% Feito via Cursor AI
- Adquirido Por Worldchain e Kraken
Avaliar um Market Maker era mais difícil do que deveria
Instituições Web3 dependem de Market Makers para manter liquidity e eficiência de mercado. Mesmo assim, entender se eles estão entregando o que foi contratado ainda exige muito trabalho manual.
Ferramentas como Dune e DeFiLlama são caras, deixam os dados espalhados e nem sempre indexam exatamente o que cada cliente institucional precisa.
Quando há dinheiro em risco, inclusive na decisão de aplicar uma penalidade contratual a um Market Maker, não dá para depender de dados incompletos.
Dois públicos. Necessidades opostas. Uma decisão.
Dois públicos usam os mesmos dados para objetivos diferentes: fundos institucionais, protocolos DeFi e exchanges precisam decidir rápido, mesmo sem domínio técnico; já os Market Makers precisam provar que cumpriram o SLA.
Quando um Market Maker sai dos limites do contrato, alguém precisa decidir, com dados confiáveis, se cabe uma penalidade.
Uma decisão errada custa dinheiro para os dois lados.
Conhecimento do mercado, depois referências de produto
A equipe já conhecia o problema por dentro. O Product Manager tinha anos de experiência como analista de dados, com contato direto com a dor que queríamos resolver.
O CEO também lidava com esse problema antes do projeto. Cruzamos esse conhecimento com referências como Dune, DeFiLlama, Bloomberg Terminal, Grafana e Datadog para entender como cada produto organiza dados financeiros densos.
O padrão era claro: ferramentas caras, dados fragmentados e pouca flexibilidade para indexar o que cada cliente precisava. A oportunidade era reunir tudo em uma única plataforma, com preço justo e contratos personalizados. Cada liquidity pool era configurado e indexado de acordo com o contrato, com clareza suficiente para reduzir perdas e evitar penalidades aplicadas com base em uma leitura errada.
Quatro decisões de UX que moldaram o produto
Quatro decisões de UX definiram o produto, cada uma comparada a uma alternativa. Todas respondiam ao mesmo objetivo: reduzir drasticamente o tempo entre consultar um dado e decidir se cabia uma penalidade.
01
SLA como contrato binário, não como percentual isolado
“98,7%” não responde ao que importa: o contrato foi cumprido ou não? A UI mostra o SLA como cumprido ou não cumprido.
02
Liquidez como comportamento ao longo do tempo, não como valor estático
Uma liquidity pool de US$ 200 mil pode ter caído 60% na última semana. Mostrar só o valor atual esconde o principal. Por isso, tendência e direção vêm primeiro.
03
Contexto e filtros na barra lateral, sempre ao alcance
Quem monitora várias liquidity pools com contratos diferentes precisa se orientar sem sair do dashboard. A barra lateral reúne dados do contrato, contexto da pool e referências; os filtros recortam por pool, período e status do SLA.
04
Um modelo mental de tela única
As informações foram organizadas em quatro camadas: status do SLA, comportamento da liquidity, comparação de mercado e metodologia. Os detalhes aparecem sob demanda, sem tirar o usuário do contexto.
Alertas automáticos avisam quando um dado passa do limite esperado e reduzem o monitoramento manual. Para entregar um produto dessa complexidade no prazo, usamos fluxos de trabalho assistidos por IA. Isso acelerou a execução e abriu espaço para testar mais variações de layout sem reconstruir cada opção do zero.
Rodadas com operadores, depois uso real em produção
Testamos com 4 operadores em várias rodadas ao longo do projeto, não em uma sessão isolada. Também fizemos testes A/B rápidos e enxutos para comparar alternativas sem comprometer o cronograma.
O principal atrito da v1 era direto: “métricas demais ao mesmo tempo”. Reduzimos o dashboard principal de 12 métricas para 4 essenciais e deixamos as demais nos níveis de detalhe.
Depois do lançamento, a validação mais forte veio do uso real pelos dois principais clientes B2B, Worldchain e Kraken. O projeto levou cerca de 6 meses do início ao handoff.
Resultados mensurados e adoção institucional
Conclusão de tarefas · 4 operadores, várias rodadas
Tempo para verificar um dado · relatado pelos clientes
Feito via Cursor AI
Por Worldchain e Kraken
A conclusão de tarefas se manteve consistente ao longo das rodadas com o mesmo grupo de operadores. O produto inteiro foi feito via Cursor AI e hoje roda em produção com Worldchain e Kraken como clientes.
- Validação em produção: Worldchain e Kraken usam o produto com contratos personalizados e várias liquidity pools monitoradas 24/7
- Velocidade relatada pelos clientes: cruzar dados entre plataformas levava ~20 minutos; no dashboard unificado, a verificação caiu para menos de 30 segundos (relato qualitativo, sem medição controlada com todos os usuários)
- Entrega assistida por IA: os ciclos de design ficaram ~60% mais rápidos, o que permitiu testar mais variações de layout dentro dos mesmos 6 meses
- Foco nas métricas: o dashboard principal passou de 12 métricas simultâneas para 4 essenciais, com as demais disponíveis sob demanda
Do monitoramento reativo às decisões preditivas
Hoje, a plataforma responde: “este Market Maker está dentro do contrato agora?” O próximo passo é responder: “ele continuará dentro do contrato amanhã?”
As prioridades são alertas preditivos antes que os limites sejam ultrapassados e comparação neutra de até três Market Makers na mesma visualização, sem reintroduzir o viés de ranking que removemos.
Em produtos institucionais, menos pode ser uma decisão estratégica. Simplificar a UI sem simplificar a arquitetura da informação só transfere a confusão para outra tela. Cada métrica removida do dashboard precisava justificar por que voltaria nos detalhes.
