26. Custom RPC selecionado (estado alternativo)

Função: Estado da UI quando RPC Connection é "Custom" — usuário fornece URL própria.

Componentes

• Pill Custom ativa (cor primária)
• Input vazio com placeholder "https://"
• Zero warning, zero validação inline visível, zero help text
• Sem botão Save explícito

Regras de negócio

• Custom permite RPC self-hosted ou de terceiro não-listado
• Aceita qualquer string com formato URL
• Sem whitelist, sem checagem de phishing-list

🟢 Insight Existência de Custom RPC é decisão correta pra power-user e dev — não force-feed dos providers comerciais. Decentralization-friendly: usuário pode rodar seu próprio nó Solana, usar RPC self-hosted, ou alternativas sem SLA comercial. Coerente com filosofia DeFi de "user choice on infrastructure".

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante e intermediário) Zero warning sobre os riscos concretos de RPC custom. Usuário pode colar URL maliciosa (RPC controlado por scammer divulgado em Telegram/Discord como "RPC anti-MEV ultra-rápido") que:

• Vê todas as transações assinadas (privacidade total comprometida)
• Pode censurar transações (não relayar, fazendo o swap "falhar")
• Pode reportar saldos/cotações falsas pra induzir decisões erradas

Nenhuma dessas dimensões aparece na UI. Pancake confia que quem escolhe Custom sabe o que está fazendo — assunção razoável em tese, mas iniciante curioso pode colar URL viu num grupo de Telegram. Vetor de ataque viável e barato (engenharia social pra colar URL → atacante captura tudo).

Fix óbvio (warning textual "Custom RPCs see all your transactions") ajuda. Fix correto: Custom atrás de barreira em camadas semelhante ao Expert Mode (modal warning + type-to-confirm da An. 20-21), porque consequência de privacidade/segurança é equivalente. Template positivo de defesa já existe no próprio produto — basta aplicar.

^friccao-1

🔴 Fricção secundária (cosmética — afeta intermediário) Input sem validação visível. Usuário cola URL malformada, "salva" (auto-save?), e descobre depois que o app não funciona. Sem feedback inline (borda colorida, mensagem "Invalid URL"), o erro só se manifesta quando tenta executar transação.

Fix óbvio (validação on-blur + erro inline) resolve. Convenção bem estabelecida (form validation) — falha em aplicar é descuido, não decisão consciente.

^friccao-2

🟡 Oportunidade competitiva (alta leverage no target) Custom RPC sem warning de privacidade/segurança é convenção universal: Pancake, Phantom, Solflare, MetaMask (lado EVM) — todos permitem entrada raw de RPC sem barreira de consciência. Passa nas 4 perguntas: convenção entre wallets e DEX, afeta iniciante (manipulável por social engineering), ninguém investiu por priorizar liberdade de decentralization sem questionar o trade-off, perceptível.

Diferenciação Kotai: Custom RPC atrás de defesa em camadas (warning estruturado sobre privacidade + type-to-confirm), seguindo o template que Pancake já aplica em Expert Mode. Avançado ganha 30 segundos de fricção ao habilitar; iniciante manipulado fica protegido. Cost-benefit claro pro target principal — e Pancake já tem o template internamente, basta reusar para outras features de risco.

Trade-off: pode parecer "paternalismo" para comunidade DeFi-purist — vale calibrar messaging do warning pra não soar como FUD, e sim como informação contextual.

^oportunidade-1

22. Solana Settings (tab)

Função: Aba Solana-specific do painel de Preferências. Configurações de explorer e RPC que se aplicam apenas a interações com a rede Solana.

Componentes

• Tabs: Global / EVM / Solana (ativa)
• Default Explorer + ? — pills: Solscan (selecionado, com avatar próprio), Explorer (sem branding visual)
• RPC Connection + ? — pills: Triton (selecionado), Helius, Custom
• Input com URL pré-preenchida (não editável quando Triton ativo): "https://pancake-solanam-09ac.mainnet.rpcp..."

Regras de negócio

• Escolha de block explorer afeta links de transação no produto
• RPC Connection define endpoint que a app usa pra ler/enviar transações
• "Custom" permite RPC próprio
• Defaults já vêm selecionados (Solscan + Triton)

🟢 Insight Separação Solana Settings (em vez de fundir com EVM) reconhece diferenças reais: Solana não tem GWEI (tem priority fees diferentes), tem explorers próprios (Solscan ≠ Etherscan) e infra de RPC com players específicos. Aba separada é arquitetura honesta, não pluralismo cosmético. Defaults pré-selecionados (Solscan + Triton) significam que iniciante não precisa tocar em nada — pode fechar o painel e seguir.

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante e intermediário) Toda a tela assume conhecimento de domínio Solana sem suporte algum. Iniciante com wallet Solana conectada que abre o painel não sabe o que é "block explorer", "RPC Connection", nem por que tem uma URL técnica visível. Intermediário pode entender que são opções de provider mas não decifra diferença operacional (latência, rate limit, confiabilidade) entre Triton e Helius.

Fix óbvio (esconder Solana Settings de iniciante) falha porque iniciante pode querer trocar de Solscan pra outro explorer, ou trocar pra RPC custom se o default falhar. Fix correto: sub-label semântica em cada pill ("Triton — recomendado", "Helius — alternativa", "Custom — avançado") + breve descrição contextual nas seções ("Where your transactions appear" / "How the app reads Solana data"). Default já selecionado mantém a tela utilizável sem leitura.

^friccao-1

🔴 Fricção secundária (cosmética — afeta intermediário) Pill "Solscan" tem avatar/branding próprio; pill "Explorer" não tem nada além do texto. Inconsistência: Solscan é provider terceiro com identidade visual; "Explorer" sozinho parece genérico ("qual explorer?"). É na verdade Solana Explorer (oficial da fundação), mas a label truncada esconde isso. Pancake mostra branding do terceiro e economiza no oficial — assimetria estranha.

Fix óbvio (renomear pra "Solana Explorer" + ícone) resolve.

^friccao-2

🟡 Oportunidade competitiva (média leverage) DEX cross-chain que suportam Solana (Pancake, Jupiter cross-chain, Uniswap em fase inicial) expõem RPC e explorer em forma técnica herdada de wallets (Phantom, Solflare). Passa nas 4 perguntas: convenção entre concorrentes que suportam Solana, afeta iniciante e intermediário cross-chain, ninguém investiu em sub-labels por priorizar power-users de Solana, perceptível.

Diferenciação Kotai: opções técnicas (RPC, explorer) com sub-labels semânticas; default sempre suficiente pro target principal; "Custom" atrás de fricção (requer URL válida + warning sobre confiar em RPC terceiro).

^oportunidade-1

23. Tooltip "Default Explorer"

Função: Tooltip do "?" ao lado de "Default Explorer" em Solana Settings.

Componentes

• Tooltip flutuante curto
• Texto: "Select preferred block explorer"

Regras de negócio

• Aparece on hover
• Descreve apenas a função do setting

🟢 Insight Tooltip curto e direto — não inventa contexto que não cabe. Pancake calibrou que setting auto-evidente (escolher entre opções listadas e visíveis) não precisa de tutorial. Decisão consciente de evitar tooltip-bloat.

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante) Tooltip é tautológico: a label diz "Default Explorer", o tooltip diz "Select preferred block explorer". Equivale a tooltip de campo "Email" dizer "Type your email". Quem abre o tooltip provavelmente é o usuário que NÃO sabe o que é block explorer — e a resposta de Pancake é repetir o termo desconhecido. Tooltip serve a ninguém: iniciante que não sabe continua sem saber; avançado que sabe não precisava ler.

Fix óbvio (expandir pra "Block explorer = ferramenta para visualizar transações on-chain") melhora a primeira camada — mas ainda assume vocabulário ("on-chain", "transações"). Fix correto: tooltip que combina definição + impacto + diferenciação curta ("Where to view your transactions on-chain. Solscan: more detailed; Solana Explorer: official, cleaner.").

^friccao-1

🔴 Fricção secundária (cosmética — afeta intermediário) Tooltip não diferencia as opções listadas. Usuário que já sabe o que é block explorer mas não conhece diferença entre Solscan e Explorer fica sem ajuda — "preferred" pressupõe preferência prévia. Para decisão informada, precisa pesquisar fora do produto.

Fix correto (englobado pelo fix da fricção primária): enumerar trade-offs concretos das opções, não apenas descrever o conceito genérico. Custo: tooltip um pouco mais longo, mas justifica.

^friccao-2

🟡 Oportunidade competitiva (média leverage) Tooltips de settings tipicamente reescrevem a label do próprio setting — pattern observável em Uniswap, Pancake, 1inch. Passa nas 4 perguntas: convenção entre concorrentes, afeta iniciante (que abre tooltip esperando ajuda real), ninguém investiu em copy informativa por priorizar enxutidade visual, perceptível.

Diferenciação Kotai: tooltips informam OU diferenciam opções concretas — nunca apenas repetem a label. Custo: copy mais cuidadosa, processo de revisão de copy mais rigoroso. Trade-off: tooltips mais longos podem poluir UI em mobile — mitigável com link "Saiba mais" pra explicações longas, tooltip enxuto pro essencial.

Observação adicional: mesmo problema (tooltip = repetição da label) provavelmente se repete em outros "?" não analisados. Vale checar sistematicamente nos próximos tooltips do canvas — pode virar fricção transversal do produto, não isolada deste setting.

^oportunidade-1

24. Tooltip "RPC Connection"

Função: Tooltip do "?" ao lado de "RPC Connection" em Solana Settings.

Componentes

• Tooltip flutuante curto
• Texto: "Select preferred RPC endpoint"

Regras de negócio

• Aparece on hover
• Descreve a função do setting

🟢 Insight Tooltip curto mantém consistência interna com o tooltip do Default Explorer (An. 23) — mesmo formato paralelo. Pancake aplica padrão coeso nos tooltips de Solana Settings. Coerência intra-painel é decisão de design system, não acaso.

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante e intermediário) Mesmo problema da An. 23, com gravidade maior. Tooltip tautológico: "RPC Connection" + "Select preferred RPC endpoint" = repetição do termo desconhecido. Iniciante que abriu o tooltip exatamente porque não sabe o que é RPC continua sem saber.

Pior que o Default Explorer: RPC tem consequências técnicas concretas (latência, downtime, censura potencial, privacidade) que o usuário precisa entender pra decidir entre Triton/Helius/Custom. Tooltip que só repete a label deixa essa decisão sem suporte algum.

Fix óbvio (expandir pra "RPC = serviço que conecta o app à rede Solana") resolve a primeira camada. Fix correto: explicação + impacto + diferenciação curta ("Servidor que envia suas transações para Solana. Triton e Helius são providers comerciais com SLA; Custom permite RPC próprio."). Liga problema à solução, sem assumir vocabulário.

^friccao-1

🔴 Fricção secundária (estrutural — afeta intermediário) Tooltip não menciona que RPC tem dimensão de privacidade: o provider vê todas as transações do usuário, incluindo endereço de origem, valores, contratos chamados. Decisão técnica é também decisão de privacidade — e Pancake omite. Iniciante escolhe Helius por marca; nunca vê que está revelando histórico de trading para um terceiro.

Fix correto: expandir ou linkar pra explicação sobre privacidade ("RPC = quem vê suas transações antes de irem pra chain"). Trade-off: tooltip mais carregado; mitigável com "Learn more" como na An. 15 (Token Risk Scanning).

Reforço de fricção transversal (não é 🟡 nova) Vide An. 23 — tooltips de settings que repetem a label sem informar é fricção transversal do produto Pancake, repetida em pelo menos 2 tooltips do mesmo painel. Já classificado como 🟡 Oportunidade competitiva na An. 23. Aqui apenas reforça que o padrão é sistêmico (não isolado).

Observação adicional: o fato de o tooltip de RPC ter custo maior de educação (envolve privacidade + técnica) mostra que tooltips com "OU informa OU diferencia" precisam de regras condicionadas ao impacto da decisão. Settings cosméticos = tooltip curto OK; settings com impacto financeiro/privacidade = tooltip estruturado obrigatório.

^friccao-2

25. Helius selecionado (estado alternativo)

Função: Estado da UI quando RPC Connection muda de Triton (default) para Helius.

Componentes

• Pill Helius ativa (cor primária verde); Triton e Custom inativos
• Input atualizado: "https://robinett-76ulze-fast-mainnet.helius-r..." (truncada)
• Sem toast de confirmação, sem botão Save, sem indicador de "salvo"

Regras de negócio

• Cada provider tem URL específica injetada automaticamente
• Input não-editável quando provider é Triton ou Helius (preset)
• Mudança presumivelmente auto-save

🟢 Insight Feedback visual imediato — pill troca de cor, URL no input atualiza no mesmo gesto. Usuário vê que sua escolha teve efeito (URL mudou) e o produto preencheu por ele (não precisou digitar). Decisão correta: provider = preset semântico; URL técnica = consequência automática invisível pro iniciante, disponível para inspeção do avançado.

^insight-1

🔴 Fricção primária (cosmética → posicionamento — afeta intermediário) URL exibida ("robinett-76ulze-fast-mainnet.helius-r...") tem subdomínio que parece pertencer à conta corporativa Pancake no Helius, em vez do endpoint público genérico. Pode ser intencional (rate limits dedicados, SLA melhor pra Pancake) mas o usuário não tem como saber. Intermediário que reconhece Helius e espera endpoint público fica em dúvida: "Estou usando Helius diretamente, ou um proxy Pancake passando por Helius?". Truncamento da URL ("...") esconde info que poderia esclarecer.

Fix óbvio (expor URL completa no hover/expand) ajuda. Fix correto: separar visualmente "Provider" (quem fornece) de "Endpoint" (URL técnica), com indicação clara quando endpoint é compartilhado vs dedicado. Avançado quer topologia; iniciante não precisa, mas o produto não esconde.

^friccao-1

🔴 Fricção secundária (cosmética — afeta iniciante e intermediário) Nenhum feedback de mudança persistida. Pill mudou de cor, URL trocou, mas sem toast "Switched to Helius" nem checkmark "Saved" o usuário não tem garantia visual de que vai persistir. Convenção implicit auto-save existe (Notion, Linear), mas em settings que afetam transações financeiras o feedback explícito é mais defensivo.

Fix correto: micro-feedback (toast curto, badge "Saved", ou checkmark animado próximo à pill ativa). Trade-off: pequeno ruído visual.

Não é 🟡 — escopo isolado Comportamento específico desta UI Pancake; não há evidência de que ausência de feedback de save seja convenção de DEX cross-chain. Pode ser checado em ondas futuras de benchmark — se Uniswap e 1inch também silenciarem o save em settings críticos, promove a 🟡.

Observação adicional: este estado revela decisão arquitetural importante — Pancake oferece "providers comerciais com URL gerenciada por Pancake" como meio-termo entre "default opaco" e "Custom pleno". Iniciante usa Triton sem pensar; intermediário escolhe Helius pra alternativa; avançado vai pra Custom. Três níveis de controle, mesma UI.

^friccao-2

Codex Consolidado — Mega Menu (pancake)

Caráter geral do fluxo

O Mega Menu da Pancake funciona mais como vitrine de ecossistema do que como mapa de tarefas. Há bons acertos locais: busca com ações, proteção ligada por default, segmentação EVM/Solana e defesa em camadas para Expert Mode. Mas o padrão dominante é transferir para o usuário a tarefa de interpretar inventário, risco, rede, infraestrutura e jargão antes de executar o job principal.

Para iniciante/intermediário vindo de CEX, o fluxo comunica amplitude e potência, mas não prioridade. Trade, Earn, Perps, Play, AI, governança, settings, redes e provedores aparecem próximos demais em peso visual e sem progressão por intenção, maturidade ou consequência financeira. A direção para Kotai é tratar navegação e settings como orientação operacional: primeiro intenção e consequência prática; depois técnica, opções avançadas e cross-sell.

🟢 Insights recorrentes

1. Pancake tem bons defaults e padrões defensivos quando reconhece risco explícito.
O fluxo mostra sinais fortes de proteção pró-mainstream: Token Risk Scanning ligado por default em tela 11 e tela 15, Subgraph Health Indicator aparecendo apenas quando há atraso em tela 14, e Expert Mode avançando de tooltip para warning e type-to-confirm em tela 20 e tela 21.

O princípio aproveitável para Kotai é: tooltip explica, ação perigosa confirma, confirmação exige gesto deliberado. Isso é especialmente relevante para slippage extremo, Expert Mode, desligar proteções e mexer em infraestrutura.

2. A busca aponta para um modelo útil de “objeto + próxima ação”.
A busca já não é apenas informacional: tokens podem disparar Swap/Send/Receive em tela 9, e pools trazem metadados úteis como versão e fee tier em tela 10. O insight é que search pode virar entrada operacional, não só lista de resultados.

O limite é consistência: se resultado vira hub de ação, cada tipo de entidade precisa ter ação primária previsível e ações secundárias coerentes. Para Kotai, busca deve responder “o que você provavelmente quer fazer com isto?”, não apenas “isto existe”.

3. Separar contextos técnicos por ambiente é uma boa base.
A segmentação Global/EVM/Solana em tela 11, tela 16 e tela 22 reconhece que chains têm diferenças reais. Isso é melhor do que fingir que todas as redes compartilham o mesmo modelo operacional.

A oportunidade interna para Kotai é manter essa separação, mas traduzi-la em consequências: saldo, custo, velocidade, confiabilidade, privacidade e risco de erro.

🔴 Fricções recorrentes

1. A navegação mistura tarefas core, produtos avançados e superfícies experimentais sem hierarquia suficiente.
A recorrência aparece no logo dropdown com governança/tokenomics ao lado de links básicos em tela 1, em Perps como produto equivalente ao core em tela 4, em Play com Lottery/Prediction/launchpad em tela 5 e em AI como item primário em tela 6.

O problema não é quantidade de itens, mas ausência de taxonomia por intenção, risco e maturidade. Kotai deve reservar a nav primária para jobs centrais do target e subordinar produtos avançados, especulativos ou adjacentes por nível de consequência.

2. Labels e tooltips frequentemente nomeiam tecnologia, fornecedor ou vocabulário interno antes da tarefa.
O padrão atravessa Info/Voting/Burn Dashboard em tela 1, Farm/Syrup Pools em tela 3, AI em tela 6, Subgraph em tela 14, GWEI em tela 16 e RPC endpoint em tela 24.

Isso reduz confiança porque obriga o usuário a interpretar arquitetura antes de decidir. A correção não é apagar termos técnicos, mas hierarquizá-los: label primária em linguagem de usuário, termo técnico em secondary label, tooltip ou detalhe expansível.

3. Informação técnica relevante aparece antes de ser traduzida em decisão prática.
Multi-chain surge como lista plana em tela 8, Tokens/Pools se misturam na busca em tela 7, V2/V3/Infinity/CLAMM e fee tiers aparecem crus em tela 10, e settings como Subgraph Health e Token Risk Scanning ficam visualmente próximos de preferências banais em tela 11.

Kotai deve mostrar primeiro consequência: “rede com saldo”, “pool recomendada para este par”, “proteção contra token suspeito”, “dados podem estar atrasados”. A técnica fica disponível, mas não como primeira camada de decisão.

4. Settings de alto impacto são tratados como preferências comuns até tarde demais.
Expert Mode aparece em lista plana antes de receber defesa melhor no modal, com risco destacado em tela 16, tela 20 e tela 21. Custom RPC fica acessível sem warning em tela 26, e mudanças de provider/RPC não dão persistência clara em tela 25 e tela 26.

Regra para Kotai: settings cosméticos, informacionais, transacionais e perigosos precisam de UI proporcional. Custom RPC, Expert Mode e desligar proteções exigem validação, warning e confirmação; não só toggle ou botão genérico.

5. Tooltips explicam definição, mas raramente mostram consequência operacional.
Isso aparece em Show username em tela 13, Subgraph em tela 14, Token Risk Scanning em tela 15, gas em tela 17, Expert Mode em tela 18 e RPC/Explorer em tela 23 e tela 24.

A fórmula recomendada é curta: o que muda, quando acontece e qual efeito ou risco esperado. Para toggles críticos, tooltip sozinho não basta; precisa aparecer também no momento da consequência.

🟡 Oportunidades competitivas

1. Transformar settings em painel por consequência, não em lista plana de preferências.
A tela de settings reúne itens cosméticos, informacionais, transacionais e perigosos com peso parecido em tela 11. A oportunidade competitiva é organizar configurações por impacto: aparência, privacidade, execução, proteção, dados e infraestrutura. Isso passa na régua porque concorrentes principais tendem a usar painéis planos, o público iniciante/intermediário é afetado diretamente, a causa parece falta de investimento em design de decisão e a diferença seria perceptível quando o usuário tenta desligar proteção ou alterar uma configuração de alto impacto.

Para Kotai, o ganho é reduzir erro antes da ação: toggles críticos devem aparecer com status, consequência resumida e barreira proporcional. Settings deixam de ser gaveta técnica e passam a funcionar como mapa de risco operacional.

2. Usar educação in-context para risk scoring no momento em que o risco importa.
Token Risk Scanning já aparece ligado por default, mas a explicação ainda tende a se comportar como tooltip/disclaimer em tela 15. A oportunidade é levar a educação para o contexto da decisão: quando o usuário vê ou negocia um token, mostrar por que ele foi marcado, quais sinais pesaram e qual ação segura está disponível.

Isso é competitivo porque muitos DEX tratam risco como texto auxiliar ou letra pequena; o iniciante vindo de CEX precisa entender consequência, não auditoria técnica. A solução depende mais de UX/copy e integração no fluxo do que de impossibilidade estrutural, e ficaria claramente visível no momento do swap ou do bloqueio de token suspeito.

3. Codificar CTAs perigosos por consequência, especialmente em modais de risco.
O warning de Expert Mode em tela 20 mostra uma oportunidade estrutural: DEX frequentemente preservam o CTA destrutivo com aparência primária, enquanto o usuário iniciante tende a seguir cor e destaque visual. Kotai pode diferenciar ações seguras, reversíveis, arriscadas e destrutivas no design system, não apenas no texto do modal.

A diferença seria percebida imediatamente: em vez de destacar “ativar” como caminho natural, a interface destaca a saída segura e obriga a ação perigosa a competir com fricção visual e confirmação deliberada. Isso complementa o insight de defesa em camadas, mas vai além dele: cria linguagem sistêmica de consequência para todos os fluxos críticos.

Pontos isolados (1 tela)

• Logo como dropdown em tela 1 é candidato forte, mas permanece menos sustentado que as oportunidades competitivas acima neste material: logo deveria tender a home, com institucional/DAO em área própria.
• Trade mistura comprar com fiat e swap on-chain em tela 2. Direção: separar entrada de capital de execução on-chain.
• Idioma sem busca em tela 12 é fricção localizada; typeahead por endônimo/exônimo resolveria.
• Subgraph Health em tela 14 sugere uma oportunidade de status operacional orientado por consequência, mas neste consolidado ela foi absorvida pelas fricções de jargão técnico e pela oportunidade maior de settings por impacto.
• “Don’t show this again” no warning de Expert Mode em tela 20 enfraquece barreira que deveria persistir.
• Type-to-confirm em inglês, sem placeholder claro, cria ruído de localização em tela 21.
• Helius parece endpoint gerenciado, mas provider e endpoint não são distinguidos em tela 25.

Nota de auditoria Codex

A régua de 🟡 não exige recorrência em duas telas do mesmo fluxo; ela depende de diferença cross-concorrente, impacto no target, causa não estrutural e percepção clara pelo usuário. Por isso, este consolidado promoveu oportunidades competitivas quando as fontes amostradas sustentam essas quatro perguntas: hierarquia de settings por consequência em tela 11, educação in-context sobre risk scoring em tela 15 e CTAs perigosos codificados por consequência em tela 20.

Oportunidades com evidência mais localizada foram preservadas como pontos isolados ou absorvidas em padrões maiores. Em especial, tela 14 reforça o tema de status operacional e jargão técnico, mas não precisou virar item autônomo porque o ganho competitivo fica mais forte quando tratado dentro de settings por impacto e comunicação de consequência.

5. Play Dropdown

Função: Submenu que agrupa produtos "não-essenciais" do ecossistema Pancake — gambling, speculation curto-prazo e launchpad de tokens.

Componentes

• Springboard ↗ (launchpad de tokens, external link)
• Prediction (apostas binárias em preço de BNB/CAKE)
• Lottery (loteria com tickets em CAKE)
• CAKE.PAD (launchpad interno, sem ↗)

Regras de negócio

• Springboard é app externa ao subdomínio principal (ícone ↗)
• Prediction = aposta binária short-term (up/down em 5min)
• Lottery = sorteio recorrente
• CAKE.PAD = IDO/IFO de novos projetos

🟢 Insight Uso correto de ↗ no Springboard antecipa saída de contexto. Agrupamento sob rótulo "Play" sinaliza separação consciente entre "negociação séria" (Trade) e "engajamento opcional" — Pancake reconhece que esses produtos não pertencem ao fluxo principal de DEX.

^insight-1

🔴 Fricção estrutural (afeta iniciante e intermediário) "Play" agrupa quatro categorias semanticamente incompatíveis sob um rótulo lúdico:

• Lottery = gambling puro (sorte)
• Prediction = speculation binária short-term (≈gambling de cripto)
• Springboard, CAKE.PAD = investimento early-stage em IDO

Empacotar gambling + investimento sob "diversão" é problemático em produto financeiro: iniciante que clica em Lottery por curiosidade não percebe que está fazendo gambling com cripto real; iniciante que clica em Springboard esperando "play" encontra IDO e pode comprar token com expectativa errada de natureza (jogo, não investimento).

O fix óbvio (renomear "Play" pra "Mais") falha — só esconde o problema, mantendo a mistura. Outro fix óbvio (separar gambling de IDO) também é insuficiente: a fricção real é a presença desses produtos no DEX, não o rótulo que os agrupa.

Direcionamento Kotai: não oferecer gambling explícito (Lottery, Prediction). Se houver launchpad, vira entrada nomeada própria (ex: "Launchpad" ou "Early Access") com disclosure de risco — não disfarçado como "Play".

Reforço posicional (não é 🟡 — Pancake é única, não convenção): entre os principais DEX, Pancake é a única que mistura gambling explícito (Lottery, Prediction) com swap/pools — Uniswap, 1inch, SushiSwap não fazem. Por isso falha a pergunta 1 do teste-padrão de 🟡 ("todos os concorrentes fazem igual?") e não pode ser classificado como Oportunidade competitiva.

Vale como decisão posicional, não como diferenciação contra convenção: Kotai assume postura de produto financeiro sério, sem gambling. Trade-off: perde-se canal de retenção via mecânicas viciantes que driveriam sessões recorrentes — sacrifício alinhado ao target iniciante vindo de CEX (público que regulação cripto crescente já está protegendo de gambling embutido).

^friccao-1

6. AI — Link Direto (sem dropdown)

Função: Entrada da nav que leva ao subdomínio pancakeswap.ai — aparentemente um app/feature com camada AI sobre o produto.

Componentes

• Label "AI" na nav primária
• Sem chevron ▾, sem ↗, sem tooltip, sem badge
• Tratamento visual idêntico a Trade/Earn/Play/Perps

Regras de negócio

• Subdomínio dedicado (pancakeswap.ai) — app independente do core
• Sem indicação no menu do que o usuário vai encontrar
• Sem onboarding contextual ao entrar

🟢 Insight Investimento em surface area dedicada ao invés de embutir como feature dentro de swap protege a UX core do swap form de poluição experimental. Decisão correta de isolamento — se a feature evoluir ou for descontinuada, não afeta o produto principal.

^insight-1

🔴 Fricção estrutural (afeta iniciante e intermediário) "AI" como label de nav não comunica nada de funcional. Iniciante não sabe se vai encontrar: agente conversacional? automação de trade? alertas? sugestão de pool? otimização de rota? A label é especulativa, não informativa — funciona como marketing dentro da nav, não como navegação.

O fix óbvio (tooltip "powered by AI" ou caption "Smart features") agrava o problema: explica a tecnologia, não o trabalho que será feito pelo usuário. Labels de nav devem nomear a tarefa do usuário ("Ask anything", "Find best route", "Summarize portfolio"), não a infraestrutura ("AI"). Equivale a ter botão "Database" na nav.

Solução nesse escopo: renomear para o trabalho que a feature efetivamente faz, descobrível pelo próprio nome. Se o app cobre múltiplas tarefas, a entrada vira hub nomeado pela tarefa primária (a mais usada), com as outras descobertas dentro do app — não pelo termo guarda-chuva "AI".

Direcionamento Kotai: features com camada de modelo são nomeadas pelo benefício ao usuário, nunca pela tecnologia. "AI" não aparece como label de navegação.

Observação adicional (não é 🟡 hoje): label genérico "AI" como entrada de nav é, por enquanto, decisão Pancake-específica entre os concorrentes diretos analisados (Uniswap, 1inch ainda não fazem). Por isso falha a pergunta 1 do teste de 🟡 e não se classifica como Oportunidade competitiva agora — é fricção Pancake-específica.

Risco emergente a monitorar: se 2-3 DEX adotarem "AI" como label de nav nos próximos meses (movimento provável dada a pressão de mercado), o padrão vira convenção problemática (1b) e a fricção promove-se a 🟡. Vale revisar essa classificação em ondas trimestrais de benchmark.

^friccao-1

7. Search Overlay (populado)

Função: Busca global unificada de tokens e pools, com filtro multi-chain. Disparada pelo campo "Search /" no header.

Componentes

• Campo de busca com placeholder "Search Tokens / Pools"
• Stack de avatares de redes + indicador "+6" (chevron sugere expansão)
• Tabs: All (selecionado), Tokens, Pools
• Section header "Tokens by 24h volume" com ícone fogo
• Lista de tokens: avatar, símbolo, nome, rede, kebab ⋯
• Loading indicator no rodapé (paginação/cross-chain fetch)

Regras de negócio

• Ordenação por volume 24h (curadoria automática no estado vazio)
• Suporta multi-chain (avatares no topo indicam redes ativas no filtro)
• "All" combina Tokens + Pools no mesmo resultado

🟢 Insight Unificar busca de token e pool num campo só é correto pro target: iniciante não distingue "token" de "pool" como entidades separadas. Ordenação por volume 24h no estado vazio serve de descoberta pra quem não tem token específico em mente — substitui o leaderboard como porta de entrada.

^insight-1

🔴 Fricção (estrutural — afeta iniciante) Na aba "All", tokens e pools aparecem como duas seções com tipografia muito similar e sem hierarquia visual forte entre elas. Iniciante que busca "USDT" recebe um item "USDT" e em seguida vários pares "USDT/WBNB", "USDT/BTCB" — sem entender que uns são tokens e outros são pools. A pergunta natural ("qual destes eu preciso?") fica sem resposta na própria tela.

Fix óbvio (forçar tabs separadas Tokens/Pools, sem "All") falha porque obriga o iniciante a escolher categoria antes de saber o que existe. Fix verdadeiro: na aba "All", colapsar pools relacionadas ao token sob o item do token (drill-down), em vez de listar paralelamente.

Direcionamento Kotai: busca unificada com agregação por entidade primária (token); pools como sub-resultados expansíveis. Trade-off: avançado que busca pool específica precisa de 1 clique a mais — aceitável pro target principal.

^friccao-1

🟡 Oportunidade competitiva (alta leverage no target) Uniswap, 1inch e Pancake todos têm busca global "/" no header e todos misturam tokens+pools no resultado de forma similar. Passa nas 4 perguntas: convenção entre concorrentes, afeta iniciante diretamente, ninguém resolveu por priorizar recall sobre clareza, diferenciação perceptível.

Diferenciação: pré-resolver intent pela própria digitação — query como "USDT" defaulta para ação direta (Swap USDT como sugestão primária); pools só aparecem quando o usuário digita par ("USDT/WBNB") ou alterna pra tab Pools. Trade-off: cobre menos resultados no primeiro paint.

^oportunidade-1

11. Preferências Globais (popover)

Função: Painel popover de configuração acionado pelo ícone ⚙️ no header. Centraliza preferências de UX, cosméticas, e proteções de segurança.

Componentes

• Tabs: Global Settings (ativa), EVM Settings, Solana Settings
• Language (dropdown — English)
• Dark mode (toggle sol/lua)
• Show username (toggle off) + ícone ?
• Show testnet (toggle off)
• Subgraph Health Indicator (toggle off) + ?
• Token Risk Scanning (toggle ON, verde) + ?

Regras de negócio

• Settings por escopo: Global, EVM-specific, Solana-specific
• Token Risk Scanning ligado por default
• Demais toggles desligados por default

🟢 Insight Token Risk Scanning ligado por default é decisão correta e contracorrente em DeFi: protege iniciante de tokens scam sem ele saber pedir proteção. Alinha com posicionamento "DEX seguro pra mainstream" em oposição à ortodoxia "user choice puro".

Tabs Global/EVM/Solana é arquitetura honesta — preferências chain-family ficam onde fazem sentido, não num painel único inchado. Reconhece heterogeneidade real de configurações multi-chain.

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante) O painel mistura cosméticas (Language, Dark mode), preferências (Show username, testnet), debug avançado (Subgraph Health Indicator) e proteção crítica (Token Risk Scanning) na mesma lista plana, com toggles visualmente idênticos. Iniciante que abre por curiosidade ou pra mudar idioma encontra opções incompreensíveis e pode desligar Token Risk Scanning achando que está "limpando interface" — perde proteção sem perceber consequência.

Fix óbvio (esconder Subgraph) falha — devs e avançados precisam dele. Fix correto: agrupamento por consequência (Cosméticas / Preferências / Segurança / Avançadas), com Segurança expandido por default e toggles de risco com style distinto + warning ao desligar.

Direcionamento Kotai: hierarquia visual de consequência. Toggles de segurança nunca têm tratamento idêntico a toggles de tema/idioma.

^friccao-1

🟡 Oportunidade competitiva (alta leverage no target) Uniswap, 1inch, Pancake todos colocam settings em painel plano sem hierarquia entre cosméticos e segurança. Passa nas 4 perguntas: convenção entre concorrentes, afeta iniciante diretamente, ninguém investiu por preguiça de design, diferenciação perceptível (especialmente em momento crítico — desligar proteção por engano).

Trade-off: design mais complexo, mais real-estate ocupado, decisão explícita sobre o que cabe em "Segurança" exposta (pode parecer alarmismo se mal calibrada).

^oportunidade-1

8. Filtro de Redes (popover)

Função: Filtro multi-chain da busca. Acionado pelo stack de avatares + chevron ao lado direito do campo.

Componentes

• Header "All networks" — toggle master no topo
• Lista de 9 redes com checkmark verde individual: Solana, BNB Smart Chain, Ethereum, ZKsync Era, Arbitrum One, Linea Mainnet, Base, opBNB, Monad
• Todos selecionados por default

Regras de negócio

• Toggle individual por rede; toggle master "All networks"
• Default = todas ligadas
• Filtro afeta tanto resultados de Tokens quanto de Pools

🟢 Insight Toggle master + estados individuais é padrão claro (Apple Mail, Slack notif, etc.) — convenção válida bem aplicada. Default "tudo ligado" é correto pra busca de descoberta: iniciante quer achar resultados antes de filtrar.

^insight-1

🔴 Fricção (estrutural — afeta iniciante) Lista plana de 9 redes exige que o usuário saiba o que cada uma significa. "opBNB", "Linea", "ZKsync Era" e "Monad" são ruído pra iniciante vindo de CEX que mal sabe a diferença entre ETH e BNB. Não há agrupamento (mainnet vs L2 vs experimental) nem priorização por contexto do usuário (redes onde ele tem saldo).

Fix óbvio (esconder redes obscuras) falha porque o produto Pancake serve usuários multi-chain — esconder Monad pra quem tem token Monad quebra a busca. Fix verdadeiro: agrupamento visual ("Mainnets" / "L2s" / "Outras") com colapso, e priorização contextual (redes da carteira conectada no topo).

Direcionamento Kotai: lista de redes priorizada pelo contexto — carteira conectada → top 3 com saldo no topo; sem carteira → mainnets primeiro, alternativas colapsadas. Trade-off: requer state de wallet pra renderizar lista contextualizada.

^friccao-1

🟡 Oportunidade competitiva (alta leverage no target) Multi-chain é frente onde Uniswap, 1inch e Pancake todos investem, mas todos mostram lista plana de redes sem hierarquia ou contextualização. Passa nas 4 perguntas: convenção atual entre concorrentes, afeta iniciante diretamente (sobrecarga de seleção), ninguém priorizou por contexto do usuário, diferenciação perceptível (especialmente em redes com saldo evidenciadas).

Trade-off da diferenciação: dependência de estado de wallet pra renderização; degradação graciosa necessária no estado desconectado.

^oportunidade-1

9. Token Action Menu (kebab)

Função: Popover de ações rápidas sobre um token listado no resultado de busca. Acionado pelo ícone ⋯ do row do token.

Componentes

• Row do token destacado (USDT — Tether USD)
• Popover com 3 ações: Swap, Send, Receive (com ícones individuais)

Regras de negócio

• Ações pertencem ao token clicado (contexto preservado)
• Swap → leva ao swap form com USDT pré-selecionado
• Send → fluxo de envio do USDT
• Receive → mostra endereço de recebimento

🟢 Insight Oferecer 3 ações (Swap/Send/Receive) num popover do kebab é decisão correta — não polui o row com 3 botões inline, e oferece atalhos relacionados além da ação primária. Resolve problema real: busca é caminho de entrada para ação, não só para info.

^insight-1

🔴 Fricção (cosmética — afeta iniciante) O comportamento dual do row (click no row = ação default; click no kebab = mais opções) não é sinalizado. Iniciante não descobre que existem 3 ações até clicar no kebab — não há hover preview, caption ou affordance visual diferenciada.

Fix óbvio (substituir kebab por 3 ícones inline) falha porque polui visualmente o resultado de busca, especialmente em viewport pequeno. Fix correto no escopo da tela: caption sutil no hover do row indicando ação default ("Click to swap") + tooltip discreto no kebab ("More actions"). Mantém affordance limpa e ensina o usuário em primeiro contato.

Direcionamento Kotai: ação default no click do row sempre comunicada (texto secundário ou ícone), ações secundárias no kebab com label revelada por hover.

Não é 🟡: uso de kebab para esconder ações secundárias é convenção válida na web (Gmail, Linear, Notion, GitHub). Aplica armadilha 1a (convenção válida → descartar): o problema não está na convenção, e sim na ausência de pista para iniciante que ainda não a internalizou. Não é diferenciação competitiva — é polimento de discoverability dentro de padrão existente.

Observação adicional: as 3 ações expostas (Swap/Send/Receive) revelam que a Pancake já está pensando o search como hub multi-função, não só como entrada do swap. Decisão estratégica relevante a se monitorar — sinaliza pressão pra ser "wallet-like" dentro do DEX.

^friccao-1

10. Pool Action Menu (kebab)

Função: Popover sobre uma pool listada no resultado de busca. Diferente do token, oferece só "Copy address" (1 ação).

Componentes

• Lista de pools com avatares dual, par, rede, fee tier visível (V2 0.25%, V3 0.05%, V3 0.01%, Infinity/CLAMM)
• Popover sobre pool ativa: "Copy address" (1 item)

Regras de negócio

• Cada pool mostra versão de protocolo (V2/V3/Infinity) e fee tier
• Click no row da pool → detalhe ou fluxo de adicionar liquidez
• Kebab da pool tem só 1 ação, vs 3 do token

🟢 Insight Expor fee tier (0.05%, 0.25%, 0.01%) e versão de protocolo (V2/V3/Infinity) já no resultado de busca é útil pra usuário avançado decidir qual pool entrar antes de clicar.

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante e intermediário) Inconsistência interna do produto: kebab do token oferece 3 ações (Swap/Send/Receive); kebab da pool oferece 1 (Copy address). Mesma affordance visual, comportamento radicalmente diferente. Iniciante que aprendeu "kebab = ações" no token agora vê só "Copy address" na pool e fica perdido: cadê adicionar liquidez? cadê visualizar detalhe?

Fix óbvio (mover Copy address pra dentro do row) falha porque copy é utilitário que precisa ser distinto da ação principal (entrar na pool). Fix correto: kebab da pool oferece ações condizentes — "Add liquidity", "View pool", "Copy address" — mantendo affordance consistente com conteúdo coerente.

^friccao-1

🔴 Fricção secundária (estrutural — afeta iniciante) Exposição de "V2", "V3", "Infinity", "CLAMM" e fee tiers (0.01%, 0.05%, 0.25%) na descoberta de pool para usuário que não sabe o que esses termos significam. Iniciante vê "USDT/WBNB V3 0.01%" e "USDT/WBNB V3 0.05%" como duas opções sem entender que 0.01% é melhor para stable-like pair.

Fix óbvio (esconder versão/fee) falha porque ambos têm impacto financeiro real (impermanent loss, capital efficiency). Fix verdadeiro: label semântica ("Recomendado pra par estável", "Alta volatilidade — taxa maior") com versão técnica em tooltip; ordenar pools por adequação ao par antes de volume.

^friccao-2

🟡 Oportunidade competitiva (média leverage) Exposição crua de versão de protocolo + fee tier na descoberta de pool é padrão em Uniswap (V2/V3/V4), Pancake (V2/V3/Infinity/CLAMM) e SushiSwap. Passa nas 4 perguntas: convenção entre concorrentes, afeta iniciante diretamente, ninguém resolveu por priorizar usuário power, perceptível.

Diferenciação Kotai: pool listada com label semântica de adequação ao par + ordenação por "best fit" antes de volume. Versão e fee técnicos em tooltip. Trade-off: avançado precisa de 1 hover para ver tier exato — aceitável pro target.

^oportunidade-1

17. Tooltip "Default Transaction Speed (GWEI)"

Função: Tooltip do "?" ao lado de "Default Transaction Speed (GWEI)" em EVM Settings.

Componentes

• Tooltip flutuante com dois parágrafos
• Texto 1: "Adjusts the gas price (transaction fee) for your transaction. Higher GWEI = higher speed = higher fees."
• Texto 2: "Choose 'Default' to use the settings from your current blockchain RPC node."

Regras de negócio

• Default = delega decisão ao RPC node da wallet conectada
• Instant/Standard/Fast = override manual com valor sugerido

🟢 Insight Duas decisões fortes em poucas linhas: (1) traduz GWEI pra "gas price (transaction fee)" entre parênteses, removendo opacidade do termo logo no primeiro contato; (2) usa fórmula simples "Higher GWEI = higher speed = higher fees" — uma equação que iniciante decifra mesmo sem dominar a unidade. O segundo parágrafo é honesto sobre o que "Default" significa em termos arquiteturais.

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante) A fórmula cria modelo mental incompleto. Iniciante lê e infere "se eu botar GWEI baixo, é mais barato" — mas não informa que GWEI baixo demais faz a transação ficar pendente, falhar ou exigir replace-by-fee. O risco de "muito baixo" não está mencionado. O tooltip cobre o eixo barato↔caro mas ignora o eixo seguro↔arriscado.

Fix óbvio (adicionar "Too low = transaction may fail") resolve parcialmente. Fix correto: visualização de faixa no próprio tooltip ou seletor — Low (risco de stuck), Default (recomendado), High (pago a mais). Mostra os limites antes do usuário descobrir por erro.

^friccao-1

🔴 Fricção secundária (cosmética — afeta iniciante) "Choose 'Default' to use settings from your current blockchain RPC node" expõe arquitetura ("RPC node") que iniciante não precisa entender. O usuário só precisa saber "Default = a wallet decide por você". Substituir "RPC node" por "wallet" no tooltip preserva precisão sem cobrar vocabulário.

Direcionamento Kotai: tooltips de gas/fee mostram faixa de risco + recomendação, não só fórmula descritiva. Termos de infra ("RPC node") substituídos por entidades familiares ("wallet", "rede").

^friccao-2

🟡 Oportunidade competitiva (média leverage) Tooltips de gas em Uniswap, Pancake, 1inch tipicamente explicam GWEI em texto sem visualização de faixa nem alerta de risco. Passa nas 4 perguntas: convenção entre concorrentes, afeta iniciante (que pode subestimar gas e ter swap stuck), ninguém investiu por priorizar simplicidade textual, perceptível.

Diferenciação: viz de "faixa segura" no tooltip ou na própria UI de seleção (slider com zones). Trade-off: mais real-estate no painel.

^oportunidade-1

18. Tooltip "Expert Mode"

Função: Tooltip do "?" ao lado do toggle Expert Mode em EVM Settings → INTERFACE SETTINGS.

Componentes

• Tooltip flutuante de 1 frase + disclaimer
• Texto: "Bypasses confirmation modals and allows high slippage trades. Use at your own risk."

Regras de negócio

• Ligar Expert Mode = remove modais de confirmação de swap
• Permite execução com slippage alto sem confirmação adicional
• Disclaimer textual ao fim

🟢 Insight Comunicação direta e honesta: descreve o que faz (bypassa confirmações), o que possibilita (high slippage trades), e fecha com disclaimer. Não esconde o trade-off nem suaviza com marketing. Pancake reconhece que Expert Mode é feature destrutiva e não tenta vender como "atalho avançado".

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante) "Use at your own risk" é a única sinalização de severidade, e está no fim do texto. Iniciante curioso lê "Bypasses confirmation modals" como benefício ("menos cliques!") antes de chegar ao warning. Não há ícone de alerta, cor distinta, nem cenário concreto do que pode acontecer. "High slippage" é termo abstrato — iniciante não associa "high" a "swap que executa com -90% do valor esperado".

Fix óbvio (negritar "high slippage" ou adicionar ⚠️) ajuda marginalmente. Fix correto: tooltip estruturado em hierarquia visual com warning como bloco destacado + cenário concreto ("Sem Expert Mode: swap cancela se preço variar mais de 1%. Com Expert Mode: executa mesmo com perda de 50%"). Mostra a consequência, não só descreve a feature.

^friccao-1

🔴 Fricção secundária (estrutural — encadeada com An. 16) O tooltip é a única barreira educacional antes do toggle plano. Tooltip pressupõe que o usuário hover, leia até o fim, e processe o disclaimer — fluxo frágil. Usuário que ativa direto (sem hover no "?") ativa Expert Mode sem ver nenhum aviso. Tooltip explicar não substitui fricção no momento de ativar.

Direcionamento Kotai: features destrutivas têm tooltip-as-warning (consequência concreta + cenário) E fricção no próprio toggle (modal de confirmação ao ativar, não toggle direto). Defesa em camadas, não single-point.

^friccao-2

🟡 Oportunidade competitiva (alta leverage no target) Expert Mode tooltip seco é convenção entre Uniswap, Pancake, SushiSwap — herança histórica do código-fonte original Uniswap. Passa nas 4 perguntas: convenção entre concorrentes, afeta iniciante (que pode ativar achando atalho), ninguém investiu por inércia, perceptível.

Diferenciação: tooltip-as-warning com exemplo de perda concreta em moeda local do usuário (R$ ou US$ específico). Trade-off: tooltip mais longo, requer copy localizada.

^oportunidade-1

16. EVM Settings (tab)

Função: Aba EVM-specific do painel de Preferências. Configurações de transação e interface que se aplicam apenas a redes EVM.

Componentes

• Section "TRANSACTION SETTINGS"
  • Default Transaction Speed (GWEI) + ? — 4 pills: Default (selecionado), Instant (0.07), Standard (0.05), Fast (0.06)
  • Tx deadline + ? — input "20" + "Mins" + botão Reset
• Section "INTERFACE SETTINGS"
  • Expert Mode + ? (toggle off)
  • Flippy sounds + ? (toggle off)

Regras de negócio

• 4 níveis de velocidade com gwei numérico sugerido
• Tx deadline default 20min (Reset volta ao default)
• Expert Mode = desabilita modais de confirmação em swap
• Flippy sounds = efeitos sonoros do swap

🟢 Insight Pills com label semântica (Default/Instant/Standard/Fast) + gwei numérico em parênteses atende dois perfis na mesma UI: iniciante escolhe pela velocidade, avançado pelo gwei. Boa decisão de progressive disclosure.

Separação visual TRANSACTION SETTINGS / INTERFACE SETTINGS com section headers é a hierarquia que falta no painel Global (Análise 11). Ironia: a mesma Pancake sabe agrupar por consequência aqui, mas não aplica no painel principal.

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante) "GWEI" no label primário é jargão. Iniciante não sabe que gwei é unidade de gas, e mesmo sabendo não decifra por que escolher entre "Default" e "Instant (0.07)". O tooltip ajuda parcialmente, mas o label impõe barreira de comprensão antes do clique.

Fix óbvio (esconder gwei) falha porque avançado precisa do número. Fix correto: label primária semântica ("Transaction speed"), gwei como secondary text na pill ("Fast • 0.06 gwei"). Iniciante escaneia pela velocidade; avançado lê o número sem clicar.

^friccao-1

🔴 Fricção secundária (estrutural — afeta iniciante) "Expert Mode" como toggle plano sem warning visual é perigoso. Descrição real (disable confirmation modals) só aparece no tooltip — mas o toggle é visualmente idêntico ao "Flippy sounds" (efeito sonoro). Iniciante pode ligar Expert Mode achando que é "modo avançado" inofensivo (atalhos, skins) e perder confirmações que previniriam slippage catastrófico.

Fix óbvio (warning "experts only" no label) ajuda. Fix correto: Expert Mode atrás de confirmação modal ao ativar — não toggle direto.

^friccao-2

🟡 Oportunidade competitiva (alta leverage no target) "Expert Mode" como toggle único sem fricção é padrão histórico em Uniswap (clone original), Pancake, SushiSwap. Passa nas 4 perguntas: convenção entre concorrentes, afeta iniciante (que pode ativar por engano), ninguém colocou fricção por razões históricas (Uniswap foi feita por/para devs), perceptível.

Diferenciação: features destrutivas atrás de fricção explícita. Expert Mode só ativável via flow educacional curto, não toggle plano. Trade-off: avançado ganha 1 clique a mais ao habilitar — minoria do target Kotai.

^oportunidade-1

2. Trade Dropdown

Função: Submenu da entrada "Trade" na nav primária. Lista os dois modos de operação considerados "trade" pela Pancake: Swap (troca de tokens on-chain) e Buy Crypto (on-ramp fiat→cripto).

Componentes

• Item "Swap" — destacado em cor primária (estado atual/selecionado)
• Item "Buy Crypto"
• Dropdown abre em hover/click sobre "Trade" na nav

Regras de negócio

• "Swap" leva pra rota /swap (mesma URL do estado atual)
• "Buy Crypto" leva pra fluxo de on-ramp fiat
• TWAP e Limit NÃO estão neste dropdown — vivem como tabs internos dentro do form de Swap

🟢 Insight Lista enxuta — apenas 2 itens, sem ruído de funcionalidades avançadas (TWAP, Limit ficam dentro do swap form). O destaque visual em "Swap" sinaliza estado atual e ajuda orientação espacial: o usuário entende que já está nessa página, não precisa clicar de novo.

^insight-1

🔴 Fricção (estrutural — afeta iniciante e intermediário) Inconsistência arquitetural: modos de negociação estão divididos em dois lugares. "Swap" e "Buy Crypto" estão no dropdown Trade; "TWAP" e "Limit" estão como tabs DENTRO do form de Swap. Não há regra clara que explique o porquê — Buy Crypto também não é tab no form, e Limit não é entrada de dropdown. O usuário precisa construir dois modelos mentais paralelos: "alguns modos ficam no menu, outros ficam no form".

Por que o fix óbvio falha: jogar tudo no dropdown infla a nav e duplica o que já está exposto nos tabs (Swap/TWAP/Limit). Jogar tudo nos tabs força Buy Crypto a virar tab — mas Buy Crypto é fluxo diferente (on-ramp fiat ≠ swap on-chain), então não pertence ao mesmo grupo de tabs.

Direcionamento Kotai: separar conceitualmente "swap on-chain" (Swap, TWAP, Limit como tabs do form) de "entrada de capital" (Buy Crypto = on-ramp, vira ação separada na nav ou no header de portfólio). Trade-off: perde-se um item no menu Trade, que pode ser eliminado ou renomeado pra "Swap" direto.

^friccao-1

🟡 Oportunidade competitiva (média leverage) Concorrentes (Uniswap, Pancake, 1inch) misturam modos de execução (Swap/Limit/TWAP) com modos de entrada/saída (Buy Crypto, Send) na mesma nav ou dropdown. Para iniciante, "trocar tokens que eu já tenho" e "comprar cripto com cartão" são tarefas radicalmente diferentes — uma exige wallet conectada e gas, a outra exige KYC e cartão de crédito. Tratá-las como sub-itens de "Trade" assume que o usuário já entende que ambas são "negociação".

Diferenciação: separar "Comprar com fiat" como ação distinta (botão no header ou empty state do portfólio), reservando Trade só para operações on-chain. Trade-off: perde-se um path de descoberta para on-ramp pra quem entra pela nav.

^oportunidade-1

3. Earn Dropdown

Função: Submenu de produtos de geração de yield. Dois caminhos: Farm / Liquidity (dual-asset) e Syrup Pools (single-asset).

Componentes

• Farm / Liquidity → pools com farming reward (LP + emissão de CAKE)
• Syrup Pools → staking single-asset (deposita 1 token, reward em outro)

Regras de negócio

• Farm exige depositar par (ex: BNB/CAKE), gera LP token + reward em CAKE
• Syrup exige depositar 1 token, gera reward em outro
• Categorização por mecânica financeira, não por intenção do usuário

🟢 Insight Separação dual-asset vs single-asset é categorização útil pra quem já entende DeFi: ajuda intermediário a achar o produto certo rápido. Lista curta (2 itens) sem ruído.

^insight-1

🔴 Fricção (estrutural — afeta principalmente iniciante vindo de CEX) "Farm" e "Syrup Pool" exigem vocabulário DeFi-nativo que iniciante vindo de Binance/Coinbase não tem. Em CEX, "Earn" é botão único com APY exposta e produto opaco por baixo; aqui, o usuário precisa escolher entre dois termos cuja diferença ele não decodifica sem contexto. "Farm" é termo padrão de uma classe de DEX (Sushi, Pancake, Curve usam — embora Uniswap não, por não emitir token), então o problema não é nomenclatura proprietária e sim ausência de tradução para a intenção do usuário ("quero ganhar com meus tokens").

Solução óbvia (renomear pra "Pools"/"Staking") falha por duas razões: (1) "Pool" sozinho colide com Liquidity Pool sem farming reward — abstração distinta na própria Pancake; (2) "Staking" não captura a mecânica dual-asset do farm. O fix é não renomear, mas adicionar camada de intenção acima: "Quero rendimento passivo" → escolha guiada que mostra Farm vs Syrup como sub-mecânicas, não como entradas equivalentes.

Direcionamento Kotai: porta de entrada por intenção ("Earn yield"), com APY e perfil de risco visíveis no dropdown. Nomes técnicos (Farm/Stake/Boost) ficam dentro do fluxo, não no menu.

^friccao-1

🟡 Oportunidade competitiva (alta leverage no target) Concorrentes farm-and-emit (Pancake, Sushi, Curve, Aerodrome) usam vocabulário técnico interno para yield (Farm, Gauge, Boost, veToken). Iniciante chega de CEX onde "Earn" = APY exposta + 1 clique e cai num catálogo de mecânicas com nomes próprios. Passa nas 4 perguntas: convenção entre DEX farm-and-emit, afeta iniciante de CEX (segmento crítico de aquisição), não foi resolvido por marketing-first culture, e diferenciação seria perceptível.

Diferenciação: yield organizado por perfil (passivo/ativo, risco baixo/médio) com APY e custo de saída visíveis no dropdown. Trade-off: perde-se diferenciação de marca via vocabulário próprio.

^oportunidade-1

4. Perps — Link Direto (sem dropdown)

Função: Entrada da nav primária que leva direto à app de perpétuos, sem sub-menu intermediário.

Componentes

• Label "Perps" na nav, sem chevron ▾
• Sem ícone de external link ↗
• Sem tooltip ou caption

Regras de negócio

• Clique único → rota de perpétuos (URL distinta do swap)
• Tratado como entrada equivalente a Trade/Earn/Play
• Nav não diferencia "produto core" de "produto separado"

🟢 Insight Decisão correta de NÃO inflar a nav com dropdown de 1 item. Perpétuos é fluxo de superfície única (form de long/short) — não há sub-modos relevantes a oferecer no menu. Pancake reconhece que dropdown só faz sentido quando há ramificação real, evitando padrão de "menu vazio" comum em outros DEX.

^insight-1

🔴 Fricção (cosmética — afeta iniciante) A entrada "Perps" na nav não diferencia visualmente de "Trade" ou "Earn", mas leva a um produto com modelo mental radicalmente diferente (alavancagem, funding, liquidação). A nav comunica "mais um modo de negociar", quando na verdade é um produto separado. Solução óbvia (ícone ↗) falha porque Perps é parte da Pancake, não saída externa.

Fix correto no escopo da nav: diferenciação visual sutil (badge, sub-label "Advanced", ou agrupamento secundário) que sinaliza nível de complexidade sem expulsar o item da nav.

Direcionamento Kotai: nav agrupada por nível de risco/complexidade, não por funcionalidade técnica. Itens "Pro" (perpétuos, opções, alavancagem) ficam visualmente subordinados a itens "Básicos" (swap, earn).

^friccao-1

🟡 Oportunidade competitiva (média leverage) Concorrentes com perpétuos (Pancake, Uniswap via integração, GMX) tratam perp como item equivalente a swap na nav primária. Passa nas 4 perguntas: convenção entre DEX que oferecem ambos, afeta iniciante (que clica esperando swap-like e cai em modelo incompatível), ninguém resolveu por falta de hierarquia de produto na nav, diferenciação perceptível.

Diferenciação: nav hierarquizada por nível de risco (Básico vs Avançado), com Perps visualmente subordinado. Trade-off: discoverability de perpétuos cai pra iniciante — que é exatamente o efeito desejado pelo posicionamento Kotai.

Observação adicional (fora do escopo da tela da nav): ao clicar em Perps, a Pancake força theme=light na URL e carrega app com UI distinta — quebra de continuidade visual entre apps do mesmo ecossistema. Esse problema pertence à análise das telas de Perps (não desta tela de nav), mas vale registrar como sinalização de inconsistência sistêmica.

^oportunidade-1

19. Tooltip "Flippy sounds"

Função: Tooltip do "?" ao lado do toggle Flippy sounds em EVM Settings → INTERFACE SETTINGS.

Componentes

• Tooltip flutuante de 1 frase
• Texto: "Fun sounds to make a truly immersive pancake-flipping trading experience"

Regras de negócio

• Toggle off por default
• Ativa efeitos sonoros associados a eventos do swap
• Setting puramente cosmético, sem impacto financeiro

🟢 Insight Tom de voz brincalhão alinhado com a marca Pancake (referência à mascote "pancake-flipping"). Setting puramente cosmético merece registro leve, não técnico — calibração correta entre tom e natureza da feature. Ativos como esse criam momento memorável e diferenciam Pancake de DEX "sérias" — decisão de identidade legítima.

^insight-1

🔴 Fricção (cosmética — afeta iniciante e intermediário) O texto é puro adjetivo de marketing ("fun", "truly immersive", "pancake-flipping experience") e não informa quando o som toca, quão alto, quantos sons, ou se respeita o volume do sistema. Usuário curioso lê e ainda não sabe se ligar vai tocar som a cada swap, a cada movimento de preço, ou só ao confirmar. Pode constrangir em escritório ou incomodar quem trabalha com fones.

Fix óbvio (acrescentar "Plays when your swap confirms") substitui adjetivos por momento de uso. Fix correto: tooltip que combina tom Pancake + clareza funcional ("Plays a fun sound each time your swap confirms on-chain. Respects your system volume."). Mantém identidade e informa.

Direcionamento Kotai: tooltips de features cosméticas podem ter tom leve, mas precisam ainda informar quando/como a feature age. Identidade ≠ vagueza.

Não é 🟡 — armadilha 1c (fricção comum de tela, trivialmente corrigível) Copy fraca de tooltip não é padrão da indústria DEX — é descuido específico Pancake daquele tooltip. Concorrentes podem ou não cometer o mesmo, mas a resolução é trivial (uma linha de copy) e não envolve repensar paradigma. Classifica como fricção cosmética de tela, não Oportunidade competitiva.

Observação adicional (fora do tooltip, escopo do painel): Flippy sounds vive no mesmo painel que Expert Mode (vide Análise 16) com toggle visualmente idêntico. Feature divertida e feature destrutiva lado a lado achatam hierarquia de consequência. Não é problema deste tooltip — é problema do painel pai. Já endereçado em 11 e 16.

^friccao-1

20. Expert Mode — Modal de Confirmação (passo 1)

Função: Modal disparado ao tentar ativar o toggle Expert Mode. Primeira camada de fricção antes de ligar a feature.

Componentes

• Bloco warning amarelo com ícone ⚠️
• Texto destacado: "Expert mode turns off the 'Confirm' transaction prompt, and allows high slippage trades that often result in bad rates and lost funds."
• Reforço: "Only use this mode if you know what you're doing."
• Checkbox "Don't show this again"
• CTA primário verde: "Turn On Expert Mode"
• CTA secundário outline: "Cancel"

Regras de negócio

• Modal aparece ao tentar ativar o toggle pelo painel EVM Settings
• Checkbox persiste preferência de não mostrar warning em ativações futuras
• Após confirmar, ainda passa pelo modal type-to-confirm (vide An. 21)

🟢 Insight Este modal corrige parcialmente o que as análises 16 e 18 apontaram como "toggle plano sem fricção" — Pancake DE FATO impõe barreira ao ativar Expert Mode (e mais uma camada na 21). Bloco warning amarelo + ícone + copy concreta ("often result in bad rates and lost funds" — sem eufemismo) + escolha explícita entre dois CTAs. Defesa em camadas bem implementada — fica registrado como mea culpa retroativo às anteriores.

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante) Checkbox "Don't show this again" enfraquece a defesa. Iniciante que ativou Expert Mode uma vez por curiosidade (sem entender) e marcou o checkbox perde o warning permanentemente. Em ativações futuras, o toggle vira plano. Pra feature que pode causar "lost funds", dismiss-forever é incompatível com a gravidade. Vale pra release notes ou ofertas — não pra warning destrutivo.

Fix óbvio (remover checkbox) resolve. Fix correto considerando defesa em camadas: manter o type-to-confirm (An. 21) sempre, eliminar só o warning visual quando dismiss — atalho pra avançado sem perder barreira de consciência.

^friccao-1

🔴 Fricção secundária (estrutural — afeta iniciante) CTAs com hierarquia visual invertida: "Turn On Expert Mode" é primário verde (cor de "seguro/ok"); "Cancel" é secundário outline. Convenção web pra ação destrutiva inverte: destrutiva fica outline/cor de alerta, segura fica primária. Aqui o botão verde comunica "esse é o caminho recomendado" — exatamente o oposto da intenção.

Fix óbvio (inverter cores) resolve. Trade-off: pequena quebra de consistency interna (Pancake usa verde pra CTA primário em todo lado) — vale a pena em contexto destrutivo.

^friccao-2

🟡 Oportunidade competitiva (média leverage) Modais de confirmação em DEX (Uniswap, Pancake, SushiSwap) tipicamente usam CTA destrutivo como primário verde. Passa nas 4 perguntas: convenção entre concorrentes, afeta iniciante (que clica no verde por instinto), ninguém investiu em inversão por preocupação com consistência visual, perceptível.

Diferenciação Kotai: CTAs destrutivos sempre como secundários, cor de alerta; "Cancel"/"Voltar" primário em contextos de risco. Trade-off: design system precisa prever variação de hierarquia por consequência.

^oportunidade-1

15. Tooltip "Token Risk Scanning"

Função: Tooltip do "?" ao lado do toggle Token Risk Scanning. Explica o que a feature faz, declara limite legal, credita provider.

Componentes

• Tooltip flutuante com texto multi-linha
• Conteúdo: "Automatic risk scanning for the selected token. This scanning result is for reference only, and should NOT be taken as investment advice."
• "Provided by HashDit" (link)
• "Learn More" (link)

Regras de negócio

• Toggle ON por default (proteção opt-out)
• Scanning provido por terceiro (HashDit)
• Disclaimer legal embutido no tooltip
• Link pra aprofundamento

🟢 Insight Tooltip multi-camada bem estruturado: (1) explica o que faz, (2) declara limite legal ("NOT investment advice", em caps), (3) credita provider externo, (4) oferece aprofundamento. Combina UX + compliance + sourcing em poucas linhas — modelo correto pra setting com implicação financeira. O disclaimer existe porque Pancake antecipou que iniciante pode confiar excessivamente em score automático ("passou no scan, é seguro") e calibra a expectativa antes do uso.

^insight-1

🔴 Fricção primária (cosmética — afeta iniciante) Texto corrido sem hierarquia visual. "should NOT be taken as investment advice" merece destaque (cor, weight) — é a frase que protege Pancake legalmente E o usuário. Hoje passa despercebida no meio das outras. "HashDit" é link mas o iniciante não tem contexto de quem é (name-drop só credibiliza quando o nome é reconhecido pelo target).

Fix óbvio (negritar "NOT investment advice") melhora marginalmente. Fix correto: tooltip estruturado em seções (O que faz / Limites / Quem fornece), HashDit qualificado em uma linha ("third-party security firm"), com preview do warning real exibido quando um token é flagged.

^friccao-1

🔴 Fricção secundária (estrutural — afeta iniciante) Disclaimer vive na UI de settings, longe do momento de uso. Quando o usuário seleciona um token e vê (ou não) o resultado do scan no swap form, a calibração "isso é referência, não conselho" já foi esquecida. Educação in-context é mais efetiva que in-settings.

Direcionamento Kotai: scoring/risk com explicação no momento de uso (in-the-moment), não apenas em settings. Provider creditado quando agrega credibilidade ao target; quando não, omitir.

^friccao-2

🟡 Oportunidade competitiva (média leverage) DEX que oferecem risk scoring (Pancake/HashDit, Uniswap/Blockaid, 1inch/Solidus) tratam disclaimer como letra-pequena de tooltip em settings. Passa nas 4 perguntas: convenção emergente entre concorrentes que adotaram scanning, afeta iniciante (que assume score=verdade), ninguém investiu em educação in-context, perceptível.

Diferenciação: educação progressiva sobre limites do scoring exibida no momento do swap, não escondida em settings.

^oportunidade-1

12. Submenu Idioma (dropdown)

Função: Dropdown de seleção de idioma, dentro de Global Settings. Lista scrollable de idiomas com endonímia.

Componentes

• Lista visível: العربية, বাংলা, English (destacado/selecionado), Deutsch, Ελληνικά
• Cada idioma escrito em seu próprio alfabeto (endonímia)
• Item ativo com background diferenciado
• Sem campo de busca, sem agrupamento, sem bandeiras

Regras de negócio

• Endonímia pura (cada idioma no próprio script)
• Lista presumivelmente passa de 10+ idiomas (vide truncamento no scroll)
• Seleção atual em destaque visual

🟢 Insight Endonímia é convenção correta de i18n — usuário árabe procura "العربية", não "Arabic". Ausência de bandeiras evita confusão histórica de mapeamento (bandeira ≠ idioma: português é PT e BR; inglês é US, UK, AU). Destaque visual do idioma atual ajuda orientação espacial.

^insight-1

🔴 Fricção (cosmética — afeta iniciante e intermediário não-anglófono) Ordenação não é alfabética nem por ISO code (a sequência ar → bn → en → de → el quebra ambos). Sem critério visível, lista com scripts heterogêneos (árabe, bengali, latino, grego) fica visualmente caótica para qualquer usuário. Falante de português precisa scrollar lista inteira pra achar "Português" — e nem consegue scanear visualmente porque idiomas em script não-latino interrompem o pattern de leitura.

Fix óbvio (ordenar alfabeticamente por nome nativo) não resolve scripts diferentes: usuário tailandês ainda não decifra "Deutsch" ou "English" pra localizar "ไทย". Fix correto: campo de busca typeahead no topo (aceita endonímia e exônimo — "Spanish" achando "Español") + bloco "Sugeridos" com 2–3 idiomas baseados em browser locale ou IP, antes da lista completa.

Direcionamento Kotai: campo de busca no topo + sugestões contextuais. Lista completa abaixo, em endonímia.

Não é 🟡 — armadilha 1a (convenção válida): menus simples de idioma sem busca são padrão em Google, Apple, Microsoft em pequena escala. Pra ser convenção problemática, a lista precisa ser longa o suficiente pra justificar o investimento. Pancake tem ~30 idiomas (típico de DEX globais), o que torna a fricção real — mas como não há evidência sólida de que isso é convenção problemática entre os DEX concorrentes especificamente, mantenho como 🔴 cosmética. Reavaliar se análise de Uniswap/1inch confirmar mesmo padrão de lista longa sem busca.

Observação adicional: ausência de campo de busca pode ser decisão honesta de produto se Pancake assume que troca de idioma é evento único (usuário muda uma vez, fica). Vale validar com dados — se troca de idioma é evento frequente (multi-language users), busca passa a ter ROI claro.

^friccao-1

13. Tooltip "Show username"

Função: Tooltip contextual disparado por hover no ícone "?" ao lado da label "Show username".

Componentes

• Tooltip flutuante posicionado acima da label
• Conteúdo: "Shows username of wallet instead of bunnies"
• Texto curto, sem ilustração, sem exemplo

Regras de negócio

• Aparece on hover do "?"
• Descreve o efeito do toggle adjacente
• Vocabulário interno ("bunnies" = avatar coelho default da Pancake)

🟢 Insight Presença de tooltip explicativo em settings não-óbvias é boa prática — iniciante não precisa adivinhar o que cada toggle faz, e a interação opcional (só aparece on hover) não polui a UI no estado default. Convenção válida bem aplicada (Apple, Slack, Notion fazem igual).

^insight-1

🔴 Fricção primária (cosmética → estrutural — afeta iniciante) O texto pressupõe vocabulário interno: "bunnies" refere-se ao avatar coelho default da Pancake (representando o endereço), mas usuário em primeiro contato não sabe disso. Lê "Shows username of wallet instead of bunnies" e fica confuso: que coelhos? onde aparecem? Tooltip que era pra explicar adiciona termo a explicar.

Mais profundo: a feature em si (username de wallet — provavelmente BSC Domain, ENS-like) é desconhecida pra quem vem de CEX. O tooltip é a primeira menção ao conceito de "endereço legível" (vitalik.eth no lugar de 0xab12...) sem explicar que esse conceito existe.

Fix óbvio (trocar "bunnies" por "avatar") resolve a primeira camada — mas usuário ainda não entende o que é "username of wallet". Fix correto: tooltip com exemplo visual concreto — "Antes: 🐰 0xab12... Depois: vitalik.eth". Mostra o que muda no produto, em vez de descrever em texto.

Direcionamento Kotai: tooltips de settings mostram preview visual do efeito quando aplicável; texto evita jargão interno (mascotes, codinomes de feature); conceitos novos têm definição inline ou link "Saiba mais", não pressuposição.

^friccao-1

🟡 Oportunidade competitiva (média leverage) Tooltips de settings em DEX (Uniswap, 1inch, Pancake) tipicamente descrevem o efeito em uma frase técnica curta, sem preview visual. Passa nas 4 perguntas: convenção entre concorrentes, afeta iniciante diretamente, ninguém investiu em preview por custo de design, perceptível.

Diferenciação: tooltip "antes/depois" com exemplo visual concreto nos toggles de maior impacto. Custo: design por toggle, não escala trivialmente para painéis com 20+ settings. Investir só nos com maior impacto/confusão (Token Risk Scanning, MEV Protection, Show username); cosméticas mantém texto simples.

^oportunidade-1

14. Tooltip "Subgraph Health Indicator"

Função: Tooltip do "?" ao lado do toggle Subgraph Health Indicator (painel Global Settings).

Componentes

• Tooltip flutuante acima do label
• Texto: "Turn on subgraph health indicator all the time. Default is to show the indicator only when the network is delayed"

Regras de negócio

• Toggle off por default
• Default behavior = indicador aparece só quando network está atrasada
• Ligar o toggle = indicador permanente

🟢 Insight Revela decisão de produto inteligente: o indicador NÃO está sempre presente (que seria ruído permanente) — aparece só quando há problema real. Toggle existe pra power-user que quer vigilância contínua. Default progressivo, não invasivo, alinhado com princípio "mostrar quando importa". Boa engenharia de visibility.

^insight-1

🔴 Fricção primária (estrutural — afeta iniciante e intermediário) "Subgraph" é jargão de infraestrutura (The Graph indexer) — usuário não tem como saber o que significa. O tooltip não define o termo, só descreve quando ele aparece. A feature em si (saber se os dados que você vê estão frescos ou defasados) é critical pra confiar em preço/saldo, mas a label expõe a arquitetura ("Subgraph") em vez do problema do usuário ("dados atualizados", "atraso de rede"). Iniciante não associa "Subgraph" a "posso confiar no preço que estou vendo agora?".

Fix óbvio (adicionar "(indexer)" no tooltip) falha — substitui jargão por jargão. Fix correto: renomear o setting pra terminologia do usuário ("Data freshness alert", "Network delay indicator"), com tooltip mostrando exemplo visual do badge ("Data may be delayed").

Direcionamento Kotai: labels de settings descrevem o problema que resolvem, não a tecnologia que monitoram. "Subgraph" nunca aparece em UI primária.

^friccao-1

🟡 Oportunidade competitiva (média leverage) DEX que dependem de The Graph (Uniswap, Pancake, SushiSwap) expõem estado de subgraph como elemento de settings/footer com o termo técnico cru. Passa nas 4 perguntas: convenção entre os concorrentes que usam o indexer, afeta iniciante diretamente, ninguém renomeou por priorizar precisão técnica sobre clareza, diferenciação perceptível.

Diferenciação: terminologia de "frescor de dados" no nível do usuário; termo técnico como secondary label ou só no tooltip. Trade-off: avançado familiarizado pode achar a label genérica demais — mitigável com hover.

^oportunidade-1

1. Logo Dropdown — More & Links

Função: Hub secundário acionado pelo chevron ▾ ao lado do wordmark PancakeSwap. Agrega utilitários (Info, Voting, Burn Dashboard), links externos (Blog, Docs) e bloco de preço do token nativo com CTA de compra.

Componentes

• Coluna 1 — More: Info, Voting, Burn Dashboard
• Coluna 2 — Links: Blog ↗, Docs ↗ (com ícone de external link)
• Bloco token: ícone CAKE, preço ($1.519), CTA "Buy CAKE"

Regras de negócio

• "More" = ferramentas internas (analytics, governança, tokenomics)
• "Links" = saídas pra fora do app (sinalizadas com ↗)
• Bloco CAKE = cross-sell do token nativo dentro de real-estate primário

🟢 Insight Menu mais enxuto que o equivalente Uniswap (5 itens vs 10+). A separação visual entre "Links" externos (com ↗) e "More" interno ajuda o usuário a antecipar saída de contexto.

^insight-1

🔴 Fricção (estrutural — afeta iniciante e intermediário) "Info" sem qualificador não comunica nada (info sobre o quê?). "Voting" e "Burn Dashboard" são funcionalidades de DAO/tokenomics que exigem contexto prévio — iniciante não tem modelo mental de "queima deflacionária" nem de "votação on-chain". O menu mostra coisas para as quais ele não tem pergunta. Solução óbvia (renomear) não resolve a raiz: o problema é misturar governança/tokenomics com utilidade básica.

^friccao-1

🔴 Fricção secundária (cosmética → posicionamento — específica Pancake) CTA "Buy CAKE" no menu do logo é cross-sell prematuro: oferece compra do token de governança antes do usuário ter completado sua primeira transação útil. Iniciante pode interpretar "Buy CAKE" como ação esperada do produto, gerando confusão sobre o que a Pancake é (DEX de swap ou exchange do CAKE?).

^friccao-2

🟡 Oportunidade competitiva (alta leverage no target) Logo como hub-de-menu é convenção entre concorrentes (Uniswap, Pancake, 1inch) e violação de convenção mainstream web (logo = home). Passa nas 4 perguntas: todos fazem igual, afeta iniciante, ninguém resolveu por falta de investimento (logo é real-estate caro para cross-promo), diferenciação seria perceptível.

Diferenciação Kotai: logo = home. Institucional (Sobre, Docs, Carreiras) vai pro footer global. Governança/DAO, quando relevante, ganha entrada nomeada própria. Trade-off: perde-se canal gratuito de cross-promo para produtos adjacentes — sacrifício alinhado ao posicionamento de DEX para iniciante/intermediário.

^oportunidade-1

21. Expert Mode — Type-to-Confirm (passo 2)

Função: Segunda camada de fricção. Modal "Warning" que exige digitação ativa da palavra "confirm" antes de ativar Expert Mode.

Componentes

• Título "Warning"
• Texto: "Please type the word 'confirm' to enable expert mode."
• Input vazio (sem placeholder visível)
• Botão "Cancel" (outline)
• Botão "OK" (primário verde)

Regras de negócio

• Aparece após passar pelo modal warning (An. 20)
• "OK" só fica clicável quando o input tem "confirm" digitado
• Cancel volta sem ativar

🟢 Insight Type-to-confirm é convenção válida pra ações destrutivas irreversíveis ou de alto impacto — GitHub (delete repo), Heroku (destroy app), DigitalOcean (destroy droplet) usam o mesmo padrão. Pancake aplicou em DEX, decisão rara e correta. Forçar digitação ativa quebra fluxo automático: o usuário não pode "passar batido" clicando OK por automatismo, precisa cometer ato deliberado. Combinada com o warning da 20, vira defesa em camadas séria.

^insight-1

🔴 Fricção primária (cosmética — afeta intermediário não-anglófono) A palavra a digitar é "confirm" em inglês, mesmo em UI configurada pra outro idioma. Iniciante brasileiro ou hispânico que está com UI em PT-BR/ES precisa entender que (a) "confirm" não é texto livre, é palavra-chave exata, (b) está em inglês mesmo a UI estando localizada, (c) é case-sensitive ou não (não está sinalizado). Sem placeholder no input ("Type: confirm"), o usuário só descobre o formato exato por tentativa e erro.

Fix óbvio (localizar pra "confirmar"/"confirmar") resolve mas quebra consistency cross-language. Fix correto: palavra a digitar localizada ao idioma da UI, com placeholder explícito no input mostrando exatamente o que digitar, e tolerância a case.

^friccao-1

🔴 Fricção secundária (cosmética — afeta iniciante) Botão final "OK" é genérico demais para a gravidade do contexto. Convenção de copy em destrutivos é repetir a ação no botão final ("Enable Expert Mode", "Yes, turn it on") pra garantir que o usuário sabe o que está confirmando. "OK" pode parecer "OK, ciente do warning" e não "OK, ativar agora a feature destrutiva".

Fix óbvio (renomear "OK" pra "Enable Expert Mode") resolve sem trade-off significativo.

Não é 🟡 — armadilha 1a (convenção válida estabelecida) Type-to-confirm é convenção bem-estabelecida em produtos sérios (DevOps, SaaS, infra). Pancake aplicou bem; as fricções aqui são de copy/localização, não de modelo. Resolve com refinamento de copy, não com mudança estrutural — não classifica como Oportunidade competitiva, classifica como polimento dentro de padrão já correto.

Observação adicional: combinação de 20 + 21 (warning visual + type-to-confirm) é exemplo positivo de defesa em camadas que Kotai pode adotar como template pra qualquer feature destrutiva (não só Expert Mode — pode aplicar a desligar Token Risk Scanning, ativar slippage > 5%, conectar wallet em testnet, etc.).

^friccao-2

3. Criar Pool Infinity — Nível de taxa 0,01% selecionado + aviso "pool já existe"

Função: Continuação da tela 2 após o usuário selecionar nível de taxa 0,01% (chip ativo + valor "0.01" replicado no campo "Persona"). O sistema detecta que já existe pool com a combinação par+motor+taxa selecionada e exibe aviso verde inline com CTA alternativo "Adicionar liquidez" (em vez de "Visualizar Pool").

Componentes: mesmos da tela 2, mas chip "0,01%" agora destacado em roxo (selecionado), e campo livre "Persona %" agora mostra "0.01" (espelha o chip); bloco verde claro no rodapé da coluna esquerda — ícone "i" + texto "Um pool com a configuração selecionada já existe." + CTA verde "Adicionar liquidez". Coluna direita continua disabled (não é pré-requisito quando a pool já existe — o sistema redireciona para o fluxo de adicionar à pool existente).

Regras de negócio: combinação (par × motor × tipo × fee tier) é o identificador único de pool — não pode existir duplicata; quando o usuário tenta criar com config já existente, o produto desvia para o fluxo "Adicionar liquidez à pool existente", evitando criação duplicada (que falharia on-chain de qualquer forma); o aviso é detecção on-chain (lookup do contrato factory) — só aparece após user input completo o suficiente para hash.

🟢 Insight: detectar colisão de configuração antes do click é decisão certa — evita gas desperdiçado e frustração pós-falha. Oferecer CTA alternativo "Adicionar liquidez" no mesmo ponto é redirecionamento útil — o usuário queria expor capital a este par com este fee; pouco importa se cria nova pool ou entra em existente. Tom verde (não-destrutivo) e cópia neutra ("já existe" sem julgamento) respeita o contexto.

🔴 Fricção 1 (estrutural — afeta iniciante): o aviso diz "Um pool com a configuração selecionada já existe" mas não mostra qual é a pool — sem TVL, sem APR, sem volume, sem link para inspeção. O usuário vai clicar "Adicionar liquidez" sem saber se está entrando em pool de $10 ou de $10M — diferença abissal para IL e retorno. Fix óbvio (link "Ver pool existente") melhora marginalmente. Fix verdadeiro: card resumo da pool existente embutido no aviso (par, TVL, APR 7d, idade) + dois CTAs claros ("Adicionar liquidez à existente" vs. "Voltar e mudar parâmetros para criar nova"). Trade-off: bloco mais alto; ganho é decisão informada antes do redirect.

🔴 Fricção 2 (estrutural — afeta intermediário): o campo "Persona %" mostra "0.01" como reflexo automático do chip — não está claro se é input independente ou espelho. Se o usuário tentar digitar 0.011 no campo livre, o chip 0,01% provavelmente desseleciona — comportamento de mestre/escravo invertido (campo livre é mestre, chips são atalhos), mas a UI sugere o oposto (chip parece principal pela posição e peso visual). Fix: tornar a relação explícita — chips são presets que populam o campo, campo livre é o valor real; quando o usuário digita valor que bate com um chip, o chip se destaca; quando digita valor fora, nenhum chip fica ativo + label "Personalizado" aparece. Trade-off: nenhum significativo; é clareza de affordance.

🔴 Fricção 3 (cosmética — afeta todo perfil): "Adicionar liquidez" no aviso usa botão verde claro distinto dos botões primários do produto (turquesa/azul "Visualizar Pool"). Inconsistência de paleta dentro da mesma tela de fluxo — verde sugere positivo/sucesso mas pode parecer secundário comparado ao azul principal. Fix: usar o mesmo token de CTA primário, mudando apenas o label e ícone.

🟡 Oportunidade competitiva (média leverage no target): detecção de pool existente com redirect é convenção parcial — Uniswap V3 detecta colisão mas apenas bloqueia a criação sem oferecer caminho alternativo no mesmo ponto; Pancake aqui está adiante. Passa nas 4 perguntas com nuance: ✓ a maioria; ✓ afeta iniciante (tenta criar e não entende por que falha); ✓ não resolvido por falta de investimento em UX de redirect contextual; ✓ perceptível mas marginal — não é diferencial estrutural, é polish bom. Mantenho como observação de design de qualidade, não diferencial Kotai prioritário. Pancake fez aqui o que outros não fizeram — vale reconhecer.

Observação adicional: a coluna direita continua disabled mesmo após o aviso de pool existente. Tecnicamente correto (não vai criar pool, vai adicionar à existente), mas visualmente ambíguo — usuário pode achar que precisa preencher direita pra ativar o CTA verde. Fix: esmaecer ainda mais a coluna direita ou substituí-la por preview da pool existente quando o aviso aparece.

4. Criar Pool Infinity — Modo CLAMM (tickspacing + intervalo de preço por %)

Função: Mesma tela 2/3 com "Tipo de pool" alternado para CLAMM. O layout reorganiza: "Etapa do bin" é substituído por "Tickspacing", os controles de "Forma de liquidez" (Spot/Curve/Bid-Ask) e "Núm. de bins" desaparecem da coluna direita, e em seu lugar aparecem inputs de "Preço mínimo" / "Preço máximo" + chips de range por porcentagem (0,1% / 0,5% / 1% / Intervalo total / Personalizar %).

Componentes: coluna esquerda — par BNB+CAKE, segmento CLAMM (ativo) / LBAMM, "Tickspacing" com "?" (input "1"), "Nível de taxa" + "Taxa dinâmica" + "Ativar configurações de hook" (idênticos à tela 2); coluna direita — "Definir preço inicial" + "Usar preço de mercado" + cotação; "Definir intervalo de preço" com chevrons ± em "Preço mínimo" e "Preço máximo" (campos 0.0); chips de range "0,1% / 0,5% / 1% / Intervalo total / Personalizar %"; "Valor do depósito" (cards BNB/CAKE disabled com mesmo copy de placeholder); "Tolerância de derrapagem 2,00%"; "Protegido pelo MEV"; CTA "Visualizar Pool" disabled.

Regras de negócio: CLAMM (concentrated liquidity) divide a curva em ticks e o LP escolhe um range contínuo de preço para concentrar liquidez (capital eficiente, mas capital fora do range para de ganhar fee); "tickspacing" é a granularidade do tick (afeta gas vs. precisão); chips de range são presets relativos ao preço atual (±0,1% até ±1% ou full-range); o user pode alternar CLAMM ↔ LBAMM a qualquer momento, mas a maioria dos parâmetros se invalida no toggle.

🟢 Insight: reorganizar a coluna direita de acordo com o motor escolhido (em vez de mostrar todos os campos de ambos os modos de uma vez) é decisão certa — reduz ruído cognitivo e admite que os dois motores são incompatíveis em vocabulário. Chips de range em % é melhor do que pedir valor absoluto cru — o iniciante entende "±1% do preço atual" mais facilmente do que "preço entre 412 e 419".

🔴 Fricção 1 (estrutural — afeta iniciante; recorrência do problema do relatório 2): o toggle CLAMM ↔ LBAMM muda 50% da tela mas sem aviso ou animação que explicite a mudança. Iniciante que aperta o segmento por curiosidade vê a UI rearranjar e provavelmente perde os campos que já preencheu (par, fee tier permanecem; range/bins/forma de liquidez resetam). Sem confirmar a perda nem narrar a transição, o produto entrega um magic act que erode confiança. Fix: micro-aviso ao toggle ("Mudar para CLAMM vai resetar configurações de range. Continuar?") quando há valores preenchidos no modo atual; sem aviso quando os campos estão zerados. Trade-off: extra clique para quem está explorando — aceitável dado o custo de perder trabalho.

🔴 Fricção 2 (estrutural — afeta iniciante; crítica): range de preço por chips (0,1% / 0,5% / 1%) sem visualização gráfica do que cada range significa em termos de IL e cobertura. O usuário escolhe "1%" sem saber que num par volátil isso significa "vou ficar fora do range em horas e parar de ganhar fee". Fix óbvio (tooltip explicando concentrated liquidity) é insuficiente. Fix verdadeiro: gráfico de preço histórico do par (7d / 30d) com o range selecionado overlay, mostrando % do tempo o preço ficou dentro vs. fora do range escolhido. Decisão informada pelo dado, não pelo nome do chip. Trade-off: gráfico exige dados de preço por par, peso visual significativo, complexidade de render — mas é o diferencial certo pra um produto Kotai mirar.

🔴 Fricção 3 (estrutural — afeta intermediário): "Tickspacing 1" como default sem contexto. Tickspacing é parâmetro de gas vs. precisão — valor baixo (1) maximiza precisão e custa mais gas em entradas/saídas; valor alto (60+) é o oposto. Iniciante e intermediário aceitam o default sem saber que estão otimizando um eixo às cegas. Fix: default derivado do fee tier (Uniswap usa tickspacing fixo por tier — 1 para 0,01%, 10 para 0,05%, 60 para 0,3%) com explicação curta sobre o trade-off no tooltip. Trade-off: nenhum se a regra for documentada.

🔴 Fricção 4 (cosmética — afeta todo perfil): os cards "BNB / CAKE — Defina o preço inicial e o intervalo de preço prim..." estão truncados em ambas as telas (2, 3 e 4). Texto corta no meio da palavra "primei...". Fix: aumentar largura do card ou quebrar linha — trabalho de minutos.

🟡 Oportunidade competitiva (alta leverage no target): range selection sem visualização histórica é convenção em Uniswap V3, Pancake V3, Sushi V3 — todos pedem range numérico ou por % sem mostrar o que aconteceria com aquele range no histórico recente. Passa nas 4 perguntas: ✓ todos os concorrentes; ✓ afeta iniciante e intermediário direto (escolhe range estreito num par volátil → fora do range em horas → APR efetiva zero); ✓ ninguém resolveu por falta de investimento em visualização histórica overlay, não impossibilidade; ✓ perceptível ("o produto me mostrou que esse range não teria coberto a última semana" vs. "perdi liquidez ativa por escolher range estreito demais"). Diferenciação Kotai: simulador inline — para cada range proposto, calcular % do tempo coberto + APR simulado dos últimos 30 dias se aquela posição existisse. Trade-off: requer dados de preço histórico granular + capacidade computacional pra simular em tempo real conforme o usuário ajusta os chevrons.

Observação adicional: "Intervalo total" como chip ao lado de "1%" oferece full-range numa única tecla — atalho importante para o iniciante que quer simplicidade V2-like dentro de CLAMM. Valor reconhecível, vale destacar visualmente (badge "Mais simples") em vez de tratar como mais um chip na fila. Pequena edição com leverage cognitivo alto.

5. Criar Pool V3 — Configuração inicial (coluna única, fee tiers 0,01-1%)

Função: Tela de configuração ao escolher "V3" no segmento de versão. Difere de Infinity/CLAMM em três pontos: layout em coluna única (sem split decisão/parâmetros), fee tiers fixos de V3 padrão (0,01% / 0,05% / 0,25% / 1%), ausência de "Tipo de pool" (V3 não tem sub-motor) e ausência de hooks. Estado mostra par BNB+CAKE selecionado, nenhum tier escolhido, todos os campos abaixo disabled.

Componentes: breadcrumb + segmento Infinity / V3 (ativo) / V2; card único com "Escolher par de token" (BNB + CAKE), "Nível de taxa" + "?" (chips 0,01% / 0,05% / 0,25% / 1%, nenhum ativo), "Definir preço inicial" (disabled) + chip "Usar preço de mercado" + cotação "415,416 CAKE = 1 BNB", input "0.00 CAKE"; "Definir intervalo de preço" (disabled) — Preço mínimo / Preço máximo com steppers ±, chips "Intervalo total" / "Personalizar %"; "Valor do depósito" 0, cards BNB e CAKE com 0.00 / ~$0 USD; "Tolerância de derrapagem 2,00%" + warning; "Protegido pelo MEV"; CTA disabled "Par inválido".

Regras de negócio: V3 (concentrated liquidity) tem 4 fee tiers padronizados — herdados da implementação Uniswap V3, com tickspacing implícito por tier (1, 10, 50, 200 respectivamente); ausência de tier selecionado deixa todos os campos subsequentes disabled (não dá pra calcular range nem depósito sem fee tier); CTA "Par inválido" sugere que o sistema considera o par BNB+CAKE inválido apesar de já estar selecionado — provavelmente erro de copy do disabled state (deveria ser "Selecione nível de taxa" ou similar).

🟢 Insight: layout em coluna única é certo pra V3 porque há menos parâmetros que Infinity — tela não precisa do split de duas colunas. Reduz ruído pro usuário que escolheu deliberadamente V3 buscando simplicidade relativa. Diferenciação visual entre tabs (Infinity = duas colunas densas; V3 = coluna simples) ajuda a comunicar a diferença de complexidade dos motores sem precisar dizer.

🔴 Fricção 1 (estrutural — afeta iniciante; reforço da fricção 3 do relatório 2): os 4 fee tiers (0,01% / 0,05% / 0,25% / 1%) aparecem como chips iguais sem indicação de uso recomendado. Em V3 a escolha de fee é decisão crítica — tier muito baixo gera quase zero fee em par volátil; tier muito alto afasta volume. Reforça o problema sistêmico do produto: tier técnico exposto sem tradução por intent. Fix: chip acompanhado de label de uso ("0,01% — pares estáveis", "0,05% — par estável-volátil", "0,25% — volátil padrão", "1% — exótico ou alta volatilidade") + indicação visual de qual tier tem mais TVL atualmente no par escolhido. Trade-off: chips maiores, ocupam mais espaço; ganho é decisão informada.

🔴 Fricção 2 (estrutural — afeta iniciante; crítica): CTA "Par inválido" com par já selecionado é mensagem errada — o iniciante lê "BNB+CAKE é par inválido?" e abandona. O par é válido; o que está faltando é fee tier + preço + range. Fix óbvio (texto dinâmico do CTA que reflete o que falta: "Selecione nível de taxa" → "Defina preço inicial" → "Defina intervalo" → "Insira quantia") é correto e barato. Trade-off: nenhum; é fix de copy. Estrutural porque a tela tem hierarquia de pré-requisitos (par → tier → preço → range → quantia) e o CTA é a única superfície que pode guiar o usuário pelo próximo passo.

🔴 Fricção 3 (cosmética — afeta intermediário): ausência de chips de range relativo (0,1% / 0,5% / 1%) em V3 é regressão em relação ao Infinity/CLAMM (relatório 4). Em V3 a UI mostra apenas "Intervalo total / Personalizar %" — usuário precisa abrir o personalizar pra qualquer range que não seja full-range. Fix: paridade de chips entre V3 e CLAMM — mesmo conjunto, mesmo comportamento. Trade-off: nenhum, são UIs do mesmo motor (concentrated liquidity).

🟡 Oportunidade competitiva (alta leverage no target; reforço dos relatórios 2 e 4): mesma oportunidade já registrada — fee tier sem tradução por intent + range sem visualização histórica. Aqui ganha peso adicional porque V3 é o motor mais usado em TVL nos DEXs (Uniswap V3, Pancake V3, Sushi V3) — escolha errada de tier ou range em V3 é onde a maioria do capital iniciante é destruído por IL/oportunidade. Não repito a diferenciação; vale por extensão.

Observação adicional: "Personalizar %" como chip — outro caso do truncamento observado no relatório 2 ("Persona %"). A versão V3 já corrige a copy ("Personalizar"), o que sugere que o problema de Infinity é só no campo livre da seção "Nível de taxa" daquela versão. Inconsistência entre as duas telas do mesmo produto.

1. Criar Pool de Liquidez — Seleção do tipo de DEX (Infinity / V3 / V2)

Função: Primeiro passo do fluxo de criação de pool — o usuário escolhe entre 3 motores de AMM disponíveis: Pool Infinity, Pool V3 e Pool V2. Cada opção apresenta uma descrição curta do trade-off técnico associado, com link "Saiba mais" no topo do card de seleção.

Componentes: breadcrumb "Farms > Criar Pool de Liquidez"; card centralizado "Selecione o tipo de DEX da pool de liquidez" com link "Saiba mais" (ícone de link externo); três cards verticais empilhados — Pool Infinity ("Suporta múltiplos tipos de pools com design eficiente em gás, hooks e opções de liquidez flexíveis. Ideal para estratégias avançadas e maximização de retornos."), Pool V3 ("Pools avançadas onde você escolhe faixas de preço específicas para fornecer liquidez, ganhando taxas mais altas na faixa escolhida."), Pool V2 ("Pools clássicas que permitem fornecer liquidez em toda a faixa de preço para taxas de transação estáveis e previsíveis"). Cada card tem seta → indicando navegação.

Regras de negócio: Infinity é a versão mais nova (suporta hooks customizáveis, sub-tipos CLAMM/LBAMM); V3 introduziu concentrated liquidity (LP define range de preço); V2 é constant product clássico (x*y=k, liquidez infinita em toda curva); a escolha aqui é estrutural — define motor de AMM, fee tiers disponíveis, mecânica de IL, complexidade do gerenciamento de posição. Não há recomendação personalizada — usuário precisa decidir sem contexto sobre par, tamanho ou perfil.

🟢 Insight: apresentar a escolha de motor de AMM como passo 1 explícito (em vez de defaultar para uma versão e esconder o resto) é honestidade de produto — admite que há trade-offs reais entre as versões e força a decisão consciente. Card único agrupando as 3 opções com descrição curta é melhor do que dropdown ou tab — usuário lê tudo lado a lado antes de clicar.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário; crítica): as descrições falam em linguagem técnica do produto, não em consequência para o LP. "Múltiplos tipos de pools com design eficiente em gás, hooks e opções de liquidez flexíveis" exige que o usuário já saiba o que é hook, o que muda em LBAMM/CLAMM, e o que "eficiente em gás" significa em prática. "Estratégias avançadas e maximização de retornos" é claim genérico sem âncora. Pra iniciante, escolher aqui é loteria — cada card promete "melhor" em um eixo que ele não consegue avaliar. Fix óbvio (tooltip "?" em cada termo técnico) explica vocabulário mas não responde a pergunta real: "qual eu uso?". Fix verdadeiro: substituir descrições técnicas por descrições por intenção do usuário ("Quero o mais simples possível — taxa estável, sem gestão" → V2; "Quero retorno maior e topo gerenciar range" → V3; "Quero acesso a configurações avançadas e hooks" → Infinity), com tag técnica em segundo plano. Trade-off: precisa de copy curado por persona, não pode ser gerado da documentação. Mas o problema é estrutural — a tela é ponto de entrada do produto e o usuário-alvo não passa dela.

🔴 Fricção 2 (estrutural — afeta iniciante): ordem dos cards prioriza o mais complexo (Infinity → V3 → V2). Para um produto cujo target é iniciante/intermediário, o ranqueamento inverso (do mais simples ao mais avançado) faria mais sentido — V2 primeiro como default cognitivo, V3 e Infinity como upgrade consciente. Fix: inverter ordem + badge "Recomendado para iniciantes" em V2 (ou no que o produto considerar default seguro). Trade-off: produto pode estar deliberadamente promovendo Infinity por motivos de roadmap (fee gerada, hooks como diferencial competitivo) — preço de honestidade vs. crescimento de adoção da v nova.

🔴 Fricção 3 (cosmética — afeta todo perfil): o link "Saiba mais" abre destino externo (ícone de link externo) — o usuário sai do fluxo de criação pra ler documentação. Em uma tela de 3 cards onde a decisão é estrutural, mandar pra fora quebra contexto. Fix: substituir por expansão inline ("Comparar versões lado a lado" como tabela embutida com colunas IL / Gestão / Fee tier / Gas / Quando usar) ou modal contextual que não tira o usuário do fluxo. Trade-off: aumenta superfície a manter dentro do produto vs. lincar para documentação atualizada externamente.

🟡 Oportunidade competitiva (alta leverage no target): apresentar versões de AMM como escolha técnica sem tradução por intent é convenção em todos os DEXs com múltiplas versões (Uniswap V2/V3/V4, Pancake Infinity/V3/V2, Sushi clássico/Trident). Passa nas 4 perguntas: ✓ todos os concorrentes; ✓ afeta iniciante direto (escolhe motor errado, sofre IL ou complexidade); ✓ ninguém resolveu por falta de investimento em descritor por intent, não por impossibilidade; ✓ perceptível ("o produto me ajudou a escolher" vs. "chutei a versão"). Diferenciação Kotai: wizard de 2 perguntas ("Você quer gerenciar range de preço?" + "Sua prioridade é taxa estável ou retorno maior?") que filtra para 1-2 versões recomendadas com motivo explícito; quem quer pular o wizard escolhe livremente. Trade-off: wizard agressivo demais vira fricção; precisa ser opt-in ou skippable.

Observação adicional: não há indicação de qual versão é a "mais usada" — métrica de ancoragem social (% do TVL do Pancake em cada versão) ajudaria o iniciante a calibrar a escolha. Sinalizar "60% do TVL atual está em V3" daria sinal sem precisar dar recomendação direta. Pequena adição com leverage cognitivo alto.

2. Criar Pool Infinity — Configuração inicial (LBAMM selecionado, lado direito disabled)

Função: Tela de configuração principal após escolher Infinity. Layout em duas colunas: à esquerda, escolha de par + tipo de pool + parâmetros do motor; à direita, definição de preço inicial + intervalo + forma de liquidez + depósito (toda a coluna direita disabled até o par estar válido + tipo definido). Estado mostra par BNB+CAKE com motor LBAMM, etapa do bin 10, nenhum nível de taxa selecionado.

Componentes: breadcrumb + segmento Infinity (ativo) / V3 / V2; coluna esquerda — "Escolher par de token" (BNB + CAKE), "Tipo de pool" com tooltip "?" (CLAMM / LBAMM, LBAMM ativo), "Etapa do bin" com "?" (input "10"), "Nível de taxa" com "?" (chips 0,01% / 0,05% / 0,1% / "Persona %" campo livre — nenhum selecionado), "Taxa dinâmica" com "?" + toggle off, "Ativar configurações de hook" + toggle off + segmento Selecionar da lista / Manualmente; coluna direita (toda disabled) — "Definir preço inicial" + chip "Usar preço de mercado" + "415,416 CAKE = 1 BNB" + ícone refresh, input "0.00 CAKE"; "Definir intervalo de preço" + toggle "Visualizar preços em BNB", "Preço mínimo" / "Preço máximo" / "Núm. de bins" com steppers ±; "Escolha a forma de liquidez" + Saiba mais; segmento Spot (selecionado) / Curve / Bid-Ask; "Valor do depósito" com cards BNB e CAKE "Defina o preço inicial e o intervalo de preço prim..."; "Tolerância de derrapagem 2,00%" com warning; "Protegido pelo MEV" badge verde.

Regras de negócio: LBAMM (Liquidity Book AMM) e CLAMM (Concentrated Liquidity AMM) são dois sub-motores da v Infinity com mecânicas distintas — LBAMM trabalha com bins discretos (etapa do bin define o tamanho de cada bin em pips), CLAMM com ranges contínuos (tickspacing); a forma de liquidez (Spot / Curve / Bid-Ask) é específica de LBAMM e descreve como o capital é distribuído entre bins; "Taxa dinâmica" altera fee em função de volatilidade; hooks são contratos externos plugados na pool; toda a coluna direita depende de o usuário ter definido par + tipo + nível de taxa antes de ficar ativa.

🟢 Insight: o layout em duas colunas separa decisão estrutural (motor da pool) de decisão paramétrica (preço, range, distribuição) — em vez de empilhar tudo verticalmente forçando o usuário a rolar muito, mostra a relação de dependência (esquerda alimenta direita). Disabled visível à direita é honestidade — diz "não preencha aqui ainda" sem esconder o que vem depois, dando preview do fluxo completo.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário; crítica): densidade técnica é hostil. Em uma tela só, o usuário encontra: CLAMM, LBAMM, etapa do bin, nível de taxa, taxa dinâmica, hook, Spot, Curve, Bid-Ask, MEV, derrapagem, núm. de bins, tickspacing — todos como labels sem contexto. Os "?" estão ali, mas o iniciante que precisa abrir 10 tooltips para entender uma tela já perdeu o fluxo. Fix óbvio (mais tooltips, glossário inline) só aumenta a superfície de leitura. Fix verdadeiro: tela em modo guiado por default (wizard que pergunta intent — "vou gerenciar range?", "quero distribuição uniforme ou concentrar próximo do preço atual?") e expõe todos os controles em "Modo avançado" como toggle. Trade-off: produto perde poder pra power user no default; ganho é o target conseguir completar o fluxo. Pode coexistir.

🔴 Fricção 2 (estrutural — afeta iniciante): "Tipo de pool" entre CLAMM e LBAMM como segmento default selecionado em LBAMM, sem indicação do que muda. Iniciante não tem como decidir — escolhe pelo nome (LBAMM "soa" mais novo) ou pela posição (chip à direita). Toda a estrutura da coluna direita (Spot/Curve/Bid-Ask, etapa do bin, núm. de bins) só faz sentido em LBAMM; em CLAMM o vocabulário muda (vira tickspacing, intervalo de preço em %). Mostrar o segmento sem ressalva do impacto é armadilha. Fix: cada chip mostra preview do que muda na coluna direita ("LBAMM: distribuição por bins discretos" / "CLAMM: range contínuo de preço") + visual diff entre os dois modos. Trade-off: mais espaço pra explicação.

🔴 Fricção 3 (estrutural — afeta intermediário): "Nível de taxa" tem 3 chips fixos (0,01% / 0,05% / 0,1%) + um campo "Persona %" livre, mas sem qualquer indicação do que cada tier serve. Reforça o problema do relatório 3 do fluxo Pool (badge sem tradução). Aqui é pior porque é decisão de criação — o LP define o fee que vai cobrar, e fee errado significa pool sem volume ou pool que dá prejuízo. Fix: chip de tier acompanhado de label de uso recomendado ("0,01% — stable-stable", "0,05% — par estável-volátil", "0,1% — volátil-volátil") + projeção de fee esperado dado o volume histórico de pares similares. Trade-off: projeção pode envelhecer mal, precisa de update contínuo.

🔴 Fricção 4 (cosmética — afeta todo perfil): "Persona %" como label do campo livre de taxa é confuso. Provavelmente "Personalizar %" truncado. Fix: corrigir copy. Trabalho de minutos.

🟡 Oportunidade competitiva (alta leverage no target): criação de pool como formulário técnico extenso sem modo guiado é convenção em Uniswap V3/V4, Curve, Balancer. Passa nas 4 perguntas: ✓ todos os concorrentes; ✓ afeta intermediário direto (cria pool com fee errado, range errado, distribuição errada → IL maximizada); ✓ não resolvido por falta de investimento em wizard com defaults baseados em par, não por impossibilidade; ✓ perceptível ("o produto sugeriu parâmetros razoáveis pra meu par e me deixou ajustar" vs. "errei e perdi capital"). Diferenciação Kotai: wizard de 3 passos (par → intent → confirmar parâmetros sugeridos derivados de pools similares existentes) com botão "ajustar manualmente" pra power user. Trade-off: precisa de base de dados de pools comparáveis + metodologia de sugestão auditável.

Observação adicional: "Protegido pelo MEV" como badge verde estático no rodapé sem explicação do que é MEV nem como a proteção funciona é selo decorativo. Para o iniciante, soa como certificado; para o intermediário, é informação útil que precisa de tooltip mínimo. Padrão recorrente no produto: badges de qualidade sem âncora.

6. Criar Pool V2 — Fee tier único (0,25%) + colisão "pool já existe" inline

Função: Tela de configuração ao escolher "V2". Layout mais simples ainda — sem range (V2 é full-range por design), apenas par + fee tier (fixo em 0,25%) + valor do depósito. Estado mostra colisão de pool detectada imediatamente após a seleção do par BNB+CAKE com aviso verde + CTA "Adicionar liquidez" no mesmo bloco.

Componentes: breadcrumb + segmento Infinity / V3 / V2 (ativo); card único com "Escolher par de token" (BNB + CAKE); aviso verde claro "Já existe uma pool com as configurações selecionadas. Por favor, adicione liquidez." + CTA "Adicionar liquidez" turquesa; bloco "Nível de taxa" com chip único "0,25%" (não-interativo, sem alternativas); "Definir preço inicial" (disabled) + cotação; "Valor do depósito" 0; cards BNB e CAKE com 0.00 / ~$0 USD; "Tolerância de derrapagem 2,00%"; "Protegido pelo MEV"; CTA disabled "Insira uma quantia".

Regras de negócio: V2 (constant product) tem fee tier único de 0,25% — não há escolha; full-range por design (liquidez em toda curva x*y=k, sem decisão de range); detecção de pool existente acionada com par+versão suficientes (não precisa de tier porque tier é fixo); CTA "Adicionar liquidez" redireciona para o fluxo de adicionar à pool existente, idêntico ao do relatório 3 mas com tom diferente — aqui sem alternativa de criar nova (não há outro tier pra escolher pra criar pool distinta).

🟢 Insight: mostrar o tier único 0,25% como chip não-interativo (vs. esconder ou substituir por texto) é decisão certa — preserva consistência visual com V3/Infinity (sempre há "Nível de taxa" nesta posição) e comunica que em V2 a escolha foi feita por design, não que está faltando. A simplicidade da tela é o argumento de V2 visível na própria UI — usuário que quer poucos eixos de decisão vê que escolheu certo.

🔴 Fricção 1 (estrutural — afeta iniciante): quando o aviso "pool já existe" aparece, ele é o único caminho — não há como criar nova pool BNB+CAKE V2 (não tem outro tier). O usuário que chegou aqui buscando criar recebe redirecionamento sem alternativa, mas o fluxo se chama "Criar Pool de Liquidez". Há descasamento entre intent (criar) e resultado (adicionar à existente). Fix óbvio (mudar título dinamicamente para "Adicionar à pool BNB+CAKE V2") é melhoria de copy. Fix verdadeiro: rotear o usuário de volta pra escolher outro par antes de bloquear (ou explicar "V2 só tem um tier por par — para criar nova, escolha par sem pool"). Trade-off: precisa de detecção mais cedo (no seletor de par, antes de mostrar todo o resto).

🔴 Fricção 2 (estrutural — afeta iniciante; recorrência da fricção 1 do relatório 3): o aviso continua sem mostrar dados da pool existente (TVL, APR, idade). Mesmo problema do relatório 3 — usuário clica "Adicionar liquidez" sem saber em que está entrando. Em V2 isso é ligeiramente menos crítico (V2 é mais previsível que V3/Infinity), mas ainda assim entra em pool com $5 ou com $5M é decisão diferente. Fix: card resumo embutido no aviso. Padrão de produto, não fix de tela.

🔴 Fricção 3 (cosmética — afeta todo perfil; recorrência da fricção 3 do relatório 3): CTA verde claro "Adicionar liquidez" no aviso vs. CTA turquesa "Insira uma quantia" abaixo. Duas paletas para CTA primário na mesma tela. Inconsistência reincidente entre as telas do fluxo. Fix: unificar token de CTA primário.

🔴 Fricção 4 (cosmética — afeta intermediário): o restante da tela (Nível de taxa fixo, preço inicial, depósito, derrapagem) fica visível e disabled mesmo quando o aviso de pool existente já decidiu o destino. Em V2 com colisão, todo esse conteúdo é teatro — o usuário não vai criar pool nem precisa ver os campos. Fix: colapsar tudo abaixo do aviso quando colisão é detectada; mostrar apenas o aviso + CTA + link "Escolher outro par". Trade-off: menos tela parece mais simples mas pode confundir se usuário esperava ver a configuração; preço pequeno por foco.

🟡 Oportunidade competitiva (média leverage no target): V2 como motor "simples" sem decisões é convenção e vantagem real — Uniswap V2 também é assim. Não há grande oportunidade Kotai na própria tela V2 — o motor é simples por design e os fixes acima são polish. A oportunidade real está antes: o usuário chegou em V2 porque escolheu deliberadamente o motor simples no relatório 1, ou tropeçou aqui sem saber a diferença? Reforça a oportunidade do relatório 1 (wizard de intent), não nova.

Observação adicional: o claim implícito do segmento (V2 = "simples") fica visível na quantidade de campos vs. Infinity/V3 — boa demonstração de que arquitetura de informação comunica posicionamento. Vale como referência interna para quando o produto Kotai apresentar suas próprias variantes: a complexidade da tela deve refletir a complexidade do motor; esconder controles em V2 que não pertencem a V2 é honestidade.

7. Adicionar liquidez à pool existente — BNB/CAKE Infinity LBAMM 0,01% (preview com gráfico vazio + 2 avisos)

Função: Tela do fluxo "Adicionar liquidez" após redirect da detecção de pool existente. Mostra preview completo da pool (par, tier, motor, preço atual, APR estimada), gráfico histórico (vazio nesta pool por dados insuficientes), seleção de range, forma de liquidez, e bloco de depósito com dois avisos amarelos relevantes (desvio de preço da pool vs. mercado + TVL baixo).

Componentes: breadcrumb "Farms > Detalhes do pool > Adicionar liquidez"; header da pool — ícone busca + par "BNB / CAKE" + badge "0,01%" + tag "Infinity | LBAMM"; à direita do header — "Preço atual: 350,74885 CAKE = 1 BNB" + ícone refresh + "APR EST. 0%"; coluna esquerda — toggle "Visualizar preços em BNB", segmento de período 1M (ativo) / 7D / 1D, área de gráfico com texto centralizado "Dados insuficientes para exibir o gráfico de preços históricos", eixo Y (342–360) com handles superior 360 e inferior 342, eixo X (06 ABR a 01 MAY), Preço mínimo 342,09311 / Preço máximo 359,62361 / Núm. de bins 51, "Escolha a forma de liquidez" + Spot (ativo) / Curve / Bid-Ask; coluna direita — "Valor do depósito $0", cards BNB e CAKE com inputs 0.0 / ~$0,00 e saldos 0, "Tolerância de derrapagem 2,00%", "Protegido pelo MEV", aviso amarelo 1 "O preço da pool mostra um desvio significativo das taxas de mercado atuais (18 %). Isso aumenta o risco de perdas por arbitragem. Por favor, prossiga com cautela.", aviso amarelo 2 "Adicionar liquidez a uma pool com baixo TVL acarreta um risco maior de perdas devido a flutuações de preço. Prossiga com cautela.", CTA disabled "Insira uma quantia".

Regras de negócio: "APR EST. 0%" indica que a pool não gerou fee suficiente nas últimas 24h pra calcular APR estável — pool nova ou inativa; gráfico vazio confirma dados insuficientes; aviso de desvio de preço é regra crítica — se o preço da pool divergir do preço de mercado externo, arbitradores corrigem antes do LP ganhar fee, transferindo valor pro arbitrador (LP sai com prejuízo); aviso de baixo TVL aumenta peso da volatilidade individual (pequenos swaps movem o preço muito); núm. de bins 51 derivado do range escolhido + etapa do bin do LBAMM.

🟢 Insight: os dois avisos amarelos são o melhor copy do fluxo de criação inteiro. Concretos, com número específico (18 %), explicam a consequência (perdas por arbitragem) em vez de só nomear o risco. "Prossiga com cautela" é tom calibrado — não bloqueia, não esconde, não amedronta excessivamente. Para um produto cujo target é iniciante/intermediário, esse copy é exatamente o que falta no resto da jornada. Reconhecer que o LP pode estar entrando em armadilha (pool órfã com preço destorcido) e narrar isso explicitamente é maturidade.

🔴 Fricção 1 (estrutural — afeta iniciante; crítica): apesar dos avisos amarelos, o produto não bloqueia nem oferece alternativa concreta. "Prossiga com cautela" é orientação sem ação — o usuário lê e tem que decidir sozinho o que "cautela" significa. Iniciante não tem ferramenta pra avaliar 18% de desvio (é alto? é normal? é catastrófico?). Fix óbvio (mudar pra "Sugerimos não prosseguir") é excessivo. Fix verdadeiro: aviso acompanhado de orientação concreta — "Aguarde o preço da pool convergir (estimativa: 2-4 horas) ou explore pool similar com TVL maior (link)" — dá alternativa ao usuário em vez de só avisar. Trade-off: precisa de heurística para tempo de convergência e descoberta de pools alternativas; é trabalho, não invenção.

🔴 Fricção 2 (estrutural — afeta iniciante; ironia da arquitetura): o fluxo "Criar Pool de Liquidez" levou o usuário até aqui (Adicionar liquidez à pool existente) sem nunca explicar a transição. O usuário começou em "criar", apertou um botão verde, e agora está em "adicionar" — o breadcrumb mudou de "Farms > Criar Pool de Liquidez" para "Farms > Detalhes do pool > Adicionar liquidez" sem narrar a mudança de contexto. Iniciante perde rastro de onde está. Fix: header da tela explicar a transição ("Você foi redirecionado para Adicionar liquidez porque a pool BNB+CAKE 0,01% Infinity já existe. Voltar para Criar.") + breadcrumb mantém referência à origem. Trade-off: header mais alto; ganho é continuidade de fluxo mental.

🔴 Fricção 3 (estrutural — afeta iniciante): gráfico vazio com texto "Dados insuficientes para exibir o gráfico de preços históricos" deixa os handles do range (360 / 342) sem âncora visual. Como o usuário decide se ±5% é razoável sem ver onde o preço esteve nas últimas semanas? Fix: quando dados são insuficientes, substituir gráfico vazio por aviso explícito + range default conservador (ex.: full-range) e mensagem "Sem histórico, recomendamos full-range para esta pool". Trade-off: força default que pode não ser o que o usuário quer; ganho é proteção do iniciante diante de incerteza máxima.

🔴 Fricção 4 (cosmética — afeta intermediário): "APR EST. 0%" em destaque no header. Para uma pool ativa, 0% seria fricção crítica; aqui é coerente (sem histórico, sem estimativa). Mas mostrar "0%" como se fosse a APR real é misleading — sugere pool que não paga. Fix: substituir por "—" ou "Sem histórico" quando o cálculo não tem base, deixar "0%" só para pools com histórico real de 0% fee. Trade-off: nenhum; é diferenciar "sem dado" de "dado é zero".

🟡 Oportunidade competitiva (alta leverage no target): avisos de risco contextual (desvio de preço, TVL baixo) com número específico são raros — Uniswap V3, Curve, Sushi V3 expõem range e APR sem alertar sobre pool órfã ou desvio. Pancake aqui faz o que outros não fazem. Mas o produto entrega aviso sem ação acompanhada. Diferenciação Kotai: cada aviso de risco vem com alternativa concreta — "Pool órfã detectada (18% desvio). Pools BNB+CAKE com TVL >$1M: [lista de 3]" — converte aviso em decisão. Trade-off: requer infraestrutura de discovery de pools similares + métricas em tempo real; é o tipo de diferencial onde a engenharia paga dividendo direto em UX.

Observação adicional: "Forma de liquidez" (Spot/Curve/Bid-Ask) aparece aqui em pool LBAMM Infinity — coerente com o motor. Em pool V3 ou V2 esse controle não existiria. Vale validar nas próximas telas (Adicionar liquidez em V3, em V2) que a UI consistentemente esconde controles que não pertencem ao motor da pool em foco, em vez de mostrar disabled.

Codex Consolidado — Criar Pool de Liquidez (pancake)

Caráter geral do fluxo

O fluxo de criação de pool do Pancake é tecnicamente completo e tem decisões de produto importantes: separa motores, reorganiza parâmetros conforme o tipo de AMM, detecta pool existente, bloqueia combinações inválidas e alerta estados de risco antes da ação on-chain. Esses acertos reduzem erro operacional em um fluxo DeFi complexo.

A fragilidade recorrente é que a experiência ainda se organiza mais pela arquitetura interna do protocolo do que pela intenção do LP. Em várias telas, o usuário precisa escolher motor, submotor, fee tier, tickspacing, range, distribuição, preço inicial e resposta a risco antes de entender o impacto prático dessas escolhas: gestão exigida, chance de ficar fora do range, aderência ao par, liquidez dominante, custo operacional e risco de entrar em uma pool ruim.

A interface frequentemente mostra estados relevantes, como pool existente, baixo TVL, desvio de preço, campos desabilitados e APR zerado. O problema recorrente é que esses estados nem sempre fecham o ciclo decisório. Eles informam que algo aconteceu, mas raramente dizem qual é a consequência, qual caminho é mais conservador ou qual próximo passo faz sentido para um usuário iniciante/intermediário.

🟢 Insights recorrentes

1. Pancake expõe honestamente a escolha de motor em vez de esconder diferenças estruturais entre pools.
A seleção entre Infinity, V3 e V2 na tela 1, a alternância Infinity/LBAMM na tela 2, a reorganização CLAMM na tela 4 e a coluna única de V3 na tela 5 mostram uma decisão positiva: o produto não trata motores diferentes como se fossem equivalentes.

Esse é um acerto porque cada motor muda o modelo mental do LP. A UI preserva distinções relevantes entre full-range, concentrated liquidity, bins, fee tier e parâmetros de range. A oportunidade posterior não é esconder essa complexidade, mas traduzi-la em intenção e consequência antes de pedir escolhas técnicas.

2. A interface separa progressivamente seleção estrutural, parâmetros e ação on-chain.
A estrutura em duas colunas da tela 2, a mudança de campos por motor na tela 4 e a simplificação em coluna única para V3 na tela 5 indicam uma tentativa consistente de agrupar decisões por etapa lógica.

Esse padrão ajuda a reduzir mistura entre escolha de par, configuração de pool e depósito. Mesmo quando faltam labels de uso ou orientação, há uma base estrutural aproveitável para evoluir o fluxo sem reescrever a experiência inteira.

3. Pancake detecta estados importantes antes de deixar o usuário avançar.
O aviso de pool existente na tela 3 e na tela 6 evita tentativa on-chain inválida. Os alertas de desvio de preço e baixo TVL na tela 7 também mostram que a interface monitora risco contextual, não apenas validade formal do formulário.

O acerto é a presença desses guardrails. A lacuna aparece no passo seguinte: esses estados ainda precisam virar orientação acionável, com severidade, consequência e recomendação contextual.

4. Estados derivados são visíveis cedo, permitindo diagnosticar pré-requisitos do fluxo.
A coluna direita disabled na tela 2, o CTA “Par inválido” na tela 5 e o “APR EST. 0%” na tela 7 tornam visíveis estados de indisponibilidade, cálculo ausente ou pré-requisito incompleto.

Isso é útil como instrumentação de interface, mas precisa de melhor semântica. Sem copy explicativa, o usuário pode interpretar indisponibilidade como erro definitivo ou valor real.

🔴 Fricções recorrentes

1. Decisões DeFi críticas aparecem como parâmetros técnicos, não como escolhas por intenção.
A seleção entre Infinity, V3 e V2 na tela 1, o formulário Infinity/LBAMM na tela 2, o range CLAMM na tela 4 e os fee tiers V3 na tela 5 repetem o mesmo padrão: a tela pede decisões estruturais antes de traduzir suas consequências.

O usuário encontra termos como CLAMM, LBAMM, bins, hooks, tickspacing, MEV e fee tier sem uma camada anterior de objetivo. O atrito é de arquitetura de decisão, não de tooltip. Um fluxo melhor começaria por intenção: simplicidade, gestão ativa, par estável/volátil, maior capital efficiency, menor risco operacional ou full-range.

2. Presets e defaults não explicam critério operacional.
Fee tier na tela 2, chip/campo customizado na tela 3, tickspacing e range na tela 4 e fee tiers V3 na tela 5 aparecem como opções neutras. Para LPs intermediários, isso é especialmente ruim: eles sabem que a escolha importa, mas não recebem labels de uso ou evidência.

Fee tier deveria indicar uso recomendado e liquidez dominante; range deveria comunicar chance de sair do range; tickspacing deveria explicar impacto operacional; presets deveriam deixar claro se são conservadores, agressivos ou compatíveis com pares específicos.

3. Pool existente vira redirect subinformado, não bifurcação informada.
Na tela 3 e na tela 6, a detecção é útil e o redirect faz sentido. O problema é que faltam TVL, volume, APR, idade, versão, inspeção ou comparação antes de levar o usuário para outro caminho.

Na tela 7, o usuário já está em adicionar liquidez sem rastro narrativo suficiente da mudança. A experiência precisaria dizer: “essa pool já existe; você está adicionando liquidez a ela”, com dados mínimos para confirmar se essa é a pool certa.

4. Transições entre criar, alternar motor e adicionar liquidez quebram continuidade mental.
A escolha de motor na tela 1, a alternância CLAMM/LBAMM na tela 2, o estado CLAMM da tela 4 e a passagem de criar para adicionar entre tela 6 e tela 7 mudam vocabulário, campos ou objetivo do fluxo sem narrativa suficiente.

O problema não é impedir criação duplicada nem reorganizar campos por motor; isso é correto. O atrito é a troca de contexto parecer consequência interna do protocolo. Ao trocar para CLAMM, por exemplo, a UI deveria explicitar que range e tickspacing passam a definir a exposição do LP.

5. Risco é alertado, mas sem severidade nem próximo passo recomendado.
A tela 7 mostra avisos relevantes, mas “prossiga com cautela” transfere a interpretação para o usuário. A recorrência com outros estados críticos do fluxo é a ausência de recomendação contextual: aguardar, usar full-range, revisar preço, ver pools similares ou trocar rota.

6. Preview de etapas futuras às vezes vira ruído operacional.
Campos disabled na tela 2 e conteúdo abaixo do aviso na tela 6 mostram a estrutura do fluxo, mas não deixam claro se algo está bloqueado por falta de input ou se deixou de ser relevante porque o caminho real mudou.

🟡 Oportunidades competitivas do fluxo

1. Wizard de criação guiado por intenção, com modo técnico preservado.
A oportunidade é sustentada por recorrência em tela 1, tela 2, tela 4 e tela 5. Kotai poderia diferenciar ao recomendar motor e parâmetros a partir de par, perfil de gestão, tolerância a risco e preferência por simplicidade. O modo avançado continuaria acessível, mas o default deixaria de ser um formulário técnico sem contexto.

Perguntas-teste: concorrentes tendem a expor parâmetros técnicos de forma parecida; isso afeta iniciantes e intermediários porque a escolha muda risco, gestão e capital efficiency; a lacuna parece falta de investimento em camada decisória, não impossibilidade técnica; e a diferença seria perceptível porque o usuário receberia recomendação antes de configurar termos como CLAMM, LBAMM, bins, tickspacing e fee tier. Trade-off: um wizard pode virar fricção para power users se bloquear edição direta, então precisa ser skippable, transparente e acompanhado de modo avançado.

2. Range de liquidez visualizado contra histórico e risco de sair do range.
A tela 4 sustenta uma oportunidade validada: mostrar histórico 7d/30d, overlay do range, percentual de tempo dentro/fora e simulação da posição. A tela 7 reforça como hipótese o limite do gráfico vazio: quando não há histórico, a UI deveria trocar a decisão precisa por recomendação conservadora com override explícito.

Perguntas-teste: concorrentes frequentemente mostram range como controle técnico, não como risco histórico interpretado; isso afeta iniciantes e intermediários porque range errado pode deixar capital fora de uso; a lacuna parece falta de investimento em visualização e cálculo de suporte, não bloqueio conceitual; e a melhoria seria perceptível porque transforma um número abstrato em probabilidade operacional. Trade-off: exige dados históricos granulares, ocupa espaço visual e pode transmitir precisão excessiva se a simulação não comunicar incerteza.

Hipóteses pendentes

• Tela 7: avisos de risco com consequência, severidade e ação recomendada parecem uma oportunidade competitiva promissora, mas ficam como hipótese pendente porque a fonte 07 não foi incluída na amostra semântica do review. Para promover a 🟡, é preciso validar diretamente se os alertas de baixo TVL/desvio de preço sustentam impacto, recorrência, viabilidade e diferenciação perceptível.

Pontos isolados (1 tela)

• Tela 2: “Persona %” parece erro de copy e reduz confiança, mas é polish pontual.
• Tela 4: textos truncados em cards de depósito são problema de acabamento, não tese estrutural.
• Tela 5: V3 não mostra chips de range relativo vistos em Infinity/CLAMM, sugerindo regressão de paridade entre motores concentrated liquidity.
• Tela 6: após detectar pool V2 existente, campos de criação permanecem visíveis e viram teatro operacional.
• Badge de MEV citado no lote 1 permanece candidato fraco, pois não há fricção formal recorrente com block id suficiente para consolidar tese.

Nota de auditoria Codex

Consolidado ajustado a partir do review Codex fornecido, sem leitura de arquivos, comandos, subagents ou edição local. Os wikilinks foram mantidos embutidos nas menções, sem links soltos. Oportunidades promovidas para 🟡 incluem agora as 4 perguntas-teste e trade-offs exigidos pela régua; a oportunidade de alertas de risco acionáveis permanece como hipótese pendente por depender da tela 7 não amostrada.

2. TWAP — Tooltip em "Tamanho por negociação" (piso de $100 USD)

Função: Mesma tela do relatório 1, agora com tooltip aberto sobre o label "Tamanho por negociação". Declara o valor de cada execução individual e revela o piso econômico mínimo.

Componentes: idênticos ao relatório 1 — nesta captura o toggle "Preço limite" está visível (off), confirmando que TWAP opera em dois modos: TWAP puro (executa no preço de mercado quando o slot dispara) e TWAP + preço limite (executa só se o mercado cruzar a barreira). Tooltip: "Define o tamanho de cada negociação individual que será executada durante a vigência da sua ordem. Obs.: o tamanho mínimo por negociação deve ser superior a 100 USD."

Regras de negócio: tamanho por execução = (valor total) ÷ (Total de negociações), com piso rígido de 100 USD por slot. Constraint cruzado: querer 10 execuções de $50 cada ($500 total) é rejeitado — o piso obriga $1000+ para 10 fatias. Piso existe para cobrir gas + fee do protocolo Orbs sem o usuário ficar no prejuízo.

🟢 Insight: declarar o piso de 100 USD por execução em tooltip — antes do erro acontecer — é forma honesta de comunicar constraint econômico. É preferível a deixar o usuário setar valores impossíveis e ver erro só na confirmação. Direção de produto correta: "explicar limites antes, não validar depois".

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): a regra de $100/negociação fica escondida em tooltip — invisível até hover/click. E o efeito da regra é cross-field: limita o Total de negociações em função do valor digitado em "De". O slider de Total de negociações não comunica essa dependência. Iniciante move o slider para N=20, depois descobre que precisa de $2000 mínimo — frustração tardia. Solução óbvia que falha: validar só no CTA gera mensagem genérica e mantém o dead-end silencioso. Alternativa: hint dinâmico embaixo do slider — "Cada execução precisa ter ≥ $100. Com seu valor atual ($X), o máximo de negociações é Y." Reage ao valor de "De" e ao N. Trade-off: cálculo reativo extra; ganho é eliminar dead-end.

🔴 Fricção 2 (estrutural — afeta iniciante): o piso é declarado em USD, mas o swap é cotado em BNB→CAKE e o preview de "Tamanho por negociação" também é em BNB ("0 BNB"). Iniciante precisa fazer conversão mental "0,3 BNB = ? USD" para saber se está acima do mínimo. Solução óbvia que falha: mostrar só em USD esconde a unidade nativa. Alternativa: dual-unit no preview — "Tamanho por negociação: 0,12 BNB (~$50 — abaixo do mínimo de $100)" com alerta amber quando viola o piso. Trade-off: mais texto; ganho é eliminar a conversão mental e sinalizar erro antes do CTA.

🟡 Oportunidade competitiva (média leverage — pisos econômicos explicados como trade-off, não como erro): Uniswap/1inch/Pancake tratam pisos econômicos (fee, slippage, tamanho mínimo) como erros silenciosos ou validações tardias. Usuário descobre o limite só na hora de executar. Passa as 4 perguntas: (1) padrão indústria de validação tardia; (2) afeta iniciante e intermediário, especialmente quem experimenta feature nova; (3) falta de investimento em UX preventiva; (4) hint proativo é claramente perceptível. Diferenciação Kotai: princípio sistêmico — todo input com constraint cross-field exibe hint dinâmico atualizado pelos outros campos. Aqui: hint do tamanho mínimo na unidade nativa + USD em parênteses, neutro quando ok, amber quando viola. Trade-off: cada campo demanda spec de validação visual; ganho é onboarding implícito em toda a tela.

Observação adicional (Preço Limite como toggle dentro do TWAP): o toggle "Preço limite" coexistindo com TWAP cria 4 modos efetivos (Swap puro, Limite puro, TWAP puro, TWAP + Limite). Para o usuário, isso é matriz de comportamentos que a UI não explicita. Em Kotai, vale decidir se o toggle merece estar nesta tela ou se TWAP-com-limite vira modo próprio nas tabs — opção que evita matriz mental escondida.

1. TWAP — Estado inicial com tooltip em "Total de negociações"

Função: Estado inicial do form TWAP (Time-Weighted Average Price), feature que divide um swap grande em N execuções menores espaçadas no tempo para reduzir slippage e exposição a MEV. Tooltip aberto no label "Total de negociações".

Componentes: tabs Swap / TWAP / Limite (TWAP ativo em roxo) + ícone gráfico; painel esquerdo "Ordens abertas (0) / Histórico de ordens" com empty state "Nenhuma ordem aberta"; painel direito com bloco De (BNB BNB Chain, 0.00, ~0 USD); seta ↓ teal; bloco Para (CAKE BNB Chain, 0.00, ~0 USD); cotação "1 BNB ⇄ 413.892 CAKE"; bloco "Total de negociações: 1" com slider e mascote-bunny; "Tamanho por negociação: 0 BNB"; row "Intervalo de negociação: 2 ▾" + "Duração máxima: 4 ▾"; CTA disabled "Insira o valor"; rodapé "Desenvolvido por Orbs". Tooltip: "O número total de negociações programadas para sua ordem. Observe que, em ordens limitadas, nem todas as negociações programadas podem ser executadas."

Regras de negócio: TWAP fraciona a ordem em N execuções espaçadas pelo Intervalo, limitadas pela Duração máxima. Combinado com Preço Limite (toggle visível em outras telas do fluxo), só dispara nos slots em que o preço cruzar a barreira — daí "nem todas podem ser executadas". Execução é feita via Orbs Network (leilão off-chain + liquidação on-chain).

🟢 Insight: explicar no tooltip que "nem todas as negociações programadas podem ser executadas em ordens limitadas" é honestidade calibrada — o produto admite o limite de garantia antes do gas pago, em vez de deixar a expectativa quebrar on-chain. Em DeFi, expectation-setting preventivo é raro; aqui virou copy de produto. Decisão correta.

🔴 Fricção 1 (estrutural — afeta iniciante): TWAP aparece como tab de peso visual igual a Swap e Limite, mas é instrumento conceitualmente avançado (exige modelo mental de slippage, market impact, MEV e fracionamento temporal). Iniciante que clica por curiosidade cai num form com 4 controles novos cujos tooltips assumem vocabulário já formado ("ordens limitadas", "negociações programadas"). Resultado: paralisia ou ordem mal-formada. Solução óbvia que falha: esconder TWAP atrás de "modo avançado" tira diferencial para intermediário/avançado. Alternativa: manter a tab visível com mini-camada pré-form de 1 frase ("TWAP divide seu swap em vários menores ao longo do tempo — útil para ordens grandes, acima de ~$500. Não tem certeza? Use Swap."). Trade-off: 1 linha de copy; ganho é redirecionar iniciante sem fechar a porta.

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário): Intervalo (2) e Duração máxima (4) aparecem como números crus sem unidade visível. 2 quê? min/h/dias? A unidade só aparece quando o dropdown abre — o estado fechado é ilegível. Solução óbvia que falha: cravar unidade fixa tira a flexibilidade do dropdown. Alternativa: mostrar a unidade inline no valor selecionado ("2 horas ▾" / "4 horas ▾"), dropdown segue editável. Trade-off: leve aumento horizontal; ganho é alto.

🟡 Oportunidade competitiva (alta leverage no target — pré-cálculo do plano TWAP antes de criar a ordem): Uniswap, 1inch e Pancake mostram os 4 inputs (N, tamanho/neg, intervalo, duração) e deixam o usuário inferir o plano final na cabeça. Iniciante e intermediário não visualizam "5 execuções de 2 BNB cada, começando agora e terminando em ~5h" — math + projeção temporal que ninguém faz mentalmente bem. Passa as 4 perguntas: (1) todos concorrentes deixam o cálculo na cabeça; (2) afeta iniciante e intermediário diretamente — TWAP é onde o intermediário tenta feature avançada e desiste; (3) falta de investimento em UX, não dificuldade técnica (cálculo é trivial); (4) preview é claramente perceptível. Diferenciação Kotai: bloco "Pré-visualização do plano" inline assim que houver valor + N — timeline visual (|—|—|—|—|) + texto natural ("5 execuções de 2 BNB cada, espaçadas em 1h, primeira agora, última às ~19:30"). Trade-off: novo componente; é o que separa "TWAP que iniciante entende" de "TWAP que só dev usa".

Observação adicional (TWAP "Desenvolvido por Orbs"): a tela declara explicitamente que a feature é powered by Orbs Network — protocolo third-party que opera leilão off-chain de resolvers e liquida on-chain. Isso explica a margem de 2 min citada no tooltip de TWAP3. Trust signal misto: "powered by" deixa claro que não é Pancake fazendo magic, mas introduz dependência externa que iniciante não sabe avaliar. Em Kotai, decidir cedo: own o TWAP (controle total, custo) ou parceria explícita (Orbs/Hashflow, mais barato). Se for parceria, declarar com a mesma clareza — não esconder.

3. TWAP — Tooltip em "Intervalo de negociação" (margem do leilão Orbs)

Função: Mesma tela com tooltip aberto sobre "Intervalo de negociação" (valor 2). Define o tempo entre execuções consecutivas e revela overhead do protocolo.

Componentes: idênticos. Tooltip: "O tempo estimado que decorrerá entre cada negociação do seu pedido. Observe que esse tempo inclui uma margem de dois minutos para o leilão de ofertantes e a liquidação de blocos, que não podem ser previstos com precisão, portanto, o tempo real pode variar."

Regras de negócio: TWAP da Pancake é executada via Orbs Network, que opera leilão off-chain entre resolvers que competem para preencher cada slot. Os ~2 minutos extras são overhead estrutural do protocolo (leilão + liquidação on-chain), não configurável. Logo, "intervalo 2" não significa 2 unidades exatas — é 2 + ~2min.

🟢 Insight: revelar overhead de protocolo no tooltip ("margem de dois minutos para leilão") é decisão de produto técnica-honesta. A maioria das DEXs esconde mecanismo (parece magic). Pancake escolhe explicar: "a execução não é determinística porque depende de leilão off-chain". Trade-off bem-feito entre simplicidade e verdade — intermediário ganha confiança, iniciante ignora mas não é prejudicado.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): valor "2" sem unidade (mesma raiz da Fricção 2 do Rel 1). Pior: o tooltip mistura duas grandezas — "tempo estimado entre negociações" (input do usuário) + "margem de 2 minutos" (overhead do protocolo). Iniciante lê "margem de 2 minutos" e infere que o intervalo todo é 2 min; intermediário não sabe se "2" é o intervalo dele ou o overhead. Solução óbvia que falha: só separar visualmente no tooltip não resolve o número cru sem unidade. Alternativa: dropdown mostra unidade selecionada ("2 horas ▾") e tooltip reformula com decomposição explícita — "Tempo entre execuções: ~2 horas (seu intervalo) + ~2 minutos (overhead do leilão Orbs). Tempo real pode variar." Trade-off: tooltip mais longo; é detalhe que constrói confiança no intermediário.

🔴 Fricção 2 (estrutural — afeta iniciante): "leilão de ofertantes" e "liquidação de blocos" não são decodificáveis para iniciante. Quem entrou porque ouviu "TWAP reduz slippage" não tem vocabulário para isso — vai inferir errado ou ignorar o tooltip e proceder com modelo mental quebrado. Solução óbvia que falha: substituir os termos técnicos quebra precisão para intermediário/avançado. Alternativa: tooltip de dois níveis — primeira linha em linguagem natural ("o tempo real pode atrasar 1–2 min porque a execução depende de uma fila externa") + link "Como funciona o leilão Orbs ↗" para quem quer mecanismo. Trade-off: design de tooltip expansível; ganho é não excluir iniciante.

🟡 Oportunidade competitiva (média leverage — decompor "seu input" vs "overhead do sistema"): toda DEX/aggregator com timing variável (TWAP, ordens limit com expiração, ordens delayed) empacota input do usuário + overhead do protocolo num número só. Iniciante e intermediário fazem suposições erradas sobre execução. Passa as 4 perguntas: (1) padrão indústria de empacotamento opaco; (2) afeta iniciante e intermediário diretamente; (3) falta de investimento em decomposição de UX; (4) ver "seu pedido + overhead = tempo real" explícito é claramente perceptível. Diferenciação Kotai: princípio sistêmico — sempre que uma métrica (tempo, fee, valor) tiver componentes "seu input + overhead do sistema", decompor explicitamente. Aplica em TWAP (intervalo + buffer Orbs), em gas (gas L1 + gas L2 em rollups), em fee (fee do protocolo + fee de roteamento). Trade-off: design demanda mais células de info; ganho é trust signal sistêmico que diferencia a marca.

9. TWAP — Tela completa wallet-desconectada, valores zerados, Preço limite off

Função: Vista zoom-out do form TWAP em estado wallet-desconectada, sem valor preenchido e Preço limite off. Mostra todo o widget de uma vez, painel esquerdo "Ordens abertas (0)" com empty state "Nenhuma ordem aberta", rodapé "Desenvolvido por Orbs" e footer institucional completo logo abaixo. Captura serve como referência arquitetural — o que o iniciante vê ao abrir a página /swap/twap pela primeira vez.

Componentes: header global (logo, nav Trade/Perpétuos/Ganhar/Jogar/IA, busca, settings, CTA wallet $0.00); painel esquerdo (tabs Ordens abertas (0) / Histórico de ordens, empty state); painel direito completo (tabs Swap/TWAP/Limite + ícone gráfico, blocos De BNB / Para CAKE, toggle Preço limite off, cotação 1 BNB = 413.892 CAKE, slider Total = 1, Tamanho 0 BNB, Intervalo 2 ▾, Duração 4 ▾, CTA disabled "Insira o valor"); rodapé do widget "Desenvolvido por Orbs"; abaixo, footer institucional completo (Ecossistema / Business / Desenvolvedores / Suporte / Sobre) com social icons; rodapé final com toggle sun/moon + CTA "Compre CAKE → $1.517".

Regras de negócio: wallet desconectada = nenhuma operação executável. Mas o widget é totalmente interativo no estado desconectado — usuário pode mexer em todos os campos, abrir dropdowns, ativar toggles. O CTA permanece "Insira o valor" (não "Conectar Wallet") — TWAP não permite cotação real sem valor. Header do wallet mostra "$0.00" como placeholder visual antes do conectar.

🟢 Insight: o widget é totalmente explorável sem wallet conectada — o iniciante pode entender o form, abrir dropdowns, ler tooltips e configurar parâmetros antes de assumir o passo psicológico de conectar wallet. Isso reduz fricção de "primeiro contato → tentativa" e está alinhado ao espírito de "try before connect" (vide oportunidade do Rel 21 do fluxo Comprar). Decisão de produto correta para o target iniciante.

🔴 Fricção 1 (estrutural — afeta iniciante): mesmo desconectado, o form TWAP tem 4 controles paramétricos (Total, Tamanho, Intervalo, Duração) + 1 toggle (Preço limite) + 2 dropdowns de token, sem nenhum onboarding contextual. Iniciante que cai aqui via search ou link externo vê dashboard de instrumento avançado sem entender o que "TWAP" significa. Não há micro-explanation, não há "o que é isso?", não há link "Como funciona" próximo do título. Solução óbvia que falha: tour modal de onboarding é intrusivo e o usuário fecha sem ler. Alternativa: linha discreta entre as tabs e o bloco De — "TWAP: divide um swap grande em vários menores ao longo do tempo. Bom para ordens acima de ~$500." + link "Saiba mais". Sem modal, sem bloqueio. Trade-off: 1 linha de copy permanente; ganho é redução de "o que é isso?" silencioso.

🔴 Fricção 2 (cosmética — afeta iniciante e intermediário): CTA disabled "Insira o valor" não comunica que o usuário ainda precisa conectar wallet em algum momento. Quando o iniciante for inserir o valor, vai descobrir que o CTA muda para "Conectar wallet" — surpresa. Mesma fricção apontada no Rel 2 do fluxo Limite (CTA disabled silencioso). Alternativa: CTA enabled com label dinâmico mostrando a próxima ação ("Conectar wallet" → "Inserir valor" → "Aprovar BNB" → "Realizar ordem TWAP"). Trade-off: aumenta complexidade do componente; ganho é eliminar dead-end.

🟡 Oportunidade competitiva (alta leverage no target — feature avançada com micro-onboarding inline, não escondida em modal): Uniswap, 1inch e Pancake jogam features avançadas (TWAP, Limit, Pools V3, Routing avançado) na cara do usuário desconectado sem nenhuma camada didática contextual. Para iniciante, é dashboard de painel de avião — fonte de paralisia. Esconder atrás de "modo avançado" perde o intermediário curioso; mostrar como está perde o iniciante. Passa as 4 perguntas: (1) padrão indústria de "jogar feature avançada sem contexto"; (2) afeta diretamente iniciante e intermediário curioso; (3) ninguém resolveu por preguiça de copy + design de hint inline, não dificuldade; (4) ler 1 linha explicativa antes do form é claramente perceptível. Diferenciação Kotai: toda tela de feature avançada tem 1 linha de hint inline persistente (não modal) entre header da feature e o form — explicando o que é, para quem é, com link "Saiba mais" para quem quer profundidade. Trade-off: copywriting + manutenção; ganho é onboarding implícito a custo zero de UX.

Observação adicional (footer + widget na mesma vista): ver o footer institucional logo abaixo do CTA é decisão de layout que dilui o foco — o iniciante pode rolar e cair em "Compre CAKE" pensando que faz parte da operação. Reaplicar a Fricção 3 do Rel 8 — divisor visual forte ou âncora "PancakeSwap" antes do footer.

10. TWAP — Form preenchido com 1 BNB, saldo insuficiente, input focado (atalhos %)

Função: Estado do form após o usuário digitar 1 no campo De (BNB). Sistema cota destino, deriva parâmetros do plano TWAP e exibe alerta de saldo insuficiente. Input De está focado — daí a aparição dos atalhos 25% / 50% / MAX no canto superior direito do bloco.

Componentes: painel esquerdo "Ordens abertas (0) / Nenhuma ordem aberta"; painel direito: tabs Swap/TWAP/Limite + ícone gráfico; bloco De com chips "25% | 50% | MAX" no canto superior direito, BNB BNB Chain à esquerda, valor "1" + sublinha "~628.74 USD" à direita; alerta inline ⓘ "Saldo insuficiente de BNB" abaixo do bloco De; seta ↓; bloco Para CAKE BNB Chain valor "413.892" + "~627.97 USD"; toggle Preço limite off + cotação "1 BNB ⇄ 413.892 CAKE"; bloco do plano: Total de negociações = 6 (slider preenchido ~80%), Tamanho por negociação = 0.166 BNB; Intervalo 2 ▾, Duração 24 ▾; CTA "Realizar ordem TWAP" agora ENABLED em teal; rodapé "Desenvolvido por Orbs".

Regras de negócio: ao digitar valor em De, o sistema (a) cota o destino com a taxa atual, (b) calcula Tamanho por negociação = valor ÷ N, (c) verifica saldo da wallet conectada e exibe alerta se insuficiente, (d) habilita o CTA mesmo com saldo insuficiente — a validação acontece no momento da assinatura. Atalhos 25%/50%/MAX aparecem só quando o input De está focado. Total = 6 mantém Tamanho por negociação no piso de ~$100 USD com $628 totais (628 ÷ 6 ≈ $105 por execução).

🟢 Insight: o alerta inline "Saldo insuficiente de BNB" aparece IMEDIATAMENTE após a digitação — antes do CTA, antes da assinatura. É validação proativa do tipo certo: o usuário descobre o problema na origem (input), não na confirmação. Linha curta, ícone informativo, sem modal interrompendo. Padrão correto a replicar em Kotai.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): apesar do alerta de saldo insuficiente, o CTA "Realizar ordem TWAP" está ENABLED em teal. Iniciante vai clicar — vai abrir wallet prompt — vai assinar (ou tentar) — vai falhar. O alerta acima é cosmético se o CTA não reage. Pior: gas gasto na tentativa fica perdido em alguns wallets/redes. Solução óbvia que falha: desabilitar o CTA leva ao padrão silencioso (Rel 2 fluxo Limite). Alternativa: CTA habilitado com label dinâmico que reflete o estado real — "Saldo insuficiente — Adicionar BNB" (clique direciona para on-ramp / depósito), ou "Reduzir valor para 0.X BNB (seu saldo)" como auto-fix. Trade-off: lógica de CTA contextual; ganho é evitar tentativa fadada e oferecer caminho de resolução no mesmo gesto.

🔴 Fricção 2 (estrutural — afeta iniciante): quando o sistema preencheu Total de negociações = 6 automaticamente (derivado do piso de $100 USD por execução), não houve aviso de que isso aconteceu nem por quê. O iniciante que mexeu no slider antes e depois digitou o valor pode achar que sua escolha foi sobrescrita silenciosamente. E quem nunca mexeu no slider vê "6 fatias" surgindo do nada. Solução óbvia que falha: travar o slider quebra autonomia. Alternativa: quando o sistema ajusta N por causa do piso, mostrar toast/inline breve ("Ajustamos para 6 execuções — cada uma precisa ter ≥ $100. Você pode reduzir até 6."). Liga com a oportunidade do Rel 2 (hints preventivos). Trade-off: lógica de "detectar ajuste automático"; ganho é transparência.

🔴 Fricção 3 (cosmética — afeta intermediário): os atalhos 25% / 50% / MAX aparecem só quando o input está focado. Quem digitou manual já tirou o foco — atalhos somem (vide Rel 11). Para o intermediário que quer ajustar para 50% do saldo, é fricção: precisa clicar de volta no input para reaparecerem os botões. Solução óbvia que falha: deixar sempre visível polui o bloco. Alternativa: manter visíveis quando há saldo > 0 na wallet conectada, esconder só no estado desconectado/zero. Trade-off: lógica condicional; ganho é eliminar clique-extra recorrente.

🟡 Oportunidade competitiva (média leverage — alertas que se conectam ao CTA, não apenas ao input): Uniswap, 1inch e Pancake mostram alertas (saldo, slippage, gas alto) acima do CTA mas o CTA não reflete o alerta. Iniciante e intermediário ignoram aviso e clicam confiantes. Passa as 4 perguntas: (1) padrão indústria de alerta dissociado do CTA; (2) afeta diretamente o iniciante — assinatura mal-fadada é o pior dead-end (gas perdido); (3) falta de investimento em CTA dinâmico; (4) ver o CTA assumir o problema ("Adicionar BNB" em vez de "Realizar ordem") é perceptível. Diferenciação Kotai: princípio sistêmico — o CTA reflete o próximo gesto real, com label dinâmico e ação direta (deeplink para on-ramp, auto-redução de valor, etc.). Trade-off: matriz de estados x labels do CTA; ganho é eliminar uma classe de erro caro.

Observação adicional (Total = 6 + Duração = 24 + Intervalo = 2): com Intervalo = 2 unidades e Duração = 24 unidades, cabem 12 execuções na janela (24 ÷ 2). O sistema reservou 6 — metade da capacidade, provavelmente por causa do piso de $100. Não fica claro para o usuário. Em Kotai, expor "plano pedido vs plano executável vs capacidade da janela" (Rel 4 e 6) cobre este caso também.

2. Ordem Limite — Estado inicial (default 0,1% "Best Returns")

Função: Tela completa de criação de ordem limite. Permite definir par, valor a vender, preço de gatilho e nível de comissão maker.

Componentes: switch superior Swap/TWAP/Limite (Limite ativo) + ícone de gráfico; bloco "Vender" BNB (0.00 / ~0 USD); seta downward; bloco "Comprar" CAKE (0.00 / ~0 USD); bloco "Vender quando 1 BNB valer: CAKE 414.552094 ~627.71 USD" com ícone de inversão; row de presets Mercado/+1%/+5%/+10%/Personalizado (Mercado selecionado); row "Nível da comissão" com chip "🔥 Best Returns" + opções 0,01% / 0,1% (0,1% selecionado); CTA disabled "Criar Ordem Limite"; link "Gerenciar Ordens Limite antigas (Obsoleto) »".

Regras de negócio: o preço de gatilho é cotado em CAKE-por-BNB. Os presets +1%/+5%/+10% aplicam o delta sobre o preço de mercado. O tier 0,1% é o default ("Best Returns") porque otimiza retorno do maker. Ordem só pode ser criada com valor > 0 e carteira conectada.

🟢 Insight: agrupar Swap/TWAP/Limite como 3 abas no mesmo header reconhece que são 3 mental models do mesmo gesto (trocar token) — o usuário muda de paradigma sem sair da tela. Os presets +1/+5/+10% são excelentes para iniciante porque ancoram o preço-alvo a uma referência conhecida (mercado) e ensinam que ordem limite vive em torno de algo, não no vácuo.

🔴 Fricção (estrutural — afeta iniciante): "Vender quando 1 BNB valer: CAKE 414.55…" é gramaticalmente ambíguo. O iniciante precisa de duas leituras para entender se é "se BNB subir" ou "se BNB cair", e nada indica direção (≥, "alcançar", "subir até"). Não há feedback dinâmico mostrando o delta vs preço atual. Diagnóstico errado: trocar para "se o preço atingir" — ainda não comunica favorabilidade. Alternativa: frase orientada à ação + delta — "Executar quando 1 BNB ≥ 414,5 CAKE • BNB precisa subir 0,0% vs mercado". Atualiza ao vivo conforme o usuário muda o preço.

🔴 Fricção 2 (estrutural): presets +1%/+5%/+10% não esclarecem contra o quê nem para qual lado é favorável. Para quem vende BNB, +X% sobre o mercado é "vender mais caro" (bom). Para quem compra CAKE, é "comprar pior". A direção da vantagem depende do papel. Alternativa: rotular como "+1% melhor que mercado" e ajustar sinal automaticamente conforme o lado da operação.

🟡 Oportunidade competitiva: o CTA "Criar Ordem Limite" fica desabilitado sem informar o que falta. Pancake/Uniswap/1inch fazem igual — CTA disabled silencioso. Para iniciante, isso é dead-end: o botão é cinza e ele não sabe o próximo passo. Critério: afeta iniciante; razão é falta de investimento; diferencial perceptível. Alternativa: CTA enabled, com label dinâmico mostrando o próximo gesto ("Conectar carteira" → "Inserir valor" → "Aprovar BNB" → "Criar Ordem Limite"). Trade-off: aumenta complexidade do componente; ganho compensa.

3. Ordem Limite — Estado após selecionar 0,01% ("Faster Execution")

Função: Mesma tela de criação de ordem limite, agora em estado interativo após o usuário clicar no tier 0,01%. O chip à direita do label "Nível da comissão" muda dinamicamente, refletindo o trade-off da escolha.

Componentes: idênticos ao estado anterior, com 3 mudanças notáveis — (a) no "Nível da comissão", o chip troca de "🔥 Best Returns" para "⚡ Faster Execution" e o highlight de seleção pula de 0,1% para 0,01%; (b) o preço cotado atualizou de 414,552094 para 414,572821 CAKE/BNB (mercado oscilou); (c) o subtotal em USD mudou de ~627,71 para ~629,44.

Regras de negócio: ao alternar o tier, o sistema reclassifica a escolha entre dois rótulos qualitativos pré-definidos (Best Returns vs Faster Execution). O preço de mercado é repolled periodicamente — mas não há indicador visível de quando foi atualizado nem botão "atualizar agora".

🟢 Insight (estrutural): o chip dinâmico que muda de label e ícone conforme a escolha do tier é um padrão raro e bem executado. Em vez de só destacar o valor selecionado, o sistema ensina o trade-off — "rapidez" vs "retorno" — em uma única superfície. Iniciante entende que existe dilema sem precisar abrir documentação. Esse é o tipo de microcopia que diferencia produto bom de produto medíocre.

🔴 Fricção (afeta iniciante e intermediário): o chip é o único feedback do trade-off, mas é qualitativo sem quantificação. Iniciante não sabe quanto mais rápido executa em 0,01% nem quanto a mais rende em 0,1%. Decisão acaba por vibe ("fogo parece mais agressivo que raio"). Diagnóstico errado: remover o chip — perde a única didática. Alternativa: chip mantém label qualitativo + micro-caption embaixo com dado real ("Faster Execution — ordens típicas preenchem em ~Xh / Best Returns — preenchem em ~Yh, +Z% retorno típico"). Trade-off: exige histórico por par; sem dados, manter qualitativo e marcar como "estimativa".

🔴 Fricção 2: existir apenas 2 tiers (0,01% e 0,1%) sugere que pode haver mais escondidos. Em AMMs V3 há 4 tiers padrão (0,01/0,05/0,30/1,00). Iniciante familiar com V3 procura outras opções e desiste. Alternativa: caption pequena ("2 níveis disponíveis para este par") fecha a dúvida.

🟡 Oportunidade competitiva: o trade-off "rapidez vs retorno" no modelo maker é mal comunicado em toda a indústria — Uniswap V3 mostra tiers como números frios, 1inch idem. Pancake já avança com chips coloridos qualitativos; falta a camada quantitativa. Critério: afeta iniciante; razão é falta de investimento em UX de pricing; ganho perceptível. Alternativa concreta: simulação inline — "0,01% → ~2h para preencher, retorno US$ X • 0,1% → ~12h, retorno US$ Y". Trade-off: depende de telemetria histórica por par; sem dados, manter qualitativo com disclaimer.

Observação adicional: o preço cotado mudou de 414,552 para 414,572 entre as duas capturas — o mercado oscila enquanto a tela está aberta, mas não há timestamp nem botão "atualizar agora". Para ordem limite isso é menos crítico (o gatilho é fixado no momento da criação), mas afeta confiança quando o usuário percebe o número mudando sob seus olhos.

1. Ordem Limite — Tooltip sobre "Nível da comissão"

Função: Estado em que o usuário fez hover no link "Nível da comissão" e o sistema exibe um tooltip explicando o conceito de fee tier no modelo maker/PMM da PancakeSwap.

Componentes: tooltip dark com texto em inglês — "Fee tier = the % you earn when your order fills. Lower tiers fill faster (at your limit price). Higher tiers earn more, but need the price to move further to execute."; campo "Comprar CAKE 0.00"; bloco "Vender quando 1 BNB valer: CAKE 414.738675 ~627.92 USD"; row Mercado/+1%/+5%/+10%/Personalizado parcialmente coberta pelo tooltip; label "Nível da comissão" com sublinhado tracejado (afordância de hover); CTA disabled "Criar Ordem Limite"; link "Gerenciar Ordens Limite antigas (Obsoleto) »".

Regras de negócio: o nível selecionado é a comissão que o usuário recebe (como maker) quando sua ordem for executada. Tiers menores (0,01%) tendem a preencher mais rápido; tiers maiores (0,1%) rendem mais por ordem mas exigem maior movimento de preço. CTA permanece desabilitado enquanto valor de venda for 0.

🟢 Insight: colocar tooltip no termo técnico mais opaco do fluxo ("Nível da comissão") é a decisão correta — é o ponto exato onde iniciante e intermediário perdem o entendimento. Posicionar antes do CTA respeita o pacing da decisão.

🔴 Fricção (estrutural — afeta 100% do target BR): o texto do tooltip está em inglês no meio de UI traduzida para PT-BR. Justamente o microcopy mais técnico do fluxo é o que falha na localização. Iniciante brasileiro lê e segue sem entender — equivale a não existir explicação. Diagnóstico errado: "traduzir literalmente" — perde-se a oportunidade de adequar ao vocabulário do produto. Alternativa: traduzir adaptando ao léxico ("Quanto você ganha quando sua ordem for executada. Níveis menores executam mais rápido; níveis maiores rendem mais, mas exigem que o preço se mova mais para disparar"). Trade-off: nenhum — é correção obrigatória.

🔴 Fricção 2 (estrutural): "Gerenciar Ordens Limite antigas (Obsoleto) »" exposto na superfície da feature ativa. Iniciante não sabe o que é "obsoleto", fica em dúvida se sua nova ordem vai parar lá, perde confiança. Alternativa: mover para Configurações/Histórico avançado com migração explicada inline.

🟡 Oportunidade competitiva: "Nível da comissão" é tradução ruim de "fee tier". Em PT-BR, "comissão" sugere algo que você paga (corretora, vendedor). Aqui o usuário recebe quando a ordem executa — significado invertido. Uniswap V3 e 1inch criam confusão parecida com seus próprios termos. Critério: afeta iniciante; razão de ninguém ter resolvido é falta de investimento em copy; ganho perceptível. Alternativa: "Recompensa do maker" ou "Quanto você ganha por ordem". Trade-off: diverge do padrão da indústria — mas o padrão está errado para o target.

Consolidado — Ordem Limite (PancakeSwap)

Caráter geral do fluxo

O fluxo tem esqueleto sólido: tabs Swap/TWAP/Limite num único header reconhecem três paradigmas do mesmo gesto sem forçar navegação, presets ancorados ao mercado ensinam que a ordem vive em torno de algo, e a PancakeSwap investe visivelmente em pedagogia inline — tooltip no ponto técnico mais opaco (#1) e chip dinâmico que ensina o trade-off sem abrir documentação (#3). O atrito se concentra em dois eixos estruturais: (1) opacidade semântica — a frase de gatilho não comunica direção, os presets não indicam favorabilidade por papel, e os chips ensinam trade-off de forma qualitativa sem quantificar, deixando o iniciante a decidir por vibe; (2) CTA disabled silencioso, presente desde a primeira tela #1 até o estado de formulário #2, que transforma um dead-end clicável em sinal de bloqueio sem saída. O link "Obsoleto" adiciona ruído de confiança em dois estados do mesmo formulário. O perfil mais afetado é o iniciante — para quem vem de CEX, "Nível da comissão" soa como custo (não receita), "Vender quando 1 BNB valer" é gramaticalmente ambíguo, e o botão cinza não explica o próximo passo.

🟢 Insights recorrentes

Pedagogia embutida no ponto de decisão — telas 1, 3

Em vez de relegar educação a uma página de docs, o fluxo investe em educação contextual exatamente onde a carga cognitiva é maior. Em #1, o tooltip aparece no termo mais opaco do fluxo inteiro — "Nível da comissão" — posicionado antes do CTA, no momento em que o usuário ainda está construindo seu mental model. Em #3, a mesma filosofia ganha uma segunda expressão: o chip não só destaca o tier selecionado — ele muda de rótulo e ícone conforme a escolha ("🔥 Best Returns" ↔ "⚡ Faster Execution"), transformando a alternância em um micro-tutorial de trade-off. É um padrão raro na indústria — a maioria exibe tiers como números frios e deixa a interpretação para o usuário. Padrão a herdar no Kotai: toda escolha que envolve trade-off (tier, slippage, expiration) merece feedback qualitativo dinâmico, não só label estático.

🔴 Fricções recorrentes

Estrutural — Opacidade semântica do gatilho de preço e dos tiers — telas 2, 3

O problema raiz é o mesmo nas duas telas: o produto apresenta parâmetros técnicos sem traduzir para o resultado esperado pelo usuário.

Em #2, a frase "Vender quando 1 BNB valer: CAKE 414,55…" não comunica direção: o iniciante precisa de duas leituras para entender se a ordem dispara "se BNB subir" ou "se BNB cair". Não há sinal (≥ / ≤), não há delta vs preço atual, não há atualização dinâmica ao vivo. Na mesma tela, os presets "+1%/+5%/+10%" não indicam favorabilidade por papel: para quem vende BNB, "+1%" é melhor que mercado; para quem compra BNB, "+1%" é pior. O sinal deveria se adaptar automaticamente conforme o lado da operação — o Uniswap já implementa isso (presets viram negativos ao inverter o par).

Em #3, o chip qualitativo é a única âncora de decisão entre os tiers, mas sem dado quantitativo o iniciante não sabe quanto mais rápido executa em 0,01% nem quanto rende mais em 0,1%. A decisão vira escolha por vibe ("fogo parece mais agressivo que raio"). O bloco de gatilho — "Vender quando 1 BNB valer: CAKE 414,73…" — também está presente em #3 com a mesma ambiguidade direcional de #2.

Por que a solução óbvia falha: adicionar tooltips a cada parâmetro fragmenta a carga entre múltiplos pontos; traduzir os rótulos literalmente sem repensar o mental model só troca a opacidade de lugar.

Direcionamento Kotai:

• Frase de gatilho orientada à ação com delta inline: "Executar quando 1 BNB ≥ 414,5 CAKE · BNB precisa subir 0,0% vs mercado" — atualiza ao vivo conforme o usuário ajusta.
• Presets com label adaptativo por papel: "Vender 1% acima do mercado" / "Comprar 1% abaixo do mercado" conforme a direção do par.
• Chips com micro-caption de dado real: "Faster Execution — preenchimento típico ~Xh · Best Returns — ~Yh, +Z% retorno estimado" (com disclaimer "estimativa" se não houver histórico suficiente por par).

Trade-off: frase dinâmica e chips com dados exigem cálculo em tempo real (delta vs market, histórico de execução por par); sem dados, defaults qualitativos com disclaimer são aceitáveis como versão inicial.

Perfil mais afetado: iniciante.

Estrutural — Link "Obsoleto" na superfície da feature ativa — telas 1, 2

"Gerenciar Ordens Limite antigas (Obsoleto) »" está exposto no rodapé do formulário de criação em #1 e mantido em #2. Para o iniciante, o termo "Obsoleto" gera dúvida imediata: "minha nova ordem vai parar nesse sistema antigo?". Para o intermediário, é ruído persistente — ele já sabe que não precisa daquilo, mas o link não desaparece. Além de poluir a hierarquia visual em dois estados distintos, deteriora confiança num momento em que o usuário ainda está avaliando se vai criar a ordem.

Por que a solução óbvia falha: ocultar completamente abandona usuários com ordens legadas que precisam de gestão. Banner genérico de migração no topo poluiria ainda mais a UI.

Alternativa: mover para Configurações > Histórico > Ordens antigas (link de baixa visibilidade, com migração explicada ali). No formulário, substituir por nota colapsável: "Se você tem ordens criadas no sistema anterior, [acesse aqui]." Aparece uma vez; pode ser fechada.

Trade-off: usuários com ordens legadas precisam de um passo a mais para chegar ao link. Benefício: elimina ruído e ambiguidade de confiança nos dois estados de formulário ativos.

Perfil mais afetado: iniciante.

🟡 Oportunidades competitivas do fluxo

CTA disabled opaco sem comunicar o gap — telas 1, 2

Padrão atual da indústria: Uniswap, PancakeSwap, 1inch, CoW Swap — todos exibem CTA desabilitado sem indicar o que falta. O botão fica cinza e silencioso.

Por que afeta nosso target: em #1 (carteira não conectada) e #2 (formulário vazio), "Criar Ordem Limite" disabled não comunica nem o bloqueio atual nem o próximo gesto. Iniciante tende a clicar antes de ler; o clique nulo sem feedback transforma o botão em dead-end. Em vez de guiar, o CTA silencia.

Hipótese de diferenciação Kotai: rótulo dinâmico que reflete o gap atual — "Conectar carteira" → "Inserir valor a vender" → "Definir preço-alvo" → "Criar Ordem Limite". O CTA comunica o próximo passo em cada estado, sem que o usuário precise inferir o que está faltando. A Uniswap implementa variação parcial desse padrão (CTA muda de "Conectar carteira" para "Confirmar") — o Kotai pode ir além com especificidade no gap.

Trade-off: aumenta a quantidade de strings de UI e estados do componente; exige sincronização do rótulo com cada combinação de validação.

Passa nas 4 perguntas-teste?

1. ✓ Todos os concorrentes principais têm CTA disabled silencioso.
2. ✓ Afeta iniciante diretamente (dead-end sem saída visível).
3. ✓ Razão de ninguém ter resolvido completamente é falta de investimento em design de estados do componente.
4. ✓ Usuário perceberia imediatamente a diferença entre botão cinza mudo e botão cinza que diz "Inserir valor a vender".

"Nível da comissão" — semântica invertida do vocabulário de maker fee — telas 1, 2, 3

Padrão atual da indústria: toda a indústria usa vocabulário técnico opaco para descrever fee tiers de maker (Uniswap: "fee tier"; 1inch: terminologia análoga). Em PT-BR, o PancakeSwap traduz como "Nível da comissão" — o que vai além da opacidade: em português, "comissão" denota custo pago (corretora, vendedor), mas aqui o usuário recebe quando a ordem executa. A label persiste em #1, #2 e #3.

Por que afeta nosso target: iniciante BR lê "Nível da comissão" e assume que está escolhendo quanto vai pagar; o significado real é quanto vai ganhar. A confusão pode levar a escolha de tier com base na premissa errada (escolher menor "comissão" = pagar menos, quando na verdade significa receber menos por ordem).

Hipótese de diferenciação Kotai: "Recompensa do maker" ou "Quanto você ganha por ordem executada" — orienta para receita, não custo. O tooltip de suporte continua explicando o trade-off velocidade/retorno.

Trade-off: diverge do padrão da indústria (pode criar estranhamento para usuários que já conhecem outros DEXes); porém o padrão atual está semanticamente errado para PT-BR, e a divergência é em favor do usuário.

Passa nas 4 perguntas-teste?

1. ✓ Todos os concorrentes usam vocabulário de fee tier opaco (a inversão semântica PT-BR é específica da Pancake, mas a opacidade do conceito é indústria-ampla).
2. ✓ Afeta iniciante e intermediário BR diretamente (decisão de tier baseada em premissa errada).
3. ✓ Razão de ninguém ter resolvido é falta de investimento em copy localizado — não impossibilidade técnica.
4. ✓ Usuário perceberia "Recompensa do maker" como algo diferente de "Nível da comissão" — e correto.

Simulação quantitativa do trade-off de tier — telas 2, 3

Padrão atual da indústria: Uniswap V3 exibe tiers como números frios (0,01%/0,05%/0,30%/1,00%) sem contexto de velocidade ou retorno. PancakeSwap avança com chips qualitativos ("🔥 Best Returns" / "⚡ Faster Execution") mas para na camada qualitativa. O componente de seleção de tier está presente em #2 (estado default, 0,1% selecionado) e em #3 (interação explícita com troca de tier).

Por que afeta nosso target: em ambas as telas, o iniciante não tem referência para saber o quanto mais rápido executa em 0,01% ou o quanto mais retorna em 0,1%. Em #3 especificamente, a decisão é opaca mesmo depois de o usuário interagir com o seletor. O Pancake já deu o primeiro passo certo com labels qualitativos; o passo seguinte é quantificar.

Hipótese de diferenciação Kotai: micro-caption embaixo do chip com estimativa por par e janela de tempo — "Faster Execution — ordens preenchidas em ~2h (últimos 7 dias) · Best Returns — ~18h, +0,09% retorno estimado por ordem". Com dados insuficientes: "Estimativa indisponível para este par" em vez de silêncio. A informação transforma o chip de rótulo de marketing em ferramenta de decisão. Rollout incremental: lançar com qualitativo e adicionar quantitativo quando a telemetria for suficiente.

Trade-off: exige indexação histórica de execução de ordens on-chain por par e cálculo de range de volatilidade. Sem dados, manter qualitativo e marcar a ausência explicitamente — não simular dados.

Passa nas 4 perguntas-teste?

1. ✓ Todos os concorrentes param no qualitativo (Pancake) ou mostram números frios sem contexto (Uniswap).
2. ✓ Afeta iniciante e intermediário (decisão de tier sem referência de magnitude).
3. ✓ Razão de ninguém ter ido além é falta de investimento em telemetria e design — não impossibilidade técnica.
4. ✓ Usuário perceberia "~2h vs ~18h" onde antes via só "⚡ vs 🔥".

Pontos isolados (1 tela)

• 🟢 Tela 2: Switch Swap/TWAP/Limite no mesmo header — três paradigmas de troca num único espaço, sem sair da tela. Padrão a avaliar para o Kotai se TWAP for relevante pro target.
• 🟢 Tela 2: Presets +1%/+5%/+10% ancorados ao mercado — ensinam que a ordem limite vive em torno de algo, não no vácuo. Boa âncora pedagógica para iniciante.
• 🔴 Tela 1 (estrutural — afeta 100% do target BR): tooltip em inglês no ponto técnico mais crítico do fluxo. Justamente o microcopy mais necessário é o que falha na localização. Correção obrigatória sem trade-off.
• 🔴 Tela 3 (cosmética): apenas 2 tiers disponíveis sem indicar que são todos. Usuário familiar com V3 (4 tiers padrão) procura mais opções e fica em dúvida. Caption "2 níveis disponíveis para este par" fecha a ambiguidade.

Comparação rápida com Uniswap

(Referência: Consolidado Uniswap — Ordem Limite)

Pancake superior:

• Chips qualitativos de tier (🔥/⚡) ensinam trade-off inline; Uniswap V3 mostra 4 tiers como números frios sem contexto.
• Apenas 2 tiers no modelo maker/PMM reduz a carga de decisão vs os 4 tiers do Uniswap V3.

Uniswap superior:

• CTA progressivo com rótulo contextual ("Conectar carteira" → "Confirmar") — PancakeSwap mantém CTA disabled silencioso em todo o formulário.
• Presets de variação de preço adaptam o sinal pela direção do par (−% ao inverter) — PancakeSwap mostra sempre +% independente do papel do usuário.
• Modal de revisão consolidando todos os parâmetros antes da assinatura — não identificado nas 3 telas do PancakeSwap analisadas.

Ambos com gap:

• CTA disabled não comunica o gap específico (🟡 Oportunidade 1 acima).
• Trade-off de tier apresentado sem dado quantitativo (🟡 Oportunidade 3 acima).
• Disclaimer estático sobre não-execução sem estimativa probabilística — oportunidade identificada também no Consolidado Uniswap.

Consolidado — Comprar (PancakeSwap)

Caráter geral do fluxo

O fluxo Comprar da PancakeSwap é um agregador de on-ramps fiat→cripto com widget dedicado — e essa é a sua principal vantagem estrutural sobre a Uniswap, que embute o mesmo fluxo no container visual do swap. O produto tenta transparência de fees, agrega provedores com critério correto (output em cripto, não taxa isolada) e posiciona disclosures antes do CTA. O problema é que essa transparência para no meio do caminho: fee breakdown em 2 camadas quando há 4 componentes, nomenclatura que mescla exchange com rede em dois momentos distintos, e tooltip de disclaimer que só funciona em desktop. O resultado é um fluxo que convence o intermediário e tropeça no iniciante CEX — que é o usuário mais provável de precisar de on-ramp, por ainda não ter cripto. O perfil mais afetado é o iniciante BR/LatAm vindo de exchange centralizada, que enfrenta rótulo de rede lido como nome de exchange, ETH repetido 5 vezes sem orientação, e disclosure de variação de taxa que não chega até ele no celular.

🟢 Insights recorrentes

Transparência proativa antes do CTA — telas 1, 4, 5, 6

O fluxo tem um padrão consistente de mostrar informação antes de comprometer dinheiro. Na tela de entrada, o fee total está exposto antes do botão de compra em #1, sem necessidade de interação extra. Na comparação de provedores em #4, o output em cripto — e não a taxa — é a unidade central: decisão correta porque iniciante quer saber "quanto vou receber", não "qual é a porcentagem". O breakdown "Provider Fees / Pancake Fees" em #5 é raro: a maioria dos DeFi on-ramps esconde a taxa da plataforma no spread sem nomear. O disclosure tooltip em #6 posiciona o aviso de estimativa acima do CTA — o usuário é avisado antes de clicar, não depois do susto no checkout. Esses quatro momentos compartilham o princípio de reduzir surpresa financeira para o iniciante; padrão a herdar e expandir.

Agregação como decisão de produto — telas 1, 4

O produto toma decisões pelo usuário em dois pontos críticos: pré-seleciona o provedor "Melhor cotação" automaticamente em #1 e mantém esse critério explícito no comparativo de #4. Iniciante não precisa pesquisar Mercuryo vs Topper — o ranking automatiza. A opção de trocar existe, mas não é o caminho default. Para usuário vindo de CEX onde a exchange já fazia essa escolha por ele, é o comportamento esperado.

🔴 Fricções recorrentes

Estrutural — Confusão exchange/rede em dois pontos do fluxo — telas 1, 3

O atrito mais sério do fluxo é um erro de naming que se replica em dois momentos distintos. Em #1, o output exibe "CAKE em binance" — "em binance" é abreviação interna para BNB Smart Chain, mas iniciante vindo de CEX lê "será creditado na minha conta Binance Exchange". A confusão exchange/blockchain é exatamente onde iniciante mais erra, e o label do produto alimenta o erro no momento de maior tensão. Em #3, ETH aparece 5+ vezes diferenciado apenas por label de rede minúsculo ("Ethereum", "Arbitrum One", "ZKsync Era", "Linea", "Base"). Quem quer "comprar ETH" escolhe o que aparece primeiro — que pode ser a rede errada para como pretende usar o token, gerando bridge desnecessário depois.

Os dois problemas têm causa diferente mas consequência igual: o usuário toma decisão errada com confiança, sem sinal de alerta. A solução óbvia (renomear "em binance" para "na BSC") resolve o display mas não o modelo mental — iniciante ainda não sabe o que "BSC" significa. Alternativa: espelhar o chip "BNB Chain" que já existe no próprio widget, criando consistência interna de nomenclatura em #1 ("CAKE • BNB Chain"); em #3, separar "qual token" de "em qual rede" em dois passos sequenciais (ver 🟡 Oportunidade). Trade-off: separar o seletor em duas etapas aumenta cliques; ganha orientação concreta para o iniciante.

Perfil afetado: iniciante CEX, especialmente BR/LatAm.

Estrutural — Transparência de taxas incompleta ao longo do fluxo — telas 1, 4, 5, 6

A transparência existe, mas para onde é mais necessária. Em #1, "Taxas totais est. US$ 4,95" é número único sem decomposição padrão — o usuário não sabe o que compõe aquele valor. Em #4, a comparação de provedores mostra output em cripto mas não fee por provedor — o usuário não sabe se Topper cobra 4% a mais pelo mesmo método, ou se tem vantagem em outra dimensão. Em #5, o breakdown expandido mostra apenas 2 linhas (Provider Fees + Pancake Fees), omitindo network fee (gas BNB Chain) e spread cambial que provavelmente estão embutidos no preço cotado pelo provedor. Em #6, o disclaimer "variar ligeiramente" não quantifica a variação — iniciante que vê US$ 4,95 e paga US$ 7,20 no checkout sente bait-and-switch.

A solução óbvia (mostrar breakdown completo na tela principal por padrão) cria risco de abandono por "parecer caro". Alternativa: fee total resumida sempre visível + expansão em 4 camadas (Provedor • PancakeSwap • Gas • Câmbio) com linha "preço de mercado X • você paga Y • diferença Z", acessível sob tap. O disclaimer de #6 ganha faixa explícita ("pode variar até ~X%") se o produto tiver dados históricos de variação. Trade-off: exige integração mais profunda com dados de spread em tempo real por provider.

Perfil afetado: iniciante e intermediário.

Cosmética — Inconsistência de copy e i18n — telas 2, 5

Em #2, o header "selecionar uma moeda" usa a mesma cor ciano e peso visual dos CTAs e links ativos do produto — o usuário tenta clicar esperando ação. Em #5, os labels "Provider Fees" e "Pancake Fees" estão em inglês num produto traduzido para PT-BR; e o toggle "Detalhes ocultos" é tradução literal de "Hide details" que resulta em leitura ambígua em PT-BR ("existem detalhes que estão ocultos" vs "ocultar detalhes"). São bugs de localização e design system sem impacto em decisão financeira, mas que compõem percepção de produto inacabado — sensação que corrói confiança justamente no fluxo de primeira compra.

Correção direta: "selecionar uma moeda" → CAPS pequeno em cinza neutro, sem interatividade visual; "Provider Fees" → "Taxa do provedor"; "Pancake Fees" → "Taxa da PancakeSwap"; "Detalhes ocultos" → "Ocultar detalhes". Perfil afetado: iniciante (percepção de trustworthiness).

🟡 Oportunidades competitivas do fluxo

Breakdown real de taxas com contexto de mercado — telas 1, 4, 5, 6

Padrão atual da indústria: Uniswap, PancakeSwap, MetaMask Portfolio e 1inch fiat apresentam taxa on-ramp como número único ou breakdown parcial de 2 camadas. Nenhum expõe spread cambial, network fee, margem do provedor e comparativo com preço spot num mesmo lugar acessível. O comparison de providers não inclui fee lado a lado — em #4 o usuário vê output em cripto, mas não o custo de chegar àquele output.

Por que afeta nosso target: iniciante que paga fiat não tem referência do que é "justo" — só sente "parece caro" ou descobre a diferença no checkout do provider e interpreta como bait-and-switch. Intermediário quer saber onde seu dinheiro foi antes de repetir a operação.

Hipótese de diferenciação Kotai: breakdown em 4 camadas (Provedor • Plataforma • Gas • Câmbio) com linha "preço de mercado → você paga → diferença %", visível sob tap sem abrir modal separado. Comparação direta de fee entre providers na tela de seleção ("Mercuryo: taxa US$ 3,86 • Topper: taxa US$ 5,20 pelo mesmo método").

Trade-off: exposição de fee real pode elevar abandono por transparência; relação comercial com providers que preferem opacidade de custo; exige integração de dado de spread em tempo real.

Passa nas 4 perguntas-teste? (1) ✓ Todos os concorrentes principais fazem igual — fee agrupada ou parcial. (2) ✓ Afeta iniciante diretamente — on-ramp é o primeiro contato com fiat→cripto. (3) ✓ Razão de ninguém ter resolvido: relação comercial com providers + falta de investimento em integração granular, não impossibilidade técnica. (4) ✓ "Você vai gastar US$ X de câmbio e US$ Y de gas além da taxa" é perceptível e diferencia da experiência atual.

Rede como decisão de primeira classe na compra de token — tela 3

Padrão atual da indústria: PancakeSwap, Uniswap, Jupiter e 1inch listam o mesmo token em múltiplas redes como entradas planas na mesma lista, diferenciadas apenas por badge de rede minúsculo no ícone em #3. O modelo implícito pressupõe que o usuário sabe o que é "rede" e qual escolher.

Por que afeta nosso target: "token na rede errada" é a causa #1 de "perdi minha cripto" em suporte de DeFi. Iniciante que compra ETH na ZKsync Era por ser o primeiro da lista, mas usa MetaMask configurada para Arbitrum, não consegue usar o token sem entender bridge — que está fora do produto e fora do modelo mental dele.

Hipótese de diferenciação Kotai: separar "qual token" de "em qual rede" em dois passos sequenciais. Após escolher ETH, exibir seleção de rede com recomendação contextual ("Recomendado: Ethereum — compatível com mais carteiras" ou "você opera em BNB Chain — comprar ETH mainnet pode exigir bridge depois"). Para intermediário/avançado: campo de busca direta ("ETH Base") mantém velocidade.

Trade-off: 2 passos em vez de 1 aumenta cliques; contraria convenção visual atual; exige curadoria de qual rede recomendar por contexto e histórico de uso do usuário.

Passa nas 4 perguntas-teste? (1) ✓ Todos os concorrentes fazem igual — lista plana com badge sutil. (2) ✓ Afeta iniciante diretamente — causa erro de rede com consequência irrecuperável sem suporte externo. (3) ✓ Razão de ninguém ter resolvido: assumir conhecimento prévio + falta de investimento em fluxo de 2 passos. (4) ✓ "Qual rede você vai usar esse token?" é pergunta que muda o output — diferença concreta e imediata.

Microcopy educativo: ensinar o mecanismo, não só cobrir liability — telas 3, 4, 6

Padrão atual da indústria: tooltips e labels de estado desabilitado em toda a indústria DeFi servem exclusivamente para cobertura jurídica ("estimativa pode variar") ou UX mínima ("item indisponível"), nunca para ensinar o mecanismo ao usuário.

Por que afeta nosso target: iniciante que vê BTC desabilitado em #3 sai pensando "PancakeSwap não tem BTC". Iniciante que vê Topper em #4 sem contexto pensa "deve ser pior em tudo — por que existe?". Iniciante que lê "variar ligeiramente" em #6 não sabe o que esperar no checkout — e quando o valor muda, sente fraude. Em todos os três, 1-2 linhas de copy educativo resolveriam o modelo mental sem custo de UI.

Hipótese de diferenciação Kotai: BTC desabilitado → "BTC nativo indisponível via on-ramp — comprar WBTC?" com atalho direto. Topper sem contexto → "Topper aceita Apple Pay e SEPA — útil se Mercuryo não aceitar seu método". Disclaimer de estimativa → "o preço oscila enquanto o provedor processa — valor final é fixado no momento do pagamento".

Trade-off: mais copy exige UX writer com foco em iniciante e manutenção por provider (métodos aceitos mudam); usar 1 linha visível + "saiba mais" expandido sob demanda para não poluir o widget.

Passa nas 4 perguntas-teste? (1) ✓ Toda a indústria DeFi usa microcopy só para liability ou UX mínima. (2) ✓ Afeta diretamente iniciante — é quem precisa de explicação de mecanismo, não de confirmação técnica. (3) ✓ Razão de ninguém ter resolvido: copywriting educativo em DeFi não é prioridade; falta de ownership de UX writer focado em iniciante. (4) ✓ "BTC nativo indisponível — comprar WBTC?" vs "?" minúsculo é diferença perceptível e imediata para iniciante que busca BTC.

Geo-contextualized ordering no seletor de fiat — tela 2

Padrão atual da indústria: PancakeSwap, Uniswap on-ramp e 1inch fiat apresentam lista única global de moedas sem personalização por localização detectada. BRL aparece nos primeiros 7 itens da Pancake em #2 — provavelmente por popularidade global, não por geo-detection — mas a posição depende do provedor ativo e pode mudar sem aviso. Não há garantia de topo para usuário BR/LatAm.

Por que afeta nosso target: iniciante BR/LatAm que abre o seletor e não vê BRL imediatamente precisa buscar ou rolar — atrito desnecessário na primeira interação do fluxo, antes mesmo de digitar o valor. Menor leverage que fee e rede, mas correção de baixo custo.

Hipótese de diferenciação Kotai: seção "Sugerida para você" no topo com 1-2 moedas por geo-IP, seguida da lista global completa. Nunca ocultar opções — apenas reordenar. Fallback manual se geo falhar.

Trade-off: geo por IP falha em VPN e viagem — mitigar com possibilidade de ajuste manual persistente; não usar geo para bloquear acesso a moedas. Menor leverage que as oportunidades de fee e rede — é redução de atrito, não eliminação de erro.

Passa nas 4 perguntas-teste? (1) ✓ Todos os concorrentes fazem lista global sem geo-ordering para seletor de moeda fiat. (2) ✓ Afeta iniciante BR/LatAm — usuário que mais usa on-ramp por ainda não ter cripto. (3) ✓ Razão de ninguém ter resolvido: falta de investimento em geo-detection no front, não impossibilidade técnica. (4) ✓ "BRL já no topo quando abrir" vs "posição instável dependente de provedor" é diferença imediatamente perceptível.

Pontos isolados (1 tela)

• 🔴 Tela 6: tooltip hover-only em produto mobile-first (estrutural, 1 tela) — o "?" que aciona o disclaimer depende de hover, comportamento ausente em mobile. Correção: converter para chip clicável ("Taxa est. US$ 4,95 ⓘ") com tap abrindo bottom sheet de 3 linhas.
• 🔴 Tela 2: backdrop "purple haze" sem dim escurecedor + ausência de botão fechar explícito — usuário com baixa visão pode não perceber que está num submodal. Correção: backdrop escuro padrão + X explícito ou swipe-to-dismiss com affordance visível.
• 🔴 Tela 4: Topper aparece sem fee exibida por provedor — usuário não consegue avaliar custo real da segunda opção sem fechar o modal e abrir "Detalhes". Correção: mostrar fee total ao lado do output ("≈ 91,182 CAKE • taxa US$ X") diretamente no card do provedor.
• 🟢 Tela 3: oferecer dois mental models no seletor de token — "Todos os tokens" (lista plana) e "Selecione tokens por rede" (link agrupado) — reconhece que multi-chain é confuso sem forçar hierarquia sobre o usuário.

Comparação rápida com Uniswap

PancakeSwap leva vantagem em widget dedicado (evita o "molde visual de swap aplicado a mecânica que não é swap" que é a fricção estrutural central da Uniswap) e em transparência parcial de fees — o breakdown "provedor / plataforma" em #5 não existe no fluxo equivalente da Uniswap. A comparação de provedores por output em cripto é mais clara do que a abordagem da Uniswap.

Uniswap leva vantagem no card educativo "Iniciar com ETH" — sem equivalente na Pancake — que antecipa o erro clássico de comprar stablecoin sem reserva de gas. Ambos compartilham a ausência de estado pós-handoff, mas o fluxo Pancake analisado não chega até o handoff final (a análise cobre até a seleção de provedor, não o checkout externo).

As 🟡 Oportunidades de "rede como decisão de primeira classe" e "breakdown real de taxas" são compartilhadas pelos dois produtos — confirmação de que são convenções problemáticas da indústria, não falhas isoladas.

Referência: Consolidado Comprar — Uniswap

4. Pools — Tooltip do APR com split (hover em APR de pool V3)

Função: Tooltip do valor APR ao hover sobre a célula da coluna "APR" em uma linha de pool V3 com farm ativa (USDT/BTCB, 21,84%). Decompõe o número combinado em duas fontes (farm + taxa de LP) e explica as ressalvas do cálculo.

Componentes: célula APR em hover (com ícones de boost + farm); tooltip dark grande com título "APR combinada: 21,84%", bullets "APR da farm: 1,21%" e "APR da taxa de LP: 20,63%", dois parágrafos de copy explicando que o cálculo usa liquidez total do pool e que APRs individuais podem variar conforme range definido em V3.

Regras de negócio: APR é métrica composta — farm (emissão de CAKE) + taxa de LP (fee real do swap); apenas pools elegíveis a farm têm o componente farm; em V3, APR exibido na tabela usa toda a liquidez do pool, mas o LP individual ganha APR proporcional ao tempo que esteve in-range; o tooltip é a única superfície na lista que explica essa ressalva crítica.

🟢 Insight: decompor o APR em farm vs. taxa de LP é honestidade que mata mal-entendido grave — o iniciante que vê 21,84% precisa saber que 20,63% vêm de swap fee (sujeito a volume) e 1,21% de emissão (sujeito a tokenomics). Reconhecer e comunicar a ressalva de V3 ("liquidez fora do range não ganha") no mesmo tooltip evita que o usuário leia o número como garantia.

🔴 Fricção 1 (estrutural — afeta iniciante; recorrência do problema da tela 2): a ressalva mais importante do tooltip — "APR real depende do range" — está no terceiro parágrafo, em corpo pequeno, depois do split e da explicação genérica. O iniciante que decide pelo número grande no topo (21,84%) já saiu antes de chegar ao texto que muda tudo. Fix óbvio (negritar a ressalva) ajuda mas não resolve hierarquia. Fix verdadeiro: inverter a ordem — ressalva primeiro como aviso visual (badge amarelo "APR efetiva varia conforme seu range"), split técnico depois. Trade-off: agressivo demais pode reduzir conversão para LP em V3, e o produto pode estar legitimamente otimizando pra TVL em vez de pra educação.

🔴 Fricção 2 (cosmética — afeta todo perfil): o tooltip aparece em hover e é grande o bastante para cobrir 3 linhas da tabela, mas o conteúdo é leitura densa — o usuário não consegue mover o cursor pra ler com calma sem perder o tooltip. Fix: variante "click-to-pin" ou popover persistente acionado por clique no número, mantendo hover só pra preview rápido.

🟡 Oportunidade competitiva (alta leverage no target): APR como número único sem decomposição é convenção em Uniswap, Curve, Sushi — ou exibem APR cru, ou separam farm vs. fee mas sem explicar a ressalva de range. Passa nas 4 perguntas: ✓ todos os concorrentes; ✓ afeta iniciante diretamente (entra esperando 21,84% e ganha 8% porque saiu de range); ✓ ninguém resolveu por falta de investimento em projeção honesta, não por impossibilidade; ✓ perceptível ("o produto me disse antes que meu APR ia depender de eu gerenciar o range" vs. "ganhei muito menos do que prometido"). Diferenciação Kotai: na linha do pool, mostrar APR esperado dado um range default (full-range para iniciante) com asterisco "APR cai X% se preço sair do range"; tooltip vira projeção, não retórica.

Observação adicional: ícones verdes de "boost" e "farm" ao lado do número APR não são explicados no tooltip — quem nunca viu Pancake antes não sabe que aquela folha verde indica boost via veCAKE/bCAKE. Outro problema sistêmico: iconografia proprietária sem legenda em ponto de decisão.

14. Pools — Tab "Todos os pools" carregada (catálogo extenso, linhas com APR loading parcial)

Função: Catálogo completo carregado, com ~25 linhas visíveis ordenadas por (provavelmente) APR ou TVL combinados, exibindo pares em múltiplas combinações de versão (V3 vários fees, V2, StableSwap "SS"). Estado mostra que algumas linhas ainda têm APR em loading (placeholder cinza nas últimas linhas da viewport) — render progressivo.

Componentes: mesmo header e filtros das telas 1/2; card "Escolhas Pancake #3 — cbETH/WETH (APR 7,62%, TVL 551,77K)"; tabela com 25+ linhas: USDT/WBNB (V3 0,01% — APR 26,48% c/ farm), USDT/BTCB, B/USD1, USDC/WBNB, BTCB/WBNB, ETH/WBNB, USDT/USDC (0,32%), USDT/DUSD (0,27%), lisUSD/USDT (SS — tipo "stable"), mubarak/WBNB, USDC, CAKE, BabyDoge (V2 0,25%), ETH/BTCB, USDT/USD1, TST/WBNB (V3 1% — APR loading), WBNB/FHE, ETH/WBNB, BTCB/WBNB (linhas finais com APR placeholder); coluna "Característica do pool" 100% "–"; kebab por linha.

Regras de negócio: APR pode estar atrasado pra alguns pares (cálculo dependente de fee gerada em 24h + emissão de farm); ícones na coluna APR variam (folha verde = boost, calculadora = derivado, frutinha = featured); "stable" como tag única em lisUSD/USDT (StableSwap); ordenação default não óbvia — não é por APR (USDT/USDC com 0,32% aparece acima de mubarak 43,13%), nem por TVL puro, nem por volume — sugere algoritmo proprietário "Quente" também aqui.

🟢 Insight: render progressivo (linhas aparecem populadas, com APR completando depois) é melhor que bloquear a tabela toda até o último APR — usuário começa a explorar e decidir. Manter o spinner por célula (não por tabela) é evolução em relação à tela 13. Reconhecer que diferentes métricas têm tempos de resolução distintos e desacoplar é correto.

🔴 Fricção 1 (estrutural — afeta iniciante; problema crítico de ordenação): a tabela está ordenada por critério não nomeado em lugar nenhum visível — não há indicador "Ordenado por: X". As setas no header (APR, TVL, Volume 24h) sugerem possibilidade de sort manual, mas o estado inicial não diz o que está aplicado. Iniciante que olha a primeira linha (USDT/WBNB 26,48%) pode interpretar como "a melhor pool" sem perceber que é critério opaco. Fix óbvio (mostrar coluna de sort ativa com seta destacada) é mínimo. Fix verdadeiro: nomear explicitamente o sort default acima da tabela ("Ordenado por: Recomendadas — TVL alta + APR competitiva + idade do contrato") com link "Mudar". Trade-off: ocupa espaço; expõe a metodologia (positivo se for sólida, fragilidade se for ad-hoc).

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário; reforço da fricção 2 do relatório 2): "Característica do pool" continua 100% vazia em 25 linhas — coluna inerte ocupando largura útil. Mesmo diagnóstico, agora com mais evidência: em 25 linhas variadas (V2, V3 múltiplos fees, StableSwap), zero têm valor. Fix: ocultar coluna até primeira ocorrência de valor; reaparecer dinamicamente. Trabalho trivial; ganho perceptível em densidade de informação útil.

🔴 Fricção 3 (estrutural — afeta iniciante; reforço da fricção 1 da tela 2): "Tipo de pool" continua código técnico (V3, V2, stable, CLAMM) sem tradução por consequência. Agora com 25 linhas reais, vê-se que stable aparece em apenas 1 (lisUSD/USDT) — informação rara que merecia destaque visual para iniciante interessado em baixo risco, mas é apenas mais uma tag entre outras V3. Fix: hierarquia visual diferente para "Stable" (badge verde) vs. tags técnicas neutras.

🟡 Oportunidade competitiva (alta leverage no target; reforço do relatório 2): mesma oportunidade do relatório 2 (scoring de risco + filtros de intent). Nesta tela com 25+ pools reais, fica mais clara — usuário-alvo precisa filtrar "stable-stable" como intent, não como tag opaca; ordenação default precisa ser declarada. Diferenciação Kotai: barra "Para você" acima da tabela com sugestões de pool por perfil (conservador → stable; moderado → blue-chip; agressivo → alta APR), separada do catálogo cru abaixo. Trade-off: precisa de input mínimo do usuário (perfil) que o iniciante pode não querer dar — fallback default "moderado" resolve.

Observação adicional: APR "loading parcial" em ~3 linhas finais (TST/WBNB, WBNB/FHE, ETH/WBNB, BTCB/WBNB) sugere que essas pools dependem de dados mais lentos (talvez pools recém-criadas ou em rede secundária). Mostrar placeholder cinza em vez de "–" é correto — distingue "ainda calculando" de "sem dado". Detalhe bem feito que vale reconhecer.

13. Pools — Tab "Todos os pools" em estado de carregamento (loading)

Função: Volta para Farm/Liquidez → "Todos os pools" → estado intermediário antes da tabela carregar. Header da tabela visível (Pares, Nível da comissão, APR, TVL, Volume 24h, Tipo de pool, Característica do pool) com spinner central e área de linhas vazia.

Componentes: tabs "Todos os pools" (ativa) / "Minhas posições"; CTAs "Criar Pool" + "Adicionar liquidez +"; filtro de rede All networks +6, search, segmento Tudo/Infinity/V3/V2/StableSwap (Tudo ativo); header da tabela com setas de ordenação em APR/TVL/Volume 24h; corpo vazio com spinner circular cinza centralizado; sem placeholder skeleton row, sem texto de status.

Regras de negócio: ao trocar de tab ("Minhas posições" → "Todos os pools") ou ao aplicar filtro novo, a lista é refetched e renderizada apenas após resposta; o header da tabela permanece estável durante o carregamento (não some); spinner é único elemento de feedback — sem mensagem "Carregando…" nem skeleton.

🟢 Insight: preservar o header da tabela durante loading é decisão acertada — usuário não perde referência visual nem sente que mudou de tela. Mostrar setas de ordenação ativas mesmo sem dados sugere que o estado de ordenação persiste através de fetches, o que é correto para uma tabela que paga vários requests.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): spinner único no centro de área grande sem skeleton row é regressão pra um produto que usa skeleton em outras telas. O usuário não sabe quantas linhas vão aparecer, qual a altura esperada, se a página vai pular. Fix óbvio (substituir por skeleton com 8-10 linhas placeholder) é convenção válida e já está em outras superfícies do mesmo produto — inconsistência interna, não inovação necessária. Trade-off: nenhum; é fix mecânico de paridade.

🔴 Fricção 2 (estrutural — afeta iniciante; reforço do problema do relatório 1): o spinner é indistinguível de "carregando dados" vs. "buscando posições da carteira" vs. "esperando filtro aplicar". Em "Minhas posições" sem wallet, o spinner gira pra sempre. Em "Todos os pools" com filtro válido, o spinner deve resolver em ~1s. Em "Todos os pools" com filtro que retorna zero, o spinner deve sumir e mostrar empty state. A UI atual usa um único affordance pra três cenários distintos. Fix: estado de loading com label explícito por contexto + timeout que aciona empty state apropriado se nada vier em N segundos. Trade-off: aumenta complexidade de estado, mas elimina ambiguidade que mina confiança.

🔴 Fricção 3 (cosmética — afeta todo perfil): durante loading, os filtros (rede, search, segmento) ficam interativos. Se o usuário aplicar filtro durante o loading, dois requests sobrepostos podem retornar fora de ordem e mostrar dados errados ou flicker. Fix: desabilitar filtros temporariamente ou usar último-cancela-anterior na camada de fetch. Trade-off: pequena pausa de interação durante refetch — preço por consistência.

🟡 Oportunidade competitiva (baixa leverage no target): spinner cru vs. skeleton vs. progressive disclosure é detalhe de UX onde os concorrentes variam — não há convenção dominante, então não passa no critério "todos fazem igual". Diferenciação aqui seria polish, não estrutural. Classificar como oportunidade aqui infla a categoria; mantenho como fricção estrutural de paridade interna do produto.

Observação adicional: Pancake usa skeleton em "Minhas posições" (relatório 1) mas spinner cru em "Todos os pools" — mesma rota, dois padrões de loading. Inconsistência interna que confunde a quem aprende a leitura da UI. Indica que essas telas foram entregues por times/momentos diferentes sem revisão de paridade.

12. Pools de Syrup — Card em modo grid (visão vertical compacta)

Função: Mesma página de Syrup com toggle de visualização alterado de lista (horizontal) para grid (vertical). Card único reorganiza as informações empilhadas, com prioridade visual diferente: APR em destaque no topo, blocos "FORU GANHO" e "STAKE CAKE" no centro, controle "Manual" + tooltip "?" e "Detalhes ▼" no rodapé.

Componentes: toggle grid/lista (grid ativado); card vertical "Ganha FORU — Faça stake Cake" com avatar do par no topo; bloco APR (2,11% + ícone calculadora); bloco "FORU GANHO" (0 / 0 USD) + CTA "Coletar" desabilitado; bloco "STAKE CAKE" + CTA "Aprovar" primário; rodapé com segmento "Manual" (selecionado) + ícone "?" e CTA "Detalhes ▼"; ilustração de coelho abaixo.

Regras de negócio: modo grid é layout alternativo para a mesma pool — preserva todos os dados mas reordena visualmente; "Manual" indica modo de coleta manual de recompensa (vs. auto-compound, presumivelmente em outra opção); approval flow se mantém (Aprovar → Stake → Coletar); CTA "Coletar" depende de saldo > 0 de reward.

🟢 Insight: oferecer grid + lista como toggle reconhece que a mesma informação tem hierarquias diferentes conforme intenção do usuário — lista é boa para comparação entre muitas pools, grid é melhor para foco em uma só. Em um produto onde há apenas 1 pool ativa, o grid de fato funciona melhor pra esta tela. O surgimento do controle "Manual" + "?" no grid (que estava escondido em "Detalhes" na lista) é elevação inteligente de affordance.

🔴 Fricção 1 (estrutural — afeta iniciante): "Manual" aparece como segmento sem contexto visual de que existe alternativa. O ícone "?" sugere explicação, mas o segmento parece um seletor (visual de botão) sem revelar o que ele segue. Iniciante vê "Manual" e não sabe se é estado, modo, ou ação. Fix óbvio (renomear para "Modo: Manual") melhora marginalmente. Fix verdadeiro: substituir por toggle explícito "Auto-compound: desligado/ligado" — vocabulário do trade-off (reinvestir reward automaticamente vs. coletar manualmente), não jargão. Trade-off: exige decisão de copy que assume responsabilidade pelo termo "auto-compound" — não-óbvio para quem nunca viu staking.

🔴 Fricção 2 (estrutural — afeta iniciante): o card grid esconde "Total em stake" e "Termina em" — duas das métricas mais importantes para decisão (tamanho da pool indica diluição, tempo restante indica janela). Por que esconder informação de decisão e expor informação de operação (Aprovar, Coletar)? Sugere que o grid foi otimizado para usuário já decidido, não para quem está avaliando. Fix: manter "Termina em" + "Total em stake" visíveis no card grid abaixo do APR; esconder os blocos de ação atrás de "Stakar" único que expande para os dois CTAs. Trade-off: card mais alto.

🔴 Fricção 3 (cosmética — afeta intermediário): "Aprovar" como CTA primário (azul, peso forte) sem nada stakado é estranho — usuário não sabe que precisa aprovar antes de stakar, e aprovar não é a operação valiosa (custa gas sem entregar benefício). Fix: CTA primário deve ser "Stakar Cake" e o approve fica como passo invisível no fluxo (ou modal explicando "Etapa 1 de 2: Aprovar gasto, Etapa 2 de 2: Stakar"). Trade-off: complica controle de erro (approve falha vs. stake falha são tratáveis em sequência).

🟡 Oportunidade competitiva (média leverage no target): approve+stake como duas transações separadas é convenção de ERC-20 — todos os DEXs sofrem disso. Passa nas 4 perguntas com nuance: ✓ todos fazem; ✓ afeta iniciante direto (gasta gas no approve e acha que stakou); ✓ a razão de ninguém ter resolvido é metade técnica (limitação de ERC-20) e metade falta de investimento em UX que esconda a sequência atrás de um único gesto; ✓ perceptível ("um clique" vs. "tive que assinar duas vezes"). Diferenciação Kotai: usar permit/permit2 onde possível (sem approve separado) + UX que apresenta o fluxo como passo único mesmo quando há 2 assinaturas. Trade-off: nem todo token suporta permit; precisa fallback para o fluxo tradicional.

Observação adicional: o toggle grid/lista é decisão de produto que vale para 1 pool tanto quanto para 100 — questão de preferência. Em pool única, é cosmético; em catálogo populado, faz diferença real. Mostrar o toggle ativo numa lista de 1 item é honestidade de UI consistente, mas reforça o tema de "controles inertes em contextos triviais" (relatórios 8 e 10).

5. TWAP — Dropdown aberto em "Intervalo de negociação" (Min / Horas / Dias)

Função: Estado interativo do form TWAP após clique no campo "Intervalo de negociação". Abre dropdown com 3 opções de unidade temporal — Minutos / Horas / Dias. Responde direto à dúvida levantada nos relatórios 1, 3 e 4: a unidade existe, está escondida atrás do dropdown.

Componentes: painel direito completo (tabs Swap/TWAP/Limite com TWAP ativo, blocos De BNB e Para CAKE, toggle Preço limite off, cotação 1 BNB = 413.892 CAKE, slider Total de negociações = 1, Tamanho por negociação = 0 BNB); campo "Intervalo de negociação" com valor 2 + borda destacada em roxo (estado focado) e dropdown aberto sobreposto à direita com itens Minutos / Horas / Dias listados verticalmente, sem indicação visual de qual é o default; campo "Duração máxima" 4 ▾ inalterado; CTA disabled "Insira o valor" parcialmente coberto.

Regras de negócio: o intervalo numérico (2) e a unidade (Min/H/Dias) são campos separados — a UI compõe "2 + unidade" no submit. O dropdown lista 3 unidades fixas, sem segundos ou semanas. Default da unidade não é indicado visualmente no dropdown — provavelmente Minutos no estado inicial.

🟢 Insight: oferecer 3 unidades distintas reconhece que TWAP tem casos de uso de horizonte muito diferentes — desde anti-MEV em janela curta (intervalos de minutos) até DCA semanal (dias). Não cravar uma unidade única respeita a diversidade de estratégias. Decisão técnica correta para a feature.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): o dropdown aberto NÃO mostra qual unidade está selecionada — não há checkmark, highlight, bold ou ordem priorizada. O usuário que abre o dropdown só para confirmar "está em min ou h?" não consegue responder à própria pergunta sem fechar e tentar inferir pela aparência do campo (que também não exibe a unidade no estado fechado — Rel 1). Loop de incerteza. Solução óbvia que falha: só destacar item no aberto não resolve o estado fechado ilegível. Alternativa combinada: (a) item atual com checkmark + cor de fundo distinta no aberto; (b) unidade inline no fechado ("2 min ▾"). As duas juntas eliminam ambiguidade em todos os estados. Trade-off: trivial.

🔴 Fricção 2 (estrutural — afeta iniciante): as 3 unidades têm escalas radicalmente diferentes (1 min = 1/60h, 1 dia = 1440 min) e o número "2" mantém o mesmo peso visual em qualquer escolha. Iniciante que estava em "2 Minutos" e troca para "2 Dias" não recebe feedback de que acabou de multiplicar o intervalo por ~720x. Resultado: ordens TWAP configuradas para janelas absurdas (2 dias entre execuções, 10 fatias = 20 dias de duração) sem o usuário perceber. Solução óbvia que falha: forçar reset do número ao trocar unidade frustra usuário avançado. Alternativa: comparativo silencioso embaixo do campo ao trocar ("antes: 2 min • agora: 2 dias") por 2-3s. Aliado ao preview de plano (oportunidade do Rel 1/4), o impacto fica óbvio em escala humana. Trade-off: micro-animação; ganho é evitar configuração acidental ruim.

🟡 Oportunidade competitiva (média leverage — affordance + estado em todos os controles): Uniswap/1inch/Pancake usam dropdowns padrão que escondem seleção no fechado e muitas vezes no aberto. Para iniciante, fonte constante de "em qual modo estou agora?". Passa as 4 perguntas: (1) padrão indústria de dropdown silencioso; (2) afeta iniciante e intermediário em qualquer tela; (3) falta de investimento em design de estado; (4) ver seleção marcada + valor inline é perceptível. Diferenciação Kotai: princípio sistêmico — todo dropdown exibe valor atual no fechado e marca seleção no aberto, sem exceção. Trade-off: leve aumento de chrome; ganho é eliminar classe inteira de fricção no produto.

Observação adicional (granularidade do dropdown): 3 opções fixas podem ser limitantes — não há "15 minutos" comum em DCA, nem "semanas" para horizonte longo. Em Kotai vale considerar input híbrido: número livre + unidade, mas com presets clicáveis ("15 min", "1 h", "4 h", "1 dia", "1 semana") para iniciante não ter que pensar no número.

6. TWAP — Dropdown aberto em "Duração máxima" (Min / Horas / Dias)

Função: Mesmo padrão do relatório 5, agora aplicado ao campo "Duração máxima". Dropdown aberto exibindo Minutos / Horas / Dias. Tela com scroll, mostrando header da página (PancakeSwap logo, nav Trade / Perpétuos / Ganhar / Jogar / IA, busca, settings, wallet $0.00) — captura levemente diferente do Rel 5.

Componentes: header global completo (PancakeSwap logo + nav primária); painel direito (tabs Swap/TWAP/Limite, blocos De BNB e Para CAKE, toggle Preço limite off, cotação 1 BNB = 413.892 CAKE, slider Total de negociações = 1, Tamanho por negociação = 0 BNB); campo "Intervalo de negociação" 2 ▾ inalterado; campo "Duração máxima" com valor 4 + borda destacada em roxo (estado focado) e dropdown aberto à direita com Minutos / Horas / Dias listados (sem indicação de seleção atual); CTA disabled "Insira o valor".

Regras de negócio: simétrico ao Rel 5 — o número (4) e a unidade são campos separados. As 3 mesmas unidades são oferecidas. Não há vínculo automático com a unidade escolhida em "Intervalo de negociação" — é possível setar Intervalo em Minutos e Duração em Dias (válido: TWAP de granularidade fina em janela longa), mas também o contrário (Intervalo em Dias e Duração em Minutos), o que cria configuração matematicamente inválida.

🟢 Insight: simetria de tratamento entre Intervalo e Duração — mesmas 3 unidades, mesma UI de dropdown, mesmo padrão de interação. Coerência de design reduz custo cognitivo: aprender 1 padrão serve para os dois campos. Decisão de design correta.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): mesma raiz do Rel 5 — dropdown aberto sem indicação da seleção atual, estado fechado sem unidade exibida. A simetria com Intervalo agrava o problema: agora há DOIS campos com a mesma ambiguidade, e o usuário não sabe se as duas unidades batem. A pergunta "meu intervalo é 2 minutos e minha duração é 4 horas, ou ambos em horas?" não tem resposta na UI. Alternativa: mesma do Rel 5 aplicada aos dois campos + linha derivada abaixo do bloco que compõe o resumo ("Executar a cada 2 min, por até 4 h") — linguagem natural em vez de tabelinha de campos.

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário): combinações Intervalo-Duração incoerentes são permitidas. "Intervalo: 2 Dias / Duração: 4 Minutos" passa pela validação visual (cada campo isolado é válido), mas é matematicamente impossível executar uma TWAP onde a granularidade entre execuções é maior que a duração total. O sistema vai aceitar a ordem e ela vai falhar — ou pior, executar 0 vezes silenciosamente. Solução óbvia que falha: bloquear combos é frágil (precisa enumerar todos os casos). Alternativa: validar pela inequação Intervalo ≥ Duração e exibir alerta amber inline ("Intervalo (2 dias) é maior que a Duração máxima (4 min) — nenhuma execução vai disparar"). Liga direto com a oportunidade do Rel 4 (preview do plano executável). Trade-off: lógica reativa entre os 2 campos; trivial.

🟡 Oportunidade competitiva (alta leverage no target — composição em linguagem natural "do plano que você acabou de configurar"): Uniswap/Pancake/1inch tratam cada campo como input isolado. Não compõem a frase "o que isso significa em conjunto". Para TWAP, onde 4 campos interagem matematicamente, isso é gap crítico para iniciante e intermediário. Passa as 4 perguntas: (1) padrão indústria; (2) afeta diretamente o target — TWAP é onde intermediário tenta e desiste; (3) falta de investimento em copy + lógica derivada; (4) ler "vai executar 5 vezes de 2 BNB cada, a cada 1 hora, por até 5 horas" é claramente perceptível vs ler 4 campos crus. Diferenciação Kotai: abaixo de todos os 4 campos, parágrafo derivado em linguagem natural que recompila a configuração — atualiza ao vivo conforme o usuário mexe nos inputs. Aproxima a UX de um construtor de receita ("você está pedindo: X"), não de um formulário desconectado. Trade-off: design da seção "Resumo"; ganho é fechar o gap entre input cru e modelo mental do usuário.

Observação adicional (header visível nesta captura vs ausente nas anteriores): o Rel 5 mostra a tela com scroll para baixo (header recolhido), o Rel 6 mostra com header. Sugere que o usuário está rolando entre os campos. Em mobile, esse comportamento de header sticky vs hidden vira decisão crítica de UX — vale checar no fluxo mobile.

7. TWAP — Toggle "Preço limite" ativado + tab "Histórico de ordens" no painel esquerdo

Função: Tela após o usuário (a) ativar o toggle "Preço limite" (passa a teal/on) e (b) clicar na tab "Histórico de ordens" no painel esquerdo. Combina duas mudanças de estado simultaneamente. Faz aparecer o bloco de configuração de preço-alvo entre o Para e o slider de Total de negociações.

Componentes: header global; painel esquerdo com tab "Histórico de ordens" ativa (roxo) e empty state "Nenhum histórico encontrado"; painel direito completo: tabs Swap/TWAP/Limite, blocos De BNB e Para CAKE, toggle "Preço limite" ON em teal; bloco novo abaixo do toggle com label "Vender BNB a uma taxa de" — input grande "CAKE 413.892" com legenda "~628.24 USD", link à direita "Definir taxa de mercado" + sub-bloco "Lucro 0.0%"; slider Total de negociações = 1 e Tamanho por negociação = 0 BNB seguem visíveis abaixo.

Regras de negócio: ativar Preço limite muda o modo da TWAP — agora cada execução só dispara se o preço de mercado cruzar a taxa-alvo definida pelo usuário. A taxa default é o preço de mercado atual (413.892 CAKE/BNB) e "Lucro 0.0%" reflete que estamos no spot — qualquer ajuste no preço-alvo recalcula Lucro como delta vs mercado. "Definir taxa de mercado" é atalho para resetar ao spot. Aba "Histórico de ordens" lista ordens TWAP encerradas (completas, parciais ou expiradas).

🟢 Insight: o sub-bloco "Lucro 0.0%" é a melhor decisão de produto da tela. Em vez de mostrar o preço-alvo cru ("414.0") sem âncora, mostra o delta vs mercado em % — o usuário vê IMEDIATAMENTE quanto a ordem dele está "acima ou abaixo do mercado" e se isso é favorável. É a quantificação que falta no Limite simples (Rel 2 do fluxo Limite, sobre presets +1/+5/+10% sem direção). Aqui, qualquer movimento no preço-alvo atualiza o Lucro — closed loop. Replicar em Kotai sem modificações.

🔴 Fricção 1 (estrutural — afeta iniciante): ativar Preço limite faz aparecer um bloco grande NOVO entre Para e o slider, empurrando os campos para baixo. Isso é mudança de layout silenciosa — iniciante que ativou o toggle por curiosidade não entende por que a tela cresceu, e pode perder o vínculo entre "liguei o toggle" e "surgiu este campo". A relação causa-efeito é geográfica (toggle → bloco abaixo dele), mas não há animação ou highlight transitório que evidencie. Solução óbvia que falha: animar in/out é convenção válida, mas não basta sem explicação. Alternativa: copy abaixo do toggle no estado on ("Sua ordem só executa quando o preço cruzar o valor abaixo"), removível em settings. Trade-off: 1 linha; ganho é o iniciante entender por que apareceu coisa nova.

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário): o label do preço-alvo é "Vender BNB a uma taxa de", e "Lucro" usa percentual sem contexto direcional. "0.0% de Lucro" no spot é neutro, mas se o usuário sobe o preço-alvo, o Lucro fica positivo — mas isso é "lucro PARA quem vende". Quem está comprando (perspectiva inversa) lê "+5% Lucro" e pode interpretar errado. Mesmo problema da Fricção 2 do Rel 2 do Limite — direção da vantagem depende do papel. Solução óbvia que falha: trocar "Lucro" por "Acima do mercado" perde a polaridade qualitativa. Alternativa: rótulo dinâmico — "+5% melhor que o mercado para você (vender BNB mais caro)". Linguagem natural cobre os dois lados sem ambiguidade. Trade-off: copy mais longa; ganho é eliminar mal-interpretação.

🔴 Fricção 3 (cosmética — afeta iniciante): "Definir taxa de mercado" como link no canto superior direito do bloco é affordance fraca (texto sem ícone, sem cor de ação clara). Para o iniciante, é fácil não perceber que isso é botão de "resetar ao spot". E semanticamente, "definir taxa de mercado" pode soar como "eu vou definir UMA taxa, manualmente", o oposto do que faz. Alternativa: ícone ↺ + label "Voltar ao preço de mercado" como botão pequeno. Trade-off: trivial.

🟡 Oportunidade competitiva (alta leverage no target — quantificar a direção da ordem em tempo real): Uniswap mostra preço-alvo cru sem Lucro/% direcional; 1inch idem. Pancake é a única dos 3 grandes que já mostra Lucro inline — mas o label ainda é ambíguo (Fricção 2). Para iniciante, ver "+5% melhor que o mercado" é a microcopy que vira ordem limite/TWAP em ferramenta de adulto, não brinquedo. Passa as 4 perguntas: (1) Uniswap/1inch não mostram; Pancake mostra mal; (2) afeta diretamente o iniciante — primeira ordem limite é onde ele desiste por não saber qual direção é "boa"; (3) ninguém resolveu plenamente por falta de investimento em copy direcional, não dificuldade; (4) o iniciante percebe na hora. Diferenciação Kotai: label direcional dependente do papel (vender/comprar) + cor (verde quando favorável ao usuário, amber quando desvantajoso) + comparativo em USD absoluto ("vai vender por $33 a mais que agora"). Trade-off: lógica de copy direcional; ganho é trazer iniciante para dentro da feature.

Observação adicional ("Histórico de ordens" como aba do TWAP): o histórico é compartilhado com o Limite (ambos passam pelo mesmo painel esquerdo). Faz sentido — ambos são "ordens pendentes/encerradas". Mas o empty state "Nenhum histórico encontrado" é genérico — não distingue se o usuário nunca usou TWAP/Limite (caso comum para iniciante) ou se usou e tudo foi cancelado. Em Kotai, o empty state pode ser diferenciado por estado da wallet (nunca usou x já usou) e oferecer onboarding contextual no primeiro caso.

4. TWAP — Tooltip em "Duração máxima" (teto da ordem e outcomes possíveis)

Função: Mesma tela com tooltip aberto sobre "Duração máxima" (valor 4). Define o tempo total máximo que a ordem TWAP tem para ser preenchida.

Componentes: idênticos. Tooltip: "O tempo máximo durante o qual o montante total das negociações individuais que compõem sua ordem completa pode ser executado. Observe que dependendo dos seus parâmetros, sua ordem pode ser executada antes desse prazo, parcialmente ou não ser executada."

Regras de negócio: Duração máxima é o teto absoluto. Se Total de negociações × Intervalo > Duração máxima, alguns slots não disparam — ordem termina parcial. Se houver Preço Limite e o mercado nunca cruzar a barreira, ordem termina não-executada. É também a única forma de cancelamento automático natural — sem ela, a ordem ficaria pendente indefinidamente.

🟢 Insight: o tooltip declara os três outcomes honestamente — "executada antes do prazo / parcialmente / não executada". Em DEX, a maioria simula determinismo onde não há. Reconhecer publicamente que a ordem pode falhar é trust signal forte. Direção de produto correta.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): três variáveis acopladas — Total de negociações (N), Intervalo (I), Duração máxima (D) — com constraint matemática N×I ≤ D invisível. Se o usuário configura N=10, I=2h, D=4h, ele cria ordem que matematicamente só executa 2 fatias (4h ÷ 2h). As 8 restantes viram "parcial" silenciosamente. Iniciante não percebe; intermediário só descobre depois. Solução óbvia que falha: bloquear input incoerente irrita avançado mid-edição. Alternativa: faixa de feedback abaixo dos 3 campos mostrando o cálculo derivado — "Com seus parâmetros: 2 de 10 execuções vão disparar dentro de 4h. As 8 restantes não rodam." Cor amber no mismatch. Trade-off: ocupa espaço; ganho é eliminar a pegadinha matemática.

🔴 Fricção 2 (estrutural — afeta iniciante): "Duração máxima: 4" sem unidade (de novo). 4 min? 4h? 4 dias? Sem unidade visível, iniciante adivinha. E há pegadinha: com Intervalo 2 e Duração 4 em minutos, a ordem só roda 2 vezes; com o piso de $100/execução, exige $200 mínimos — micro-ordem, não TWAP real. Solução óbvia que falha: forçar default em horas tira flexibilidade. Alternativa: unidade explícita no valor exibido ("4 horas ▾"), mesma fix da Fricção 2 do Rel 1, com default sensato (horas, unidade típica de uso de TWAP). Trade-off: trivial.

🟡 Oportunidade competitiva (alta leverage no target — preview projetivo "plano pedido vs plano executável"): mesmo argumento do Rel 1, aprofundado. A Duração máxima é onde a constraint matemática explode. Passa as 4 perguntas (já validadas no Rel 1): (1) padrão indústria; (2) afeta iniciante e intermediário; (3) falta de investimento em UX; (4) preview é perceptível. Diferenciação Kotai (aprofundando): o preview deve distinguir executable plan vs requested plan. Se o usuário pediu 10 fatias em 4h mas só cabem 2, o preview mostra "Você pediu: 10 fatias / Vai rodar: 2 fatias (as outras 8 não cabem na duração máxima)". Cor amber. Botão "Ajustar" sugere fix ("aumentar duração para 20h" ou "reduzir N para 2"). Trade-off: lógica de sugestão fica não-trivial; ganho é o produto trabalhar a favor do iniciante.

Observação adicional (Duração máxima como cancelamento natural): em TWAP, a Duração máxima garante que a ordem não fica pendente para sempre. Em Uniswap e 1inch, ordens TWAP/Limit muitas vezes ficam abertas até cancelamento manual. Pancake escolhe boundary explícito — decisão técnica boa, mas exige que o usuário entenda o trade-off de pôr duração curta (ordem expira sem completar) vs longa (exposição prolongada a market changes). Em Kotai, vale defaultar a Duração para um valor sensato baseado em N × I e oferecer override consciente.

5. Pools — Tooltip do APR sem split + menção a bCAKE (hover em pool V2)

Função: Mesmo tooltip do APR, mas em uma linha de pool V2 (SKYAI/WBNB, 150,76%) onde não há farm ativa — só APR da taxa de LP. Acrescenta um terceiro parágrafo sobre bCAKE e boost de farm que aparece apesar de não haver componente de farm visível no split. Estado mostra também rotação do card "Escolhas Pancake" para #3 cbETH/WETH.

Componentes: célula APR em hover (150,76%, sem ícones de boost/farm); tooltip dark com título "APR combinada: 150,76%", bullet único "APR da taxa de LP: 150,76%", parágrafo padrão sobre cálculo do APR, parágrafo sobre ressalva de range em V3, e parágrafo extra "O bCAKE apenas impulsiona o APR da Farm. O multiplicador de boost real está sujeito às condições da farm e do pool."

Regras de negócio: quando a pool não tem farm, o split colapsa para uma única fonte (LP fee) e o número combinado iguala a esse componente; o tooltip mantém o mesmo template, ocultando bullet vazio de farm; menções a bCAKE e ressalvas de V3 aparecem mesmo em contextos onde não se aplicam (pool V2 sem farm), porque o tooltip parece ser estático/global.

🟢 Insight: colapsar o split para um único bullet em vez de mostrar "APR da farm: 0,00%" é decisão certa — evita ruído numérico que sugeriria farm inativa em vez de farm inexistente. Manter o template visual estável entre pools com e sem farm preserva previsibilidade da UI.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): o tooltip mostra ressalvas que não se aplicam à pool em foco. SKYAI/WBNB é V2 (constant product, sem range) e não tem farm, mas o tooltip menciona "intervalo de preço definido" (só V3) e "bCAKE impulsiona APR da Farm" (não há farm). Para o iniciante, isso é ruído cognitivo — ele tenta mapear cada frase à pool que está olhando, encontra contradição, e perde confiança no que lê. Fix óbvio (esconder parágrafos não-aplicáveis) exige regra condicional por (versão × farm × ativos) — viável, não trivial. Fix verdadeiro: tooltip dinâmico que mostra só ressalvas pertinentes à pool exata sob hover; o resto sai pra um link "Como o APR funciona" no rodapé. Trade-off: aumenta superfície de manutenção (precisa testar todas combinações), mas é fricção estrutural — o usuário-alvo lê copy errado em quase toda pool V2.

🔴 Fricção 2 (cosmética — afeta intermediário): APR de 150,76% em V2 sem farm aparece sem qualquer sinal de cautela. Em pool de altcoin volátil (SKYAI), número desse tamanho é quase sempre puxado por volume especulativo de curto prazo e tende a colapsar. A UI trata 150% e 5% com mesmo peso visual — só ordenação por número. Fix: badge sutil de risco (volatilidade do par, idade do contrato) na linha, não no tooltip. Não é fricção isolada desta tela, mas a tela é onde a ausência fica mais visível.

🟡 Oportunidade competitiva (alta leverage no target): APR display sem contexto de sustentabilidade é convenção em todos os concorrentes. Passa nas 4 perguntas: ✓ todos exibem APR cru; ✓ afeta iniciante direto (entra em pool de 150% pensando que é o "melhor", sai com -40% por IL); ✓ não resolvido por falta de investimento em scoring de risco, não por impossibilidade técnica; ✓ perceptível ("o produto me avisou que esse APR alto é volátil" vs. "perdi sem entender"). Diferenciação Kotai: APR exibido com selo de qualidade ("Sustentável — par estável" / "Variável — par volátil" / "Especulativo — token novo") derivado de métricas objetivas (volatilidade, idade, profundidade). Trade-off: o usuário-alvo pode perceber como paternalismo se a classificação for excessiva; precisa ser sutil e auditável.

Observação adicional: o card "Escolhas Pancake" rotacionou de #2 USDC/MUSD para #3 cbETH/WETH no mesmo intervalo da sessão. Rotação automática é decisão sensata para evitar viés, mas se o usuário tentar voltar ao card que viu, não há paginação por nome — só pelos dots. Fricção da landing (tela 1), não desta, mas o estado captura o problema.

1. Perpétuos — Tela de trading (BTCUSD)

Função: Mesa de operação de contratos perpétuos. Permite ao usuário definir direção (Up/Down), colateral, alavancagem, duração e take profit para abrir posição derivativa, com gráfico, estatísticas de mercado e oracle (Pyth) visíveis.

Componentes: header com seletor de par BTCUSD + stats (preço 81.319,5 / variação +0,92% / 1h Funding Long -0,00096% / 1h Funding Short +0,00000% / Long OI 210,1K/2M / Short OI 49K/2M / Leverage 485X–1001X); badge "ALP APY 43,88%" com CTA "Earn"; card sidebar "If you have open positions on Perps Pro, click here to manage them"; gráfico TradingView com 1s/1m/5m/15m/1h/4h/D + indicators + Pyth oracle; abas Positions/Orders/History (todas em 0), Close All, switch Perpetual/Fixed Expiry; painel lateral direito de trade — toggle Up/Down (Up ativo), Collateral USDT (0.0, Avbl 0.00, presets 25%/50%/MAX), Leverage slider 0→1001X com badge "Degen" (default em 1001X), Duration (Perpetual/1h/30m/15m/5m), seção Advanced colapsada, Take Profit +300%, CTA "Approve USDT", linhas Size in USD 0.0, Entry Price (0% Spread) 81.319,5, Liq. Price (-65% Margin) 81.266,6 com tag "(Rekt)".

Regras de negócio: produto é perp DEX com colateral em stable. Funding rate cobrado/pago a cada hora conforme posição (Long/Short). Liquidação calculada por margem; "Rekt" sinaliza preço de liquidação. Leverage até 1001X (degen tier). ALP é o pool LP que provê liquidez aos traders — APY exibida no header. Aprovação de USDT é pré-requisito antes da primeira operação.

🟢 Insight: a tela é honesta sobre o que é. Badge "Degen", label "(Rekt)" na Liq. Price e leverage máximo de 1001X comunicam imediatamente o nível de risco — não tenta disfarçar perp como produto seguro. Para o público-alvo do produto (avançado/degen), essa transparência crua é parte do branding e gera confiança. "Up/Down" em vez de "Long/Short" também é decisão correta de localização cognitiva — termo direcional puro em vez de jargão de derivativos.

🔴 Fricção 1 (estrutural — afeta intermediário curioso): os defaults são extremos. Slider de leverage abre em 1001X (máximo), Take Profit em +300%, direção em Up. Um intermediário que entra "pra ver como funciona" pode aprovar USDT sem entender que está se comprometendo com posição absurdamente alavancada — e a primeira operação real vira liquidação quase imediata. Diagnóstico errado: "reduzir leverage máximo" — mata o público-alvo do produto. Alternativa: defaults conservadores no primeiro acesso (5X–10X, Take Profit razoável) com toggle "Degen mode" persistente que destrava o range completo. Trade-off: degen veterano vai precisar de 1 clique extra; iniciante/intermediário não é liquidado por default.

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário): densidade de jargão técnico sem progressive disclosure. "Funding (Long) / Funding (Short)", "Long OI / Short OI", "Liq. Price (-65% Margin)", "Entry Price (0% Spread)", "ALP APY" — cada label é termo de derivativos sem explicação inline. Intermediário que conhece spot mas nunca operou perp se perde nas primeiras 3 linhas. Diagnóstico errado: tooltip em cada label — polui. Alternativa: agrupar stats secundárias sob "Detalhes do mercado" colapsável e expor inline só o essencial (preço, variação 24h, leverage range). Trade-off: power user precisa expandir; ganho em primeira impressão compensa.

🔴 Fricção 3 (cosmética — copy): "Rekt" como label oficial na Liq. Price é cultura degen explícita. Para target BR iniciante/intermediário, "Rekt" é jargão de imageboard cripto sem tradução natural. Alternativa: "Liquidação" — mesmo significado funcional, sem barreira cultural. Manter "Degen" no badge é decisão de marca defensável; "Rekt" num campo crítico de risco não é.

🟡 Oportunidade competitiva: ausência total de paper trading / modo educacional. dYdX, GMX, Hyperliquid, Pancake — todos os perps DEX pulam direto pra produção. Iniciante curioso só tem dois caminhos: arriscar dinheiro real ou sair. Critério das 4 perguntas: ✓ todos fazem igual, ✓ afeta iniciante e intermediário, ✓ razão é falta de investimento em onboarding (não impossibilidade — saldo fictício é trivial tecnicamente), ✓ ganho perceptível (testar perp sem risco real). Alternativa: modo paper trading com toggle visível no header, simulando o mesmo fluxo com saldo fictício e marcação visual clara ("Simulação"). Trade-off: pode reduzir volume real no curto prazo; ganho de retenção e funil compensa no médio prazo.

🟡 Oportunidade competitiva 2: "Up/Down" é única concessão de linguagem para iniciante; resto da tela permanece em vocabulário avançado. Convenção: indústria perps assume jargão técnico. Critério: ✓ todos fazem igual, ✓ afeta iniciante e intermediário, ✓ falta de investimento em copy duplo, ✓ perceptível. Alternativa: dual labels persistentes ("Long — apostar que sobe") + toggle "modo simples/técnico" no header. Trade-off: aumenta complexidade visual; mitigar mantendo modo simples como default e técnico como opção memorizada.

Observação adicional: o card "If you have open positions on Perps Pro, click here to manage them" sinaliza que houve migração de arquitetura (Perps Pro → este produto). Para usuários migrados pode ser fricção real (precisam gerenciar posições em outro lugar), mas não dá pra avaliar sem ver a outra versão. Fica registrado como ponto a investigar.

Consolidado — Perpétuos (PancakeSwap)

Caráter geral do fluxo

Perpétuos é produto de nicho high-risk: uma única tela que concentra toda a operação (colateral, alavancagem, duração, take profit, gráfico, estatísticas de mercado) num painel denso voltado deliberadamente para público avançado/degen. Isso cria tensão direta com o target do Kotai: o atrito identificado em #1 não está no design para quem é o público-alvo do produto PancakeSwap, mas nos defaults que liquidam quem entra "pra ver como funciona" e na ausência de qualquer rampa de entrada para o intermediário de spot curioso sobre derivativos. O perfil mais afetado pelas fricções estruturais é o intermediário — quem já fez swap, talvez ordem limite, e quer explorar perps sem ainda ter vocabulário do mercado de derivativos. Iniciante genuíno raramente chega até aqui; avançado/degen é o target declarado do produto e não sofre com os problemas identificados.

🔴 Fricções

Estrutural — Defaults extremos criam liquidação por omissão — Tela 1 (estrutural, 1 tela)

O slider de leverage abre em 1001X (máximo absoluto), Take Profit em +300%, direção em Up — sem nenhuma contextualização de risco antes do CTA "Approve USDT". Um intermediário que entra em #1 para explorar o produto aprova o token e abre posição sem perceber que está comprometido com alavancagem absurda: a liquidação vem em segundos, não em dias.

O diagnóstico errado aqui seria "reduzir o leverage máximo" — isso mata o público degen que é o target declarado do produto. O problema não é o range disponível, é o default do primeiro acesso.

Alternativa: defaults conservadores na primeira sessão (5X–10X, TP em 20–30%) com toggle "Degen mode" persistente que destrava o range completo e é memorizado por sessão. A lógica é idêntica ao "Advanced mode" de produtos de câmbio: quem sabe, ativa uma vez e não vê de novo; quem não sabe, não é liquidado por omissão.

Trade-off: degen veterano precisa de 1 clique extra na primeira vez. Ganho: intermediário curioso não perde capital na primeira exploração do produto.

Perfil mais afetado: intermediário.

Estrutural — Jargão técnico sem progressive disclosure — Tela 1 (estrutural, 1 tela)

O header de #1 exibe simultaneamente: Funding (Long/Short), Long OI / Short OI com cap, Leverage range, ALP APY — tudo antes de qualquer interação. O painel de trade adiciona: Entry Price (0% Spread), Liq. Price (-65% Margin), Size in USD. São seis a oito termos de derivativos expostos ao mesmo tempo sem hierarquia, sem collapse, sem progressive disclosure.

Nota de classificação: esse ponto beira 🟡 Oportunidade competitiva — todos os perps DEX (dYdX, GMX, Hyperliquid) exibem o mesmo bloco de métricas técnicas sem organização progressiva. Mantenho como 🔴 estrutural porque a intervenção é de organização de UI (agrupar stats secundárias, colapsá-las), não de redefinição de terminologia — e porque é corrigível sem mudar o paradigma do produto. Se o Kotai vier a ter um produto perps, vale tratar como oportunidade de diferenciação naquele momento.

Por que a solução óbvia falha: tooltip em cada label fragmenta a carga e polui a interface já densa. Traduzir rótulos literalmente ("OI em aberto" em vez de "OI") não resolve o problema de densidade.

Alternativa: colapsar sob "Detalhes do mercado ▾" os stats secundários (Funding, OI, ALP APY), expondo no header apenas preço, variação 24h e leverage range. O painel de trade mantém Entry Price e Liq. Price, mas os agrupa sob "Resumo da posição" com tooltip acionado por toque — não inline.

Trade-off: power user clica mais uma vez para ver Funding e OI. Ganho: primeira impressão da tela para o intermediário de spot é legível.

Perfil mais afetado: intermediário de spot explorando perps pela primeira vez.

🟡 Oportunidades competitivas do fluxo

Paper trading / modo educacional — Tela 1

Padrão atual da indústria: dYdX, GMX, Hyperliquid, PancakeSwap Perps — nenhum oferece paper trading nativo e acessível. O usuário tem dois caminhos: arriscar capital real ou sair.

Por que afeta nosso target: o intermediário curioso que quer entender como perps funcionam não tem como praticar o fluxo em #1 sem risco real. A tela é cognitivamente densa (ver Fricção 2), os defaults são extremos (ver Fricção 1) — a combinação cria barreira de entrada alta justamente pra quem ainda está avaliando se quer operar derivativos.

Hipótese de diferenciação Kotai: toggle "Simulação" visível no header (com badge visual permanente indicando que não é capital real), usando o mesmo fluxo e a mesma UI com saldo fictício. O intermediário aprende sem risco; a transição para conta real é o mesmo botão no mesmo lugar.

Trade-off: pode reduzir volume real no curto prazo (usuário fica em simulação por mais tempo). Ganho: funil de conversão de intermediário → trader real; diferenciação de produto perceptível e comunicável externamente ("teste sem risco antes de operar de verdade").

Passa nas 4 perguntas-teste? (1) ✓ Todos os concorrentes principais fazem igual — nenhum tem paper trading nativo visível. (2) ✓ Afeta intermediário diretamente — é exatamente o perfil que quer explorar sem comprometer capital. (3) ✓ Razão de ninguém ter resolvido é falta de investimento — saldo fictício com mesma UI é tecnicamente trivial. (4) ✓ Usuário perceberia a diferença — completamente: pode testar o produto sem risco real.

Vocabulário técnico sem camada de linguagem acessível — Tela 1

Padrão atual da indústria: todos os perps DEX assumem vocabulário de derivativos como pré-requisito. A única concessão de linguagem na tela da PancakeSwap é "Up/Down" em vez de "Long/Short" — o restante (funding, OI, spread, liquidação) permanece em jargão técnico puro.

Por que afeta nosso target: o intermediário de spot que conhece "comprar/vender" e "taxa de câmbio" não mapeia automaticamente para "funding (long)", "OI" ou "(-65% Margin)". A tela de #1 usa corretamente "Up/Down" — mas para por aí.

Hipótese de diferenciação Kotai: dual labels no modo padrão — label técnico + descrição funcional em linha (ex.: "Funding (Long) — taxa que você paga/recebe por hora por estar comprado") — com toggle "modo técnico" que oculta as descrições para quem já não precisa. O modo técnico seria memorizado por sessão.

Trade-off: aumenta o espaço vertical necessário por stat; em mobile, a densidade já é crítica. Mitigar com expansão inline ao hover/toque, não labels sempre visíveis.

Passa nas 4 perguntas-teste? (1) ✓ Todos os concorrentes fazem igual — jargão técnico dominante é padrão universal de perps DEX. (2) ✓ Afeta intermediário de spot explorando perps — sim, diretamente. (3) ✓ Razão é falta de investimento em copy e UX — não impossibilidade técnica. (4) ✓/⚠ Ganho perceptível — sim, mas com ressalva: usuário que chega a perps já aceitou uma curva de aprendizado. O ganho é real para o intermediário de spot, mas mais modesto que a Oportunidade 1 (paper trading). Esta é a pergunta mais fraca desta oportunidade — se o Kotai tiver que priorizar, papel trading entrega mais leverage por esforço.

Pontos isolados (1 tela)

• 🟢 Tela 1: Honestidade de branding — badge "Degen", leverage explícita no header e "Up/Down" em vez de "Long/Short" comunicam o produto sem eufemismo. Para o público-alvo declarado (avançado/degen), essa transparência crua gera confiança. Padrão a herdar seletivamente: comunicar risco real sem eufemismo, mas sem intimidar o iniciante que não é target de perps.
• 🔴 Tela 1: "(Rekt)" como label oficial no campo Liq. Price — jargão de imageboard sem tradução natural para público BR não-degen. Para o intermediário que chegou na tela, o campo de liquidação é o mais crítico da tela; "Liquidação" cumpre o mesmo papel funcional sem barreira cultural. Correção cosmética trivial.

Nota: os drafts de lote não foram gerados para este fluxo (1 tela, processamento direto). Não há equivalente de Perpétuos no consolidado Uniswap para comparação cruzada.

11. TWAP — Mesmo form preenchido, input desfocado (atalhos % somem, ícone wallet aparece)

Função: Mesmo estado do Rel 10 (form preenchido com 1 BNB, alerta de saldo insuficiente, plano TWAP de 6 fatias por 24h), agora com o input De DESFOCADO. A diferença está no canto superior direito do bloco De — os atalhos "25% | 50% | MAX" foram substituídos pelo contador wallet "⌑ 0" (ícone de carteira + saldo zero).

Componentes: idênticos ao Rel 10 com 1 mudança — onde antes havia chips "25% | 50% | MAX", agora aparece apenas "⌑ 0" (ícone wallet + saldo da wallet conectada, que é 0 BNB). Todo o resto da tela permanece: alerta "Saldo insuficiente de BNB", bloco Para CAKE 413.892, toggle Preço limite off, plano TWAP (Total 6, Tamanho 0.166 BNB, Intervalo 2, Duração 24), CTA "Realizar ordem TWAP" enabled, rodapé Orbs.

Regras de negócio: o componente do canto superior direito do bloco De é multi-estado — alterna entre "chips de atalho %" (quando o input está focado) e "contador wallet" (quando desfocado). Provavelmente para reduzir clutter visual no estado de leitura. "⌑ 0" mostra o saldo do token selecionado (BNB) na wallet conectada, o que conecta com o alerta abaixo ("Saldo insuficiente") — saldo é literalmente 0.

🟢 Insight: trocar atalhos por saldo da wallet quando o input perde foco é decisão de espaço inteligente — informação relevante para cada modo (editar vs ler). No modo edit, atalhos % são úteis; no modo read, saldo da wallet contextualiza o que foi digitado. A lógica é correta em princípio.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): a troca de estado é silenciosa e o ícone "⌑" (wallet) sem label é ambíguo. Iniciante olha "⌑ 0" e pode ler como "contador de carteiras" (0 wallets?), "contador de notificações" ou simplesmente ignorar. A relação "⌑ 0 = saldo da BNB na minha wallet" não é decodificável sem hover/explicação. Pior: justamente o iniciante que está com saldo 0 é quem PRECISA decifrar este número para entender o problema antes de tentar. Solução óbvia que falha: spelling out "Saldo: 0 BNB" sempre polui. Alternativa: label em hover/tooltip + cor para indicar zero ("⌑ 0" em cinza-muted vs amber/vermelho quando saldo < valor digitado). E unidade visível ("⌑ 0 BNB") em vez de só "0". Trade-off: trivial; ganho é eliminar ambiguidade do ícone.

🔴 Fricção 2 (estrutural — afeta iniciante): mostrar saldo 0 ao mesmo tempo que o alerta "Saldo insuficiente de BNB" é redundância silenciosa que não ajuda. O usuário tem dois sinais do mesmo problema, mas nenhum oferece caminho de resolução. Idem Fricção 1 do Rel 10: a UI sinaliza, mas o CTA não age. Solução óbvia que falha: esconder o saldo quando há alerta é ruim — usuário perde contexto. Alternativa: o "⌑ 0 BNB" vira link clicável → abre on-ramp / depósito direto ("Adicionar BNB ↗"). Saldo deixa de ser informação morta e vira affordance. Trade-off: integração de on-ramp; alinha com a oportunidade do Rel 10.

🔴 Fricção 3 (cosmética — afeta intermediário): a mudança visual entre foco e desfoco é abrupta — chips % desaparecem instantaneamente. Para quem tirou o foco acidentalmente (clique fora, scroll), os atalhos somem sem aviso e o usuário pode achar que "foram removidos" em vez de "estão escondidos". Alternativa: transição suave (fade) e/ou manter chips como fantasma (opacity baixa) no estado desfocado quando há saldo > 0. Trade-off: micro-animação; ganho é continuidade visual.

🟡 Oportunidade competitiva (média leverage — saldo da wallet como ação, não como display): Uniswap, 1inch e Pancake mostram saldo da wallet como número estático ao lado do input — informação morta. Quando o saldo é insuficiente, o usuário precisa sair do produto para resolver (abrir CEX, comprar, transferir, voltar). Passa as 4 perguntas: (1) padrão indústria de saldo estático; (2) afeta diretamente iniciante e intermediário — sair do produto é onde 30%+ não voltam; (3) ninguém resolveu plenamente por exigir integração com on-ramp/bridge, não dificuldade técnica isolada; (4) clicar no saldo e ir direto para comprar é claramente perceptível. Diferenciação Kotai: saldo da wallet sempre clicável; quando insuficiente, vira deeplink para on-ramp (com valor pré-preenchido para cobrir o déficit). Quando saldo está em outra chain, vira deeplink para bridge. Trade-off: integrações de on-ramp e bridge; ganho é a wallet deixar de ser parede entre o usuário e a ação.

Observação adicional (estado foco vs desfoco como pattern recorrente): este padrão de UI mostrar atalhos só com foco é comum em DEXs e em apps de input financeiro (Apple Pay, Wise, Revolut). Faz sentido para reduzir clutter mas, em DeFi, o estado desfocado é o estado de "revisão antes de assinar" — onde mais informação é desejada, não menos. Em Kotai, vale considerar manter atalhos visíveis também no desfoco, e usar a transição apenas para hierarquia visual (chips menores quando desfocado).

8. TWAP — Tela completa com Preço limite ativo + alerta de execução condicional

Função: Vista completa (zoom out) do estado TWAP com Preço limite ativo, mostrando o widget inteiro, o alerta de execução condicional embaixo do CTA, e o footer institucional. Materializa todo o objeto que o usuário vai assinar.

Componentes: painel direito visto completo — tabs Swap/TWAP/Limite, De BNB, Para CAKE, toggle Preço limite ON, bloco "Vender BNB a uma taxa de" CAKE 413.892 (~628.24 USD) | "Definir taxa de mercado" + "Lucro 0.0%", slider Total de negociações = 1 + Tamanho por negociação 0 BNB, campos Intervalo 2 ▾ + Duração máxima 4 ▾, CTA disabled "Insira o valor", rodapé "Desenvolvido por Orbs"; alerta novo destacado abaixo do widget: ⚠ "Ordens limitadas podem não ser executadas quando o preço do token estiver igual ou próximo ao preço limite, devido às taxas de gas e taxas padrão de swap. Saiba mais"; footer institucional completo (Ecossistema / Business / Desenvolvedores / Suporte / Sobre + social icons + "Compre CAKE → $1.518").

Regras de negócio: o alerta aparece SÓ quando Preço limite está on. Reconhece que, perto do preço-alvo, o custo de execução (gas + fee Orbs + swap fee padrão) pode tornar a ordem economicamente inviável — mesmo se o preço cruzar a barreira, a ordem pode pular o slot para evitar prejuízo. Link "Saiba mais" abre documentação externa. "Compre CAKE → $1.518" persiste no rodapé.

🟢 Insight: o alerta inline de "ordens limitadas podem não ser executadas perto do preço limite" é declaração honesta de constraint econômica que afeta a maioria das ordens TWAP+Limite na prática. Ninguém configura preço-alvo MUITO distante do mercado (não executa nunca); a tendência é configurar próximo (onde o custo de execução engole o lucro). Pancake reconhece isso publicamente, antes do gas pago — trust signal forte. Tratamento didático bem-calibrado.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): o alerta diz que a ordem PODE NÃO executar perto do preço limite, mas não quantifica "perto" — quão perto? 0.1%? 1%? Sem âncora, o iniciante lê e fica em dúvida ("meu preço-alvo está dentro da zona de risco?"). Pior: o sub-bloco "Lucro 0.0%" já está exatamente no estado de risco (preço-alvo = mercado), mas o alerta é estático — não fica vermelho ou destacado quando o usuário está justamente no caso problemático. Solução óbvia que falha: definir um threshold fixo ("abaixo de 0.5% é zona de risco") esconde que o threshold real depende do gas/fee do momento. Alternativa: alerta dinâmico — quando o delta vs mercado entra na zona crítica, copy muda para "⚠ Seu preço-alvo está a +0.0% do mercado — provavelmente o custo de execução vai impedir a ordem. Sugerimos pelo menos +0.5% ou +1%.". Cor vai para amber/vermelho. Trade-off: precisa estimativa de gas/fee em tempo real; ganho é o alerta deixar de ser aviso genérico e virar guia.

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário): "Saiba mais" é link genérico — abre documentação externa (presumível) onde o iniciante precisa decifrar parágrafos de tech docs. É padrão de "jogar a responsabilidade educacional para fora". Para target Kotai (iniciante/intermediário), isso quebra o fluxo. Solução óbvia que falha: inline com tudo polui demais. Alternativa: mini-explicação progressiva — clique em "Saiba mais" abre side-panel ou bottom-sheet dentro do produto com 3-4 parágrafos curtos + exemplo concreto ("Suposição: gas atual ~$2, fee Orbs 0.1%, swap fee 0.25% — ordem precisa de ao menos $X de margem para valer"). Trade-off: design de side-panel; ganho é manter o usuário dentro do contexto.

🔴 Fricção 3 (cosmética — afeta iniciante): o footer institucional aparece logo abaixo do widget, sem separação visual forte. O usuário que rolou a página para ver os campos de Intervalo/Duração pode confundir "Compre CAKE → $1.518" com botão da operação TWAP que está configurando. Especialmente porque "Compre CAKE" é botão de ação claro, próximo do CTA "Insira o valor". Solução óbvia que falha: aumentar espaçamento resolve só visualmente. Alternativa: divisor explícito + label "PancakeSwap" antes do footer, sinalizando que sai da feature. Trade-off: trivial.

🟡 Oportunidade competitiva (alta leverage no target — alerta de viabilidade econômica em tempo real para ordens condicionais): toda DEX que oferece Limite/TWAP enfrenta o mesmo problema (custos de execução podem matar a ordem perto do alvo), e todas tratam o assunto como nota de rodapé estática ou documentação externa. Pancake já avançou (alerta inline), mas é estático. Passa as 4 perguntas: (1) padrão é nota estática ou docs; (2) afeta diretamente iniciante/intermediário — é o motivo número 1 de "minha ordem nunca executou"; (3) ninguém resolveu por falta de investimento em estimativa econômica em tempo real, não dificuldade técnica; (4) ver o alerta mudar de cor + recomendar margem mínima é claramente perceptível. Diferenciação Kotai: módulo de viabilidade econômica que estima gas + fees no momento da criação e mostra "margem mínima recomendada" — número derivado, não opinião. Idealmente, sugere preço-alvo recomendado ("Sugerimos definir preço entre 415 e 418 CAKE para garantir execução") com 1 clique para aceitar. Trade-off: dependência de oráculo de gas e telemetria histórica; ganho é a feature TWAP/Limite ter taxa de execução muito maior que a da concorrência — métrica que vira marketing.

Observação adicional ("Compre CAKE → $1.518" persistente no footer): já mencionado no relatório 21 do fluxo Comprar (canvas existente) — o CTA é cross-promo agressivo de token nativo. Aqui ele aparece bem ao lado do alerta de viabilidade, criando contraste irônico: "sua ordem pode não executar por causa de fees, mas compre nosso token agora". Em Kotai, vale evitar que CTAs de marca/cross-promo apareçam adjacentes a alertas de risco — quebra confiança.

Codex Consolidado — TWAP (pancake)

Caráter geral do fluxo

O TWAP da Pancake é tecnicamente honesto, mas cognitivamente fragmentado. A interface expõe regras importantes: execução parcial ou nula, piso econômico por execução, limites temporais, preço limite, dependência da Orbs e riscos de inviabilidade. O problema recorrente não é ausência absoluta de informação; é que a informação aparece em tooltips, estados abertos, alertas genéricos ou números derivados sem recompor o plano final para o usuário.

Para iniciante/intermediário, TWAP exige entender fracionamento temporal, saldo, preço-alvo, execução condicional, tamanho mínimo e duração. A UI trata esses conceitos como campos independentes, quando na prática eles formam um contrato operacional: quantas execuções vão rodar, em qual janela, com qual tamanho, sob quais condições e o que pode impedir a ordem. O fluxo fica mais seguro quando transforma parâmetros técnicos em frase, preview e próxima ação.

🟢 Insights recorrentes

A Pancake prefere transparência técnica a simplificação excessiva. Tooltips e alertas em tela 1, tela 2, tela 3, tela 4 e tela 8 mostram que o produto não esconde constraints críticas. Isso é um bom ponto de partida: o sistema reconhece risco real, execução parcial, piso mínimo e viabilidade condicional.

Editar e revisar pedem superfícies diferentes. Em tela 10 aparecem atalhos 25% / 50% / MAX durante foco; em tela 11, o estado fechado prioriza saldo. O insight é correto: durante edição, o usuário precisa de velocidade; na revisão, precisa de conferência. A falha está na troca silenciosa e na perda de continuidade, não na intenção do padrão.

A dependência da Orbs é exposta como sinal de infraestrutura. Em tela 1 e tela 3, “Powered by Orbs” e a explicação do mecanismo tornam o terceiro visível. Isso pode funcionar como trust signal para avançados, embora ainda precise ser traduzido para usuários que não sabem avaliar risco de execução terceirizada.

🔴 Fricções recorrentes

Campos temporais ficam ilegíveis no estado fechado. Intervalo e Duração aparecem como números crus em tela 1, tela 3, tela 4, tela 5 e tela 6. “2” ou “4” não carregam sentido operacional sem unidade. A correção estrutural é renderizar valor composto no fechado: “2 min”, “2 h”, “4 dias”.

Dropdowns não confirmam a seleção atual. Em tela 5 e tela 6, Minutos/Horas/Dias aparecem sem checkmark, highlight ou seleção ativa. O usuário abre o controle para confirmar a unidade e continua sem resposta. O padrão adequado combina unidade inline no campo fechado e item selecionado marcado no aberto.

Inputs acoplados são apresentados como independentes. Total de negociações, tamanho por negociação, intervalo, duração e preço limite interagem entre si, mas a UI distribui cada campo como se bastasse editar isoladamente. Isso aparece no piso mínimo por execução em tela 2, na regra temporal em tela 4, na incoerência Intervalo > Duração em tela 6 e no ajuste automático de execuções em tela 10. O usuário precisa de feedback derivado, não de bloqueio prematuro.

Constraints críticas aparecem tarde, escondidas ou sem recomposição. Regras essenciais estão em tooltip, hover, dropdown ou alerta genérico em tela 1, tela 2, tela 3, tela 4 e tela 8. Para regras que mudam validade, custo ou execução da ordem, tooltip é documentação escondida. Elas precisam aparecer junto ao campo ou no resumo derivado.

Estados avançados entram sem microcontexto. TWAP aparece ao lado de Swap e Limite em tela 1, e a primeira visita em tela 9 expõe Total, Tamanho, Intervalo, Duração e Preço limite sem uma linha de orientação. Quando Preço limite é ativado em tela 7, surge um novo bloco sem explicitar a consequência operacional. O problema não pede tour; pede copy curta e persistente no ponto de complexidade.

A UI diagnostica risco, mas não entrega a próxima ação. Em tela 8, o alerta diz que ordens perto do preço limite podem não executar, mas não indica se o caso atual está crítico nem o que ajustar. Em tela 10 e tela 11, saldo insuficiente ou zero aparece enquanto o CTA ainda não vira uma resolução clara como “Adicionar BNB”, “Reduzir para saldo disponível” ou “Ajustar preço limite”. Com a evidência atual, isso fica como fricção/recomendação de produto, não como oportunidade competitiva promovida.

Números derivados aparecem sem causa visível. “Lucro 0.0%” em tela 7, alerta de proximidade ao preço limite em tela 8 e ajuste para 6 execuções em tela 10 são cálculos úteis, mas sem explicação causal suficiente. O usuário vê o resultado, não a regra.

🟡 Oportunidades competitivas do fluxo

Preview executável do plano TWAP. Evidência em tela 1, tela 4, tela 6 e tela 10. O diferencial é recompor os campos em uma frase viva: “Executar 5 vezes de 2 BNB, a cada 1h, por até 5h”. Quando houver conflito: “Você pediu 10 execuções; com esta duração, só 2 podem disparar. Ajuste para 20h ou reduza para 2 execuções.” Passa a régua porque resolve recorrência comprovada, afeta usuários não avançados, é implementável por cálculo/copy e o ganho é imediatamente perceptível.

Como subprincípio desse preview, parâmetros automáticos e derivados precisam carregar justificativa inline. Evidência em tela 2, tela 3, tela 4, tela 7, tela 8 e tela 10. Quando o sistema calcula lucro, margem, número de execuções ou mínimo por fatia, precisa dizer a razão no próprio resumo: “ajustado para 6 execuções porque cada execução precisa ser ≥ $100”. Assim, a explicação deixa de ser oportunidade separada e passa a ser parte do mecanismo competitivo principal.

Pontos isolados (1 tela)

• Tela 2: mínimo em USD com input em BNB obriga conversão mental. Melhor mostrar unidade dupla: “0,12 BNB (~$50 — abaixo do mínimo de $100)”.
• Tela 3: vocabulário como “leilão de ofertantes” e “liquidação de blocos” é preciso, mas opaco para iniciante. Melhor tooltip em dois níveis.
• Tela 5: mudar de minutos para dias preserva o mesmo número e não comunica salto de escala. Cabe microfeedback de mudança.
• Tela 7: “Definir taxa de mercado” é affordance fraca para resetar ao spot; “Voltar ao preço de mercado” com ícone de reset seria mais claro.
• Tela 8: “Saiba mais” desloca explicação crítica para documentação externa; melhor side-panel ou bottom-sheet com exemplo numérico curto.
• Tela 8 e tela 9: footer institucional e “Compre CAKE” ficam próximos demais da operação, criando ruído de confiança.

Nota de auditoria Codex

Consolidação feita somente a partir dos drafts fornecidos. Hipóteses não promovidas: viabilidade econômica em tempo real para ordens condicionais, micro-onboarding como oportunidade competitiva ampla, saldo da wallet como ação integrada e decomposição entre input do usuário versus overhead do sistema. Todas são promissoras, mas os próprios drafts pedem validação cross-lote/concorrencial antes de subir para oportunidade.

Nota técnica do fix: o review apontou anchors de bloco inexistentes nas referências do consolidado. Como este runner deve gravar apenas o consolidado e não alterar os .md individuais, as referências foram mantidas embutidas na menção de tela, mas sem #^block-id, preservando navegação por arquivo e evitando links para blocos inexistentes.

14. Aba "Transações" — Feed on-chain carregado

Função: Feed cronológico de todas as transações do pool — swaps, aportes e remoções de liquidez. Permite ao usuário inspecionar atividade real do pool, identificar tendências e auditar movimentos.

Componentes: header reduzido do pool + gráfico Volume + sidebar inalterada; tabs "Minhas posições"/"Transações" (Transações ativa); sub-filtros "Tudo / Trocas / Adiciona / Remove" (Tudo ativo); cabeçalho da tabela com colunas ordenáveis "VALOR DA TRANSAÇÃO ↑↓" / "CONTA ↑↓" / "TEMPO ↑↓" e tooltips "ℹ"; 10 linhas — cada uma com "Swap BTCB for USDT" + ícone link externo, valor principal ($3,38K / $4,2K / $8K / $5,54K / $1,46K / $4,09K / $1,77K / $3,08K / $3,36K / $8,47K) com sub-linha "X USDT, Y BTCB", endereço truncado tipo "0xf197...774A" com ícone explorer, e "3 minutes ago"; paginação "Page 1 of 14" no rodapé.

Regras de negócio: dados vêm do subgraph em ordem temporal reversa. Filtros aplicam predicado por tipo de evento. Cada linha é clicável para o explorer (Bscscan/etc.) via o ícone link. A coluna CONTA mostra a wallet do executor truncada. Pool com 14 páginas indica volume significativo de transações.

🟢 Insight: feed on-chain com filtros por tipo de evento é arquitetura correta — separar Swaps de Aportes/Remoções é exatamente como o intermediário/avançado raciocina sobre atividade de pool. Ordenação por todas as colunas + link direto ao explorer respeitam o mental model de quem audita on-chain. Para target avançado, essa transparência é diferencial sobre CEX.

🔴 Fricção 1 (estrutural — afeta iniciante): linhas em inglês dentro de UI PT-BR — "Swap BTCB for USDT", "3 minutes ago", "Page 1 of 14". Localização incompleta sistêmica (mesma fricção já apontada em R1 Limite, R5 Comprar). Iniciante BR perde leitura natural; intermediário percebe inconsistência e perde confiança. Alternativa: "Trocou BTCB por USDT" / "há 3 minutos" / "Página 1 de 14". Trade-off: nenhum — é correção obrigatória.

🔴 Fricção 2 (estrutural — afeta iniciante): coluna "CONTA" com endereço truncado (0xf197…774A) é jargão técnico puro. Iniciante BR vindo de CEX nunca leu hash de carteira e não decodifica. Diagnóstico errado: esconder coluna — perde transparência on-chain que é valor central de DEX. Alternativa: coluna colapsável por default no "modo simples" do produto (toggle), expandível no "modo técnico"; manter ícone discreto "Ver no explorer" mesmo no modo simples para quem quiser auditar.

🔴 Fricção 3 (cosmética — copy): sub-tabs "Tudo / Trocas / Adiciona / Remove" — "Adiciona" e "Remove" são conjugações verbais no presente, não substantivos. Quebra o paralelismo com "Trocas" (substantivo plural). Alternativa: "Tudo / Swaps / Aportes / Remoções" ou "Tudo / Trocas / Adicionar / Remover" — escolher um padrão e aplicar.

🔴 Fricção 4 (cosmética): valores como "$3,38K", "$4,2K" usam vírgula como separador decimal (PT-BR correto), mas "K" como abreviação é convenção EN. Mistura. Alternativa: "$3,38 mil" (PT-BR puro) ou aceitar "K/M/B" como vocabulário cripto internacionalizado e padronizar em todo o produto.

🟡 Oportunidade competitiva: feed on-chain transparente é valor distintivo de DEX vs CEX, mas a leitura é completamente técnica em todos os DEX (Uniswap, 1inch, Curve, Pancake idem). Critério: ✓ todos fazem igual, ✓ afeta iniciante (curiosidade saudável, mas barreira de entrada), ✓ razão é falta de investimento em camada narrativa (dado existe), ✓ ganho perceptível. Diferencial: modo "narrativo" opcional — cada linha como frase humana ("Há 3 min, uma carteira trocou US$ 3,38 mil — 3.382 USDT por 0,041 BTCB"), com link discreto para o explorer. Toggle "simples/técnico" persistente. Trade-off: dois layouts para manter; ganho de inclusão alto.

Observação adicional: várias transações são da mesma carteira em poucos minutos (0xFa5d…02EE aparece duas vezes consecutivas) — comportamento típico de bot/MEV. Para o avançado isso é leitura natural; para iniciante/intermediário é ruído sem contexto. Diferencial possível: badge "Bot/MEV" inferido por heurística (frequência alta, padrão de execução) — ajuda iniciante a entender que parte do "volume" do pool não é atividade humana.

12. Aba TVL — Hover ativo

Função: Estado de hover sobre o area chart de TVL. Revela TVL exato de um instante específico do período visível.

Componentes: mesmo area chart; header atualiza — "$19,46M" + data "May 5, 2026 (UTC)" (em vez do valor atual $19,66M e range completo); tooltip flutuante "May 5, 2026, 04:00 AM UTC" + "$19,46M"; cursor vertical sutil ancorando o ponto.

Regras de negócio: mesmo pattern de scrub das abas Volume e Taxas — header dinâmico + tooltip + cursor. Granularidade do ponto = 1 hora (consistente com range D que mostra 24h).

🟢 Insight: padrão de scrub consistente entre Volume, Taxas e TVL — mesmo header dinâmico, mesmo posicionamento de tooltip, mesmo cursor. Coerência interna que reduz custo cognitivo: o usuário aprende uma vez e aplica em todas as abas. Granularidade horária bate com o range Day, sem confusão (diferente do R10 que tinha desencaixe).

🔴 Fricção 1 (estrutural — afeta iniciante): o tooltip mostra apenas o valor pontual ($19,46M) sem delta vs início do range ou vs valor atual. Iniciante hovers para "explorar variação" e não vê variação — só números absolutos sucessivos. A interpretação requer cálculo mental ($19,66M atual − $19,46M hovered = -1,0%, etc.). Diagnóstico errado: adicionar mini-gráfico — polui. Alternativa: tooltip com 2 linhas — "$19,46M • -1,0% vs início do range". Trade-off: tooltip cresce um pouco; ganho informacional alto.

🔴 Fricção 2 (estrutural — herdada do R11): a variação $19,66M → $19,46M é ~1%, mas o gráfico (eixo iniciando em $0) não comunica a queda visualmente. O hover revela um número diferente do header, mas o usuário precisa confiar nos números porque o desenho não traduz. Alternativa: mesma do R11 — auto-zoom contextual no eixo Y.

🔴 Fricção 3 (cosmética): ao tirar o mouse o header deve voltar ao "valor atual + range completo", mas o comportamento exato no mouseleave não é confirmável pela captura estática. Se voltar, OK; se persistir o último valor hovered, fica ambíguo. Alternativa: sempre retornar ao default no mouseleave.

🟡 Oportunidade competitiva: tooltip de série temporal sem delta vs início do range é convenção universal — Uniswap, Curve, DefiLlama todos mostram só valor absoluto. Critério: ✓ todos fazem igual, ✓ afeta iniciante (não consegue ler variação), ✓ falta de investimento em microcopy do tooltip, ✓ ganho perceptível. Diferencial: tooltips de scrub sempre com valor + delta contextual (vs início do range, vs valor atual, ou vs período anterior — escolha consistente). Aplica em todas as abas (Volume, Taxas, TVL, Liquidez).

Observação adicional: R7→R12 confirmam que o produto tem boa coerência interna de scrub (mesmo padrão em três abas diferentes) mas fricções herdadas (escala iniciando em $0, ausência de delta no tooltip, hover-only inacessível em mobile, par com preço minúsculo sem auto-flip). Essas fricções são sistêmicas — corrigir uma vez resolve em todas as abas.

13. Aba "Minhas posições" — Estado vazio

Função: Lista as posições de liquidez do usuário neste pool específico. No estado vazio (sem carteira conectada ou sem posições), comunica ausência.

Componentes: página completa do pool visível (header, gráfico Volume, sidebar de métricas, CTA "Adicionar liquidez"); tabs "Minhas posições" (ativa) e "Transações" (inativa); abaixo das tabs, área grande com apenas o texto centralizado "Nenhuma posição encontrada" — sem ilustração, sem CTA, sem indicação de próximo passo, sem chip de estado da carteira; rodapé do site logo abaixo (links de navegação, ECOSSISTEMA, BUSINESS etc.).

Regras de negócio: lista é populada filtrando posições NFT V3 da carteira conectada que pertencem ao pool atual. Estados possíveis: (a) sem carteira conectada, (b) carteira conectada em rede diferente, (c) carteira conectada na rede correta mas sem posições neste pool, (d) carregando. A UI atual não distingue entre os 4 cenários — todos caem em "Nenhuma posição encontrada".

🟢 Insight: o empty state é textual e explícito em PT-BR — supera o R6 (que era apenas ilustração de panelas). Pelo menos o usuário entende que não há posições, sem ambiguidade entre "carregando" e "vazio".

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): mensagem descritiva mas não acionável. Não diz por que está vazio (carteira não conectada? rede errada? simplesmente sem posição neste pool?), nem como criar uma posição. Iniciante que abriu o pool buscando "ver minha posição" ou "começar a ter uma" cai em dead-end emocional. Diagnóstico errado: trocar por "Conecte sua carteira" fixo — pode estar conectado e simplesmente sem posição. Alternativa: empty state inteligente baseado no estado da carteira:

• Sem wallet → "Conecte sua carteira para ver suas posições" + CTA "Conectar"
• Wallet em rede errada → "Sua carteira está em [outra rede]. Troque para BNB Chain"
• Wallet conectada sem posição neste pool → "Você ainda não tem posições aqui. Adicionar liquidez para começar" + CTA "Adicionar liquidez"

Trade-off: exige condicional simples sobre estado conhecido — custo de engenharia baixo, ganho de orientação alto.

🔴 Fricção 2 (estrutural — afeta iniciante): o CTA "Adicionar liquidez" existe no card lateral, mas o empty state não reforça onde clicar. O usuário tem que descobrir sozinho que o caminho para "ter posição" está num botão à direita. Alternativa: link inline no próprio empty state ("Adicionar liquidez →") apontando para a mesma ação.

🔴 Fricção 3 (cosmética): área vazia ocupa 100% da largura sem hierarquia — funciona como filler que empurra o rodapé para próximo. Alternativa: card compacto centralizado com ilustração pequena, texto e CTA — empty state vira componente, não filler.

🟡 Oportunidade competitiva: empty states informativos e acionáveis baseados em estado de carteira são raros — Uniswap, Curve, 1inch mostram "No positions" estático sem cura. Critério: ✓ todos fazem igual, ✓ afeta iniciante e intermediário (são justamente os que mais tropeçam aqui), ✓ razão é falta de investimento em microcopy condicional (não impossibilidade técnica), ✓ ganho perceptível imediato. Diferencial: sistema padronizado de empty states condicionais aplicado em todo o produto, não isolado nesta tela.

9. Aba Taxas — Série anual

Função: Visão histórica da receita do pool em taxas (fees orgânicas) ao longo de um período longo. Permite ao LP avaliar consistência de geração de receita, não apenas snapshot recente.

Componentes: abas Volume/Liquidez/Taxas/TVL (Taxas ativa); header com valor agregado "$4,69M" + range "May 4, 2025 – May 4, 2026 (UTC)" (= 365 dias); bar chart denso com ~365 barras verticais (taxa por dia), spikes visíveis em alguns dias (notadamente em fevereiro); eixo Y direito com escala $0 / 25K / 50K / 75K / 100K; ausentes nesta aba os controles de range "D/W/M/Y" que aparecem em Volume, Liquidez e TVL.

Regras de negócio: taxa do pool = soma de fees pagas pelos swappers no período. Em V3 0,05%, a taxa coletada vai aos LPs proporcionalmente à liquidez ativa no range em que o swap ocorreu. A série longa permite identificar volatilidade e sazonalidade.

🟢 Insight: agregar taxas em janela anual é diferencial — a maioria dos DEX mostra só 24h/7d, sem visão de consistência. Para LP que está decidindo aportar capital, ver "este pool gerou $4,69M em 12 meses, com pico em fevereiro" é informação estratégica que muda a decisão.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): ausência dos controles D/W/M/Y nesta aba quebra o pattern das outras abas (Volume, Liquidez, TVL têm o seletor visível). Usuário tenta achar e não acha. Pode estar abaixo do fold ou simplesmente não existir aqui. Diagnóstico errado: assumir bug específico — pode ser convenção interna desta aba. Alternativa: controles consistentes em todas as abas; se o default anual é proposital, deixar "Y" pré-selecionado mas com os outros visíveis. Trade-off: ajustar o componente para herdar o controle global.

🔴 Fricção 2 (estrutural — afeta iniciante): 365 barras no mesmo eixo torna o gráfico denso demais para leitura. Spikes ofuscam o baseline; iniciante não consegue ler dia individual. Diagnóstico errado: zoom default — perderia o ganho do macro. Alternativa: overlay de média móvel (linha) sobre as barras + range default 90d com Y como opção. Trade-off: mais componentes no chart; legibilidade compensa.

🔴 Fricção 3 (cosmética): sem hover ativo nesta captura, não há tooltip nem cursor visível. Confirma que o drill-down é hover-only (problema replicado de outras abas) — mobile perde de novo.

🟡 Oportunidade competitiva: a visão de série anual de taxas já é diferencial sobre Uniswap/Curve. O que falta é a leitura ser confortável — micro-controles de zoom, smoothing, comparativos. Critério: ✓ ninguém entrega bem (Pancake entrega meio), ✓ afeta intermediário/LP, ✓ falta de investimento em UX de série temporal, ✓ ganho perceptível para quem decide aportar. Diferencial: gráfico com média móvel + brush de zoom + comparativo com mediana de pools similares.

10. Aba Taxas — Hover ativo

Função: Estado de hover/scrub sobre uma barra específica do gráfico anual de taxas. Revela receita daquele ponto temporal específico.

Componentes: mesmo gráfico anual de barras; header atualizou — agora mostra "$83,67K" (valor do ponto) + data "Feb 4, 2026 (UTC)" (em vez do total anual e range completo); tooltip flutuante próximo ao cursor com "Feb 4, 2026, 21:00 PM UTC" + "$83,67K"; spike grande visível atrás do tooltip (corresponde ao bin hovered).

Regras de negócio: scrub temporal — ao passar o mouse sobre uma barra/ponto, o header reflete o valor daquele instante. O comportamento parece reutilizado das abas Volume e TVL (mesmo padrão de "header dinâmico").

🟢 Insight: header dinâmico durante hover é boa UX — o usuário lê o valor sem precisar olhar o tooltip e o gráfico ao mesmo tempo. Padrão consistente entre as abas (mesma técnica aparece em Volume e TVL), o que reforça previsibilidade.

🔴 Fricção 1 (estrutural — afeta iniciante): o header perde o valor agregado ao ativar o hover. O usuário entra na aba vê "$4,69M anual", passa o mouse para explorar, e perde a referência principal — agora vê "$83,67K". Iniciante pode esquecer que o valor original era anual e interpretar $83,67K como o total. Diagnóstico errado: voltar ao default no mouseleave — já faz isso, mas durante o hover a ambiguidade existe. Alternativa: manter dois números no header — total fixo (sempre visível) + valor do ponto hovered como secundário ao lado. Trade-off: header maior; ganho de contexto compensa.

🔴 Fricção 2 (cosmética — copy): "Feb 4, 2026, 21:00 PM UTC" — formato redundante. "21:00" já indica PM em horário militar; "PM" sobra. Pode ser bug de localização (string montada para 12h e exibida em 24h). Alternativa: "Feb 4, 2026 21:00 UTC" ou "Feb 4, 2026 9:00 PM UTC" — escolher um sistema e ser consistente.

🔴 Fricção 3 (estrutural): granularidade inconsistente. O gráfico parece ter 1 barra por dia (365 barras / ~1 ano), mas o tooltip mostra hora exata ("21:00 PM UTC"). Ou os dados são horários e estão sendo agregados por dia visualmente, ou o tooltip está mostrando o timestamp errado. Iniciante fica confuso se a barra é dia ou hora. Alternativa: alinhar — se a barra é diária, tooltip mostra "Feb 4, 2026 (dia inteiro)"; se é horária, manter hora.

🟡 Oportunidade competitiva: scrub temporal limpo, com header dinâmico que preserva o total agregado, é um padrão raro em DEX (Uniswap V3 mostra só o valor do ponto, sem manter o total). Critério: ✓ todos fazem incompleto, ✓ afeta iniciante (perde referência), ✓ falta de investimento em design do header, ✓ ganho perceptível. Diferencial: dois números no header durante scrub (total + ponto).

11. Aba TVL — Range D (Day)

Função: Histórico do Valor Total Bloqueado (TVL) no pool ao longo do tempo. Permite ao LP avaliar estabilidade do tamanho do pool, sinal de saúde e atratividade. View default em "D" (último dia).

Componentes: abas Volume/Liquidez/Taxas/TVL (TVL ativa); seletor de range "D / W / M / Y" presente (D selecionado, fundo roxo); header "$19,66M" + range "May 4, 2026 – May 5, 2026 (UTC)"; area chart turquesa cobrindo 24h em janelas horárias; eixo Y direito $0 / 5M / 10M / 15M / 20M; linha praticamente reta, oscilação visualmente imperceptível.

Regras de negócio: TVL = soma do valor em USD dos dois lados do pool no momento. Em V3, varia com (a) entradas/saídas de LPs e (b) variação de preço dos tokens. Em pares stable-correlatos como USDT/BTCB, oscilação esperada é baixa.

🟢 Insight: area chart é a escolha correta para TVL — comunica continuidade/estabilidade visualmente, diferente de bar chart que sugere eventos discretos. Default em "D" mostra estabilidade no curto prazo, leitura tranquilizadora para LP avaliando entrada. Os controles D/W/M/Y voltam a aparecer aqui (consistência com Volume e Liquidez), reforçando padrão.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): escala do eixo Y começa em $0 com max $20M, e o TVL real fica em $19,66M (~98% do max). Resultado: variações reais de 1–3% no TVL ficam visualmente invisíveis — a linha parece reta. Iniciante vê "constante" quando na verdade pode haver entradas/saídas significativas. Diagnóstico errado: aumentar a resolução do eixo manualmente — power user resolve, iniciante não. Alternativa: auto-zoom em janela ±5–10% do valor médio do período visível, com indicador visual claro de que o eixo não inicia em zero (linha de baseline tracejada com label "$19.6M"). Trade-off: pequena distorção perceptiva — mitigar com label explícito.

🔴 Fricção 2 (estrutural — afeta iniciante): TVL absoluto sem comparativo não diz nada. "$19,66M" é muito? pouco? comparado a quê? Iniciante não sabe se este pool é grande ou marginal. Diagnóstico errado: mostrar ranking — pune pools nichados. Alternativa: linha de referência opcional ("mediana de pools V3 0,05%") ou badge "Top X em TVL na categoria".

🔴 Fricção 3: ausência de variação % no período visível. O usuário vê o número atual mas não sabe se subiu ou caiu em D. (Existe "▲0,46%" no card lateral, mas é janela diferente e não vinculado ao seletor D/W/M/Y do gráfico.) Alternativa: label "início → fim do range: $X → $Y (±Z%)" próximo ao valor.

🟡 Oportunidade competitiva: escala iniciada em $0 em gráficos de TVL é convenção universal dos DEX (Uniswap, Curve, 1inch idem). Critério: ✓ todos fazem igual, ✓ afeta iniciante e intermediário (não percebem variação real), ✓ razão é convenção preguiçosa, não impossibilidade técnica, ✓ ganho perceptível imediato. Diferencial: auto-zoom contextual + baseline visível como padrão de visualização da casa.

9. Pools — "Minhas posições" + filtro "Ativo" + empty state ilustrado

Função: Volta para Farm/Liquidez → tab "Minhas posições" → filtro de status "Ativo" selecionado → empty state ilustrado. Estado mostra que o usuário não tem posições ativas (carteira não conectada, $0.00 no header).

Componentes: tabs "Todos os pools" / "Minhas posições" (ativa); CTAs "Criar Pool" + "Adicionar liquidez +"; filtro de rede "All networks +6", search, segmento Tudo/Infinity/V3/V2/StableSwap; filtros de status Tudo / Ativo (selecionado) / Inativo / Fechado, toggle "Apenas Farms" desligado, ícone de histórico; bloco central com ilustração de coelho amarelo agricultor + texto "Página vazia: nenhum resultado encontrado."

Regras de negócio: "Minhas posições" depende de carteira conectada — sem wallet, nunca há posições; filtro Ativo/Inativo/Fechado classifica posições por estado da liquidez (em range / fora de range / removida); ilustração é o mesmo recurso usado em outros empty states do produto (continuidade de personagem da marca).

🟢 Insight: a ilustração quebra com a frieza do skeleton da tela 1 ("Carregando…") — é uma escolha de tom que reduz o sentimento de "produto quebrado" em estado vazio. Personagem consistente (coelho Pancake) reforça marca em momento de baixa fricção, o que é o lugar certo pra investir em personalidade.

🔴 Fricção 1 (estrutural — afeta iniciante; recorrência do problema da tela 1): o empty state diz "Página vazia: nenhum resultado encontrado" — copy que sugere "filtrei algo e zerou", não "você não tem posição porque não conectou carteira". O iniciante que chegou na tela sem entender pré-condição lê "nenhum resultado" e conclui que o produto está vazio ou quebrado. Fix óbvio (mudar copy pra "Conecte sua carteira") só funciona se a wallet realmente estiver desconectada — precisa diferenciar 3 estados: (a) wallet desconectada → "Conecte para ver suas posições" + CTA; (b) wallet conectada sem posição → "Você ainda não tem posições. Veja pools disponíveis" + CTA "Ver pools"; (c) wallet com posição filtrada pra fora → "Nenhuma posição neste filtro" + CTA "Limpar filtros". A copy atual cobre os três como se fossem o mesmo caso. Fricção crítica porque é o primeiro contato com a área de posições — onde o iniciante decide se o produto serve pra ele.

🔴 Fricção 2 (cosmética — afeta todo perfil; recorrência da tela 1): os filtros completos (rede, search, segmento de versão, status, "Apenas Farms", histórico) aparecem na tela vazia. Não há o que filtrar entre Ativo/Inativo/Fechado em zero posições. Fix: ocultar filtros até existir ≥1 posição; reaparecem após a primeira. Mesmo diagnóstico que a tela 1, padrão sistêmico do produto.

🔴 Fricção 3 (estrutural — afeta iniciante): com wallet desconectada, a tela inteira ("Minhas posições" + filtros + empty state) é teatro — nenhum elemento funciona até conectar. Mas não há CTA de conectar carteira em lugar nenhum do conteúdo principal — só no header global ($0.00 dropdown). O iniciante precisa adivinhar que o produto exige conexão e descobrir o botão fora do bloco de trabalho. Fix: empty state assume papel de CTA de conexão quando wallet desconectada. Caso comum, mas convenção problemática — quase todos os DEXs erram aqui.

🟡 Oportunidade competitiva (alta leverage no target): empty state genérico para wallet desconectada é convenção em Uniswap, Sushi, Curve. Passa nas 4 perguntas: ✓ todos fazem igual; ✓ afeta iniciante direto (perde contexto na primeira tela onde tentaria buscar a própria posição); ✓ ninguém resolveu por falta de investimento em estados condicionais por contexto da wallet, não por impossibilidade; ✓ perceptível ("o produto me explicou que eu precisava conectar antes" vs. "achei que estava quebrado"). Diferenciação Kotai: empty states de "área pessoal" sempre detectam pré-condição faltante (wallet, rede, saldo) e oferecem CTA contextual, não copy genérico. Mesma oportunidade aplica a "Meu Portfolio", "Minhas ordens", "Histórico" — é padrão de produto, não fix de tela.

Observação adicional: "Apenas Farms" toggle continua disponível em "Minhas posições" — filtro pertinente apenas para o catálogo (existem farms entre pools), não para posições do usuário (ele já sabe se entrou em farm). Item de filtro que migrou entre tabs sem reavaliação de aplicabilidade.

8. Pools de Syrup — Dropdown "Classificar por" aberto

Função: Mesma página de Syrup Pools com card colapsado (estado "Detalhes" em vez de "Ocultar") e popover do controle "Classificar por" aberto, revelando as opções de ordenação. Estado mostra hover/click em "Quente" no topo do popover.

Componentes: controle "Classificar por" com valor atual "Quente" e chevron; popover branco com 5 opções verticais — APR, Ganho, Total em stake, Mais recente (e "Quente" presumivelmente no topo, fora do crop visível); card colapsado com 4 métricas em linha (FORU ganho / Total em stake / APR) e CTA "Detalhes ↓" no canto.

Regras de negócio: "Classificar por" tem 5 critérios, sendo "Quente" o default — provavelmente algoritmo proprietário (combinação de novidade + TVL + APR + featured). Demais critérios são objetivos e ordenáveis. Não há indicação visual no popover do que "Quente" significa; o usuário vê o nome sem critério explícito. Apenas uma pool ativa visível no momento, o que torna o ordenamento sem efeito prático — controle ativo em conjunto vazio.

🟢 Insight: ter sort dedicado em Syrup é certo — pools de stake têm trade-offs claros (APR vs. tempo restante vs. tamanho) e fixar uma única ordem cobriria mal o conjunto de intents. Manter o popover compacto (só nomes, sem ícones extras) respeita um controle que aparece tarde no fluxo de decisão.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): "Quente" como critério default é caixa-preta sem explicação. Para o iniciante, "Quente" sugere "popular" ou "em alta", mas não diz se é por TVL, por inflows recentes, por APR ou por curadoria — três coisas que mudam quem fica no topo. Sort default opaco é problemático porque é a ordem que define qual pool o iniciante considera primeiro. Fix óbvio (tooltip "?") explica mas mantém a opacidade no controle. Fix verdadeiro: renomear default para algo descritivo ("Recomendadas" + tooltip de critério, ou "Por TVL"), e deixar "Quente" como label visual ao lado dos itens que se qualificam (badge na linha), não como sort. Trade-off: produto perde alavanca pra promover pools — o que pode ser exatamente por isso que "Quente" existe como termo vago.

🔴 Fricção 2 (cosmética — afeta intermediário): o popover lista 5 opções sem agrupar por tipo (objetivo vs. proprietário). "APR / Ganho / Total em stake / Mais recente" são todos derivados de dados objetivos; "Quente" é critério editorial. Misturar os dois no mesmo nível visual sugere paridade que não existe. Fix: divisor + label de seção ("Métricas" vs. "Sugeridas"). Trabalho cosmético, mas reforça a confusão da fricção 1.

🔴 Fricção 3 (cosmética — afeta todo perfil): com apenas 1 pool ativa visível, o controle "Classificar por" não tem efeito perceptível — qualquer ordem produz a mesma tela. Mostrar controles que não fazem nada na configuração atual é ruído. Fix: desabilitar (ou ocultar) sort + busca quando o resultado é ≤1 item.

🟡 Oportunidade competitiva (média leverage no target): sort default editorial e opaco é convenção em produtos com inventário curado (Uniswap em "Featured", marketplaces em "Recomendados"). Passa nas 4 perguntas: ✓ convenção; ✓ afeta iniciante direto (acredita que "Quente" é avaliação neutra quando é editorial); ✓ não resolvido por falta de transparência intencional — produto se beneficia da opacidade; ✓ perceptível ("vi por que essa pool está em destaque"). Diferenciação Kotai: critério de ordenação default é sempre nomeado pelo que mede ("Por TVL", "Recomendadas pela editoria") e badges de curadoria são separados de ordenação. Trade-off: produto perde alavanca de merchandising; difícil de fazer sem reduzir cliques em pools featured.

Observação adicional: a sub-tab "Pools de Syrup" continua ativa apenas para essa seção e desaparece se o usuário voltar a Farm/Liquidez — comportamento contextual correto, mas reforça a observação da fricção 1 do relatório 1 (dois eixos de tab que o usuário precisa decodificar como matriz 2x2).

6. Detalhes do pool — Aba "Liquidez" + tabs "Minhas posições"/"Transações"

Função: Estado após o usuário clicar na aba "Liquidez" (saindo de Volume). Esperado: visualização da distribuição de liquidez do pool ao longo da curva de preços — a feature que diferencia V3 (concentrated liquidity) de V2. Adicionalmente, ao rolar, aparecem as tabs "Minhas posições" / "Transações" do usuário neste pool.

Componentes: header reduzido do pool (USDT/BTCB, 0,05%, v3, preço atual, APR EST.); abas Volume/Liquidez/Taxas/TVL (Liquidez ativa, sublinhado roxo); área central do gráfico vazia, com apenas duas panelas ilustrativas (uma em pé com panqueca, outra deitada vazia) — sem texto, sem mensagem de loading, sem call-to-action; sidebar direita inalterada (TVL, composição, Volume 24h, Taxa 24h, CTA "Adicionar liquidez"); ao final, novo bloco "Minhas posições" (ativo) / "Transações" (inativo), conteúdo cortado abaixo do fold.

Regras de negócio: em V3, a aba Liquidez tradicionalmente mostra a distribuição da liquidez concentrada por faixa de preço (histograma/curva) — é o dado mais importante para um LP escolher o range. As tabs "Minhas posições"/"Transações" filtram, respectivamente, posições próprias da carteira conectada e o feed de swaps recentes do pool. Como a carteira está com $0,00, "Minhas posições" provavelmente exibe vazio.

🟢 Insight: as tabs "Minhas posições"/"Transações" abaixo das métricas globais são o lugar correto arquitetonicamente — separam visão pública do pool (acima) de visão pessoal/histórica (abaixo). É o mesmo padrão de Uniswap, e funciona. A consistência da ilustração da panela como linguagem visual de "vazio/loading" reforça identidade.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário, alta prioridade): a aba "Liquidez" entrega apenas ilustração sem texto, sem dados, sem feedback. Não dá pra saber se está carregando, se não há dados ou se a feature simplesmente não foi implementada. Para V3 isso é grave: a visualização de distribuição de liquidez por faixa de preço é uma das principais razões para abrir o detail do pool — é como o LP decide qual range vai escolher. Uniswap V3 entrega isso, então é fricção específica do produto, não convenção da indústria. Diagnóstico errado: "atualizar o ilustrador" — não resolve a falta de conteúdo. Alternativa: entregar o gráfico de distribuição de liquidez ou, no mínimo, mensagem clara ("Visualização de liquidez indisponível para este pool" + razão) com link para o concorrente quando aplicável. Trade-off: implementar a visualização tem custo de engenharia real, mas é diferencial óbvio sobre não ter nada.

🔴 Fricção 2 (estrutural — afeta iniciante): ausência total de texto na área vazia. Ilustração sem copy = dead end emocional. O usuário não sabe se errou de aba, se a feature está em manutenção, ou se o produto realmente não suporta isso. Diagnóstico errado: adicionar spinner — não esclarece. Alternativa: título + 1 linha de explicação ("Gráfico de liquidez por faixa de preço" / "Carregando…" ou "Dados indisponíveis para este pool"). Custo desprezível, ganho grande.

🔴 Fricção 3 (cosmética — afeta intermediário): tabs "Minhas posições"/"Transações" aparecem abaixo do fold sem âncora visual no topo da página nem indicação de que existem. Iniciante que abre o pool buscando "ver minha posição" rola sem saber que precisa rolar até lá. Alternativa: chip/link "Suas posições neste pool (N)" no header, com scroll-to-anchor.

🟡 Oportunidade competitiva (modesta): comunicação de estados vazios em DEX é universalmente fraca — ilustração bonitinha sem mensagem. Critério: ✓ todos fazem igual (incluindo Uniswap em algumas telas), ✓ afeta iniciante, ✓ razão é falta de investimento em copy/microcopy de estados intermediários, ✓ perceptível. Diferencial: estados vazios sempre com título + razão + próxima ação possível, padronizados como sistema (não decoração isolada).

Observação adicional: o fato de a aba "Liquidez" estar vazia (vs "Volume" que renderizou bar chart corretamente em R2/R5) sugere que a feature pode estar parcialmente implementada ou falhando para este pool específico. Sem testar outras abas (Taxas, TVL) e outros pools não dá pra concluir se é bug pontual ou ausência sistemática da feature.

8. Aba Liquidez — Hover sobre um bin

Função: Estado de hover sobre uma barra específica do gráfico de distribuição. Revela as métricas daquele bin — preço da faixa, liquidez total em USD e quantidade de um dos tokens bloqueada.

Componentes: mesmo gráfico de bins; barra destacada com cor sólida (vs demais com opacidade reduzida); tooltip flutuante com três linhas — "Preço: 0,000012 BTCB per USDT", "Liquidez: $56.606,59", "BTCB Bloqueado: 0,69" (com ícone do token).

Regras de negócio: cada bin V3 contém uma fatia de liquidez aportada por LPs cujos ranges incluem aquele tick. A composição do bin varia conforme o preço — bins acima do preço atual têm mais do token de cima, bins abaixo têm mais do de baixo. O valor em USD é a soma dos dois lados na cotação atual.

🟢 Insight: o tooltip expõe três dimensões úteis (preço da faixa, liquidez em USD, quantidade do token bloqueada) e o destaque visual da barra com fade nas vizinhas é a melhor prática de scrub. Para LP que está estudando onde concentrar, é informação acionável.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): o tooltip mostra apenas BTCB Bloqueado, não USDT. Como o par é USDT/BTCB, cada bin contém quantidades dos dois tokens (proporção varia com a posição relativa ao preço atual). Mostrar só um lado tira metade da informação que o LP precisa para entender o que existe naquele tick. Diagnóstico errado: alternar qual token mostrar — confunde mais. Alternativa: três linhas — "USDT Bloqueado: X", "BTCB Bloqueado: Y", "Valor total: $Z". Trade-off: tooltip cresce; ganho informacional compensa.

🔴 Fricção 2 (estrutural): "0,000012 BTCB per USDT" repete o mesmo problema de legibilidade do R7. Inverter (USDT/BTCB) tornaria o preço da faixa um número humano. Mesma alternativa: auto-flip baseado em magnitude.

🔴 Fricção 3 (estrutural — afeta mobile): o drill-down depende inteiramente de hover. Mobile não tem hover preciso — usuário toca no bin e provavelmente perde foco rapidamente. Crítico porque esta é a feature principal para decidir range. Alternativa: tap-and-stick em mobile (toque seleciona, tap fora fecha) com indicador visual de "selecionado".

🟡 Oportunidade competitiva: Uniswap V3 também esconde um dos lados (mostra só o ativo dominante por bin). Critério: ✓ todos fazem igual, ✓ afeta intermediário/LP (target válido), ✓ razão é falta de investimento em exibição completa (cálculo é direto a partir do tick), ✓ ganho perceptível para quem está aportando. Diferencial: tooltip com composição completa dos dois tokens + valor USD por bin como padrão.

7. Aba Liquidez — Distribuição V3 carregada

Função: Visualização do gráfico de distribuição de liquidez do pool V3 por faixa de preço (bin/tick), ferramenta-chave para o LP decidir em qual range concentrar sua liquidez.

Componentes: abas Volume/Liquidez/Taxas/TVL (Liquidez ativa); indicador "● Preço atual" com texto "0,00001229 BTCB per USDT"; bar chart com bins verticais (turquesa), uma barra rosa marcando o bin do preço atual, range visível com eixo X mostrando valores ~0,000012 repetidos; eixo Y direito com escala $0 / $20.000 / $40.000 / $60.000 / $80.000; controles "+/-" pequenos no canto direito para zoom; tabs "Minhas posições"/"Transações" abaixo.

Regras de negócio: em V3, a liquidez é distribuída por faixas (ticks). Cada bin mostra o valor em USD concentrado naquela faixa. A barra rosa = faixa onde o preço está agora. O preço pode "atravessar" bins, ativando/desativando liquidez. Esta visualização é a ferramenta primária para definir o range de uma posição V3.

🟢 Insight (forte): Pancake entrega a visualização que é a feature crítica do V3 — bins por faixa de preço, marcador rosa indicando preço atual, distribuição visualmente clara. Para LP que vai decidir range, é exatamente a informação certa. Confirma que o R6 era loading/empty state intermediário, não ausência de feature.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): o eixo X mostra valores praticamente idênticos ("0,000012" repetido em todas as posições) porque o preço BTCB/USDT é minúsculo. Iniciante não consegue ler a diferença entre bins, embora cada um seja uma faixa distinta. Diagnóstico errado: aumentar casas decimais — pioraria a ilegibilidade. Alternativa: inverter automaticamente para "USDT por BTCB" (mesma lógica do R2) — os bins viram números humanos (~81.000 a 82.000 USD/BTCB). Trade-off: usuário precisa converter mentalmente se quiser raciocinar "em BTCB", mas a leitura primária fica útil.

🔴 Fricção 2 (estrutural — afeta iniciante): ausência de legenda explicativa nos eixos. "$80.000 / $60.000…" no Y é valor de liquidez por bin em USD, mas não está rotulado — iniciante pode interpretar como preço do token. Diagnóstico errado: tooltip global — não comunica em scan rápido. Alternativa: label do eixo Y "Liquidez por faixa (USD)" + label do eixo X "Faixa de preço (USDT/BTCB)".

🔴 Fricção 3 (cosmética): controles "+/-" para zoom são minúsculos e sem tooltip — pouco descobríveis. Alternativa: controles maiores com label "Zoom de faixa" ou substituir por brush horizontal no próprio gráfico (drag-to-select).

🟡 Oportunidade competitiva: Uniswap V3, Pancake e demais V3 forks mostram o ratio nominal sem inverter automaticamente. Critério: ✓ todos fazem igual, ✓ afeta iniciante e intermediário (par com preço sub-1 vira ilegível), ✓ falta de investimento em auto-flip (operação trivial), ✓ ganho de leitura imediato. Diferencial: auto-flip baseado em magnitude do preço em todos os displays do produto (preço atual, gráfico, tooltip).

Observação adicional: o R6 mostrava esta mesma aba como ilustração vazia. Concluo que R6 foi estado de loading e a fricção principal apontada lá ("feature não implementada") era diagnóstico errado por evidência insuficiente — a feature existe e está bem executada. As fricções secundárias do R6 (sem texto no empty state, tabs abaixo do fold sem âncora) permanecem válidas.

5. Detalhes do pool — Tooltip do APR (hover sobre o card "APR EST.")

Função: Estado de hover sobre o card "APR EST. 17,18%". Revela a decomposição do APR em farm + taxa de LP, com nota explicativa sobre como o cálculo é feito e por que pode variar.

Componentes: tooltip dark posicionado sobre o card APR; lista decomposta — "APR combinada: 17,18%", sub-itens "APR da farm: 1,20%" e "APR da taxa de LP: 15,98%"; parágrafo 1 — "Os APRs são calculados usando a liquidez total no pool em comparação com o valor total da recompensa, os APRs reais podem ser maiores, pois parte da liquidez não está em stake ou dentro do range."; parágrafo 2 — "Os APRs para posições individuais podem variar dependendo do intervalo de preço definido."; ao fundo, o resto do layout permanece visível mas inativo.

Regras de negócio: APR combinada = APR da farm (incentivos CAKE) + APR da taxa de LP (fees orgânicas do pool). O número exibido assume liquidez total e dentro do range; APR real do LP pode ser maior porque (a) parte da liquidez não faz stake na farm e (b) em V3 parte da liquidez fica fora do range ativo. Para posições individuais, o range escolhido pelo LP é determinante.

🟢 Insight (forte): o tooltip já entrega a decomposição que iniciante precisa para confiar no APR — separa incentivo (farm) de rendimento orgânico (taxa de LP) com valores claros. Mais importante: explica honestamente que APRs reais podem ser maiores porque liquidez fora de range não rende, abordando diretamente a mecânica central do V3 (concentrated liquidity) sem maquiar. Isso é raro e correto — Uniswap mostra APR sem explicar mecânica, Curve idem.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): o conteúdo existe mas está escondido atrás de hover. Iniciante que precisa decompor o APR para decidir não sabe que essa informação está lá. A descoberta é acidental. Diagnóstico errado: substituir tooltip por badge — perde a explicação rica. Alternativa: decomposição (Farm + Taxa) sempre visível inline embaixo do número grande no card; tooltip permanece para o texto explicativo mais longo. Trade-off: card cresce verticalmente — mitigar usando dois números secundários menores na mesma linha.

🔴 Fricção 2 (copy — afeta iniciante): "parte da liquidez não está em stake ou dentro do range" assume que o usuário entende dois conceitos V3 simultaneamente — "stake na farm" e "range de preço". Iniciante perde a frase. Diagnóstico errado: encurtar e remover detalhes — perde precisão. Alternativa: simplificar para "parte da liquidez do pool não está ativa neste momento" + link "Como funciona o range em V3?" abrindo conteúdo educacional curto. Trade-off: exige conteúdo educacional próprio; ganho de compreensão é alto.

🔴 Fricção 3 (cosmética — copy): "APR combinada" com concordância feminina soa estranho — em PT-BR a sigla APR costuma ser tratada como masculino ("o APR"). Pequena, mas indica revisão de localização incompleta. Alternativa: "APR total" ou "APR combinado".

🟡 Oportunidade competitiva: mesmo conteúdo bom já existe no tooltip — a barreira é só a visibilidade. Indústria inteira (Uniswap, Curve, 1inch) esconde breakdown atrás de hover quando o oferece. Critério: ✓ todos fazem igual, ✓ afeta iniciante e intermediário, ✓ razão é falta de investimento em hierarquia visual, ✓ ganho perceptível imediato. Diferencial: decomposição visível por default, tooltip reservado só para o "como funciona". Confirma o que apontei no R2 — o problema não é falta de conteúdo, é falta de hierarquia.

Observação adicional: TVL e Volume 24h no card lateral também atualizaram entre R2 e R5 ($19,62M ▲0,46% vs ▲0,51%; $18,94M vs $18,91M). Confirma a oscilação contínua dos números sem timestamp/refresh explícito (apontado em outros relatórios).

7. Pools de Syrup — Card "Ganhar FORU" expandido + tooltip "Hora de término"

Função: Página de pools single-asset (Syrup Pools), tab "Pools de Syrup" ativa, com card único da pool ativa expandido ("Ocultar") e tooltip ao hover do ícone de relógio na linha "Termina em" mostrando data e hora exatas do fim da emissão.

Componentes: sub-tabs "Farm / Liquidez" / "Pools de Syrup" (ativa); hero "Pools de Syrup — Basta fazer stake de alguns tokens para ganhar. APR alto, baixo risco."; toggles de visualização (grid/lista), segmento Ativas/Antiga, toggle "Apenas em stake", "Classificar por" (Quente), busca "Pesquisar Pools"; card "Ganhar FORU — Stake Cake" com métricas (FORU ganho 0, Total em stake 1.449.415 Cake, APR 2,11%, Termina em 36 dias) e detalhes expandidos: APR, Stake máx. por usuário ~400 Cake, links "Ver informações do token", "Ver site do projeto", "Visualizar contrato", "Adicionar à carteira"; bloco "FORU GANHO" com CTA "Coletar" desabilitado; bloco "ATIVAR POOL" com CTA "Aprovar"; tooltip dark "Hora de término: 11 de jun. de 2026, 3:00 AM" cobrindo a linha "Stake máx. por usuário".

Regras de negócio: Syrup é single-asset (stake X, ganha Y) — diferente de Farm/Liquidez (dual-asset LP); "Termina em 36 dias" é janela de emissão fixa do token de recompensa, depois disso o APR cai a zero; "Aprovar" é approval ERC-20 prévio ao stake — duas transações no fluxo (approve + stake); "Coletar" só ativa quando há recompensa acumulada; "Stake máx. por usuário" limita exposição individual à pool — mecanismo anti-baleia comum em launchpools de token novo.

🟢 Insight: expor "Termina em 36 dias" + tooltip com data/hora absoluta é decisão certa — Syrup pool tem ciclo de vida finito e iniciante que vê só APR sem horizonte temporal pode entrar em pool que termina amanhã. A combinação relativo (36 dias) + absoluto no hover (11/jun/2026 3:00 AM) atende skim e checagem precisa no mesmo gesto.

🔴 Fricção 1 (estrutural — afeta iniciante; crítica): o hero declara "APR alto, baixo risco" como afirmação de marketing, não como propriedade derivada da pool em foco. Syrup pool com APR 2,11% pagando em token novo (FORU) não é nem "APR alto" nem "baixo risco" — o risco do token de recompensa (preço, liquidez, possibilidade de rug) determina o retorno real. Promessa de "baixo risco" no hero, em uma página onde a maior parte do risco está no ativo que o usuário recebe, é fricção estrutural — mina confiança quando o iniciante descobre, e fricção regulatória em jurisdições com regras de marketing financeiro. Fix óbvio (remover frase) deixa hero vazio. Fix verdadeiro: substituir por linha funcional ("Faça stake de um token, ganhe outro — janela limitada de emissão") e mover a tese de risco para o card de cada pool, derivada (não copiada) — Stake Cake é baixo risco no token staked; FORU é o risco real.

🔴 Fricção 2 (estrutural — afeta iniciante): o card empilha 7+ informações de status (FORU ganho, Total em stake, APR, Termina em, Stake máx., 4 links de "Ver…", 2 CTAs) sem hierarquia clara entre "o que eu preciso saber pra decidir" e "o que eu preciso saber pra agir depois de decidir". O iniciante chega no card e tem que ler tudo pra entender qual o próximo passo. Fix óbvio (esconder detalhes atrás de "Detalhes") perde a vantagem do expanded — esconde justamente o que importa antes da decisão (Stake máx., contrato). Fix verdadeiro: dois níveis dentro do expanded — bloco "Antes de stakar" (APR, Termina em, Stake máx., risco do token de recompensa) primeiro, bloco "Verificar" (links de contrato/site/explorer) depois, CTAs por último. Trade-off: card mais alto, mas leitura linear.

🔴 Fricção 3 (cosmética — afeta todo perfil): o tooltip "Hora de término" cobre parcialmente a linha "Stake máx. por usuário", que é informação crítica de decisão. Quando hover em um elemento esconde informação adjacente, o usuário precisa mover o cursor pra ler — gesto desnecessário em desktop. Fix: posicionar tooltip acima do ícone (não à direita), padrão consistente com tooltips de "?" da mesma família.

🟡 Oportunidade competitiva (alta leverage no target): sinalização de risco em pools single-asset com recompensa em token novo é convenção fraca em todos os concorrentes — APR exibido sem qualificação sobre o token de recompensa (líquido? listado em CEX? supply unlocked?). Passa nas 4 perguntas: ✓ todos os concorrentes; ✓ afeta iniciante direto (entra esperando 2,11% líquidos, sai com 2,11% de um token que perdeu 80%); ✓ ninguém resolveu por falta de investimento em scoring de risco do reward token, não impossibilidade; ✓ perceptível ("o produto me avisou que o token de recompensa é novo" vs. "saí no prejuízo sem entender"). Diferenciação Kotai: APR efetivo em USD com banda de incerteza baseada em volatilidade histórica do reward token + selo "Token novo / Token listado / Stable". Trade-off: classificar errado destrói confiança rápido; exige metodologia auditável.

Observação adicional: "Antiga" como segmento ao lado de "Ativas" é honestidade de produto (sinaliza pools de versão anterior), mas a palavra "Antiga" é vaga — não diz se é UI antiga, contrato antigo, ou ambos. Pequeno problema de copy.

11. Pools de Syrup — Tab "Antiga" (catálogo legado de pools v1 encerradas)

Função: Mesma página Syrup com tab "Antiga" selecionada, exibindo o catálogo histórico de pools Syrup v1 já encerradas. Header informativo: "Procurando pelos pools Syrup v1 de CAKE? Ir para a página de migração." Lista densa com ~20 linhas todas em estado terminal.

Componentes: segmento Ativas / Antiga (ativa); link de migração no topo; tabela com colunas Nome (Ganhar X — Stake Y), Token ganho (0 / 0 USD), Total em stake (em token base, ex: 82.147 Cake, 1.469.168 Cake, 904.411 Sigma, 4.323.835 WBAI), APR (0%), Termina em ("–"), CTA "Detalhes ▼"; ícone do par no início da linha; sem filtros de rede ou busca contextuais para essa tab.

Regras de negócio: "Antiga" agrega pools com janela de emissão encerrada — APR sempre 0% (não há mais reward), "Termina em" sempre "–" (já terminou); o capital pode continuar lá (Total em stake > 0 em todas) porque o usuário não sacou após o fim da emissão; é o cemitério visível do produto. Link de migração existe por uma versão v1 separada do CAKE staking que não foi automaticamente movida — uma das poucas migrações que o produto ainda mantém como friction necessária.

🟢 Insight: manter o cemitério acessível em vez de esconder é decisão de honestidade — usuário antigo que tem stake parado em pool morta precisa de caminho para sacar; esconder a tab criaria suporte. Reconhecer que pools encerradas seguem com capital ativo (não removido) é realismo sobre o comportamento real.

🔴 Fricção 1 (estrutural — afeta intermediário e avançado; o iniciante não chega aqui): "Termina em: –" + "APR: 0%" em todas as linhas é redundância — informação que diz "está encerrado" repetida em 4 colunas (nome implica histórico, APR 0%, termina em vazio, link de detalhes obrigatório). A tabela inteira poderia ser reduzida a "Pool X — Você tem N tokens parados → Sacar". Fix óbvio (esconder colunas vazias) ajuda mas mantém a tabela como inventário; o que o usuário precisa aqui é ação, não inspeção. Fix verdadeiro: trocar tabela por lista de cards de ação, ordenada por "Você tem capital aqui?" — pools com saldo do usuário primeiro com CTA "Sacar", pools sem saldo colapsadas em "Ver todas". Trade-off: exige wallet conectada pra filtrar; sem wallet, default vira o catálogo cru atual.

🔴 Fricção 2 (estrutural — afeta iniciante; armadilha de descoberta): o iniciante que chega via curiosidade ("o que é Antiga?") encontra ~20 pools com APR 0% e pode concluir que o produto inteiro está parado. Não há aviso explícito do tipo "Estas pools estão encerradas — só visíveis para quem precisa sacar capital antigo". Fix: header com tom mais firme ("Estas pools terminaram. Esta página existe para que você possa sacar fundos parados, não para entrar em novos stakes") + esconder a tab para wallets sem saldo herdado. Trade-off: descoberta cai (intencional aqui), e o produto admite explicitamente o legado — preço pequeno por clareza.

🔴 Fricção 3 (cosmética — afeta intermediário): o link "Ir para a página de migração" aparece como copy de header sem peso visual de aviso. Para usuário com saldo em Syrup v1 de CAKE, a migração é caminho crítico — perde se não percebe. Fix: banner persistente com CTA explícito, condicional a saldo detectado on-chain na versão v1.

🟡 Oportunidade competitiva (média leverage no target): quase nenhum DEX expõe seu cemitério explicitamente; a maioria esconde ou deixa em link de rodapé. Pancake exibe — é desvio positivo da convenção. Não passa nas 4 perguntas como oportunidade Kotai porque (a) afeta principalmente intermediário/avançado com capital herdado, não o target prioritário, e (b) já há transparência aqui — o ganho marginal é menor. Mantenho como observação de design, não diferencial estratégico.

Observação adicional: as pools estão ordenadas por critério opaco — "Quente" continua aplicado, mas "quente" em pools encerradas não significa nada. Outra ocorrência do problema do relatório 8: critério proprietário aplicado a contexto onde perdeu semântica.

10. Pools de Syrup — Card "Ganhar FORU" colapsado (segunda leitura, APR 0,90%)

Função: Mesma página Syrup, tab "Ativas", com card único colapsado (CTA "Detalhes ▼"). Diferença em relação à tela 7/8: a APR caiu de 2,11% para 0,90% e o "Total em stake" foi de 1.449.415 para 463.126 Cake — uma releitura da mesma pool em momento distinto da sessão.

Componentes: sub-tabs "Farm / Liquidez" / "Pools de Syrup" (ativa); hero "APR alto, baixo risco"; toggle grid/lista (lista selecionada), segmento Ativas (ativo) / Antiga, toggle "Apenas em stake", "Classificar por: Quente", busca; card horizontal "Ganhar FORU — Stake Cake" com 4 métricas (FORU ganho 0 / 0 USD, Total em stake 463.126 Cake, APR 0,90% + ícone calculadora, Termina em 36 dias + ícone relógio) e CTA "Detalhes ▼"; ilustração de coelho na base.

Regras de negócio: APR de Syrup é função de (emissão fixa de FORU por bloco) ÷ (total em stake) × preço — quando stake cresce, APR diminui mecanicamente; quando preço do reward cai, APR também cai. Total em stake não bate com leitura anterior (463k vs 1.4M) — sugere que entre as duas capturas houve unstake massivo ou snapshot de outro momento; em qualquer caso, o número exibido é volátil. "Termina em 36 dias" permanece igual — janela absoluta, não afetada por movimento de stake.

🟢 Insight: mostrar APR em tempo real (não congelada por sessão) é honestidade que evita decisão baseada em número estale. A coexistência do ícone de calculadora ao lado do APR sinaliza que o número é derivado, não fixo — convite à exploração que respeita a natureza dinâmica da métrica.

🔴 Fricção 1 (estrutural — afeta iniciante; reforço da fricção 1 da tela 7): o hero "APR alto, baixo risco" agora coabita com pool em APR 0,90% — promessa pública de "alto" sem âncora numérica vira contradição visível. Ou o hero está errado, ou o card está, ou o produto considera 0,90% "alto" relativo a algo não declarado. Fix: remover claim genérico do hero e mostrar faixa de APR observada no conjunto ("APRs entre 0,90% e 2,11% nos últimos 7 dias") — descritivo, não promissório. Trade-off: marketing perde headline; ganho é honestidade.

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário): o card não mostra histórico nem indicação de que o número exibido é instantâneo. Iniciante que viu 2,11% ontem e abre hoje em 0,90% conclui ou que o produto manipulou, ou que perdeu uma janela — quando o que aconteceu é apenas drift natural. Fix: badge de timestamp + delta ("APR 0,90% — caiu 1,21% nas últimas 24h") ou minissparkline ao lado do número. Trade-off: pode aumentar ansiedade do usuário sensível à volatilidade; ganho é capacidade de tomar decisão informada.

🔴 Fricção 3 (cosmética — afeta todo perfil): com apenas 1 pool ativa, todos os controles superiores (grid/lista, segmento, toggle "Apenas em stake", classificar por, busca) ficam aparentes mas sem efeito — mesmo padrão da tela 8. Fix: ocultar controles inertes quando o resultado é trivial.

🟡 Oportunidade competitiva (alta leverage no target; mesma do relatório 4): APR exibido como número pontual sem contexto temporal é convenção universal. Não repito a oportunidade aqui — já registrada no relatório 4. Esta tela reforça o caso: o mesmo produto exibiu duas APRs distintas para a mesma pool em duas leituras, sem nunca admitir o range ao usuário. Diferenciação Kotai válida para esta tela específica: APR sempre acompanhada de banda (7d/30d) e timestamp do último update.

Observação adicional: a contradição "APR alto, baixo risco" + "0,90%" é exemplo de como copy estático em hero envelhece pior do que copy derivado. Manter literal de marketing em página de inventário dinâmico é antipadrão — em produto sério, hero deve ser função do conjunto, não fixo.

6. Pools — Tooltip do kebab (hover em "...") com ação "Adicionar liquidez"

Função: Tooltip ao hover sobre o ícone kebab "..." da última coluna da linha do pool. Revela o rótulo da ação primária ("Adicionar liquidez") sem abrir o menu. Estado mostra hover na linha USDT/WBNB.

Componentes: ícone kebab em hover, tooltip claro (white) com label única "Adicionar liquidez" abaixo e à direita do ícone; restante da linha e tabela inalterados.

Regras de negócio: o kebab funciona como entrada para ações secundárias sobre a pool (no caso, "Adicionar liquidez" é o que o tooltip antecipa); o tooltip aparece antes do clique como pré-visualização do conteúdo do menu — comportamento de "preview de affordance". A coluna kebab fica colada à borda direita, depois de "Característica do pool" (vazia em 100% das linhas no estado capturado).

🟢 Insight: antecipar a ação primária do kebab via tooltip é decisão melhor do que o kebab típico (mistério até clicar). Reduz risco de clique exploratório e ajuda quem hesita em interagir com elementos ambíguos. Para um iniciante, "..." é convite ao desconhecido — anunciar "Adicionar liquidez" antes do clique diminui essa fricção.

🔴 Fricção 1 (estrutural — afeta iniciante): se a única ação do menu é "Adicionar liquidez", o kebab é abstração desnecessária — basta um botão direto na linha. O padrão kebab existe para esconder N ações secundárias atrás de um único affordance; com 1 ação, ele só adiciona um clique e um momento de incerteza. Fix óbvio (substituir kebab por botão "+" ou "Adicionar") expõe a ação mas pode quebrar consistência visual se outras linhas tiverem mais opções. Fix verdadeiro: investigar se outras pools têm 2+ ações no menu; se a maioria tem só 1, promover para botão inline e usar kebab só onde há overflow real. Trade-off: tabela mais larga; risco de inconsistência entre linhas (algumas com botão, outras com kebab).

🔴 Fricção 2 (cosmética — afeta todo perfil): com "Adicionar liquidez" também presente como CTA principal global no topo da tela (botão azul "Adicionar liquidez +"), a ação aparece em três níveis (CTA global, kebab por linha, e provavelmente dentro da página de detalhes). Sem contexto, o iniciante não sabe a diferença entre "Adicionar liquidez" global (escolho pool depois) e "Adicionar liquidez" por linha (já escolhi este pool). Fix: rotular o item do kebab como "Adicionar liquidez a este pool" — desambigua sem custo.

🟡 Oportunidade competitiva (baixa leverage no target): o padrão kebab para "ação única" é comum (Uniswap usa botão direto, Curve usa kebab, Sushi varia). Não passa fortemente nas 4 perguntas — afeta o usuário-alvo mas a diferenciação seria sutil ("preferi um produto porque o botão era mais óbvio") e fácil de copiar. Classificar como oportunidade aqui seria inflar a categoria. Mantenho como observação de design, não diferencial.

Observação adicional: o tooltip é light/branco enquanto os tooltips de APR e badge nesta mesma tela são dark. Inconsistência de token visual no mesmo contexto (hover em elementos da tabela) — provavelmente herança de componentes vindos de bibliotecas distintas. Não é fricção crítica, mas erodir consistência visual em pontos de decisão aumenta carga cognitiva de forma cumulativa.

Codex Consolidado — Pools (pancake)

Caráter geral do fluxo

Pools no Pancake é um fluxo rico em inventário e métricas, mas organizado mais como catálogo técnico do que como jornada de decisão. A interface expõe versões, tipos de pool, fee tiers, APR, filtros, estados pessoais, modos grid/lista e áreas legadas, porém frequentemente presume que o usuário já sabe converter esses sinais em ação. Para iniciante/intermediário, a pergunta central não é “qual métrica existe?”, mas “qual pool faz sentido para minha intenção, qual risco estou assumindo e o que devo fazer agora?”.

O padrão dominante é uma tensão entre precisão protocolar e clareza decisória. Pancake mostra bastante coisa correta, mas muitas vezes em camadas secundárias, com copy genérica ou em estruturas reaproveitadas fora de contexto. Isso aparece tanto no catálogo de LP quanto em Syrup Pools e estados pessoais.

🟢 Insights recorrentes

1. Há esforço real de transparência técnica, mas ele ainda não vira orientação.

O fluxo não esconde completamente os mecanismos: há badges de versão/taxa, split de APR, tooltips, colunas de TVL/APR, filtros e modos de visualização. Em tela 4, por exemplo, o APR é decomposto em farm e LP fee; em tela 14, a tabela consegue carregar parcialmente e manter células específicas em loading. O problema é que essa transparência fica mais descritiva do que decisória.

2. A plataforma tenta cobrir muitos casos de uso no mesmo sistema visual.

O mesmo fluxo abriga catálogo ativo, Minhas posições, Syrup, pools antigas, grid, tabela, filtros, ações de approve/stake e ações de liquidez. Isso dá amplitude ao produto, mas também revela onde uma arquitetura única não basta: áreas pessoais, legadas e catálogos ativos precisam de hierarquias diferentes.

🔴 Fricções recorrentes

1. Informação técnica aparece sem tradução por consequência.

Tags como V2, V3, CLAMM, stable, Infinity e fee tier aparecem como códigos autoexplicativos em tela 2, tela 3 e tela 14. Mesmo quando há tooltip, ele pode ser tautológico ou pouco acionável. O usuário recebe o nome do mecanismo, mas não a consequência prática: gestão de range, volatilidade relativa, previsibilidade, perfil de par ou risco operacional.

2. APR é usado como atração antes de ser contextualizado como estimativa variável.

Em tela 4, a ressalva decisiva sobre range V3 vem depois do número e do split técnico. Em tela 5, um APR alto em V2 aparece sem sinal de sustentabilidade ou risco. Em Syrup, a promessa “APR alto, baixo risco” em tela 7 entra em choque com a APR de 0,90% em tela 10. O número parece mais estável e comparável do que realmente é.

3. Camadas contextuais nem sempre são contextuais.

Tooltips e popovers aparecem como solução, mas parte deles não responde ao caso exato. O tooltip de versão/taxa em tela 3 apenas reformula o rótulo; em tela 5, a explicação menciona V3/bCAKE numa pool V2 sem farm; em tela 7, o tooltip cobre dado crítico. Quando a educação contextual é genérica ou atrapalha a leitura, ela reduz confiança.

4. Controles e colunas continuam visíveis quando não têm efeito ou semântica.

Filtros aparecem em empty states ou sem posições em tela 1 e tela 9. Sort, busca e alternância grid/lista seguem expostos com conjunto trivial em tela 8 e tela 10. Colunas vazias ou sem valor decisório aparecem em tela 2 e tela 14. A UI preserva a casca do catálogo mesmo quando o estado corrente pede outra prioridade.

5. Estados pessoais, loading e legado não diferenciam bem pré-condições.

“Minhas posições” não separa wallet desconectada, ausência real de posição e filtro sem resultado em tela 1 e tela 9. Loading inicial genérico em tela 13 não distingue busca, filtro vazio, espera de wallet ou fetch. Em tela 11, pools antigas ainda parecem catálogo, quando deveriam se comportar como área de recuperação/saque. Essa é uma fricção estrutural recorrente e uma recomendação de produto relevante, mas não foi promovida a oportunidade competitiva porque as fontes não demonstram rigidamente que todos os concorrentes principais preservam a mesma convenção.

6. A hierarquia entre decidir, verificar e agir fica embaralhada.

Em tela 7, APR, término, stake máximo, links e CTAs competem no mesmo bloco. Em tela 6, uma ação relevante fica atrás de kebab; em tela 12, “Aprovar” vira CTA primário, embora seja etapa técnica, não objetivo final do usuário.

🟡 Oportunidades competitivas do fluxo

1. Camada de intenção e risco acima do catálogo técnico.

Aparece de forma recorrente em tela 1, tela 2 e tela 14. Kotai pode diferenciar criando uma entrada por intenção: conservador, stable-stable, blue-chip, APR alto com risco explícito, ou estratégias que exigem gestão ativa. Isso ataca um padrão comum de DEXs, afeta diretamente iniciantes/intermediários, é resolvível com UX + metodologia de scoring e seria perceptível. O cuidado é não transformar curadoria em aconselhamento financeiro; a metodologia precisa ser visível e auditável.

2. APR contextualizado por fonte, tempo, range e risco.

A oportunidade é recorrente em tela 4, tela 5 e tela 10. Em vez de APR bruto como ranking, Kotai pode mostrar qualificação curta na própria linha/card: estimado, variável, depende do range, sem farm, reward token volátil, atualizado há X min, faixa 7d/30d. O ganho competitivo é confiança; o trade-off é reduzir conversão impulsiva em pools chamativas.

Recomendações de produto recorrentes

1. Estados condicionais para wallet, dados pessoais e listas sem ação.

A recorrência aparece em tela 1, tela 9, tela 11 e tela 13. Toda área “minha” deveria detectar a pré-condição faltante e oferecer CTA contextual; toda área legada deveria priorizar recuperação; todo loading deveria comunicar o estado real. É uma melhoria de produto mais estrutural que visual, e tende a reduzir suporte e abandono. Foi mantida fora de 🟡 porque as evidências disponíveis sustentam recorrência dentro do fluxo analisado, mas não comprovam, por si só, uma convenção problemática generalizada entre concorrentes.

Pontos isolados (1 tela)

• Em tela 1, “Farm/Liquidez” e “Pools de Syrup” competem com “Todos os pools/Minhas posições” no mesmo plano, misturando tipo de produto e visão de catálogo.

• Em tela 2, o seletor de redes é uma lista plana de nove redes, sem priorização por saldo, conexão ou uso provável.

• Em tela 8, “Quente” é default editorial opaco; não fica claro se mede TVL, APR, novidade ou curadoria.

• Em tela 11, migração v1 aparece com pouco peso visual apesar de poder ser caminho crítico para saldo legado.

• Em tela 12, o grid reduz métricas de decisão e aumenta peso operacional, favorecendo quem já decidiu em vez de quem está comparando.

• Em tela 13, filtros ativos durante loading podem gerar refetches sobrepostos ou flicker, exigindo cancelamento/lock de request.

Nota de auditoria Codex

Consolidado derivado exclusivamente dos drafts fornecidos. As oportunidades foram promovidas apenas quando apareceram em pelo menos duas telas/lotes ou quando os próprios drafts indicaram passagem explícita pelas perguntas-teste. Hipóteses mais localizadas, como separação approve/stake, rankings editoriais, recuperação de legado e estados condicionais para wallet/dados/listas, foram mantidas como fricções, recomendações de produto ou pontos isolados, não como oportunidade competitiva principal.

Para preservar a rastreabilidade sem apontar para blocos inexistentes, os wikilinks foram mantidos embutidos nas menções de tela e normalizados para as páginas-fonte. Anchors específicos de fricção/oportunidade foram removidos quando o review indicou missing_blocks ou desalinhamento semântico.

1. Detalhes do pool — Estado de loading

Função: Estado inicial da página de detalhes de um pool de liquidez logo após o clique na listagem. Aguarda os dados do par (preço, APR, métricas, composição) carregarem antes de exibir o layout completo.

Componentes: header global (logo, nav Trade/Perpétuos/Ganhar/Jogar/IA, busca, settings, carteira); área de conteúdo praticamente vazia, apenas com um mascote (panela com panqueca) centralizado servindo de "loading"; sem breadcrumb visível; sem skeleton do layout que virá; sem mensagem de status; aba do navegador mostra "Detalhes do pool | PancakeSwap" (única pista textual de o que está acontecendo).

Regras de negócio: os dados do pool são buscados via RPC + subgraph após o roteamento. Tempo de carga varia com a rede e a saúde do indexador. Nada no estado é pré-renderizado a partir do URL — mesmo o nome do par só aparece quando a resposta chega.

🟢 Insight: usar mascote próprio em vez de spinner genérico mantém identidade de marca durante a espera. Para iniciante, ver um elemento "Pancake" reduz a sensação de tela travada ou erro de roteamento — o produto continua "presente" mesmo sem conteúdo.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): o mascote sozinho não comunica o que está acontecendo. Não há título ("Carregando detalhes do pool…"), nem skeleton mostrando a forma do conteúdo, nem progresso. Iniciante clicou em "ver pool" e está num limbo: travou? errou de página? acabou a internet? Diagnóstico errado: trocar o mascote por spinner — perde identidade sem resolver a ambiguidade. Alternativa: mascote + título descritivo + skeleton da estrutura final (caixas cinzas onde virão header, gráfico, sidebar). Trade-off: skeleton custa esforço de design, mas reduz abandono e ansiedade. Para iniciante a diferença é grande.

🔴 Fricção 2 (estrutural): o breadcrumb "Farms › USDT/BTCB" e o nome do par poderiam ser renderizados imediatamente a partir do URL e do state da listagem — não dependem da API. Mostrá-los antes dos dados ancora o usuário no contexto e elimina a sensação de "página vazia". Diagnóstico errado: esperar tudo para mostrar tudo — é a escolha atual e está errada para o target.

🟡 Oportunidade competitiva: loading state "página vazia + spinner/mascote" é convenção da indústria — Uniswap, 1inch, Jupiter, Curve fazem igual. Critério das 4 perguntas: ✓ todos fazem igual, ✓ afeta iniciante e intermediário direto, ✓ razão é falta de investimento em estados intermediários (não impossibilidade — skeletons são triviais), ✓ ganho perceptível (a tela parece "viva" em vez de morta). Alternativa: skeleton inteligente que reflete a estrutura final + header já populado com dados conhecidos (nome do par, rede, fee tier — todos viáveis a partir do URL). Trade-off: requer disciplina de engenharia para sincronizar skeleton com layout real.

3. Modal de busca de pool — Estado de loading

Função: Modal acionado pelo ícone de lupa no header do pool atual. Permite procurar e trocar para outro pool sem perder o contexto da página de detalhes.

Componentes: modal sobreposto centralizado; campo de busca "Search" com ícone de lupa + ícone "?" pequeno à direita; row de filtros — Tudo / Infinity / V3 / V2 / StableSwap (Tudo ativo, fundo roxo); lista com 5 linhas de skeleton (avatar + título + dois valores) em cinza claro; sem rodapé, sem CTA, sem botão fechar visível (dismiss por overlay/ESC).

Regras de negócio: o catálogo de pools é segmentado por versão/tipo da implementação (V2, V3 concentrada, Infinity, StableSwap). A aba "Tudo" agrega. A consulta vai para o subgraph com filtros aplicados; durante a chamada, skeletons reservam o layout.

🟢 Insight: integrar a troca de pool dentro da página de detail (mantendo contexto de navegação) é decisão correta — o usuário não precisa voltar à listagem global para comparar. Skeletons reais (linhas com a forma do conteúdo) em vez de spinner único elevam a percepção de qualidade e reduzem ansiedade durante a espera.

🔴 Fricção 1 (estrutural — afeta iniciante): as abas "Infinity / V3 / V2 / StableSwap" expõem o paradigma técnico do produto e empurram a escolha para o usuário sem dar critério de decisão. Iniciante não sabe a diferença entre V3 e Infinity, nem para que serve StableSwap. Sem essa explicação, ou ignora o filtro (paga preço de relevância) ou escolhe errado. Diagnóstico errado: esconder os filtros — útil para power user. Alternativa: rotular abas pelo benefício, não pela tecnologia ("Todos / Concentrada / Clássica / Stable→Stable / Nova versão") com o nome técnico exposto no hover/tooltip. Trade-off: aumenta verbosidade — mitigar usando duas linhas curtas no chip.

🔴 Fricção 2 (cosmética — afeta mobile): o ícone "?" pequeno à direita do search é a única afordância de ajuda no modal, e assume hover/tooltip. Em mobile, o toque preciso falha e a informação some. Alternativa: converter o "?" em chip "Como funcionam as abas?" que abra bottom sheet curto.

🔴 Fricção 3: ausência de botão fechar explícito no modal. Dismiss por overlay/ESC é convenção, mas iniciante mobile pode ficar preso. Alternativa: "✕" no canto superior direito, padrão consolidado.

🟡 Oportunidade competitiva: todos os DEX expõem versões técnicas (V2/V3) como vocabulário primário — convenção literal-Uniswap. Critério: ✓ todos fazem igual, ✓ afeta iniciante (e intermediário novo no produto), ✓ razão é falta de investimento em vocabulário traduzido, ✓ ganho perceptível. Alternativa: layer de "modo simples" que substitua as labels técnicas por labels funcionais, com toggle para "modo técnico" persistente.

2. Detalhes do pool — Estado carregado (USDT/BTCB V3 0,05%)

Função: Página de visão completa do pool USDT/BTCB. Apresenta identificação do par, métricas históricas (gráficos), estado atual (sidebar) e CTA principal para adicionar liquidez.

Componentes: breadcrumb "Farms › USDT/BTCB"; header com ícone de busca/troca de pool, avatares dos dois tokens, nome "USDT/BTCB", logo de rede sobreposto, badge "0,05%" com tooltip "V3 LP — Nível de taxa de 0,05%"; bloco "PREÇO ATUAL 0,00001 BTCB = 1 USDT" com toggle de inversão; card "APR EST. 17,18%"; abas Volume/Liquidez/Taxas/TVL (Volume ativo); seletor de range D/W/M/Y; valor agregado "$18,45M"; intervalo de datas; bar chart horário; sidebar — "VALOR TOTAL BLOQUEADO (TVL) $19,62M ▲0,51%"; composição USDT 11,54M / BTCB 99,41 com barra de proporção visual; "VOLUME EM 24H $18,91M ▼50,16%"; "TAXA POR 24H $9,45K"; CTA "Adicionar liquidez".

Regras de negócio: o pool é V3 com fee tier de 0,05% (concentrated liquidity). APR estimada deriva de volume × fee tier × share do LP (+ possíveis incentivos CAKE quando ativos). Métricas atualizadas em janelas de 24h. A composição em USD/quantidade do par muda com o preço e o volume.

🟢 Insight: a separação histórico (gráficos) vs estado atual (sidebar) é arquitetura correta — o usuário tem macro (tendência) e snapshot (agora) sem rolagem. A barra de composição USDT/BTCB com proporção visual é diferencial pedagógico: iniciante entende que LP é "duas partes" sem precisar abrir documentação. Tooltip do fee tier no hover do badge é boa prática contextual.

🔴 Fricção 1 (estrutural — afeta iniciante): "APR EST. 17,18%" aparece sem decomposição visível. Não fica claro se vem de fees orgânicos, incentivos CAKE, ambos, e qual a volatilidade histórica do número. Iniciante lê como rendimento garantido tipo poupança. Diagnóstico errado: trocar APR por APY — não resolve, complica. Alternativa: APR com breakdown sempre visível ou em hover de detalhe ("Taxas: 13,2% • Incentivos: 4,0% • Faixa últimos 7d: 14-19%") + disclaimer curto "estimativa baseada nos últimos 7d, varia com volume e IL".

🔴 Fricção 2 (estrutural — afeta iniciante): "Preço atual: 0,00001 BTCB = 1 USDT" é ilegível por excesso de zeros. A direção escolhida (BTCB por USDT) dá número minúsculo; inverter (USDT por BTCB) daria ~99.617 — leitura natural. O toggle existe, mas o default deveria ser automático. Alternativa: detectar magnitude e abrir na direção em que o número seja ≥ 1. Trade-off: aprenderá a duas convenções no produto; ganho de legibilidade compensa.

🔴 Fricção 3 (cosmética mas conceitual): breadcrumb diz "Farms" embora a página seja "Detalhes do pool". PancakeSwap mistura "Farms" (yield farming/staking) com "Pools" no mesmo vocabulário, e isso transborda no breadcrumb. Iniciante não sabe se está vendo pool ou farm. Alternativa: padronizar vocabulário ("Pools › USDT/BTCB").

🟡 Oportunidade competitiva: nenhum DEX importante (Uniswap, Curve, Pancake) decompõe APR inline na página de pool — todos mostram número agregado sem componentes nem volatilidade. Critério: ✓ todos fazem igual, ✓ afeta iniciante (e intermediário que quer comparar pools), ✓ razão é falta de investimento em UX de pricing, ✓ ganho perceptível (decisão informada de LP). Trade-off: mais informação visual; mitigar com hierarquia (número grande + breakdown menor + faixa histórica como caption).

3. Form Adicionar Liquidez — V2 selecionado

Função: Mesmo form do R2 com V2 selecionado em vez de V3. Tela praticamente idêntica em layout — único elemento que muda é qual segmento da pílula está ativo.

Componentes: breadcrumb idêntico; card com pílula (V2 ativo); BNB Chain; par BNB + CAKE; sem passo 3; CTA "Próximo". URL muda para /liquidity/select/bsc/v2/....

Regras de negócio: V2 = AMM clássica de produto constante (x·y=k) — liquidez distribuída uniformemente em toda a faixa de preço, sem fee tier configurável (taxa única fixa do protocolo). Por isso, como em V3, o passo 3 (filtro de pool) não aparece — mas por motivo diferente do V3.

🟢 Insight: V2 mantém a opção viável para o usuário que quer aporte "simples e passivo" — sem decisão de range, sem decisão de fee tier. Pancake reconhece que nem todo provedor de liquidez quer otimizar capital — alguns querem só depositar e esquecer. Manter o V2 disponível protege esse perfil de complexidade desnecessária.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário, alta severidade): V2 e V3 produzem telas visualmente indistinguíveis (mesmo layout, mesmos campos, mesmo CTA), mas representam decisões financeiras radicalmente diferentes. V2 = liquidez passiva ampla, retorno menor, sem gestão; V3 = liquidez concentrada, retorno potencial maior, exige gerência ativa e re-ranging. Iniciante que clica entre V2 e V3 não percebe nenhuma diferença na tela — então conclui que a escolha é cosmética e segue com qualquer uma. A consequência só aparece na próxima tela (ou pior, semanas depois, quando impermanent loss ou capital ocioso se materializa). Fix óbvio (tooltip por versão) é insuficiente — tooltip não compete com a evidência visual de que "as telas são iguais". Fix correto: previews lado-a-lado de retorno estimado vs esforço de gestão para o par escolhido, expostos no momento de selecionar a versão, não escondidos atrás de hover.

🔴 Fricção 2 (cosmética → estrutural — afeta iniciante): nomenclatura "V2/V3/V4/Infinity" trata versões como progresso linear, sugerindo implicitamente que "V3 é melhor que V2" (afinal, é número maior). Mas V2 ainda existe porque atende caso de uso diferente, não porque é "inferior". Iniciante racional escolhe V3 por achar que é a versão "atualizada", quando V2 pode ser a melhor escolha para seu perfil. Alternativa: rotular por intenção, não por versão ("Simples (V2)", "Concentrada (V3)"). O nome técnico pode ficar entre parênteses para preservar reconhecimento de quem já conhece, mas a label primária é a intenção.

🟡 Oportunidade competitiva (alta leverage no target): versionamento numérico crescente como label primária é convenção universal entre AMMs (Uniswap V2/V3/V4, Pancake V2/V3, Sushi Trident, Curve V1/V2). Passa nas 4 perguntas: convenção entre concorrentes ✓; afeta iniciante diretamente — induz a escolher "V mais alto" por achar melhor ✓; ninguém renomeou por inércia de marca e identidade de produto ✓; diferenciação perceptível ✓. Diferencial Kotai: label por intenção ("Liquidez simples", "Liquidez concentrada", "Pool estável") com versão técnica em sub-label. Trade-off: força decisão de nomenclatura própria e diverge do vocabulário compartilhado da indústria — usuário avançado vindo de outros DEX precisa de mapeamento mental.

1. Form Adicionar Liquidez — Infinity (estado inicial)

Função: Tela de entrada do fluxo de provisão de liquidez. Reúne, num único card, três decisões prévias ao aporte: protocolo (versão da AMM), rede, par de tokens e filtro de pool. Aporte propriamente dito acontece na tela seguinte.

Componentes: breadcrumb "Farms > Adicionar liquidez"; card com 3 passos numerados; (1) pílula segmentada de protocolo Infinity/V3/V2/StableSwap (Infinity ativo) + dropdown de rede "BNB Chain"; (2) seletores duplos de token (BNB + CAKE) com chevron; (3) dropdown "Filtro de pool (opcional)" pré-preenchido com "Todos os pools, Tipo de Pool, CLAMM, LBAM..." (truncado); CTA primário "Próximo".

Regras de negócio: numeração 1→2→3 sugere fluxo sequencial dentro do mesmo card. Protocolo é escolha primária — define quais sub-opções aparecem abaixo (passo 3 condicional). Infinity habilita o passo 3 com filtros de mecânica (CLAMM, LBAMM). "Opcional" sinaliza que o usuário pode avançar sem tocar no filtro.

🟢 Insight: numeração explícita 1→2→3 + CTA "Próximo" no fim do card é decisão correta. Quebra uma decisão composta em sub-passos cognitivamente menores e ancora a ordem (rede antes de par, par antes de filtro). Pancake reconhece que escolha de pool é decisão em camadas, não uma única seleção — diferencial em relação a forms que jogam tudo em uma linha.

🔴 Fricção 1 (estrutural — afeta iniciante): o passo 1 cobra uma escolha de protocolo (Infinity/V3/V2/StableSwap) antes do usuário ter contexto pra decidir. Iniciante vindo de CEX não sabe o que diferencia V2 de V3, não conhece "Infinity", e a tela não explica. Pior: o protocolo é a primeira escolha, posicionada como pré-requisito — produzindo dead-end cognitivo logo no primeiro passo. Fix óbvio (tooltip explicando cada versão) falha porque empilha 4 explicações técnicas em vez de remover a decisão. Fix correto: defaultar para um protocolo recomendado (o de melhor adequação ao par escolhido) e mover seleção de versão para um "avançado" colapsável. O usuário-alvo decide "que par quero fornecer" e a UI decide "qual versão é melhor".

🔴 Fricção 2 (cosmética — afeta iniciante e intermediário): o passo 3 mostra texto truncado "Todos os pools, Tipo de Pool, CLAMM, LBAM..." — mistura de meta-categoria ("Tipo de Pool") com tags específicas (CLAMM, LBAMM) numa string CSV-like, sem hierarquia. "CLAMM" e "LBAMM" são jargão de design de AMM. Iniciante não decodifica; intermediário precisa adivinhar o que está incluso. Alternativa: pílulas/chips com label semântica ("Concentrada", "Liquidez gerenciada") e contagem de pools por filtro; termo técnico em tooltip.

🟡 Oportunidade competitiva (alta leverage no target): todos os DEX com múltiplas versões (Uniswap V2/V3/V4, Pancake Infinity/V3/V2, Sushi Classic/Trident) cobram do usuário a escolha de protocolo como pré-requisito ao aporte. Passa nas 4 perguntas: convenção entre concorrentes ✓; afeta iniciante e intermediário ✓; ninguém resolveu por priorizar fidelidade ao modelo interno do protocolo ✓; diferenciação perceptível ✓. Diferencial Kotai: entrada por intenção ("quero render BNB+CAKE") → UI recomenda versão + tier ótimos para o par, com opção "trocar versão" colapsada para avançado. Trade-off: precisa de heurística de recomendação confiável e fallback para casos onde não há pool ideal.

Consolidado — Visualizar Farm (PancakeSwap)

Caráter geral do fluxo

O fluxo Visualizar Farm é essencialmente um dashboard de avaliação pré-decisão: o usuário chegou para decidir se vai aportar liquidez naquele pool. O produto acerta na entrega de dados ricos — a distribuição de liquidez V3 em #7 está bem implementada, a série anual de taxas em #9 é diferencial sobre Uniswap e Curve, e o sistema de scrub temporal é coerente entre todas as abas de gráfico (confirmado nas telas #10 e #12). O problema não é falta de dado; é falta de camada de interpretação. O APR — número que governa a decisão de LP — aparece agregado no card de #2 e escondido atrás de hover em #5. Os estados de carregamento e de vazio deixam o iniciante em dead-end sem orientação em três pontos distintos do fluxo (#1, #6, #13) sem nenhum sistema unificando as respostas. Perfil mais afetado: iniciante (fortemente — APR lido como rendimento garantido, preços sub-1 ilegíveis, dead-ends em estados vazios), seguido pelo intermediário (hover-only inacessível em mobile, inconsistências entre abas de gráfico).

🟢 Insights recorrentes

Sistema de scrub temporal coerente — telas 10, 12

O header dinâmico durante hover (reflete o valor do ponto explorado sem abandonar o layout), o posicionamento do tooltip e o cursor vertical seguem o mesmo padrão em Volume, Liquidez, Taxas e TVL. Em #10 o comportamento já é descrito como consistente entre abas; em #12 a granularidade horária do TVL bate exatamente com o range Day, sem o desencaixe que aparece na aba Taxas (tela #10). O usuário aprende o padrão uma vez e aplica nos seis gráficos do fluxo — coerência interna rara em produtos DeFi.

Separação arquitetônica visão pública / pessoal — telas 2, 6

Em #2 a divisão histórico (gráficos com abas) vs estado atual (sidebar com TVL, composição, volume 24h e CTA) é a escolha certa: macro + snapshot sem rolagem. Em #6 o mesmo princípio se aplica verticalmente — métricas globais do pool acima, Minhas Posições/Transações abaixo. A decisão de arquitetura é deliberada e funciona; o que falta é âncora no topo da página apontando para a seção pessoal abaixo do fold (ver Pontos isolados, tela 6).

🔴 Fricções recorrentes

Estrutural — Empty states sem ação / não condicionais — telas 1, 6, 13

A evolução ao longo do fluxo é reveladora: #1 usa apenas o mascote de loading sem texto descritivo nem skeleton; #6 usa uma ilustração de panelas sem mensagem de status na aba Liquidez (que parece sem dados mas na verdade estava carregando — revelado em #7); #13 dá um salto positivo com texto explícito ("Nenhuma posição encontrada") mas não distingue os quatro estados possíveis: sem wallet conectada, wallet em rede errada, wallet conectada sem posição neste pool, ou carregando. O resultado em #13 é dead-end emocional: o iniciante não sabe se errou de produto, de rede ou simplesmente ainda não tem posição.

O diagnóstico real é ausência de sistema de estados intermediários — o produto resolve cada tela de forma isolada, sem padrão unificado de feedback. Solução óbvia errada: adicionar texto em cada tela individualmente (a empresa já fez isso entre #1 e #13, e ainda não resolveu). Alternativa: sistema de componentes de estado (loading → skeleton refletindo a estrutura final; vazio → copy condicional + CTA contextual; erro → causa + ação de recuperação) aplicado como padrão de produto. Trade-off: requer disciplina de design system; ganho é proporcional — 3 ocorrências confirmadas neste fluxo, mais prováveis em outros. Perfil afetado: iniciante (fortemente).

→ ver 🟡 Oportunidade: Sistema de estados intermediários com microcopy condicional

Estrutural — APR opaco / decomposição escondida — telas 2, 5

Em #2 o card "APR EST. 17,18%" não tem breakdown algum — iniciante lê como rendimento garantido tipo poupança, sem distinção entre incentivo CAKE e fee orgânica do pool. Em #5 o breakdown correto existe (Farm 1,20% + Taxa de LP 15,98%) e inclui até disclosure honesto sobre variabilidade — mas está escondido atrás de hover. A maioria dos LPs iniciantes nunca descobre que aquela informação existe.

O atrito real não é falta de dado, é falta de hierarquia: o produto já fez o trabalho de calcular e escrever a decomposição; não investiu em torná-la visível por default. Solução óbvia que falha: modal ou tooltip mais proeminente — continua dependendo de interação ativa. Alternativa: decomposição sempre visível inline embaixo do número grande ("Taxas: 15,98% • Incentivos: 1,20% • Faixa 7d: 14–19%"), tooltip reservado para o texto explicativo longo. Trade-off: card cresce verticalmente — mitigável com dois números secundários em fonte menor na mesma linha. Perfil afetado: iniciante e intermediário que quer comparar pools.

→ ver 🟡 Oportunidade: APR decomposto visível por default

Estrutural — Preço ilegível por zeros excessivos — telas 2, 7, 8

A direção de exibição do par (BTCB per USDT) gera números sub-1 com quatro zeros antes do primeiro algarismo significativo em #2 ("0,00001 BTCB = 1 USDT"), no eixo X do gráfico de distribuição em #7 (onde "0,000012" repetido em todos os bins torna a faixa de preço ilegível) e no tooltip de bin em #8. O toggle de inversão existe em #2 mas o default deveria ser automático. Inverter (USDT por BTCB) daria ~99.617 — número humano, leitura imediata.

Atrito real: a lógica de auto-flip por magnitude existe como ideia trivial de produto mas nunca foi implementada — provavelmente porque o par foi tratado como um template único, não como exibição adaptativa. Alternativa: detectar quando o preço nominal < 0,001 e inverter automaticamente o ratio em todos os displays (card, eixo, tooltip), com badge discreto indicando a direção "USDT/BTCB". Trade-off: usuário habituado ao ratio BTCB/USDT pode estranhar; ganho de legibilidade para o iniciante compensa. Perfil afetado: iniciante e intermediário menos habituado ao par.

→ ver 🟡 Oportunidade: Auto-flip de preço por magnitude

Estrutural — Vocabulário técnico sem tradução funcional — telas 3, 4

Caso primário — bloqueante em #3: as abas do modal de busca expõem "Infinity / V3 / V2 / StableSwap" como critério primário de filtro. O iniciante não tem base para decidir qual selecionar — é forçado a uma escolha ativa sem critério, ou aceita todos os resultados com APRs misturados de versões distintas. Esse é o ponto de bloqueio real: a decisão de filtro é obrigatória e o vocabulário não orienta.

Caso secundário — cosmético em #4: os badges "V3|0,05%" ao lado de cada par são igualmente opacos para o iniciante, mas o impacto é menor — o badge é informativo, não bloqueia navegação e não força escolha ativa.

Atrito real: o produto herdou a taxonomia técnica como interface primária, sem investir em camada de vocabulário orientado a benefício. Alternativa para #3: rotular abas por função ("Todos / Concentrada / Clássica / Stable→Stable / Nova versão") com nome técnico no hover. Trade-off: verbosidade das abas — mitigável com chips de tamanho médio. O peso estrutural do item vem exclusivamente de #3; #4 reforça o padrão mas não adiciona bloqueio independente. Perfil afetado: iniciante (principalmente em #3).

→ ver 🟡 Oportunidade: Vocabulário funcional nas abas de filtro

Estrutural — Escala do eixo Y iniciando em $0 — telas 11, 12

O TVL real do pool fica em ~$19,66M, mas o eixo Y cobre $0–$20M. Em #11 a variação de 1–3% no período visível fica visualmente invisível — a linha do area chart parece absolutamente reta. Em #12 o hover revela $19,46M (uma queda de ~1%) enquanto o gráfico não comunica queda nenhuma — o usuário precisa confiar nos números porque o desenho não traduz. Para um LP avaliando estabilidade do pool, isso é leitura enganosamente tranquilizante.

Atrito real: escala com baseline em $0 é o default de todas as bibliotecas de charting, e ninguém configurou auto-zoom. Alternativa: eixo Y em janela ±5–10% do valor médio do período visível, com indicador visual explícito de que o eixo não começa em zero (linha de baseline tracejada com label "$19,6M"). Trade-off: pequena distorção perceptiva — mitigável com label explícito. Perfil afetado: iniciante e intermediário.

→ ver 🟡 Oportunidade: Auto-zoom contextual no eixo Y

Estrutural — Tooltip sem delta vs início do range — telas 10, 12

Em #10 o header dinâmico durante hover na aba Taxas substitui o total anual ($4,69M) pelo valor do bin explorado ($83,67K) sem manter referência — usuário que estava calibrando o número perde o contexto. Em #12 o tooltip do TVL mostra "$19,46M" como valor pontual sem Δ% vs início do range ou vs valor atual, forçando cálculo mental para qualquer leitura de variação.

Atrito real: scrub temporal sem delta é o padrão mínimo de toda biblioteca de charting — ninguém adicionou o cálculo. Alternativa: duas linhas no tooltip — valor pontual + Δ% contextual ("$19,46M • -1,0% vs início do range"); no header, manter total fixo como referência enquanto o secundário reflete o ponto hovered. Trade-off: tooltip e header crescem ligeiramente; ganho de legibilidade é imediato. Perfil afetado: iniciante e intermediário.

→ ver 🟡 Oportunidade: Tooltip com delta vs início do range

🟡 Oportunidades competitivas do fluxo

Sistema de estados intermediários com microcopy condicional — vista em telas 1, 6, 13

Padrão atual da indústria: Uniswap, Curve, 1inch e Pancake usam loading states com spinner/ilustração genérica e empty states estáticos sem copy condicional. "No positions found" (ou variante) é a resposta universal, independente da causa.

Por que afeta nosso target: o iniciante não distingue "carregando", "feature não existe" e "você não tem posição aqui" sem texto orientador — como ficou evidente em #6 (onde a aba Liquidez parecia sem feature mas estava só carregando) e em #13 (onde "Nenhuma posição encontrada" não diz se o problema é a rede, a wallet ou ausência mesmo de posição).

Hipótese de diferenciação Kotai: sistema de estados com três camadas — (a) loading → skeleton que reflete a estrutura final do conteúdo (sem mascote avulso), (b) vazio condicional → copy baseado no estado real da wallet ("Conecte sua carteira", "Troque para BNB Chain", "Você ainda não tem posições neste pool → Adicionar liquidez"), (c) erro → causa explícita + ação de recuperação. Aplicado como componente de design system, não como solução isolada por tela.

Trade-off: requer mapeamento explícito de todos os estados possíveis por tela e disciplina de design system para não divergir. Custo de implementação baixo por tela; custo de governança médio para manter consistente.

Passa nas 4 perguntas-teste? (1) ✓ todos os concorrentes fazem igual (2) ✓ afeta iniciante fortemente (3) ✓ razão é falta de investimento em sistema, não impossibilidade — estados são tecnicamente conhecidos (4) ✓ diferença perceptível imediata: produto parece "vivo" vs "travado".

APR decomposto visível por default — vista em telas 2, 5

Padrão atual da indústria: Uniswap, Curve, 1inch e Pancake exibem APR como número único agregado. Pancake tem a decomposição correta em #5 — mas atrás de hover, invisível para quem não sabe procurar.

Por que afeta nosso target: o iniciante interpreta APR agregado como rendimento garantido. Sem saber que 1,20% vem de incentivos temporários (CAKE) e 15,98% de fees orgânicas, não consegue avaliar a sustentabilidade do retorno nem comparar pools com perfis diferentes.

Hipótese de diferenciação Kotai: decomposição sempre visível inline embaixo do número principal ("Taxas: 15,98% • Incentivos: 1,20% • Faixa 7d: 14–19%") + disclaimer de uma linha ("estimativa baseada nos últimos 7d, varia com volume e IL"). Tooltip reservado para o texto explicativo detalhado. O dado já existe no Pancake — falta só a hierarquia visual.

Trade-off: card de APR cresce; mitigável com números secundários em fonte menor. Risco de overload visual em telas com muitos cards — design system deve definir tamanho padrão do componente.

Passa nas 4 perguntas-teste? (1) ✓ todos fazem igual (2) ✓ afeta iniciante e intermediário (3) ✓ falta de investimento em hierarquia visual — decomposição já existe no Pancake (4) ✓ diferença perceptível: decisão informada de LP vs leitura cega.

Auto-flip de preço por magnitude — vista em telas 2, 7, 8

Padrão atual da indústria: Uniswap V3, Pancake e demais V3 forks exibem o ratio nominal do par sem auto-inversão — independente da magnitude do número resultante.

Por que afeta nosso target: o par USDT/BTCB na direção BTCB per USDT gera "0,000012" — ilegível no card de #2, repetido identicamente em todos os bins do eixo X do gráfico de distribuição de #7 (tornando a faixa de preço indistinguível visualmente), e no tooltip de bin de #8. O toggle manual existe em #2, mas iniciante não o descobre.

Hipótese de diferenciação Kotai: detectar magnitude do preço nominal; se < 0,01, inverter o ratio automaticamente em todos os displays do produto. Badge discreto indicando a direção ativa ("USDT/BTCB ↕"). Aplicar de forma consistente em card, eixo de gráfico e tooltips — não resolver isoladamente em cada componente.

Trade-off: usuário avançado habituado ao ratio BTCB/USDT de outras plataformas pode precisar de ajuste. Mitigável com o toggle de inversão manual sempre visível.

Passa nas 4 perguntas-teste? (1) ✓ todos fazem igual (2) ✓ afeta iniciante e intermediário (3) ✓ falta de investimento — auto-flip é operação trivial (4) ✓ ganho de leitura imediato e perceptível.

Interação mobile tap-and-stick em gráficos — vista em telas 8, 9, 10, 12

Padrão atual da indústria: todos os DEX constroem drill-down de gráficos (bin hover, scrub temporal, tooltip de ponto) exclusivamente via hover de mouse. Mobile não tem hover — toque dispara e solta.

Por que afeta nosso target: o iniciante que acessa o produto pelo celular (proporção crescente, especialmente em BNB Chain) perde completamente a exploração de bins em #8 (a ferramenta principal para decidir range) e a exploração temporal em #9, #10 e #12.

Hipótese de diferenciação Kotai: padrão tap-and-stick em todos os gráficos — toque seleciona o bin/ponto, indicador visual de "selecionado" persiste, segundo toque fora do gráfico fecha. Aplicar como padrão de componente, não por gráfico individualmente.

Trade-off: requer detecção de touch vs pointer e lógica de estado para cada componente de gráfico. Custo de engenharia médio; ganho de inclusão para todo usuário mobile.

Passa nas 4 perguntas-teste? (1) ✓ todos os DEX são hover-only (2) ✓ afeta iniciante e intermediário mobile (3) ✓ falta de investimento em interaction design mobile (4) ✓ diferença perceptível — ou o dado é acessível ou não é.

Vocabulário funcional nas abas de filtro — vista em telas 3, 4

Padrão atual da indústria: Uniswap, Pancake e todos os V3 forks expõem versões técnicas (V2/V3/StableSwap/Infinity) como vocabulário primário de navegação e filtro.

Por que afeta nosso target: o iniciante sem conhecimento de arquitetura DeFi não tem critério para escolher entre "V3" e "Infinity" em #3. Ou ignora o filtro (aceita todos os resultados), ou escolhe errado. O padrão não é pontual: os badges nos resultados de #4 repetem o mesmo jargão ("V3|0,05%") fora do modal de filtro, confirmando que o vocabulário técnico permeia o fluxo. O intermediário que sabe o que quer encontra o filtro útil — mas não é o perfil prioritário.

Hipótese de diferenciação Kotai: rotular abas por benefício/comportamento ("Todos / Concentrada / Clássica / Stable→Stable / Nova versão") com o nome técnico exposto no hover ou como sub-label. Toggle "modo técnico" persistente para quem prefere o vocabulário original.

Trade-off: dois vocabulários para manter em sincronia; aumento de verbosidade nas abas. Mitigável com chips de tamanho adequado e sub-label em fonte menor.

Passa nas 4 perguntas-teste? (1) ✓ todos fazem igual (2) ✓ afeta iniciante (3) ✓ falta de investimento em vocabulário traduzido (4) ✓ ganho perceptível: iniciante consegue filtrar com critério.

Auto-zoom contextual no eixo Y — vista em telas 11, 12

Padrão atual da indústria: Uniswap, Curve, 1inch e Pancake usam $0 como baseline em todos os gráficos de TVL e métricas de pool. É o default de bibliotecas como Chart.js, Recharts e Highcharts sem configuração explícita.

Por que afeta nosso target: em #11 o TVL de $19,66M numa escala $0–$20M faz a variação de 1% ficar visualmente plana — iniciante avaliando estabilidade do pool lê "constante" quando pode haver entradas/saídas relevantes. Em #12 o hover revela uma queda que o gráfico não comunica.

Hipótese de diferenciação Kotai: auto-zoom em janela ±5–10% do valor médio do período visível como padrão, com baseline tracejado e label explícito do valor de referência. Aplica em TVL, Volume e Taxas — todo gráfico de série temporal com amplitude pequena relativa ao valor absoluto.

Trade-off: pode criar percepção de volatilidade onde o usuário não esperava; mitigável com label explícito do eixo e nota "escala ajustada — ver linha base".

Passa nas 4 perguntas-teste? (1) ✓ todos fazem igual (2) ✓ afeta iniciante e intermediário (3) ✓ falta de configuração — não é impossibilidade técnica (4) ✓ diferença perceptível: variações reais passam a ser visíveis.

Tooltip com delta vs início do range — vista em telas 10, 12

Padrão atual da indústria: Uniswap, Curve, DefiLlama e Pancake exibem valor absoluto pontual no tooltip de scrub temporal. Nenhum mostra variação relativa ao período ou ao valor atual por padrão.

Por que afeta nosso target: em #12 o iniciante vê "$19,46M" e precisa calcular mentalmente a diferença em relação ao "$19,66M" no header para entender se o pool cresceu ou encolheu naquele ponto. Em #10 o header já substitui o total pelo valor do ponto, eliminando até a referência para o cálculo.

Hipótese de diferenciação Kotai: tooltip com duas linhas — valor do ponto + Δ% contextual ("$19,46M • -1,0% vs início do range"). No header dinâmico, manter total fixo como referência enquanto o valor do ponto aparece como número secundário ao lado. Aplica em Volume, Taxas e TVL com consistência.

Trade-off: tooltip e header crescem; requer definição de qual "referência" usar (início do range? valor atual? média do período?) — escolher uma e ser consistente.

Passa nas 4 perguntas-teste? (1) ✓ todos fazem igual (2) ✓ afeta iniciante (3) ✓ falta de investimento em microcopy — cálculo é trivial (4) ✓ diferença perceptível: leitura de variação direta vs cálculo mental.

Pontos isolados (1 tela)

🟢

• Tela 3: modal de busca inline sem perder contexto de navegação + skeletons reais em vez de spinner — melhor prática de loading state no fluxo.
• Tela 4: exibição de tipo + fee tier ao lado do par ("V3|0,05%") — informação densa mas necessária para comparar pools do mesmo par em versões diferentes.
• Tela 5: decomposição APR Farm + Taxa de LP no tooltip com disclosure honesto sobre variabilidade ("APRs reais podem ser maiores porque parte da liquidez não está no range") — raro e correto; Uniswap não chega perto disso.
• Tela 7: distribuição de liquidez V3 por faixa de preço (bins + marcador rosa do preço atual) bem implementada — feature crítica de V3 entregue corretamente.
• Tela 9: série anual de taxas ($4,69M em 12 meses, com sazonalidade visível) — diferencial real sobre Uniswap e Curve que mostram só 24h/7d.
• Tela 14: feed on-chain com filtros por tipo de evento (Swaps/Aportes/Remoções) + ordenação por colunas + link direto ao explorer — arquitetura correta para auditoria de atividade de pool.

🔴

• Tela 2: breadcrumb "Farms › USDT/BTCB" numa página que é tecnicamente "Detalhes do pool" — nomenclatura inconsistente entre Farms e Pools no produto.
• Tela 3: modal sem botão fechar explícito — dismiss por overlay/ESC é convenção desktop, mas iniciante mobile pode ficar preso.
• Tela 4: coluna de ordenação ativa não marcada visualmente — chevrons aparecem em APR e TVL mas nenhum indica qual está ativo e em qual direção.
• Tela 5: copy "APR combinada" com concordância feminina em PT-BR — APR é tratado como masculino no padrão da indústria ("o APR"). Indica revisão de localização incompleta.
• Tela 6: tabs "Minhas posições/Transações" abaixo do fold sem âncora visual no topo — iniciante buscando "ver minha posição" rola sem saber que existe essa seção.
• Tela 7: eixos do gráfico de distribuição sem label — "$80K" no eixo Y é liquidez em USD por bin, não preço; iniciante pode interpretar como preço do token.
• Tela 7: controles de zoom "+/-" minúsculos e sem tooltip — pouco descobríveis em desktop, inacessíveis em mobile.
• Tela 9: aba Taxas sem controles D/W/M/Y — inconsistência com Volume, Liquidez e TVL que têm o seletor; a janela anual fixa pode ser intencional, mas o padrão quebrado confunde.
• Tela 9: 365 barras no gráfico anual sem smoothing — spikes ofuscam o baseline; iniciante não consegue ler tendência, só picos.
• Tela 10: granularidade inconsistente na aba Taxas — gráfico parece diário (365 barras ≈ 1 ano) mas tooltip mostra hora exata ("21:00 PM UTC"); iniciante não sabe se a barra é dia ou hora.
• Tela 10: "21:00 PM UTC" — formato redundante (21:00 já indica PM em horário militar); bug de localização na montagem da string.
• Tela 13: empty state não reforça onde criar posição — o CTA "Adicionar liquidez" existe no card lateral, mas o usuário em dead-end emocional não sabe que deve olhar para a direita.
• Tela 14: localização incompleta sistêmica — "Swap BTCB for USDT", "3 minutes ago", "Page 1 of 14" em UI PT-BR. Não é problema isolado desta tela; é dívida de processo de localização do produto inteiro.
• Tela 14: sub-tabs "Tudo / Trocas / Adiciona / Remove" — conjugações verbais no presente quebram paralelismo com "Trocas" (substantivo). Alternativa: "Tudo / Swaps / Aportes / Remoções".
• Tela 14: "$3,38K" mistura separador decimal PT-BR (vírgula) com abreviação EN (K) — escolher um sistema e aplicar consistentemente.

🟡

• Tela 4: Score de risco inline no catálogo (estrutural, 1 tela) — Uniswap, Curve, Pancake e 1inch listam pools sem indicador de risco. APRs de 150–157% ao lado de tokens opacos ("SKYAI", "TAG") expõem o iniciante a decisões binárias erradas ("golpe" ou "dinheiro fácil"). Hipótese Kotai: badge baixo/médio/alto baseado em TVL + idade do pool + verificação de tokens, clicável para critério explícito. Trade-off central: governança pública do critério, não a implementação técnica. Passa nas 4 perguntas-teste: ✓ ✓ ✓/⚠ ✓.
• Tela 8: tooltip de bin com composição completa dos dois tokens (USDT + BTCB) — atualmente mostra só BTCB; Uniswap V3 também exibe apenas o token dominante. Afeta LP intermediário decidindo range; cálculo direto a partir do tick.
• Tela 14: feed narrativo (modo simples) para o histórico de transações — cada linha como frase humana ("Há 3 min, uma carteira trocou R$ 3,38 mil...") com link discreto ao explorer; toggle simples/técnico persistente. Diferencial para iniciante vindo de CEX que nunca leu hash de carteira.

Comparação rápida com Uniswap

Não existe consolidado equivalente do fluxo de visualização de pool/farm no lado Uniswap — a análise foi feita apenas no Pancake. Uniswap V3 tem a página de pool analytics como referência comparável (app.uniswap.org/explore/pools), mas não foi analisada no mesmo nível de detalhe. Pontos onde o Pancake demonstra vantagem técnica sobre o que se conhece do Uniswap V3: entrega a série anual de taxas (Uniswap mostra só 1d/1w/1m), o tooltip do APR decomposto com disclosure honesto de variabilidade (Uniswap mostra APR sem breakdown), e o feed on-chain com filtros por tipo de evento. Pontos onde Uniswap provavelmente se sai melhor ou equivalente: todos os problemas estruturais listados acima são compartilhados (APR agregado, empty states pobres, hover-only, escala $0) — são convenções da indústria, não vantagens de nenhum dos dois.

5. Dropdown de Rede aberto (Infinity)

Função: Submenu de seleção de rede do passo 1 do form. Acionado pelo chevron ao lado de "BNB Chain". Define em qual blockchain o pool de liquidez será criado/escolhido.

Componentes: dropdown aberto mostrando 2 opções: "BNB Chain" (atual, com ícone amarelo/preto) e "Base" (com ícone azul); cada item é uma linha com avatar + nome; o restante do form fica visualmente atrás do popover (passo 2 escondido sob a sobreposição).

Regras de negócio: lista de redes restrita ao subset onde o protocolo Infinity está deployado. URL permanece em /bsc/infinity/... até o usuário confirmar nova seleção. Lista filtrada por compatibilidade protocolo↔rede (Infinity ≠ V3 ≠ V2 em termos de chains suportadas).

🟢 Insight: restringir a lista de redes ao subset compatível com o protocolo escolhido é decisão correta — evita o anti-padrão "clica e descobre que não tem". Apenas 2 opções aqui significa que o produto sabe filtrar combinações inválidas, mostrando só o que faz sentido. Contraponto coerente ao que levantei como observação no R2.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): o dropdown não indica por que só há 2 redes. Iniciante vindo de outras telas Pancake (search com 9 redes — ver R8 do MegaMenu) estranha a redução repentina. Não há microcopy explicando "Apenas redes onde Infinity está disponível". Usuário pode interpretar como bug ("sumiram minhas redes") ou desconhecimento ("como acesso Ethereum?"). Fix óbvio (adicionar tooltip "?" ao lado do label do passo 1) não resolve a leitura no momento — usuário precisaria saber que pode haver mais. Fix correto: hint inline no rodapé do dropdown — "Outras redes disponíveis em V3 ou V2" + atalho que troca protocolo automaticamente.

🔴 Fricção 2 (cosmética — afeta iniciante): o item "BNB Chain" atualmente selecionado não tem indicador visual de "selecionado" (check, fundo destacado, borda) — o usuário precisa lembrar o que estava no campo fechado para saber qual é o atual. Pattern de dropdown sem destacar o item ativo. Alternativa: checkmark à direita do item atual ou background sutil — convenção já consolidada em outros componentes do mesmo produto (vide submenu de idioma no R12 do MegaMenu, onde a Pancake faz isso direito).

Não é 🟡: restrição de rede por protocolo é convenção variável entre concorrentes (Uniswap mostra mesmas redes em todos os protocolos; 1inch agrega; Pancake filtra). Não passa na pergunta 1 do teste — não é convenção uniforme. É decisão de produto Pancake-específica, com vantagens (evita combinação inválida) e desvantagens (reduz discoverability). Mantenho como fricção cosmética de feedback, não oportunidade competitiva.

Observação adicional: ausência de campo de busca aqui é convenção válida (lista curta — 2 itens). Mas em V3 ou V2 a lista pode crescer (Ethereum, Arbitrum, Base, Linea, etc.) e a mesma UI sem busca pode ficar pesada. Vale verificar o comportamento do dropdown em outras versões — pode ser fricção emergente que aparece só em protocolos com mais redes.

4. Form Adicionar Liquidez — StableSwap selecionado

Função: Mesmo form com StableSwap (AMM otimizada para ativos correlacionados em preço, como par stable/stable) ativo. Aqui o passo 3 reaparece — mas com forma diferente do Infinity.

Componentes: breadcrumb idêntico; pílula com StableSwap ativo; BNB Chain; par BNB + CAKE; passo 3 "Filtro de pool" reaparece com label sem o sufixo "(opcional)" e pré-preenchido como "Tipo de Pool, Classic"; CTA "Próximo". URL: /liquidity/select/bsc/stableSwap/....

Regras de negócio: StableSwap usa curva côncava (Curve-style) que minimiza slippage e impermanent loss quando os tokens mantêm paridade. "Classic" é o tipo de pool padrão. O passo 3 reaparece porque StableSwap tem sub-tipos de curva configuráveis. A ausência de "(opcional)" sugere que o filtro é obrigatório aqui — diferente do Infinity, onde era opcional.

🟢 Insight: reaparecimento condicional do passo 3 confirma que o card respeita a taxonomia real de cada protocolo. Pancake não força o usuário a configurar coisas que não existem na versão escolhida, nem esconde decisões obrigatórias. Reconhecimento honesto da heterogeneidade entre protocolos.

🔴 Fricção 1 (estrutural — afeta iniciante, severidade altíssima): o form aceita BNB + CAKE como par para StableSwap sem qualquer warning. StableSwap é desenhada para pares correlacionados (USDT/USDC, ETH/stETH) — usar para par volátil (BNB/CAKE) resulta em arbitragem permanente contra o LP e perdas estruturais. O form deveria bloquear ou alertar fortemente esta combinação. Iniciante vê "StableSwap, slippage reduzido" no marketing do produto e seleciona achando que vai ter "swap mais estável" — sem entender que a otimização só vale para o caso correto. Fix óbvio (validação no clique do CTA) chega tarde demais. Fix correto: validação inline no momento da seleção — quando StableSwap é escolhida e o par já está preenchido, exibir warning imediato ("BNB e CAKE não são pareados — StableSwap pode causar perdas para esse par. Escolha V3 ou Infinity") com link para corrigir.

🔴 Fricção 2 (cosmética — afeta iniciante e intermediário): o passo 3 mostra "Tipo de Pool, Classic" — repete o pattern CSV-like da tela R1 mas aqui com apenas uma tag ("Classic"). Estrutura "Categoria, Valor" é confusa: parece que "Tipo de Pool" é um item separado de "Classic". Iniciante pode interpretar como "escolhi Tipo de Pool e também Classic" — quando na verdade é apenas "Classic" sob a categoria "Tipo de Pool". Alternativa: pílula nomeada ("Tipo: Classic") ou label segregada ("Curva: Classic").

🔴 Fricção 3 (cosmética): "StableSwap" e "Classic" permanecem em inglês dentro de UI PT-BR ("SELECIONE ONDE FORNECER LIQUIDEZ", "ESCOLHA O PAR DE TOKENS", "FILTRO DE POOL"). Mistura PT-EN comum nas telas Pancake (já observada em R1 Limite, R5 Comprar, R14 Pools). Alternativa: manter "StableSwap" como termo de produto (justificável — é nome de feature), traduzir "Classic" para "Padrão" ou "Clássico".

🟡 Oportunidade competitiva (alta leverage no target): seletores de pool que aceitam qualquer combinação token+versão sem validar adequação são padrão entre DEX (Uniswap, Pancake, Curve permitem combinações que não fazem sentido financeiro). Passa nas 4 perguntas: convenção entre concorrentes ✓; afeta iniciante diretamente (perda financeira real) ✓; ninguém investiu por respeito ao princípio "user choice" e medo de paternalismo ✓; diferenciação perceptível ✓ (e proteção contra perda real). Diferencial Kotai: validação de adequação par↔protocolo no momento da seleção, com warning sério para combinações tóxicas (par volátil em StableSwap, par stable em V3 high-fee). Trade-off: precisa de heurística confiável para classificar pares como "correlacionados" ou "voláteis" — possível com price feed + correlação histórica.

Observação adicional: o passo 3 do StableSwap não tem "(opcional)" no label, sugerindo obrigatoriedade — mas o campo já vem pré-preenchido com "Classic". Se há um valor default válido, o passo na prática não exige decisão do usuário, e a ausência do "(opcional)" gera ansiedade sem ganho real. Vale verificar se o produto suporta múltiplos sub-tipos hoje ou se "Classic" é o único — se for único, esconder o passo 3 aqui também seria coerente.

2. Pools — Catálogo "Todos os pools" + filtro de redes aberto

Função: lista completa de pools de liquidez disponíveis, ordenável por APR/TVL/Volume 24h, com filtros de rede, busca, versão de protocolo e tipo. Estado mostra popover do filtro de redes aberto e tabela populada com pools em V2, V3 e CLAMM.

Componentes: tabs "Todos os pools" (ativa) / "Minhas posições"; CTAs "Criar Pool" + "Adicionar liquidez +"; filtro de rede "All networks +6" com popover aberto (toggle master + 9 redes com check verde individual: Solana, BNB Smart Chain, Ethereum, ZKsync Era, Arbitrum One, Linea Mainnet, Base, opBNB, Monad); search; segmento Tudo/Infinity/V3/V2/StableSwap; cabeçalho da tabela com colunas ordenáveis: Par, [badge versão+fee], APR, TVL, Volume 24h, Tipo de pool, Característica do pool, kebab; linhas: avatar do par + nome + rede + badge "V3 | 0,01%" / "V2 | 0,xx%" / "Infinity | 0,01%"; valores como APR 150,76% / TVL $15,4M / Volume $37,4M / Tipo V2/V3/CLAMM; coluna "Característica do pool" toda preenchida com "–".

Regras de negócio: APR, TVL e Volume 24h são ordenáveis (setas no header). Badge de versão expõe protocolo (V2 constant product, V3 concentrated liquidity, Infinity stableswap variante, CLAMM tipo novo). Fee tier é parte do identificador da pool junto ao par (mesma combinação Par+Fee+Versão é o que define unicidade). "Característica do pool" parece ser campo opcional para tags especiais (hook, dynamic fee, etc.) — atualmente nulo na maioria dos registros.

🟢 Insight: expor "Tipo de pool" como coluna dedicada (não embutida no nome) é decisão correta e diferencial frente a Uniswap, onde a versão fica escondida no card. Reconhece que mecânica do AMM é informação de decisão, não detalhe técnico. Combinar APR + TVL + Volume 24h ordenáveis na mesma linha entrega o trinômio que o intermediário precisa pra escolher sem clicar.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): "Tipo de pool" aparece como tag opaca (V2 / V3 / CLAMM / Infinity) sem tradução por consequência. O usuário-alvo não sabe se V3 é "melhor" que V2, se CLAMM é seguro, ou o que muda entre Infinity e StableSwap. Fix óbvio (tooltip com definição técnica) explica o termo mas não responde à pergunta real: "qual eu uso?". Fix verdadeiro: rotular pelo trade-off do usuário ("Concentrada — APR maior, exige gestão de range" / "Constant product — APR menor, sem gestão" / "Stable-stable — baixo risco") com a tag técnica em modo secundário pra quem busca explicitamente. Kotai: nome técnico nunca é o label primário em ponto de decisão; ele acompanha a consequência.

🔴 Fricção 2 (estrutural — afeta iniciante; recorrência do problema de sistema): filtro "All networks" mostra 9 redes em lista plana, sem agrupamento (Mainnets / L2s / experimentais) e sem priorização contextual (redes onde o usuário tem saldo). opBNB, Linea, ZKsync Era e Monad são ruído pro iniciante vindo de CEX. É o mesmo padrão já observado no Search Overlay (relatório 7 do Swap) — não é fricção isolada desta tela, é problema sistêmico do produto. Fix verdadeiro: priorizar redes da carteira conectada no topo, agrupar visualmente Mainnets / L2s / Outras, manter "Todas" como toggle master. Sem wallet, defaultar a mainnets relevantes ao usuário (BNB Chain primeiro num produto Pancake-first).

🔴 Fricção 3 (cosmética — afeta todo perfil): coluna "Característica do pool" aparece em 100% das linhas visíveis com "–". Ou ela tem semântica para subconjunto raro (e nesse caso não pertence ao primeiro paint), ou nunca foi populada. Em qualquer cenário, ocupa largura da tabela sem entregar informação e reduz espaço pras colunas de decisão (APR/TVL/Volume). Fix: ocultar coluna quando 100% dos registros da página são vazios; reaparecer condicionalmente quando há valor.

🟡 Oportunidade competitiva (alta leverage no target): catálogo de pools como tabela plana ordenável é convenção entre Uniswap, Pancake, Curve, SushiSwap. Pro iniciante e intermediário inicial, escolher pool num catálogo de centenas/milhares é overload — não há recomendação personalizada nem filtro por intent. Passa nas 4 perguntas: ✓ todos fazem catálogo plano; ✓ afeta target direto (paradoxo da escolha + risco de IL não compreendido); ✓ ninguém resolveu por falta de investimento em scoring de risco, não por impossibilidade; ✓ perceptível ("o produto me explicou o risco antes de eu entrar" vs. "entrei numa pool e perdi por IL sem saber por quê"). Diferenciação Kotai: scoring de risco por pool baseado em volatilidade do par, profundidade, idade do contrato e correlação dos ativos; filtros de intent ("APR alto", "baixo risco", "stable-stable") acima da tabela. Trade-off: scoring exige metodologia auditável e atualização contínua; errar destrói confiança mais rápido do que acertar a constrói.

Observação adicional: o popover de filtro de redes está aberto cobrindo a coluna "Par" da tabela, o que impede o usuário de validar o efeito do filtro em tempo real (não vê a lista mudar enquanto desmarca rede). Em tela larga isso é desperdiçar a vantagem do desktop — o popover poderia ser side panel não-modal, permitindo seleção + preview simultâneos. Não é fricção crítica isolada, mas reforça o tema de "interfaces feitas pra catálogo cru, não pra exploração guiada".

1. Pools — Landing "Ganhe com LP" (Minhas posições, vazio)

Função: porta de entrada da seção de yield. Reúne Farms/Liquidez e Syrup Pools sob hero "Ganhe com LP", com curadoria editorial (Escolhas Pancake), tabs de catálogo vs. posições do usuário, e CTAs para criar pool ou adicionar liquidez. Estado mostra "Minhas posições" como default, carregando.

Componentes: header com Trade/Perpétuos/Ganhar/Jogar/IA + busca "/" + settings + wallet $0.00; sub-tabs "Farm / Liquidez" (ativa) e "Pools de Syrup"; hero "Ganhe com LP — Pools e Farms de liquidez" + links "Saiba como" e "Página de liquidez anterior"; card "Escolhas Pancake #2 — USDC/MUSD" com Fee Tier 0,01% / APR 24,82% / TVL 88,03K + paginação por dots; tabs "Todos os pools" / "Minhas posições" (ativa); CTAs "Criar Pool" + "Adicionar liquidez +"; filtros: rede (All networks +6), search, segmento (Tudo/Infinity/V3/V2/StableSwap); filtros de status (Tudo/Ativo/Inativo/Fechado), toggle "Apenas Farms", ícone de histórico; lista com skeleton + "Carregando…".

Regras de negócio: Farm/Liquidez e Syrup são produtos com mecânica distinta (dual-asset com LP + emissão vs. single-asset stake → reward em outro token). "Minhas posições" depende de carteira conectada — sem wallet a lista nunca resolve para conteúdo. Filtros de versão refletem migração de protocolo (V2/V3/Infinity/StableSwap coexistem). "Apenas Farms" filtra pools sem emissão de CAKE. "Página de liquidez anterior" sinaliza legado mantido por compatibilidade.

🟢 Insight: "Minhas posições" como tab default é decisão certeira pro recorrente — entra pra ver o que tem, não pra navegar o catálogo. Card "Escolhas Pancake" funciona como curadoria editorial e ataca diretamente o paradoxo da escolha em pools (centenas disponíveis). "Ganhe com LP" + "Saiba como" inline traduz a intenção do usuário antes do vocabulário técnico.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): dois eixos de tab no mesmo plano cognitivo. "Farm/Liquidez" vs. "Pools de Syrup" é eixo de produto; "Todos os pools" vs. "Minhas posições" é eixo de visão (catálogo vs. pessoal). O usuário precisa entender uma matriz 2×2 (Farm+Minhas, Farm+Todos, Syrup+Minhas, Syrup+Todos) que a UI não evidencia — Syrup vira link discreto ao lado da tab ativa, sem indicar que é par. Fix óbvio (unificar tudo numa tabela com filtro de tipo) falha porque Syrup tem mecânica distinta — misturar piora a leitura. Fix verdadeiro: tornar Farm/Syrup segmento primário (controle único, peso forte) e Todos/Minhas sub-tab dentro de cada produto. Kotai: segmento de produto sempre acima do segmento de visão, hierarquia visual explícita.

🔴 Fricção 2 (cosmética — afeta iniciante): "Carregando…" não distingue "buscando suas posições" de "você não tem posições" nem de "você não conectou carteira". Sem wallet, a lista nunca resolve — o iniciante fica observando skeleton sem saber que a pré-condição é conectar. Fix: empty state explícito com pré-requisito inline ("Conecte sua carteira para ver suas posições") + CTA de conexão na própria área da lista.

🔴 Fricção 3 (cosmética — ruído em estado vazio): filtros de status (Tudo/Ativo/Inativo/Fechado) aparecem mesmo quando "Minhas posições" está vazio. Não há o que filtrar entre Ativo e Inativo se não existe posição. Fix: ocultar filtros de status até que exista ≥1 posição; reaparecem com a primeira.

🟡 Oportunidade competitiva (alta leverage no target): o card "Escolhas Pancake" é exatamente o que o iniciante precisa (par + Fee Tier + APR + TVL num bloco com curadoria), mas é tratado como banner promocional rotativo, não como caminho recomendado. Uniswap, 1inch, Curve entregam catálogo cru sem recomendação personalizada. Passa nas 4 perguntas: ✓ convenção entre concorrentes; ✓ afeta iniciante direto (paradoxo da escolha em pools); ✓ ninguém resolveu por falta de investimento em scoring/curadoria, não por impossibilidade; ✓ diferenciação perceptível ("o produto me recomendou pool seguro" vs. "caí num catálogo de 800 pares"). Diferenciação Kotai: pool finder por perfil (conservador/moderado/agressivo) com pré-seleção stable/blue-chip/yield alto e justificativa de risco visível. Trade-off: exige metodologia transparente de scoring — classificar errado destrói confiança; demanda manutenção contínua.

Observação adicional: "Página de liquidez anterior" como link na hero é honestidade de produto (sinaliza migração V2→V3→Infinity), mas em uma landing de aquisição polui a leitura. Faz mais sentido como item dentro de Settings ou Help, não competindo visualmente com "Saiba como".

4. Modal de busca de pool — Estado carregado

Função: Mesma busca, agora populada com pools reais ordenáveis por APR e TVL. Permite ao usuário comparar oportunidades e trocar para outro pool com 1 clique.

Componentes: mesmo modal de busca; lista de pares com avatares duplos, nome do par (SKYAI/WBNB, USDT/WBNB, USDT/BTCB, TAG/WBNB, B/USD1...), badge de tipo + fee tier (V2|0,25% / V3|0,01% / V3|0,05%), coluna APR ordenável com ícone de gráfico (150,76% / 26,48% / 21,84% / 157,86% / 62,01%), coluna TVL ordenável ($15,40M / $15,65M / $19,52M / $2,69M / $2,91M); header das colunas "PARES / APR / TVL" com chevrons de ordenação.

Regras de negócio: APR e TVL vêm do subgraph em janelas de 24h–7d. Pools com baixo TVL e alto APR tipicamente refletem (a) volume concentrado em pouca liquidez ou (b) emissões de incentivo elevadas para atrair liquidez nova. Ordenação default não é explícita na UI (parece ser por TVL desc, mas inconsistente — TAG e B aparecem com TVL baixo).

🟢 Insight: exibir tipo + fee tier ao lado do par (V3|0,05%) é informação densa mas necessária — usuário compara pools "iguais" do mesmo par em fee tiers diferentes. Colunas APR e TVL ordenáveis com chevrons explícitos respeitam o mental model do trader/LP que quer scanning rápido.

🔴 Fricção 1 (estrutural — afeta iniciante): APRs de 150,76% e 157,86% aparecem sem contexto de risco. Iniciante vê "150% ao ano" e tem duas reações possíveis, ambas ruins: ou conclui "isso é golpe" e sai, ou conclui "achei dinheiro fácil" e entra sem entender impermanent loss e baixo TVL. Não há badge de risco, indicador de IL, marcação de "token novo / não verificado". Diagnóstico errado: esconder pools com APR alto — pune oportunidades legítimas. Alternativa: badge contextual ao lado do APR ("⚠ APR elevado costuma vir de baixo TVL ou token novo — confira antes") clicável para explicação curta. Trade-off: pode reduzir clique em pools high-yield; ganho de proteção compensa.

🔴 Fricção 2 (estrutural — afeta iniciante): pares com símbolos opacos ("B / USD1", "TAG / WBNB", "SKYAI / WBNB") + ícones genéricos coloridos não dão âncora pra avaliar se o token é legítimo. "B" é símbolo de um token, "USD1" é stablecoin alternativa pouco conhecida — o iniciante não tem como decidir. Alternativa: tooltip ao hover do ícone com nome completo do projeto, contract address truncado, link para explorer e flag "Não verificado" quando aplicável. Trade-off: aumenta complexidade do componente; ganho de proteção contra rugpull é alto.

🔴 Fricção 3 (cosmética): o critério de ordenação default não é evidente — chevrons aparecem ao lado de APR e TVL mas nenhum está marcado como ativo. Alternativa: marcar visualmente a coluna ordenada e direção (↓/↑ destacado).

🟡 Oportunidade competitiva: nenhum DEX importante sinaliza risco de pool inline na listagem — Uniswap, Curve, Pancake mostram catálogo "neutro" e empurram o ônus de avaliação para o usuário, que tipicamente nem sabe o que avaliar. Critério: ✓ todos fazem igual, ✓ afeta iniciante e intermediário, ✓ razão é falta de investimento em curadoria/risco (não impossibilidade — TVL, idade do contrato e verificação do token são dados públicos), ✓ ganho perceptível e protetivo. Alternativa: score de risco simples (baixo/médio/alto) baseado em TVL + idade do pool + verificação dos tokens + concentração de holders, exposto como badge na linha. Trade-off: definir critérios públicos para não virar "blacklist arbitrária" exige governança.

3. Pools — Tooltip do badge de versão+fee (hover em "V3 | 0,05%")

Função: Tooltip contextual disparado por hover sobre o badge de versão+fee tier na coluna "Nível da comissão". Traduz o código compacto ("V3 | 0,05%") para o nome legível ("V3 LP — Nível de taxa de 0,05%"). Estado mostra hover na linha USDT/BTCB.

Componentes: badge da linha (versão + fee) em estado hover; tooltip dark com título "V3 LP" + linha secundária "Nível de taxa de 0,05%"; seta apontando para o badge de origem; restante da tabela permanece interativa abaixo.

Regras de negócio: o badge condensa duas informações (versão de protocolo e fee tier) em um único token visual; o tooltip aparece apenas em desktop por depender de hover; o conteúdo é literal — só repete o que já está no badge em forma expandida, sem agregar consequência ou comparação entre tiers.

🟢 Insight: reconhecer que o badge "V3 | 0,05%" é compacto demais e merece tradução é decisão acertada — admite que a densidade da tabela cobra um custo de leitura. Manter o tooltip discreto, dark, com seta clara, respeita o gesto de hover sem competir com o conteúdo da linha.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): o tooltip é literal e tautológico — diz "V3 LP, Nível de taxa de 0,05%" para quem hover em "V3 | 0,05%". Para o iniciante, a pergunta real não é o que o código significa em palavras, e sim qual a consequência de escolher V3 0,05% vs. V3 0,01% vs. V2 0,25%. O fix óbvio (link "Saiba mais") empurra o problema pra outra tela e quebra fluxo. Fix verdadeiro: tooltip com uma linha de consequência por tier ("0,05% — recomendado para pares voláteis; taxa maior compensa risco de IL") + a tag técnica embaixo. Trade-off: exige curadoria de copy por combinação versão×fee, não pode ser gerado automaticamente sem perder qualidade.

🟡 Oportunidade competitiva (média leverage no target): todos os concorrentes (Uniswap, Curve, Sushi) tratam fee tier como número técnico sem tradução por intent. Passa nas 4 perguntas: ✓ convenção entre concorrentes; ✓ afeta iniciante e intermediário direto (escolher tier errado = retorno menor ou IL maior); ✓ não resolvido por falta de investimento em copy contextual, não por impossibilidade; ✓ perceptível ("entendi por que existe esse tier" vs. "chutei 0,05% porque era o primeiro"). Diferenciação Kotai: cada tier acompanhado de label de uso recomendado (stable-stable / blue-chip / volátil / exótico) no próprio badge, com tooltip aprofundando o porquê. Trade-off: aumenta peso visual do badge; precisa de regra clara de classificação.

Observação adicional: o tooltip está bem posicionado mas cobre parcialmente o badge da linha de baixo (USDT/WBNB). Em listas densas, hover de tooltip que cobre conteúdo adjacente força o usuário a mover o cursor pra ler e quebra a comparação visual entre linhas — comportamento típico de tooltip não-aware do layout.

6. Filtro de Pool aberto (Infinity)

Função: Dropdown do passo 3 do form, expandido. Mostra árvore hierárquica de critérios para filtrar quais pools Infinity aparecerão na próxima tela. Permite refinar a busca por mecânica de AMM e por features do pool.

Componentes: árvore com checkboxes verdes (todos marcados por default) e chevrons de expansão; nível 1: "Todos os pools" (master); nível 2 sob ele: "Tipo de Pool" e "Característica do Pool"; nível 3 sob "Tipo de Pool": CLAMM, LBAMM; nível 3 sob "Característica do Pool": Dynamic Fees, Liquidity Incentivisation, Yield Optimisation (truncado no viewport — scroll vertical no dropdown).

Regras de negócio: todos os filtros ligados por default = todos os pools elegíveis. Hierarquia em árvore: marcar/desmarcar nó pai propaga aos filhos. Permite combinar mecânica (CLAMM/LBAMM) com features de gestão (fees dinâmicas, incentivos, otimização de yield).

🟢 Insight: estrutura em árvore com checkbox master + sub-níveis é decisão correta — Pancake reconhece que filtro de pool é decisão multi-dimensional (mecânica × features), não lista plana. Default "tudo ligado" é coerente com o sufixo "(opcional)" no label: usuário pode avançar sem tocar e ver todos os pools. Convenção válida bem aplicada (árvores de checkbox = padrão de Finder, Outlook, ferramentas de filtro).

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário, severidade alta): todas as labels técnicas do filtro estão em inglês e sem definição: "CLAMM", "LBAMM", "Dynamic Fees", "Liquidity Incentivisation", "Yield Optimisation". Apenas "Todos os pools", "Tipo de Pool" e "Característica do Pool" estão em PT-BR — mistura de idiomas dentro do MESMO componente. Iniciante BR não decodifica CLAMM (Concentrated Liquidity AMM) nem LBAMM (Liquidity Book AMM); intermediário lê "Dynamic Fees" e não sabe se quer ligar ou desligar. Fix óbvio (traduzir tudo) falha em parte — termos como CLAMM são acrônimos de design de AMM que perdem precisão técnica em PT. Fix correto: label semântica em PT como primária ("Liquidez concentrada", "Liquidez em livros") + acrônimo técnico em parênteses para reconhecimento ("Liquidez concentrada (CLAMM)"); ícone "?" por item com definição de 1 linha + exemplo.

🔴 Fricção 2 (estrutural — afeta iniciante): filtro é descrito como "opcional" no label do passo 3, mas o conteúdo expandido é cognitivamente caro — 5+ termos técnicos hierarquizados. "Opcional" comunica "você pode pular", mas o iniciante curioso que abre o dropdown encontra complexidade que não consegue avaliar nem confirmar ("se eu desmarcar Dynamic Fees, perco o quê?"). A própria existência do filtro ensina o usuário que há algo importante ali — depois, ao não entender, ele cancela. Pior que esconder o filtro seria mostrá-lo sem permitir compreensão. Alternativa: defaultar fechado, com label "Filtros avançados" e indicação "toque para refinar". Quem abre é minoria que sabe o que procura — calibrar o esforço de design para esse subset.

🔴 Fricção 3 (cosmética): checkboxes verdes com check brancos é ok, mas o padrão visual idêntico em todos os níveis (Todos os pools, Tipo de Pool, CLAMM) não comunica hierarquia — só a indentação diferencia. Em listas longas com scroll, perde-se contexto de qual nó pai está afetando os filhos. Alternativa: estilo distinto para nós-pai (semibold, ícone de pasta) vs filhos.

🟡 Oportunidade competitiva (média leverage no target): filtros de pool baseados em mecânica de AMM são padrão em DEX com múltiplos modelos (Uniswap V3 fee tiers, Curve crypto pools vs stable, Balancer weighted vs stable). Todos expõem vocabulário interno sem tradução. Passa nas 4 perguntas: convenção entre concorrentes ✓; afeta iniciante e intermediário ✓; ninguém investiu por priorizar precisão técnica ✓; perceptível ✓. Diferencial Kotai: filtros nomeados pela consequência financeira ao usuário ("Pools de alto risco", "Pools com taxa dinâmica", "Pools incentivados com farming") com mecânica técnica em sub-label. Trade-off: precisa de copy curatorial validada com usuários reais; risco de simplificação enviesar a escolha.

7. Filtro de Pool aberto (StableSwap)

Função: Mesmo componente do R6, agora no contexto StableSwap. Mostra que a árvore de filtros é dinâmica: muda conforme o protocolo escolhido no passo 1.

Componentes: árvore com 2 níveis apenas; nível 1: "Tipo de Pool" (checkbox marcado); nível 2: "Classic" (único item, marcado). Label do passo 3 sem "(opcional)" — diferente do Infinity (R1/R6). URL: /liquidity/select/bsc/stableSwap/....

Regras de negócio: StableSwap tem apenas um sub-tipo configurável hoje ("Classic"). A árvore reflete a taxonomia real do protocolo, sem "Característica do Pool" (que é conceito Infinity, não StableSwap). Default "Classic" marcado significa: mostrar todos os pools (não há outro tipo para excluir).

🟢 Insight: o mesmo componente do R6 escala honestamente para baixo — em vez de mostrar campos vazios ou seções inexistentes, StableSwap exibe só a folha relevante ("Classic"). Confirma que a árvore é gerada a partir da taxonomia real do protocolo, não hardcoded. Boa engenharia de progressive disclosure.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário, severidade alta): filtro com um único item filho ("Classic" sob "Tipo de Pool") não filtra nada — marcar ou desmarcar tem efeito binário trivial (mostrar tudo vs mostrar nada). É um filtro vazio de função, mantido por consistência arquitetural com o R6. Iniciante abre, vê 1 checkbox, e fica confuso: "o que escolher se só tem uma opção?". Pior: a remoção do sufixo "(opcional)" do label (vs R1 Infinity) sugere obrigatoriedade — mas decisão é não-decisão. Fix óbvio (manter o filtro por consistência) falha — consistência com componente sem função vira incoerência semântica. Fix correto: esconder o passo 3 inteiro quando há ≤1 sub-tipo, como já é feito em V2 e V3 (R2/R3); reaparece se Pancake adicionar novos sub-tipos de StableSwap no futuro.

🔴 Fricção 2 (estrutural — afeta iniciante): ausência do "(opcional)" no label cria dissonância — usuário interpreta como passo obrigatório, mas o campo já vem pré-preenchido válido. Microcopy inconsistente entre os mesmos componentes (Infinity tem "opcional", StableSwap não tem) sem razão visível ao usuário. Diagnóstico errado seria "adicionar (opcional) no StableSwap também"; o fix real é a fricção 1 (esconder o passo). Mantida aqui como sintoma reforçando o caso.

🔴 Fricção 3 (cosmética): "Classic" em inglês dentro de UI PT-BR — mesma fricção sistêmica de localização incompleta (já apontada em R4, R6, R14 Pools). Alternativa: "Padrão" ou "Clássico".

Não é 🟡: preservar UI vazia por consistência arquitetural é decisão de Pancake-específica (Uniswap esconde campos sem efeito; 1inch também). Não passa na pergunta 1 — não é convenção uniforme entre concorrentes. Vira fricção localizada Pancake, não diferenciação competitiva.

Observação adicional: vale verificar histórico do produto — se "Classic" sempre foi único tipo de StableSwap, esse filtro é dead UI desde o lançamento. Se há plano de adicionar "V2 Stable", "Crypto-Stable" etc., o componente está antecipando expansão. No primeiro caso, é tech debt; no segundo, é decisão de arquitetura forward-looking. Em ambos, hoje o usuário paga o custo de ler um filtro inútil — esconder até existir segundo sub-tipo é a decisão correta independentemente do roadmap.

2. Form Adicionar Liquidez — V3 selecionado

Função: Mesmo form do R1, agora com V3 ativo na pílula segmentada. Mostra o comportamento dinâmico do card: a escolha de protocolo altera os passos visíveis abaixo.

Componentes: breadcrumb idêntico ao R1; card com pílula segmentada (V3 ativo); dropdown de rede "BNB Chain"; passo 2 com par BNB + CAKE; passo 3 "Filtro de pool" não aparece; CTA "Próximo".

Regras de negócio: ao alternar Infinity → V3, o passo 3 desaparece silenciosamente. URL muda (/liquidity/select/bsc/v3/...). V3 da Pancake usa fee tiers fixos selecionados na tela seguinte; por isso o filtro de "tipo de pool" do Infinity não existe aqui. O card encurta sem aviso visual.

🟢 Insight: esconder o passo 3 quando ele não se aplica é decisão correta — evita o anti-padrão "campo desabilitado mas visível" que polui forms. O card se reorganiza conforme a versão escolhida, refletindo honestamente que V3 e Infinity têm modelos de configuração diferentes.

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário): a numeração 1→2→3 da tela R1 estabelece modelo mental de "fluxo de 3 passos". Aqui, ao trocar para V3, o passo 3 some sem transição visual ou explicação. Usuário que estava no passo 3 do Infinity e clica em V3 perde contexto: "sumiu o filtro? eu errei alguma coisa?". Fix óbvio (manter passo 3 desabilitado com label "não aplicável em V3") falha — adiciona ruído permanente. Fix correto: animação curta de colapso + microcopy abaixo da pílula explicando o que mudou ("V3 usa taxa fixa — você escolherá na próxima etapa"). Comunica a consequência da escolha em vez de simplesmente reorganizar a UI.

🔴 Fricção 2 (estrutural — afeta iniciante): a pílula Infinity/V3/V2/StableSwap não comunica trade-off entre versões. Iniciante vê 4 botões com nomes ininteligíveis e nenhum tem badge "recomendado", "mais usado", "mais simples" ou "melhor para par estável". A escolha é apresentada como neutra quando, na prática, há quase sempre uma versão objetivamente melhor para o par. Diagnóstico errado seria "falta de tooltip"; a fricção real é ausência de recomendação. Alternativa: badge "Sugerido para BNB+CAKE" sobre a versão recomendada, e ordenar a pílula com a recomendada primeiro.

Não é 🟡 (armadilha 1a): reorganização dinâmica de form conforme seleção é convenção válida na web (Stripe Checkout, Shopify admin). O problema não está em esconder o passo, mas em fazer isso sem feedback — fricção localizada da tela Pancake, não diferenciação competitiva. A oportunidade estrutural (ausência de recomendação de protocolo) já foi elevada a 🟡 no R1; não duplicar aqui.

Observação adicional: o seletor de rede "BNB Chain" continua no passo 1 mesmo em V3 — sugere que rede é variável independente do protocolo. Em produção, nem toda combinação rede+protocolo existe (V3 pode não estar deployado em todas as chains). A tela não sinaliza restrição até o usuário tentar. Possível fricção em tela subsequente.

9. Modal Connect Wallet — Estado de loading (aguardando confirmação)

Função: Estado pós-clique em Connect (Trust Wallet, neste caso). Painel direito muda pra estado de espera enquanto Pancake aguarda o usuário confirmar a conexão na própria wallet (popup externo, fora da Pancake).

Componentes

• Painel esquerdo: seletor inalterado, com More Wallets visível por scroll (Coinbase/WalletConnect/Opera começando a aparecer)
• Painel direito:
  • Ícone Trust Wallet centralizado
  • Label "Trust Wallet"
  • Texto "Please confirm in Trust Wallet"
  • Spinner sutil abaixo
• Sem CTAs no painel direito (estado bloqueado, sem ação possível da Pancake)

Regras de negócio

• Após clicar Connect (EVM ou Solana), Pancake dispara request à wallet via injected provider/extension API
• A wallet (Trust Wallet aqui) abre popup próprio pedindo confirmação ao usuário — fora do contexto da Pancake
• Enquanto Pancake aguarda callback de resposta, mostra esse estado
• Sem timeout visível, sem botão de cancelar — o usuário só pode fechar o modal manualmente
• Se o popup da wallet for fechado/dismissado, Pancake provavelmente fica indefinidamente nesse estado (não há feedback de erro óbvio)

🟢 Insight Decisão correta de criar estado dedicado de espera em vez de fechar o modal ou mostrar overlay vazio. "Please confirm in Trust Wallet" é direção explícita — o usuário sabe pra onde olhar (popup da wallet) em vez de ficar perdido entre Pancake e extension. Ícone + nome da wallet repetidos no painel ancoram visualmente "é dessa wallet que você está esperando confirmação", evitando confusão se o usuário tiver múltiplas wallets instaladas.

^insight-1

🔴 Fricção 1 (estrutural — handoff sem rota de saída, afeta todos) O estado não oferece nenhuma ação pro usuário se a confirmação não acontecer: sem botão de cancelar, sem "tentar novamente", sem timeout visível, sem link "problema com sua wallet?". Spinner indefinido. Casos comuns onde isso vira armadilha:

• Popup da Trust Wallet aberto atrás de outras janelas → usuário não vê e Pancake espera para sempre
• Popup bloqueado pelo browser → usuário não percebe que nada apareceu
• Usuário fecha o popup sem clicar nada → Pancake não detecta e fica esperando
• Usuário desiste e quer trocar wallet → tem que descobrir que precisa fechar o modal (X no canto) e reabrir

Fix óbvio (timeout com mensagem de erro) só resolve um dos casos. Fix correto: estado ativo, não passivo. Mostrar "Não viu o popup? [Reabrir popup da Trust Wallet]" + "Mudou de ideia? [Voltar pra escolher outra wallet]". Trade-off: "Reabrir popup" depende de API da wallet permitir re-trigger (Metamask, Trust Wallet tipicamente permitem).

Direcionamento Kotai: estados de espera nunca são becos sem saída. Sempre oferecer (a) reabrir/retentar a ação externa e (b) abandonar/trocar — independente da resposta do sistema externo.

^friccao-1

🔴 Fricção 2 (cosmética — afeta iniciante) "Please confirm in Trust Wallet" assume que o iniciante sabe O QUE significa confirmar e ONDE achar o popup. Iniciante vindo de CEX nunca viu popup de extension antes; pode procurar dentro da própria página da Pancake ("onde tá esse confirm?"). Sem captura visual ou setinha apontando pra extension ícone do browser, o instructional copy fica abstrato.

Fix correto: microcopy com referência espacial concreta ("Abra a Trust Wallet no canto superior direito do seu browser — ela está pedindo permissão pra conectar") ou mini-screenshot/diagrama mostrando onde o popup aparece. Trade-off: copy mais longa, vale pro iniciante.

^friccao-2

🔴 Fricção 3 (cosmética — afeta intermediário com múltiplas wallets) Intermediário com Metamask + Trust Wallet + Phantom instalados simultaneamente pode receber popup de outra wallet por engano (race condition entre injected providers) — ou simplesmente confundir qual wallet está pedindo. O painel direito repete "Trust Wallet" duas vezes (ícone + label + nome no texto), o que ajuda, mas não resolve o caso de wallet errada respondendo.

Observação: isso é mais problema do paradigma EOA + injected provider que da Pancake. Mas vale anotar como caso de borda do fluxo.

^friccao-3

🟡 Oportunidade competitiva (média leverage) Estados de "aguardando confirmação na wallet" são pontos cegos de UX em DEXes — Uniswap, 1inch, Pancake fazem todos versão similar: spinner + "confirm in wallet" + nada mais. Passa nas 4 perguntas: (1) convenção entre concorrentes; (2) afeta iniciante diretamente (perfil mais propenso a fechar popup ou se perder); (3) ninguém resolveu por falta de investimento em fluxos de fallback/retry; (4) perceptível ("a Kotai me deixou retentar sem fechar tudo").

Diferenciação Kotai: estados de espera ativos — sempre com (a) re-trigger explícito ("abrir popup novamente"), (b) opção de abandonar ("trocar wallet"), (c) timeout visível com sugestão concreta após N segundos ("o popup pode estar bloqueado — verifique seu browser"). Trade-off: requer instrumentação detalhada por wallet (cada injected provider tem comportamento próprio); aumenta superfície de manutenção.

Observação adicional: o painel esquerdo continua interativo durante o loading (scroll funcionando, More Wallets visível). Isso pode parecer feature ("posso mudar de ideia"), mas também pode confundir — se o usuário clicar em outra wallet enquanto Trust Wallet espera, qual conexão prevalece? Vale testar comportamento.

^oportunidade-1

8. Modal Connect Wallet — More Wallets expandido

Função: Estado pós-clique em "More Wallets +11". O seletor à esquerda colapsa a Top + Social e mostra grid de wallets adicionais. Painel direito mantém o último estado contextual (no print, ainda "OKX is not installed" + QR — provavelmente porque o usuário tinha clicado em OKX antes de abrir More Wallets).

Componentes

• Header "Connect Wallet" + X
• Card Social Login ainda no topo
• Section "MORE WALLETS" com chevron pra cima (estado expandido)
• Grid de wallets visíveis: Coinbase Wallet, WalletConnect, Opera Wallet, Brave Wallet, Rabby Wallet, MathWallet, TokenPocket, SafePal, Coin98 (e mais, com scroll vertical na lista)
• Painel direito: estado anterior (OKX not installed + QR + links Install/Setup Guide)

Regras de negócio

• Top Wallets (4 cards) é a curadoria default; More Wallets desbloqueia +11 opções
• Toggle expandir/colapsar via chevron
• Critério de ordenação dentro de More Wallets não é evidente (popularidade? parceria? alfabético? não-explicitado)
• Painel direito não reseta quando More Wallets expande — herda contexto da última wallet clicada

🟢 Insight Progressive disclosure correta: Top Wallets visível por default, More colapsado. Usuário avançado expande quando precisa. Total de 15 wallets organizadas em 2 níveis sem virar wall of icons. Inclusão de WalletConnect entre as More (não no Top) também é decisão útil — WalletConnect é meta-protocolo (lista de wallets), faz sentido não competir com wallets diretas no Top.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário) Critério de ordenação dentro de More Wallets não é evidente. Coinbase Wallet (provavelmente top 5 globalmente em volume e a wallet onboarding mais comum entre iniciantes vindos de Coinbase exchange) aparece em More, não no Top. Pancake favorece BNB-aligned wallets no Top — decisão estratégica consciente, mas pro iniciante vindo de Coinbase fica confuso: ele procura, não vê no Top, pode achar que Pancake não suporta Coinbase Wallet, e abandona ou cai num suporte equivocado.

Fix óbvio (mover Coinbase pro Top) viola posicionamento da Pancake. Fix correto: campo de search inline no header do seletor ("Procurar wallet") que filtra ambos os grupos — usuário digita "Coinbase" e vê ela imediatamente, independente do grupo. Curadoria continua válida pra quem não procura; busca atende quem sabe o que quer.

Direcionamento Kotai: seletor de wallet com search-first; grupos viram pistas visuais, não barreiras de descoberta.

^friccao-1

🔴 Fricção 2 (estrutural — paridade visual injusta, afeta iniciante) Todos os 9+ ícones de wallet no grid têm peso visual idêntico (mesmo tamanho, borda, posição). Mas representam wallets com modelos radicalmente diferentes:

• Coinbase Wallet (custodial-adjacent, vinculada a exchange)
• WalletConnect (meta-protocolo, não wallet em si — abre lista de wallets)
• Brave/Opera Wallet (built-in no browser, sem extension)
• Rabby Wallet (multi-chain focada, com tx simulation)
• TokenPocket / SafePal / Coin98 / MathWallet (regionais, predominantemente Ásia)

Iniciante não decodifica essas diferenças. Pra ele, todos os 9 são "wallet diferente". Sem filtro por modelo (browser-built-in / exchange-linked / regional / multi-chain), sem ordenação por relevância pro contexto (BNB ecosystem / EVM / Solana).

Fix óbvio (categorizar visualmente os subgrupos) infla a UI. Fix correto: agrupamento sutil por contexto da chain default (BNB Chain → mostra wallets BNB-friendly primeiro; se Solana selecionada antes, prioriza Phantom/Solflare nas More). Iconografia leve de tipo (badge "exchange" / "browser" / "mobile") sem mudar layout.

^friccao-2

🔴 Fricção 3 (cosmética → bug — painel direito não reseta) O painel direito ainda mostra "OKX Wallet is not installed" + QR mesmo depois de o usuário ter expandido More Wallets — provavelmente herança do clique anterior em OKX. Estado obsoleto que polui contexto da nova escolha: se o usuário olha o painel direito antes de clicar numa wallet do grid, vê info de wallet diferente da que está prestes a clicar. Pequeno desalinhamento, mas confuso.

Fix óbvio (reset on group toggle): trivial. Pode ser bug de implementação.

^friccao-3

🟡 Oportunidade competitiva (média leverage) Lista plana/quase-plana de 15 wallets sem critério explícito de ordenação ou recomendação contextual é convenção em DEX (Uniswap, 1inch, Pancake). Iniciante recebe sobrecarga de opções sem ferramenta de redução. Passa nas 4 perguntas: (1) convenção; (2) afeta iniciante (paralisia de escolha), perfil que justamente menos sabe escolher; (3) ninguém resolveu por falta de investimento em wallet recommendation engine; (4) perceptível ao usuário ("a Kotai me sugeriu a melhor wallet").

Diferenciação Kotai: motor de recomendação contextual baseado em 1-2 perguntas simples no primeiro contato ("Você vem de qual exchange?" / "Já tem wallet?") → recomenda 1 wallet alinhada (Binance → Binance Wallet; Coinbase → Coinbase Wallet; nenhuma → login social/smart wallet) com explicação curta de por quê. Opção "Ver todas as wallets" preservada pra quem prefere escolher manualmente.

Trade-off: introduz pergunta extra no fluxo (fricção positiva pra iniciante, negativa pra avançado). Mitigação: opt-out óbvio ("Já sei qual wallet quero usar →") visível ao lado da recomendação.

Observação adicional: o grid tem scroll vertical (a tela 8 mobile mostra mais wallets cortadas embaixo). Scroll dentro de modal é UX hostil quando o usuário não percebe que existe — vale verificar se há affordance de scroll visível (barra, fade na borda, indicador). Sem affordance, parte das 15 wallets pode ficar invisível pra usuários que não rolam o seletor.

^oportunidade-1

7. Modal Connect Wallet — OKX não instalada + QR fallback

Função: Variante do estado "não instalada" da tela 6. Agora oferece QR code para usuários que têm o app OKX no celular, com texto que ramifica o caminho conforme a chain alvo (EVM via QR, Solana exige extension).

Componentes

• Painel esquerdo: seletor inalterado
• Painel direito:
  • Título "OKX Wallet is not installed"
  • Texto: "If you're using the app, scan your wallet to continue on EVM, or install OKX Wallet to proceed on Solana."
  • QR code grande no centro
  • Links pequenos abaixo: "Install" / "Setup Guide" (teal, peso reduzido em relação à tela 6)

Regras de negócio

• QR code é deeplink/WalletConnect-like — escaneado pelo app mobile do OKX, faz pairing pra autenticar a sessão no desktop
• Caminho QR cobre EVM apenas; Solana via mobile app não está suportada (limitação técnica da OKX)
• Pra Solana, usuário forçado a instalar a extension
• Setup Guide e Install agora são links secundários (em contraste com tela 6, onde eram botões primários)

🟢 Insight Inclusão do QR code reconhece caso real: usuário que tem OKX Wallet só no celular (sem extension), mas opera no desktop. Cobre o gap mobile-to-desktop sem forçar instalação obrigatória. Decisão correta de oferecer fallback — concorrentes (Uniswap, 1inch) tendem a oferecer só Install.

^insight-1

🔴 Fricção 1 (estrutural — copy densa demais, afeta iniciante) "If you're using the app, scan your wallet to continue on EVM, or install OKX Wallet to proceed on Solana." comprime 4 informações condicionais numa frase: (1) você pode usar o app; (2) se usar, escaneia o QR; (3) mas só funciona em EVM; (4) pra Solana, instala extension. Iniciante lê uma vez e fica perdido. Por que Solana não funciona com app? Pancake não explica.

Fix correto: 2 cards visualmente distintos no painel direito — "Já tenho OKX Wallet no celular → escaneie o QR (EVM)" e "Quero conectar Solana → instale a extension". Cada caminho com seu CTA único e seu motivo claro. Bifurcação visual elimina a condicional textual.

^friccao-1

🔴 Fricção 2 (estrutural — restrição arbitrária sem explicação) A limitação "Solana só via extension, não via app" é restrição técnica (provavelmente a OKX mobile não tem suporte WalletConnect Solana, ou o snap Solana não está disponível no mobile). Pancake passa essa limitação pro usuário sem explicar o motivo, sem prometer roadmap, sem oferecer alternativa ("Quer Solana mobile? Considere Phantom"). Iniciante que quer Solana e só tem OKX mobile fica sem solução clara — abandona o fluxo ou cai num esforço de descoberta que a Pancake não devia transferir pra ele.

Fix correto: explicitar a razão em microcopy curta ("O app mobile do OKX não suporta Solana hoje — instale a extension para continuar") e idealmente sugerir alternativa ("ou conecte uma wallet com suporte Solana mobile").

^friccao-2

🔴 Fricção 3 (estrutural — inconsistência de CTA entre telas 6 e 7) Na tela 6, Setup Guide e Install são botões primários. Na 7, viraram links secundários minúsculos abaixo do QR. Mesma decisão (instalar) tem peso visual radicalmente diferente conforme presença ou ausência do QR. Pra usuário que voltou da tela 6 ("deixa eu ver de novo"), a hierarquia mudou inexplicavelmente — pode parecer que algo aconteceu.

Provavelmente a tela 6 e a 7 são variantes A/B ou estados diferentes do mesmo fluxo (talvez 6 = primeira tentativa, 7 = depois que detectou OKX mobile no histórico do usuário). Sem rotulação, vira inconsistência.

Fix correto: unificar — sempre mostrar QR + Install + Setup Guide na mesma tela, com hierarquia visual consistente. QR como caminho primário (mais conveniente), Install como secundário com microcopy do motivo ("para Solana ou se preferir extension").

^friccao-3

🟡 Oportunidade competitiva (média leverage) Fluxos de wallet com fallbacks (extension / mobile-via-QR / WalletConnect) tendem a escalar mal entre concorrentes — cada wallet tem combinação própria, e DEXes acabam com matriz N×M de telas. Não chega a ser convenção fraca da indústria, mas é território onde ninguém investiu em padronização. Passa as 4 perguntas com ressalva: convenção fragmentada entre DEXes; afeta iniciante (sobrecarga de fluxos de fallback); ninguém resolveu por falta de design pattern unificado para wallet onboarding; perceptível ao usuário se feito bem.

Diferenciação Kotai: padrão unificado de fallback wallet — sempre na mesma estrutura visual (Recomendado: caminho A / Alternativa: caminho B), com microcopy explicando o porquê de cada caminho. Trade-off: exige investimento em design system de wallet onboarding antes de escalar suporte a wallets.

Observação adicional (QR sem URL — armadilha 1a): O QR no centro do painel não tem URL visível abaixo. Aqui aplica convenção válida — QR de pairing tipo WalletConnect é padrão da indústria, WhatsApp/Discord/Apple Pay todos fazem igual, e expor URL adiciona ruído sem ganho prático (URL não é digitável manualmente em deeplink). Classifica como convenção válida; não vira fricção.

^oportunidade-1

6. Modal Connect Wallet — OKX Wallet não instalada (Install/Setup)

Função: Estado pós-clique em OKX Wallet quando a extensão de browser não está instalada. Painel direito muda completamente: mensagem de erro/estado + 2 CTAs (Setup Guide / Install).

Componentes

• Painel esquerdo: seletor inalterado, OKX Wallet selecionada
• Painel direito (sem ícone grande, sem Select Chain):
  • Título em roxo "OKX Wallet is not installed"
  • Texto "Please install the OKX Wallet browser extension to connect the OKX Wallet wallet."
  • Botão "Setup Guide" (primário, roxo sólido)
  • Botão "Install" (secundário, roxo outline)

Regras de negócio

• Detecção automática: Pancake verifica se a extensão da wallet está instalada no browser
• Quando não está, troca o painel direito de "Select Chain" pra "not installed"
• Setup Guide e Install presumivelmente levam a destinos diferentes (Setup = docs/tutorial, Install = Chrome Web Store ou site da OKX)
• O fluxo abandona o contexto da Pancake — usuário vai instalar em outra aba

🟢 Insight Detecção automática de wallet não-instalada + estado dedicado no painel direito é decisão correta. Não joga o usuário num erro críptico ("connection failed"); reconhece o estado e oferece caminho de instalação. Separar Setup Guide de Install dá 2 caminhos: o avançado vai direto pra Install (sabe o que está fazendo), o iniciante pode pegar contexto antes.

^insight-1

🔴 Fricção 1 (cosmética → bug — afeta todos) "...to connect the OKX Wallet wallet." — repetição literal de "wallet wallet". Indica template ${walletName} wallet que não considera nomes que já contêm "Wallet". O mesmo bug deve afetar Trust Wallet ("the Trust Wallet wallet"), Binance Wallet, etc.

Fix óbvio: condicional no template — se o nome já termina em "Wallet", não duplicar. Trivialmente corrigível, vergonhoso pra um produto da escala da Pancake. Sinal de pipeline de QA fraco no fluxo de wallets — vale checar outras strings template-driven.

^friccao-1

🔴 Fricção 2 (estrutural — hierarquia errada entre CTAs, afeta iniciante) Dois botões: Setup Guide (cheio, roxo sólido) acima de Install (outline, peso menor). O destaque visual sugere que Setup Guide é a ação primária, mas o texto da tela diz "Please install..." — a ação primária deveria ser Install. Hierarquia visual contradiz a copy.

Iniciante fica em dúvida sobre o próximo passo. Avançado provavelmente ignora Setup Guide e vai direto pra Install, mas o iniciante (mais frequente nesse estado, justamente porque não tem wallet) é o mais prejudicado.

Fix correto: Install como CTA principal grande e cheio; Setup Guide como link secundário ("Como funciona a OKX Wallet?") abaixo, em peso de texto. Afirme qual é o próximo passo via design.

^friccao-2

🔴 Fricção 3 (estrutural — handoff sem retorno, afeta iniciante) Clicar em Install provavelmente abre o site da OKX ou Chrome Web Store em nova aba. O usuário sai do contexto da Pancake, instala a extensão em outro site, e tem que voltar. A tela atual não promete nada sobre o retorno — não diz "vamos detectar quando a wallet estiver pronta" nem oferece estado intermediário ("Aguardando instalação..."). Esse handoff é o ponto mais frágil do onboarding: o usuário pode instalar, voltar, e não saber se a conexão vai funcionar automaticamente; ou pior, fechar o modal e perder o contexto.

Fix correto: após "Install", manter o modal aberto com state "Aguardando instalação... vamos detectar automaticamente quando a wallet estiver pronta". Polling do extension namespace (ou listener de injection) mostra o estado pro usuário em vez de fazer ele reabrir o fluxo.

Direcionamento Kotai: estados de transição entre contextos (instalação, autorização externa) precisam ter feedback persistente. Não abandone o usuário no momento de handoff — esse é o ponto de maior churn.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target) Tratar wallet-não-instalada como erro descartável (em vez de estado legítimo do fluxo) é convenção entre DEXes. Uniswap, 1inch, Pancake fazem todos versão similar: detecta ausência, manda pro site da wallet, abandona o usuário. Passa nas 4 perguntas: (1) convenção entre todos os DEX; (2) afeta iniciante diretamente — é o perfil que MAIS precisa instalar wallet pela primeira vez; (3) ninguém resolveu por falta de investimento em detection-and-resume; (4) perceptível ao usuário ("a Kotai me detectou e continuou de onde parei").

Diferenciação Kotai: estado "Aguardando instalação" com auto-detect contínuo + microcopy in-app explicando o que esperar ("Você vai ver um popup do Chrome pedindo permissão — clique em adicionar, depois volte aqui"). Trade-off: requer poll/listener contínuo do extension namespace por wallet suportada; tem casos de falha (popup blocked, ad-blocker, instalação cancelada) que precisam tratamento explícito.

Observação adicional: a sequência "Setup Guide / Install" abre questão sobre quantos cliques o iniciante precisa antes de ter uma wallet funcional. Pancake transfere todo o onboarding pra fora do produto. Pra Kotai, vale considerar wallet provisionada via login social como caminho default pra iniciante (cria smart wallet em segundos) e tratar "conectar wallet externa" como opção avançada — inverte a hierarquia atual.

^oportunidade-1

13. Modal Connect Wallet — Tooltip MEV protection (Trust Wallet conectada)

Função: Tooltip que aparece sobre o painel direito (ancorado próximo ao check verde do EVM ou ao chip MEV Protected abaixo do modal) explicando que a wallet conectada opera com proteção MEV em EVM chains. Mesmo conteúdo do tooltip da tela 3 (Metamask), agora visível com Trust Wallet conectada.

Componentes

• Tooltip preto popover
• Texto: "This wallet on PancakeSwap offers MEV protection against front-running and sandwich attacks on EVM chains."
• "MEV protection" como link sublinhado azul/teal (clicável pra detalhamento)
• Modal Select Chain visível em background (Trust Wallet, EVM com check verde, Solana com Connect)
• Chip "MEV Protected" visível abaixo do modal no Swap form

Regras de negócio

• MEV protection é capability default da Pancake em wallets compatíveis em EVM chains
• Tooltip aparece em hover de pontos específicos (logo da wallet no seletor / check verde do estado conectado / chip do Swap form)
• Mesmo tooltip exibido em wallets diferentes (Metamask na tela 3, Trust Wallet aqui) — não é exclusivo de Metamask
• Aplica-se a EVM chains, não a Solana

🟢 Insight Confirmação importante: o tooltip de MEV protection NÃO é exclusivo de Metamask — também aparece em Trust Wallet. Capability é multi-wallet, depende da chain (EVM), não da carteira. Trust signal consistente posicionado em múltiplos pontos do fluxo (seletor, estado conectado, chip do Swap form) é decisão correta — usuário vê o signal 3-4 vezes durante o onboarding e absorve por repetição. Pancake investiu em redundância visual de signal de segurança, prática rara entre DEXes.

A "MEV protection" como link clicável dentro do tooltip também é decisão acertada: oferece aprofundamento ("saiba mais") sem forçar definição imediata.

^insight-1

🔴 Fricção 1 (estrutural — descoberta dependente de hover, afeta iniciante) O trust signal de MEV protection só fica visível por hover em pontos específicos do painel. Iniciante que move o mouse rapidamente entre regiões pode passar por cima do affordance sem ativá-lo. Para signal de segurança — onde reforço da confiança é valor central — entrega hover-only é frágil: depende de o usuário decidir investigar em vez de ser exposto passivamente.

Fix óbvio (sempre aberto) polui. Fix correto: signal persistente como badge ao lado da wallet ("MEV protected" abaixo do nome no seletor) + chip persistente no Swap form (que já existe). Tooltip vira detalhamento de hover sobre o badge, não fonte exclusiva.

Direcionamento Kotai: features de segurança são entregues como signal visível persistente, não como conteúdo descobrível por hover. Reforço visível também ajuda na hora da decisão de assinatura — quando o usuário mais precisa lembrar que está protegido.

^friccao-1

🔴 Fricção 2 (cosmética → educacional — copy técnica densa, herdada da tela 3) "MEV protection against front-running and sandwich attacks on EVM chains" empilha 3 conceitos técnicos numa frase. Já apontado no relatório 3 — reescrita: "MEV protection" como label + 1 linha plain language ("Protegemos você contra bots que se aproveitariam do seu swap pra lucrar com a diferença de preço"); termos técnicos viram destino do link clicável, não conteúdo de entrada do tooltip.

O fato de a Pancake JÁ TER um link "MEV protection" clicável dentro do tooltip é meio caminho andado — mas o link aponta pra mais jargão, não pra explicação user-friendly. Fix: o link leva pra página de educação com seção "Em termos práticos" (uma linha plain language) antes da explicação técnica.

^friccao-2

🔴 Fricção 3 (estrutural — correção retroativa do relatório 4) A tela 13 prova que o relatório 4 precisa correção: a ausência de tooltip MEV em Trust Wallet (tela 4) NÃO indica falta de capability — Trust Wallet TEM MEV protection na Pancake. O tooltip simplesmente não estava ativo na tela 4 porque o cursor não estava no ponto correto de hover. Isso reclassifica a Fricção 1 do relatório 4 ("anti-trust signal por ausência"): o problema real não é capability gap, é DESCOBERTA inconsistente do signal entre wallets — em algumas telas o tooltip aparece, em outras não, dependendo de pixel exato do hover.

Fix correto: signal de capability não pode depender de hover preciso. Badge persistente no card resolve as duas frentes simultaneamente (descoberta + reforço).

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target) Features de segurança como trust signal hover-only são convenção entre DEXes — Uniswap usa tooltips similares pra slippage warnings, route info, etc.; Pancake replica o padrão pra MEV. Passa nas 4 perguntas: (1) convenção; (2) afeta iniciante diretamente (o perfil que mais se beneficia de saber que está protegido); (3) ninguém resolveu por falta de investimento em hierarquia de signals; (4) perceptível ao usuário ("a Kotai mostra na cara que estou protegido, sem eu precisar caçar").

Diferenciação Kotai: features de segurança como signal de primeira classe — badge persistente no card de wallet + chip persistente no swap form + reforço no momento da assinatura (antes do user confirmar transação, lembrar dos guardrails ativos). Trade-off: mais peso visual no UI; mas em momento de decisão financeira (assinar swap), o ganho de confiança vale o custo de densidade.

Observação adicional: a Pancake tem MEV protection ativada por default e comunicada — Uniswap depende de o usuário ativar manualmente (UniswapX). Diferencial real, mas comunicação fraca anula parte do ganho. Pra Kotai, vale tratar MEV protection como narrativa de marca, não como tooltip enterrado: "Não te deixamos perder dinheiro para bots — é assim que opera por padrão". Decisão estratégica de comunicação mais que de UI.

^oportunidade-1

11. Modal Connect Wallet — Pós-conexão EVM + PREVIOUSLY USED + MEV Protected

Função: Estado pós-conexão bem-sucedida (Trust Wallet EVM). Painel direito mostra Select Chain com EVM já com check verde (= conectado) e Solana ainda pendente. Seletor à esquerda agora tem section "PREVIOUSLY USED" no topo. Toggle SOLANA ONLY continua ligado. Abaixo do modal, no widget de Swap, aparece chip "MEV Protected".

Componentes

• Header "Connect Wallet" + chip SOLANA ONLY (ainda ligado, teal)
• Card Social Login
• PREVIOUSLY USED (novo): Trust Wallet listada como wallet usada recentemente
• TOP WALLETS: Phantom, Binance Wallet, Solflare (filtrado Solana)
• More Wallets visível por scroll
• Painel direito: ícone Trust Wallet + Select Chain
  • Linha EVM com check verde GRANDE no botão (= já conectado, Connect substituído por estado conectado)
  • Linha Solana com botão Connect ainda disponível
• Abaixo do modal, no Swap form: chip teal "MEV Protected" com ícone shield
• Header global: "$0.00" (saldo EVM)
• URL chain=bsc

Regras de negócio

• Section "PREVIOUSLY USED" persiste wallets que o usuário já conectou (provavelmente localStorage)
• O check verde grande no EVM substitui o botão Connect — comunicando "esta chain está conectada"
• Botão Connect permanece em Solana — o usuário pode adicionar essa segunda conexão sem desconectar a primeira
• Chip "MEV Protected" no Swap form aparece quando uma wallet com MEV protection (Trust Wallet, no caso — corrigindo análise da tela 4: aparentemente Trust Wallet também tem MEV) está conectada e a chain ativa suporta

🟢 Insight 1 "PREVIOUSLY USED" como section dedicada é decisão excelente. Pra usuário recorrente, eliminar o esforço de relembrar/procurar a wallet usada antes acelera o re-engagement. Diferencial sutil sobre Uniswap, que mostra histórico só em estado conectado via header.

^insight-1

🟢 Insight 2 A escolha de NÃO substituir o botão Connect de Solana após EVM conectar é correta. O usuário multi-chain pode ter os dois conectados simultaneamente sem precisar reabrir fluxo separado. Estado "parcialmente conectado" reconhecido como legítimo, não como erro a resolver.

^insight-2

🟢 Insight 3 Chip "MEV Protected" no widget de Swap (não no modal) é arquitetura correta: trust signal aparece no LUGAR onde o efeito acontece (form de swap), não enterrado em modal de conexão que o usuário só visita uma vez. Reforço visual contínuo, não evento único.

^insight-3

🔴 Fricção 1 (estrutural — afeta intermediário, ambiguidade do toggle SOLANA ONLY) Depois de conectar EVM com sucesso, o toggle SOLANA ONLY continua ligado e o seletor à esquerda mostra só wallets Solana. Mas o painel direito (Select Chain) ainda lista EVM e Solana como opções. Discrepância: o filtro do seletor (Solana only) não bate com as opções do painel direito (EVM + Solana). Pra intermediário que conectou Trust Wallet via EVM, o filtro "SOLANA ONLY" agora é vestígio sem sentido — devia ter sido desligado automaticamente após sucesso.

Fix correto: ao completar conexão de uma chain, reavaliar contexto do filtro. Se o objetivo do usuário era "conectar Solana" (filtro ativo), e ele acabou conectando EVM, perguntar ("Você queria Solana — quer continuar pra conectar Solana também?"). Se o objetivo era EVM, desligar o filtro Solana automaticamente.

^friccao-1

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário, status pouco evidente) O check verde grande à direita do EVM é o único sinal de "você está conectado em EVM". Tamanho do ícone ajuda, mas:

• Não há texto auxiliar ("Conectado" / "Pronto")
• Não há indicação de qual chain específica está ativa dentro do guarda-chuva EVM (BNB Chain? Ethereum? URL diz bsc, mas o painel só diz "EVM")
• O endereço da wallet conectada não aparece nesta tela — só o saldo no header global

Fix correto: estado conectado mostra (a) badge "Conectado", (b) chain ativa específica ("em BNB Chain"), (c) endereço truncado da wallet ("0x1234...abcd"). Painel direito serve como mini-dashboard do estado de conexão, não só ação concluída.

^friccao-2

🔴 Fricção 3 (cosmética — afeta iniciante, chip MEV Protected sem contexto) Chip "MEV Protected" aparece embaixo do modal, semi-visível (cortado parcialmente porque o modal ocupa centro da tela). Iniciante que vê isso provavelmente nem clica. Quando o modal fechar, o chip vai estar visível no Swap form — mas é a primeira vez que aparece e iniciante não sabe o que é MEV.

Diagnóstico distinto da tela 3 (onde o tooltip empilhava jargão): aqui o problema é descoberta + contexto inicial. Fix correto: na primeira aparição do chip (pós-conexão), abrir tooltip explicativo de plain-language uma vez ("Você está protegido contra MEV — bots que se aproveitariam do seu swap"), com opção "Não mostrar de novo". Trade-off: "primeira aparição" requer state per-user, mais complexo.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — estado conectado como mini-dashboard) DEXes (Uniswap, Pancake, 1inch) tratam estado pós-conexão como "botão muda de texto, fim". Não há micro-dashboard contextualizando o que foi conectado, qual chain, qual wallet, qual endereço, qual segurança ativa. Passa nas 4 perguntas: (1) convenção entre concorrentes; (2) afeta iniciante e intermediário diretamente (perfil precisa de feedback explícito do que aconteceu); (3) ninguém resolveu por falta de investimento em UI de estado conectado; (4) perceptível ao usuário ("a Kotai me mostrou tudo que eu acabei de conectar").

Diferenciação Kotai: painel pós-conexão mini-dashboard — wallet (endereço + ícone), chain ativa (nome explícito), security features ativas (MEV, simulação de tx, etc.), com CTAs claros ("Trocar de chain", "Adicionar outra wallet", "Desconectar"). Trade-off: investe em UI que aparece pouco (estado pós-conexão antes do fechamento do modal); valor é maior no perfil que clica X cedo demais e perde info do que acabou de fazer.

Observação adicional: sequência das telas 9 → 10 → 11 revela que a Pancake tem fluxo multi-conexão (EVM + Solana paralelos) bem mais sofisticado que Uniswap, mas a UX deixa o usuário descobrir isso por exploração. Vale considerar onboarding sutil ("Conecte EVM agora — depois você pode adicionar Solana") na primeira conexão pra explicitar o modelo. Outra leitura: ajuste de classificação da tela 4 (Trust Wallet sem tooltip MEV) — aparentemente Trust Wallet TEM MEV protection (vide chip da tela 11). A ausência de tooltip lá pode ser bug de display, não falta de feature. Vale revisitar a fricção 1 do relatório 4 com essa correção.

^oportunidade-1

12. Modal Connect Wallet — Tooltip explicativo do ⓘ no EVM

Função: Tooltip on-demand que aparece ao hover/clique no ⓘ ao lado de "EVM" no card Select Chain. Mostra definição de EVM + row de 6 ícones de chains que compõem o ecossistema EVM.

Componentes

• Tooltip preto popover, ancorado ao ⓘ de EVM
• Texto: "EVM stands for Ethereum Virtual Machine and allows different blockchains to run Ethereum-based apps using the same wallet and address"
• Abaixo: row de 6 ícones de chain (BNB, Ethereum, Base, ZKsync, Linea, Arbitrum/outra) sem labels
• Resto do modal inalterado (Select Chain visível em background, Trust Wallet conectada via EVM)

Regras de negócio

• Tooltip aparece em hover do ⓘ — sem clique persistente, fecha ao mouse-out
• Ícones representam as chains que a Pancake suporta dentro do guarda-chuva EVM
• A explicação é estática — não muda conforme a wallet conectada (Trust Wallet vê os mesmos 6 ícones que Metamask veria)

🟢 Insight A Pancake reconheceu o gap diagnosticado nos relatórios 3 e 4 ("EVM como sigla técnica não decodificada por iniciante") e criou camada de explicação on-demand: definição + visualização das chains contidas. Progressive disclosure correta — não polui o card primário, fica disponível pra quem quer entender. Os ícones de chain ao lado do texto também são bom complemento visual ao definicional.

^insight-1

🔴 Fricção 1 (estrutural — patch na camada errada, afeta iniciante) A Pancake resolveu o problema do "EVM como sigla" criando tooltip explicativo em vez de consertar o card primário. Mas o tooltip só aparece em hover/clique do ⓘ — affordance que iniciante nem sempre decodifica como interativo. O ⓘ é discreto, sem destaque, e na primeira visita o usuário não sabe que está atrás dele a tradução de "EVM" → "BNB, Ethereum, Base, etc.".

Esta tela confirma o diagnóstico anterior: a informação CORRETA existe, mas está na camada errada. Fix óbvio (deixar o tooltip sempre aberto) não funciona — polui card. Fix correto (já apontado nos relatórios 3/4): nomes específicos de chain no próprio card primário ("EVM (Ethereum, BNB Chain, Base, e mais)") + tooltip como detalhamento pra quem quer ainda mais info. Tooltip vira reforço, não fonte primária.

Direcionamento Kotai: resolver na camada certa. Empilhar tooltip sobre sigla técnica é design layer-on-layer — adia o problema, não resolve.

^friccao-1

🔴 Fricção 2 (cosmética — copy técnica demais, afeta iniciante) "EVM stands for Ethereum Virtual Machine and allows different blockchains to run Ethereum-based apps using the same wallet and address" é definição precisa, mas para iniciante é wall of jargon: "Ethereum Virtual Machine", "different blockchains", "Ethereum-based apps", "same wallet and address". Cada termo carrega bagagem. A frase explica o QUE EVM É, não O QUE O USUÁRIO PODE FAZER.

Fix correto: inverter foco — começar pelo o que o usuário sente, não pelo o que a tecnologia é. "EVM = Ethereum, BNB Chain, Base, Arbitrum e outras redes compatíveis. Conectar aqui permite usar a mesma wallet em todas elas". Definição técnica vira opcional num link ("Detalhes técnicos"), não conteúdo primário do tooltip.

^friccao-2

🔴 Fricção 3 (cosmética — ícones sem rótulo) Os 6 ícones de chain abaixo do texto não têm label inline. BNB e ETH talvez sejam reconhecíveis por cor/forma; Linea, ZKsync, Base, opBNB são logos que iniciante decodifica como decoração. O ganho visual de "ver quais chains estão dentro" é parcial — usuário reconhece 2 de 6.

Fix óbvio (label embaixo de cada ícone) polui pouco — vale o trade. Alternativa: texto inline ("Ethereum, BNB Chain, Base, ZKsync Era, Linea, Arbitrum One") em vez de ícones, ou combinar (ícone + label embaixo, denso mas claro).

^friccao-3

🟡 Oportunidade competitiva (alta leverage — herdada de 3/4) A tela 12 prova que a Pancake reconheceu o problema da sigla "EVM" mas resolveu na camada errada (tooltip patch em vez de fix no card). Esse padrão de "adicionar layer pra explicar a layer anterior" é convenção entre DEXes pra justificar a manutenção de vocabulário técnico em vez de traduzir o conteúdo primário. Passa nas 4 perguntas: (1) convenção; (2) afeta iniciante; (3) ninguém resolveu por inércia de design system; (4) perceptível ao usuário-alvo.

Diferenciação Kotai: traduzir conteúdo primário pra linguagem do usuário; tooltips reservados pra reforço de detalhe ("como funciona tecnicamente?"), não pra desvendar o que deveria estar visível. Trade-off: cards primários ficam mais densos textualmente; mitiga-se com hierarquia tipográfica.

Observação adicional: o ⓘ está exclusivo do EVM — Solana não tem tooltip equivalente. Decisão correta porque "Solana" não precisa de tradução (é nome próprio reconhecível), mas reforça que o design system reconhece a fragilidade da sigla "EVM" sem agir na camada certa. Assimetria do affordance entre os dois itens (EVM com ⓘ, Solana sem) é, ironicamente, mais um sinal de que algo precisa ser explicado num lado e não no outro — pista de que "EVM" deveria virar "Ethereum + redes compatíveis" direto.

^oportunidade-1

10. Modal Connect Wallet — Filtro SOLANA ONLY ativo

Função: Estado do seletor com toggle "SOLANA ONLY" ligado no header do modal. A lista de Top Wallets reorganiza pra mostrar wallets Solana-nativas (Phantom, Solflare, Backpack) + wallets multi-eco que suportam Solana (Binance Wallet). Wallets EVM-only (Metamask, Trust Wallet, OKX) descem pra More Wallets em estado visualmente discreto.

Componentes

• Header "Connect Wallet" + chip "SOLANA ONLY" com toggle ON (teal) à direita
• Card Social Login
• TOP WALLETS: Phantom, Binance Wallet, Solflare, Backpack (todas com suporte nativo/forte a Solana)
• MORE WALLETS expandido: Metamask, Trust Wallet, OKX Wallet aparecem em ordem secundária, com peso visual reduzido
• Painel direito: ainda mostra "Trust Wallet — Please confirm in Trust Wallet" (estado herdado da tela 9, não resetou)
• Header global mostra "$0.00" no canto superior direito (wallet EVM já conectada de fluxo anterior)
• URL chain=eth (Ethereum como chain ativa na Pancake nesse momento)

Regras de negócio

• Toggle SOLANA ONLY filtra o seletor pra mostrar apenas wallets que suportam Solana
• Pancake provavelmente associa o filtro a metadata por wallet (suporta_solana: true/false)
• Wallets sem suporte Solana caem pra More Wallets ou ficam ocultas — não está claro se desaparecem ou só descem
• Wallet já conectada (Trust Wallet, EVM) persiste no header; o filtro afeta só o seletor pra próxima conexão

🟢 Insight Decisão arquitetural acertada: oferecer filtro "SOLANA ONLY" no momento de conexão remove ruído pro usuário que vem com objetivo claro ("quero operar em Solana"). Em vez de o usuário precisar saber de cabeça que Phantom/Solflare/Backpack são as wallets relevantes pra Solana, a Pancake faz a filtragem por ele. É raro entre DEXes — Uniswap e 1inch tratam multi-chain como problema do usuário, não do produto.

Reordenação dinâmica do Top Wallets conforme o filtro (Phantom assume topo, Metamask desce) também é correta — não esconde wallets de uso secundário, só rebaixa.

^insight-1

🔴 Fricção 1 (estrutural — visibilidade do toggle, afeta iniciante) O chip "SOLANA ONLY" + toggle vive no header do modal, pequeno, à direita do título "Connect Wallet". Iniciante que aterrissa nesse estado (talvez por ter clicado em algum link contextualizado pra Solana) pode não perceber que está vendo lista filtrada — vê "Phantom", "Solflare", "Backpack" como Top Wallets e infere que Pancake é Solana-first, quando na verdade só está filtrado.

Pior: se o usuário tem Metamask e procura no Top, não acha — pode achar que Pancake "perdeu" sua wallet ou que houve bug. O toggle existe mas não anuncia seu efeito ("você está vendo só wallets de Solana — desligue pra ver todas").

Fix óbvio (label de alerta no topo) infla a UI. Fix correto: faixa fina logo abaixo do header informando o estado do filtro com 1 clique pra alternar ("Mostrando apenas wallets compatíveis com Solana · [Mostrar todas]"). Estado do filtro vira primeiro-classe na hierarquia visual, não detalhe.

Direcionamento Kotai: filtros que alteram o conjunto de opções precisam de rotulagem visível quando ativos. Toggle em header é compacto mas vira armadilha pra quem não percebeu que ligou.

^friccao-1

🔴 Fricção 2 (estrutural — handoff entre fluxos, afeta intermediário) O painel direito ainda mostra "Please confirm in Trust Wallet" da tela 9, mesmo depois de o usuário ter ligado o filtro Solana e estar navegando lista nova. Esse estado obsoleto cria ambiguidade: o usuário está esperando confirmação da Trust Wallet (EVM) ou começando fluxo novo pra Solana? Se clica em Phantom agora, cancela a tentativa de Trust Wallet ou roda em paralelo?

Fix óbvio (resetar painel ao toggle Solana) pode anular ação anterior do usuário. Fix correto: pop-up de confirmação leve quando o estado conflita ("Você ainda tem uma conexão Trust Wallet pendente — quer cancelar e começar de novo?"). Trade-off: mais um diálogo, mas elimina ambiguidade em momento crítico.

^friccao-2

🔴 Fricção 3 (cosmética — afeta iniciante, copy do toggle) "SOLANA ONLY" em caixa alta + abreviado é estilo de chip técnico. Iniciante decodifica "ONLY" como ênfase de exclusividade ("só funciona aqui") em vez de "filtro ligado". Vale checar se a copy melhora com "Apenas wallets Solana" (forma plena) — mais espaço mas mais claro.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target) Filtro por chain/ecossistema no momento da conexão é diferenciação acima da média — Uniswap e 1inch não oferecem nada equivalente. Mas a Pancake esconde o feature em chip pequeno, sem promover seu uso. Passa nas 4 perguntas com inversão: (1) Pancake já fez algo que concorrentes não fizeram — convenção ainda não emergiu; (2) afeta iniciante (quem mais precisa de filtro); (3) Pancake já resolveu, problema é descoberta; (4) tornar o filtro visível seria perceptível.

Diferenciação Kotai: filtro de ecossistema/chain como primeira pergunta do seletor (cards visuais grandes: "EVM (Ethereum, BNB, Base, ...)" / "Solana" / "Bitcoin" / "Todas") em vez de toggle escondido no header. Decisão antes do seletor, não como modificador depois. Trade-off: 1 clique a mais; mas elimina toda fricção 1 e 2 dessa tela.

Observação adicional: a presença do header "$0.00" indica que esse estado acontece com wallet já conectada (provavelmente EVM Trust Wallet). Adicionar wallet pra outro ecossistema é caso de uso real e bem tratado, mas a tela mistura sinais: "Connect Wallet" no título sugere primeira conexão, header sugere já conectado. Reescrever título contextualizado ("Adicionar wallet Solana") quando o usuário já tem conexão ativa eliminaria ambiguidade.

^oportunidade-1

1. Modal Connect Wallet — estado inicial

Função: Modal de conexão de wallet. Esquerda: seletor (Social Login + Top Wallets + More Wallets). Direita: card de educação com mascote, microcopy e links How to connect / Disclaimer.

Componentes

• Header "Connect Wallet" + X
• Card Social Login (ícones Google/X/Telegram/Discord empilhados + chevron →)
• Section "TOP WALLETS": Metamask, Trust Wallet, Binance Wallet, OKX Wallet
• Card "More Wallets +11" (colapsado, mostra 4 logos + contador)
• Painel direito: mascote coelho + "Manage and store your private keys and assets securely" + links "How to connect" / "Disclaimer"

Regras de negócio

• Social Login e wallets EOA tratados como entradas equivalentes no mesmo seletor
• Top Wallets visível por default, restante (+11) colapsado em "More Wallets"
• Painel direito troca de conteúdo conforme item do seletor recebe hover/clique (master/detail)
• Sem onboarding prévio: o modal abre direto, sem tela explicativa sobre "o que é conectar wallet"

🟢 Insight Social Login no topo da hierarquia é decisão honesta pro target iniciante: oferece on-ramp familiar antes de exigir wallet instalada — Uniswap e 1inch tratam wallet como pré-requisito; Pancake reconhece que usuário vindo de CEX não tem wallet ainda. Hierarquia "Top Wallets" (4 visíveis) + "More Wallets +11" (colapsado) protege contra paralisia de escolha sem privar avançado das 15 opções. Painel direito ocupa real-estate vazio com canal educacional (mascote + links) sem competir com o seletor.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante) Modal abre sem nenhuma explicação prévia do que significa "conectar wallet" nem do que acontece depois da conexão. "Manage and store your private keys and assets securely" pode ser lido como "a Pancake vai guardar suas chaves" (oposto do que acontece em wallet non-custodial) — o sujeito gramatical é ambíguo. "How to connect" e "Disclaimer" são links pequenos que exigem clique pra abrir conteúdo fora do fluxo de decisão. Não há resposta inline pra "o que essas wallets podem fazer com meus tokens depois de conectar?".

Fix óbvio (parágrafo explicativo dentro do modal) falha — polui o seletor e atrasa quem já entende. Fix correto: linha persistente no painel direito ANTES do clique ("Conectar permite que a Pancake leia seu saldo e proponha transações — você assina cada uma na carteira"); expansão progressiva via tooltip ao hover em "Disclaimer".

Direcionamento Kotai: contrato de confiança em 1 linha visível no estado pré-conexão. O que o produto vê (saldo, endereço) e o que precisa de assinatura (transações) fica explícito antes do clique.

^friccao-1

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário) Social Login e wallets EOA aparecem como itens equivalentes no mesmo seletor. Mas "login com Google" cria uma wallet nova (smart wallet ou MPC, com modelo de custódia e recuperação atrelado à conta social), enquanto "Metamask" conecta wallet existente já gerida pelo usuário. Duas decisões com implicações radicalmente diferentes (custódia, gas, recovery, ponto de falha único) tratadas como parelhas. Iniciante escolhe sem entender que está optando por modelos diferentes.

Fix óbvio (badge "Smart Wallet" no Social Login) falha — "Smart Wallet" é jargão. Fix correto: bifurcação visual no topo do modal entre "Criar wallet com login social" e "Conectar wallet que já tenho", com microcopy de 1 linha sobre o modelo de custódia em cada caminho.

^friccao-2

🟡 Oportunidade competitiva (alta leverage no target) Mesclar "criar wallet via social" com "conectar wallet existente" no mesmo seletor é convenção emergente em DEXes (Pancake, Uniswap, 1inch já adotaram). Passa nas 4 perguntas: (1) padrão em adoção rápida entre concorrentes principais; (2) afeta iniciante diretamente — primeira escolha técnica do fluxo, feita sem entender modelo; (3) ninguém resolveu por falta de investimento em onboarding bifurcado, não por impossibilidade técnica; (4) separação clara seria perceptível ao target.

Diferenciação Kotai: bifurcação no topo do modal — "Ainda não tenho wallet" (cria smart wallet, explica modelo de recuperação) vs "Já tenho wallet" (conexão Metamask/etc). Trade-off: 1 clique a mais pra quem já decidiu, em troca de redução de abandono no segmento crítico de aquisição (iniciante vindo de CEX).

Observação adicional: o card "More Wallets +11" não comunica o critério de ordenação entre Top e More. Provavelmente é volume/instalações, mas pra iniciante "top" pode ser lido como "as melhores" ou "as recomendadas pela Pancake" — vira trust signal não-intencional. Vale rotular explicitamente ("Mais populares" em vez de "Top Wallets").

^oportunidade-1

5. Modal Connect Wallet — Binance Wallet + Select Chain

Função: Estado pós-clique em Binance Wallet. Painel direito mostra ícone Binance Wallet + "Select Chain" idêntico ao padrão das telas 3 e 4. Sem tooltip MEV.

Componentes

• Painel esquerdo: seletor inalterado, Binance Wallet selecionada
• Painel direito: ícone Binance Wallet grande + label
• Card "Select Chain" com copy "Binance Wallet supports multiple ecosystems. Please select which chain(s) to connect to."
• Linha "EVM" + ⓘ + check verde + botão Connect (teal)
• Linha "Solana" + botão Connect (teal)

Regras de negócio

• Mesma arquitetura das telas 3 e 4 — "Select Chain" replicado
• Binance Wallet é wallet vinculada à exchange Binance, com fluxo de auth próprio
• Default da Pancake é BNB Chain; Binance Wallet no Top alinha com isso
• Copy idêntica às telas 3 e 4 — template wallet-agnostic

🟢 Insight Decisão correta da Pancake: posicionar Binance Wallet entre as Top Wallets em paridade com Metamask e Trust Wallet alinha com posicionamento honesto do produto (centrado em BNB Chain, não chain-neutral). Iniciante vindo do ecossistema Binance encontra wallet familiar entre as primeiras opções. Outro DEX (Uniswap, 1inch) tende a enterrar Binance Wallet em More Wallets — Pancake reconhece quem é o target.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante vindo de exchange diferente) Binance Wallet aparece com peso visual idêntico ao de Metamask e Trust Wallet, mas tem modelo diferente: é wallet ligada à conta Binance (exchange), com implicações de KYC, restrições geográficas e dependência operacional da Binance. Pra usuário vindo de Coinbase, Kraken ou nenhuma exchange, escolher Binance Wallet pode arrastar amarrações que ele não tem.

Fix óbvio (mover Binance Wallet pra More Wallets) viola o posicionamento da Pancake (BNB-aligned é decisão consciente). Fix correto: badge ou microcopy distinguindo "Wallet vinculada a exchange" (Binance Wallet, Coinbase Wallet, OKX Wallet) vs "Wallet independente" (Metamask, Trust Wallet, Rabby). Iniciante decide com modelo mental claro; não vira armadilha pra quem não sabe.

^friccao-1

🔴 Fricção 2 (cosmética — copy boilerplate, herdada das telas 3 e 4) Mesma copy template (" supports multiple ecosystems") repetida pela terceira vez. Confirma que é decisão de design system, não vacilo de copy. Pro iniciante que está comparando 3 wallets diferentes no mesmo fluxo, frase repetida não ajuda a escolher.

Fix correto: copy específica por wallet — "Binance Wallet — login via conta Binance, opera bem em BNB Chain; suporta EVM e Solana". Custa redação, mas elimina ruído boilerplate.

^friccao-2

🔴 Fricção 3 (estrutural — assimetria EVM/Solana, herdada das telas 3 e 4) Mesma fricção das telas anteriores. Pioria adicional aqui: Binance Wallet em Solana é especialmente raro — usuários de Binance Wallet vão estar quase 100% em BNB Chain/EVM. Oferecer Solana com mesma proeminência que EVM ignora o perfil de uso real desta wallet específica. Fix correto envolve não só renomear EVM, mas reorganizar prioridade do card conforme contexto (Binance Wallet → EVM em destaque, Solana colapsado com "também suportado").

^friccao-3

🟡 Oportunidade competitiva (média leverage) Mistura de exchange-linked wallets com independent wallets sem distinção é convenção entre DEXes. Passa nas 4 perguntas com ressalva: (1) convenção entre concorrentes; (2) afeta iniciante (modelo de custódia/KYC implícito); (3) ninguém resolveu por neutralidade comercial (nenhum DEX quer chamar Binance Wallet de "exchange wallet" e ofender parceiro); (4) diferenciação perceptível.

Diferenciação Kotai: rotulagem honesta do modelo de custódia/dependência no card de wallet. Trade-off: tensão comercial — chamar Binance Wallet de "wallet vinculada à Binance" é factual mas pode azedar relação institucional. Avaliar se vale o ganho de clareza vs custo de partnership.

Observação adicional: a sequência de telas 3 → 4 → 5 (Metamask → Trust → Binance) é a primeira oportunidade de o usuário comparar wallets nesta UI. Cada uma abre o mesmo painel direito sem diff visual. Faltou oportunidade de comparação lado a lado — quem fica indeciso é forçado a clicar wallet por wallet e memorizar.

^oportunidade-1

4. Modal Connect Wallet — Trust Wallet + Select Chain

Função: Estado pós-clique em Trust Wallet. Painel direito mostra ícone Trust Wallet + "Select Chain" pedindo qual ecossistema conectar (EVM ou Solana), idêntico ao padrão da Metamask na tela 3. Ausente: o tooltip de MEV protection.

Componentes

• Painel esquerdo: seletor inalterado, Trust Wallet selecionada
• Painel direito: ícone Trust Wallet grande + label
• Card "Select Chain" com texto "Trust Wallet supports multiple ecosystems. Please select which chain(s) to connect to."
• Linha "EVM" + ⓘ + check verde + botão Connect (teal)
• Linha "Solana" + botão Connect (teal)
• Sem popover/tooltip flutuante (em contraste com a tela 3 — Metamask exibia tooltip MEV)

Regras de negócio

• Mesmo passo intermediário entre wallet e assinatura
• Trust Wallet também suporta EVM e Solana
• Copy do card é template (" supports multiple ecosystems...") — mesma para todas as wallets multi-eco
• MEV protection só é sinalizada em wallets específicas (parece exclusivo de Metamask nesse fluxo)

🟢 Insight Consistência arquitetural: o passo "Select Chain" é replicado idêntico para cada wallet multi-ecossistema. Usuário aprende o padrão na primeira wallet (Metamask, tela 3) e replica em Trust Wallet sem reaprender. Decisão correta de design system — comportamento previsível reduz carga cognitiva em fluxo de onboarding.

^insight-1

🔴 Fricção 1 (estrutural — afeta usuário que compara wallets) Ausência do tooltip MEV protection em Trust Wallet, em contraste com a tela 3 (Metamask), comunica implicitamente "Trust Wallet não tem MEV protection na Pancake" — mas a UI não diz isso explicitamente. Trust signal por presença vira anti-trust signal por ausência, sem rótulo. Usuário que compara ("qual wallet protege contra MEV?") não distingue capabilities pela tela atual — precisa lembrar de cabeça.

Fix óbvio (adicionar tooltip "MEV protection NOT available" em Trust Wallet) é hostil — enfatiza o que falta e parece campanha contra wallet específica. Fix correto: matrix de comparação via badges discretos nos próprios cards do seletor à esquerda ("MEV protected", "Smart account", "Multi-chain"). Usuário compara ANTES de clicar, não descobre por ausência depois.

Direcionamento Kotai: badges de capability nos cards do seletor — comparação explícita, não implícita. Trade-off: badges podem inflar visualmente cards pequenos; exige set limitado (3-4 max) e iconografia tight.

^friccao-1

🔴 Fricção 2 (estrutural — herdada da tela 3) "EVM" como categoria abstrata ao lado de "Solana" como nome próprio — mesma assimetria diagnosticada na tela 3. Reescrita já apresentada lá. Indicação importante aqui: como o problema se repete em todas as wallets multi-eco, ele é do design system, não da tela isolada — o ganho ao consertar atinge as 3 (ou mais) wallets de uma vez.

^friccao-2

🔴 Fricção 3 (cosmética — copy boilerplate) "Trust Wallet supports multiple ecosystems. Please select which chain(s) to connect to." é literalmente a mesma frase de "Metamask supports..." / "Binance Wallet supports...". Preenchida por template ${walletName} supports multiple ecosystems. Pra iniciante, copy repetida entre wallets não ajuda — "supports multiple ecosystems" não diferencia quando as 3 wallets do Top dizem o mesmo.

Fix correto: copy específica destacando o que muda entre wallets ("Trust Wallet — mobile-first, com EVM e Solana via app" / "Metamask — extension + snap pra Solana, MEV protection na Pancake"), em vez de boilerplate.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target) A fricção 1 (comparar capabilities entre wallets) é convenção entre Uniswap, 1inch, Pancake: seletor lista wallets como ícones equivalentes sem expor capabilities. Passa nas 4 perguntas: (1) padrão em todos os DEX; (2) afeta iniciante e intermediário diretamente — escolha de wallet é decisão estrutural de longo prazo feita com pouca info; (3) ninguém resolveu por falta de taxonomia padronizada de wallet capabilities; (4) badges no card seriam perceptíveis e diferenciantes.

Diferenciação Kotai: badges de capability nos cards + página "Comparar wallets" linkada pra quem quer detalhamento. Trade-off: requer manutenção contínua de matriz de capability conforme features mudam (MEV protection, smart account, etc.). Erro factual em badge perde credibilidade — exige processo, não só decisão de design.

Observação adicional: vale validar se a ausência de MEV protection em Trust Wallet é decisão técnica (limitação da wallet) ou comercial (integração só com Metamask). Diferença importa pro direcionamento: se técnico, badge é factual; se comercial, pode ampliar.

^oportunidade-1

3. Modal Connect Wallet — Metamask + Select Chain

Função: Estado pós-clique em Metamask. Painel direito mostra ícone grande da carteira escolhida e tela "Select Chain" pedindo ao usuário decidir qual ecossistema conectar antes da assinatura. Tooltip flutuante anuncia MEV protection.

Componentes

• Painel esquerdo: seletor inalterado, Metamask em estado hover/selecionado
• Tooltip preto (popover): "This wallet on PancakeSwap offers MEV protection against front-running and sandwich attacks on EVM chains."
• Painel direito: ícone Metamask grande + label
• Card "Select Chain" com texto "Metamask supports multiple ecosystems. Please select which chain(s) to connect to."
• Linha "EVM" + ícone ⓘ + check verde + botão Connect (teal)
• Linha "Solana" + botão Connect (teal)

Regras de negócio

• Passo intermediário entre "escolhi wallet" e "wallet abre popup de assinatura"
• Metamask suporta múltiplos ecossistemas via snap (EVM nativo + Solana via plugin)
• "EVM" agrupa N chains (BNB, Ethereum, Base, Arbitrum, Linea, opBNB...) numa categoria técnica única
• Botões Connect independentes — usuário pode conectar só EVM, só Solana, ou os dois em sequência
• Check verde em EVM presumivelmente indica "wallet suporta este ecossistema"

🟢 Insight Decisão arquitetural excelente: ao escolher Metamask, Pancake intercepta o passo entre seleção e assinatura pra fazer uma pergunta importante (qual ecossistema conectar). Não é simplesmente "abre popup do Metamask" — o produto reconhece que wallet moderna é multi-ecossistema e força a escolha consciente. Isso resolve problema real: usuário com Metamask + Solana snap precisa saber qual lado vai operar antes da assinatura, em vez de descobrir depois quando o saldo "não aparece".

Tooltip de MEV protection é trust signal no momento certo — bem antes do swap, o produto comunica que opera com proteção contra MEV. Educação contextual fina, posicionada no instante de decisão (escolha de wallet), não enterrada em página de docs.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário) "Select Chain" apresenta "EVM" e "Solana" como itens equivalentes de uma lista. Problemas:

• "EVM" é categoria técnica abstrata. Iniciante não sabe que EVM significa "Ethereum + BNB + Base + Arbitrum + Polygon + Linea + opBNB + ..." — vê só uma sigla.
• Ao lado, "Solana" é nome próprio de chain concreta. A assimetria (sigla técnica vs nome conhecido) confunde — usuário pode achar que "EVM" é uma chain alternativa a Solana, quando na verdade agrupa várias chains que terão que ser escolhidas DEPOIS, dentro do swap.
• O ⓘ ao lado de "EVM" deve explicar isso, mas exige hover/clique pra descobrir.

Fix óbvio (renomear "EVM" pra "Ethereum + redes compatíveis") melhora mas trunca a lista. Fix correto: dois cards com peso visual igual e conteúdo claro — "Redes EVM (Ethereum, BNB Chain, Base, Arbitrum, Linea, opBNB e mais)" vs "Solana". Check verde discreto em EVM indica "sua wallet suporta" sem virar trust signal genérico que confunde.

Direcionamento Kotai: nesta tela, nomear chains específicas em vez de famílias técnicas. Iniciante reconhece nomes de chain (BNB, Ethereum, Solana), não taxonomia técnica (EVM, L1, L2).

^friccao-1

🔴 Fricção 2 (estrutural — afeta todos) Permitir conectar EVM E Solana paralelamente abre uma questão que a tela NÃO responde: depois de conectar os dois, saldos e histórico serão combinados? Separados? Qual é o ecossistema "default" no resto da experiência? O efeito de conectar ambos só vira evidente depois — pra intermediário multi-chain isso é informação crítica pra tomada de decisão no instante da escolha.

Fix correto: linha curta abaixo dos botões Connect explicando o comportamento ("Você pode conectar os dois — vai alternar entre redes pelo header depois" ou similar). Eliminar a ambiguidade de modelo no momento da escolha, não após.

^friccao-2

🔴 Fricção 3 (cosmética — afeta iniciante, anula trust signal) O tooltip de MEV protection empilha três conceitos técnicos densos numa frase: "MEV protection", "front-running", "sandwich attacks". Pra iniciante que provavelmente está conectando wallet pela primeira vez, vira ruído azul: ele interpreta como "algo bom" sem entender o quê. Trust signal vira decoração — efeito anulado.

Fix óbvio (traduzir todos os termos inline) infla tooltip. Fix correto: "MEV protection" como label clicável + 1 linha plain language ("Protegemos você contra bots que se aproveitam da sua ordem para lucrar com a diferença de preço — saiba mais"). Termos técnicos viram destino de link, não conteúdo de entrada.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target) Tela "qual ecossistema" como passo intermediário é arquitetura correta — mas todos os concorrentes (Uniswap, Pancake, 1inch) usam taxonomia técnica ("EVM", "Solana", "Bitcoin", "Cosmos") sem traduzir pra nomes de chain reconhecíveis. Passa nas 4 perguntas: (1) convenção em todos os DEX multi-ecossistema; (2) afeta iniciante diretamente — é a primeira escolha técnica que ele faz no produto; (3) ninguém resolveu porque "EVM" é vocabulário interno reaproveitado, não problema técnico; (4) substituir "EVM" por nomes de chain seria perceptível ao usuário-alvo.

Diferenciação Kotai: nomear chains específicas em vez de famílias técnicas; collapse inteligente quando a wallet suporta 8+ chains ("Ethereum, BNB, Base e mais 5"). Trade-off: lista pode crescer visualmente — exige design responsivo. Mas o ganho cognitivo pro iniciante ("sei o que estou conectando") é maior que o custo de layout.

Observação adicional: o tooltip de MEV protection abre sobre o painel esquerdo, oclusionando parte do seletor (Trust Wallet/Binance Wallet ficam cobertos). Posicionamento de popover precisa ser revisitado — em momento de decisão, esconder opções concorrentes é UX hostil mesmo quando o conteúdo é positivo.

^oportunidade-1

2. Modal Connect Wallet — Social Login expandido

Função: Estado pós-clique no card Social Login. Painel direito muda pra detalhe das opções sociais (Google em destaque + X/Telegram/Discord em cards menores) e exibe aviso sobre cobertura limitada de chains.

Componentes

• Painel esquerdo inalterado (seletor de wallets)
• Painel direito: card hero "Continue with Google" (largo, com logo G)
• Três cards menores parelhos: X Login, Telegram, Discord
• Aviso azul (ícone ⓘ): "Social login works only on BNB Chain, Ethereum, Base, Arbitrum One, Linea, opBNB. Sending funds on other networks may cause permanent loss."

Regras de negócio

• Login social cria/recupera wallet vinculada ao provider escolhido (smart wallet ou MPC)
• Cobertura limitada a 6 chains EVM listadas — fora delas, o aviso transfere risco ao usuário
• Hierarquia visual: Google > X/Telegram/Discord (provavelmente baseado em conversão histórica)
• Aviso é estático: não muda conforme a chain ativa no seletor de Swap

🟢 Insight Padrão master/detail bem aplicado: clique em Social Login expande o painel direito sem fechar o seletor à esquerda. Usuário mantém contexto e pode voltar sem reabrir o modal. Hierarquia visual também é correta — Google ganha card grande (maior conversão), os outros viram cards pequenos parelhos.

Aviso azul sobre cobertura limitada e "permanent loss" é decisão acima da média: Pancake declara explicitamente a limitação ANTES do usuário comprometer fundos. Avisar sobre perda permanente no momento de escolha (em vez de só na FAQ ou disclaimer enterrado) é honestidade rara entre DEXes.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante) O aviso comete erro clássico: lista 6 chains por nome técnico ("opBNB", "Linea", "Arbitrum One") e atribui ao usuário a responsabilidade de evitar a perda. Iniciante que não conhece a diferença entre opBNB e BNB Chain não tem como agir corretamente — o aviso transfere risco sem entregar capacidade de decisão. Pior: não diz O QUE de fato acontece. "May cause permanent loss" não esclarece se (a) o produto bloqueia envios pra chains não suportadas, ou (b) deixa o usuário enviar e perder fundo. Sem precisão, fica medo abstrato sem ferramenta concreta de evitar.

Fix óbvio (lista mais longa de chains + explicação técnica) piora — vira wall of text. Fix correto: o aviso promete o que o PRODUTO vai fazer ("vamos bloquear envios em chains não suportadas e avisar antes da assinatura"), em vez de transferir vigilância. Se o produto não bloqueia, o aviso é insuficiente — vira armadilha legal-style ("avisei, problema seu").

Direcionamento Kotai: pra social login / smart wallet, bloquear ativamente chains não suportadas e mostrar o conjunto suportado como "redes onde você pode operar com este login", não como "redes onde NÃO há perda". Posicionamento de guardrails em vez de disclaimer.

^friccao-1

🔴 Fricção 2 (cosmética → estrutural — afeta iniciante) "Continue with Google" como botão hero implica fluxo familiar (OAuth Google) como em qualquer SaaS, mas o resultado é a criação de uma wallet on-chain vinculada à conta Google — com saldo, gas, e recuperação atrelada ao Google. Se o iniciante perde acesso à conta Google, perde acesso à wallet. Nenhum elemento da UI sinaliza isso antes do clique.

Fix óbvio ("Criar wallet com Google") melhora copy mas adiciona fricção e ainda é vago. Fix correto: microcopy de 1 linha sob o botão ("Sua wallet ficará vinculada à conta Google — se perder acesso a ela, perde a wallet · Saiba mais"), com link curto para explicação de 30s.

^friccao-2

🔴 Fricção 3 (cosmética — copy do aviso é abstrato) "May cause permanent loss" usa hedging linguístico ("may") que dilui o peso. Pra iniciante, "may" pode ser lido como "é improvável". A linguagem correta em alerta destrutivo é factual e direta ("Fundos enviados para chains fora desta lista são irrecuperáveis"), não condicional.

^friccao-3

🟡 Oportunidade competitiva (média leverage) Aviso de "chain não suportada → perda permanente" é herança do paradigma EOA multi-chain. Todo DEX que oferece social login / smart wallet replica versão do mesmo padrão: aviso textual + transferência de vigilância. Passa nas 4 perguntas: (1) convenção entre DEXes com login social; (2) afeta iniciante, que é justamente o público-alvo dessa feature; (3) ninguém resolveu porque bloquear ativamente exige investimento em validação client-side e roteamento por chain; (4) perceptível ao usuário ("a Kotai não me deixa cometer esse erro").

Diferenciação Kotai: contrato de "guardrails em vez de avisos" pra perfis iniciantes — produto bloqueia ação destrutiva em vez de avisar e permitir. Trade-off: limita poder do avançado, exige modo opt-in pra destravar. Aceitável dado o posicionamento de target.

Observação adicional: o aviso lista 6 chains mas o seletor de wallet à esquerda mostra 15 wallets, cada uma com cobertura potencialmente diferente. O aviso é estático — não avisa que escolher Solana via Metamask (próxima tela) tem outras restrições. Vale checar se o aviso adapta-se conforme a wallet/chain escolhida ou se é só copy genérica.

^oportunidade-1

1. Painel My Wallet — Estado Novo (carteira recém-conectada, saldo zero)

Função: Painel direito persistente que apresenta o estado da carteira conectada. Quando o saldo é zero, transforma-se em onboarding contextual com dois CTAs (Buy / Receive) e um terceiro caminho secundário (Bridge Crypto), substituindo a lista de tokens pelo passo necessário pra começar a operar.

Componentes

• Avatar multichain (stack de 4 ícones) + chevron — entrada pra submenu Accounts (Análise 2)
• Chip de chain ativa (BNB Chain) + chevron — entrada pra dropdown de redes (Análise 3)
• Título "My Wallet" + saldo "$0.00" em tipografia grande
• Copy contextual: "This wallet looks new — choose an option below to add crypto and start trading"
• Dois cards lado a lado: Buy (cofre, "Purchase with credit card, Apple Pay, or Google Pay") e Receive (porquinho, "Receive crypto from another wallet")
• Link secundário "Bridge Crypto →" abaixo dos cards
• Form de Swap permanece visível e ativo (From/To com endereço, Slippage 0.50%, MEV Protected) mesmo com saldo 0

Regras de negócio

• Estado vazio detectado por saldo zero — copy muda de "My Wallet" lista de assets para versão onboarding
• Buy = on-ramp fiat (terceirizado, KYC necessário)
• Receive = mostra endereço da carteira pra receber transferência
• Bridge Crypto = move ativos de outra rede (assume usuário já tem cripto em outro lugar)
• Swap form permanece interativo (usuário pode preencher antes de ter saldo, mas execução vai falhar)

🟢 Insight Decisão correta de transformar empty state em jornada: em vez de "sua carteira está vazia" + nada, Pancake oferece os três caminhos reais (comprar fiat, receber de outra wallet, bridge entre redes) em hierarquia clara. Os dois CTAs primários cobrem os dois perfis de entrada mais comuns no target: iniciante 100% fora de cripto (Buy) e iniciante vindo de CEX/outra wallet (Receive). Bridge fica em link secundário porque pressupõe usuário mais avançado que já entende multi-chain. Hierarquia visual condiz com hierarquia de complexidade do path — boa engenharia de progressive disclosure.

A copy "This wallet looks new" também é acerto de tom: não diz "empty" (que soa erro) nem "$0 balance" (frio), reconhece o momento ("parece nova") e propõe ação. Reduz fricção emocional do estado vazio.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante vindo de fora de cripto) O swap form permanece totalmente interativo com saldo zero. Iniciante curioso pode preencher From/To, ajustar slippage, ver MEV Protected verde — e só descobrir que não pode swapar quando tentar executar (erro tardio: "Enter an amount" → "Insufficient balance"). O painel direito grita "sua carteira está vazia, comece aqui" enquanto o painel central grita "swap normalmente". Dois sinais contraditórios competindo pela atenção do usuário.

Fix óbvio (desabilitar o swap form até ter saldo) falha porque o usuário precisa explorar a UI para entender o produto, e bloquear interação parece quebrado. Fix correto: manter o form interativo, mas casar visualmente os dois painéis — quando saldo é zero, o input "Enter an amount" mostra hint "Add crypto first →" apontando para o painel direito; o botão de execução fica em estado disabled-but-explained ("Add crypto to swap") em vez de validação genérica. Une os dois painéis na mesma narrativa.

^friccao-1

🔴 Fricção 2 (cosmética → estrutural — afeta iniciante) Os dois CTAs (Buy / Receive) usam ilustrações 3D charmosas mas semanticamente fracas: o cofre verde e o porquinho rosa não comunicam diferença funcional entre "comprar com cartão" e "receber de outra wallet". Iniciante decide pelo texto, não pelo ícone. Pior: o porquinho da Receive parece cofre de poupança (associação cultural com "guardar dinheiro"), o que conflita com a ação real (receber/depositar).

Fix óbvio (trocar ilustração) é parcial. Fix correto: ícones funcionais que mapeiem direto pra ação (cartão de crédito para Buy, seta-pra-dentro ou QR para Receive), com a ilustração charmosa reservada pra confirmação de sucesso onde o tom emocional cabe. Iconografia em momento de decisão = clareza primeiro, charme depois.

^friccao-2

🔴 Fricção 3 (estrutural — afeta iniciante vindo de CEX) "Bridge Crypto" em link secundário pressupõe que o usuário entende o que é bridge e quando precisa dela. Iniciante vindo de Binance que tem USDT na exchange não sabe se a opção pra ele é Receive (sacar pra própria wallet) ou Bridge (mover entre redes). Os dois termos competem sem que o usuário tenha critério pra escolher.

Fix correto: condicionar o terceiro caminho à pergunta real do usuário ("Já tem cripto em outra rede?") — bridge só aparece nomeadamente em fluxo guiado, não como link genérico. Receive cobre 80% do caso "já tenho cripto em algum lugar" e o resto é roteado dentro do fluxo Receive ("está em qual rede?").

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — iniciantes vindos de fora de cripto) Empty state de wallet conectada com saldo zero é tratado pelos concorrentes de duas maneiras, ambas inferiores ao que a Pancake faz aqui: (a) Uniswap mostra lista de tokens vazia + botão "Get tokens" genérico que abre on-ramp Moonpay/Robinhood — fricção de descoberta alta; (b) 1inch, SushiSwap mostram apenas "No tokens" sem CTA, deixando o usuário sem caminho. Passa nas 4 perguntas: convenção entre concorrentes diretos é tratar empty state como erro ou catálogo vazio, afeta iniciante diretamente (é o primeiro momento de verdade — chegou na DEX e não sabe o que fazer), ninguém resolveu por priorizar usuário com saldo (otimização do happy path), diferenciação seria perceptível desde o primeiro minuto.

A Pancake já avança contra a convenção ao transformar empty state em jornada com 3 caminhos. A oportunidade Kotai é levar mais longe: empty state como flow guiado, não como menu. Pergunta única no centro do painel ("De onde vem seu primeiro depósito? • Não tenho cripto • Tenho em outra wallet • Tenho em uma exchange") roteia o usuário para o caminho certo sem cobrar dele o vocabulário (Buy/Receive/Bridge). Trade-off: mais cliques pro avançado que sabe exatamente o que quer — mitigável com "skip" pequeno; o ganho com iniciante (target principal) compensa de longe.

Observação adicional (não é fricção, é decisão a monitorar): o painel direito persiste mesmo durante swap em outras redes, o que sugere que Pancake quer treinar o usuário a usar o painel como "hub de portfolio + identidade" em vez de só widget de carteira. Decisão estratégica relevante — se confirmada em outras telas (portfolio expandido, histórico), reposiciona o painel direito como real-estate de retenção, não só de status. Vale revisitar quando analisarmos telas com saldo > 0.

^oportunidade-1

4. Toast de Erro — Falha ao Trocar de Chain

Função: Notificação flutuante exibida no topo direito após tentativa fracassada de troca de chain (acionada pelo dropdown da Análise 3). Comunica que a operação falhou e sugere ação. Substitui temporariamente o painel My Wallet enquanto visível.

Componentes

• Container rosa/magenta com barra lateral colorida
• Ícone de erro (proibido) à esquerda
• Label "Error" em bold
• Mensagem: "An unexpected error occurred while switching chains. Please try again."
• Botão de fechar (×) no canto superior direito
• Posicionado sobre o avatar/chip da wallet — oculta parcialmente o painel direito

Regras de negócio

• Toast aparece quando a chamada wallet_switchEthereumChain (ou equivalente) retorna erro genérico
• Texto é o mesmo para qualquer causa de falha (rede não adicionada na wallet, RPC indisponível, usuário cancelou, chain-family incompatível)
• Persiste até ser fechado manualmente ou expirar por timeout (não confirmado nesta tela)
• Painel My Wallet abaixo continua refletindo o estado anterior (chain antiga ainda ativa)

🟢 Insight Decisão correta de NÃO bloquear a UI com modal pra erro de troca de chain — o swap form permanece operacional na chain anterior, então o usuário pode continuar usando o produto enquanto resolve. Toast como notificação não-modal é proporcional à severidade real (falha recuperável, não-destrutiva). Posicionamento próximo ao componente que originou a ação (chip da wallet) ajuda na associação causal — usuário entende que o erro vem dali.

A cor rosa/magenta da Pancake como sinalização de erro é interessante pelo desvio da convenção vermelha — encaixa identidade visual sem perder leitura de "algo deu errado" (a tonalidade ainda é alarmante). Decisão de marca bem calibrada.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante, intermediário e até avançado) "An unexpected error occurred" é a frase que melhor representa o anti-padrão de erro genérico em DeFi. O texto não informa: (a) qual chain falhou; (b) por que falhou (wallet rejeitou? rede não está adicionada? RPC fora?); (c) o que tentar agora (adicionar a rede manualmente? trocar de wallet? esperar?). "Please try again" assume que retry vai funcionar, quando metade das causas é estrutural (rede não cadastrada na wallet não se resolve com retry).

Iniciante lê esse toast, clica em "try again", obtém o mesmo erro, e fica preso — não há onde clicar para entender. O texto é desculpa, não diagnóstico. Pior: "unexpected" treina o usuário a desconfiar do produto ("se o erro foi inesperado pro Pancake, será que meu dinheiro está seguro?").

Fix óbvio (substituir por "Network switch failed. Please try again.") só mascara — continua sem diagnóstico. Fix correto: erro tipado com mensagem específica por causa real. Pelo menos três variantes:

• Usuário cancelou na wallet → "Switch cancelled in your wallet" (sem alarme, é ação voluntária)
• Rede não adicionada → "This network isn't added to your wallet. Add it now?" + CTA para adicionar via wallet_addEthereumChain
• RPC/network falhou → "Network unreachable. Check your connection and try again."

A biblioteca de erros da wallet (codes 4001, 4902, etc.) já entrega essa informação — o Pancake escolhe agregar tudo em "unexpected", o que é decisão de engenharia, não limitação técnica.

Direcionamento Kotai: toda mensagem de erro é tipada por causa. "Unexpected" só aparece como último recurso (catch-all) e mesmo assim com link "Report this" pra usuário sinalizar e equipe diagnosticar.

^friccao-1

🔴 Fricção 2 (cosmética → estrutural — afeta iniciante) O toast posicionado em cima do avatar/chip da wallet oculta exatamente o componente que o usuário precisa pra reagir ao erro (avatar pra abrir Accounts, chip pra tentar novamente a troca de chain). Iniciante que quer tentar de novo precisa fechar o toast primeiro pra ver o chip — fricção desnecessária.

Fix óbvio (mover o toast pra fora do path do componente) é trivial — empurrar pra baixo do painel ou pra cima do header. Fix mais correto: toast com CTA inline ("Try again" / "Add network") que resolve sem precisar voltar ao chip. Erro e correção no mesmo objeto.

^friccao-2

🔴 Fricção 3 (estrutural — afeta intermediário e avançado) O toast não nomeia a chain que falhou. Em fluxo multi-chain rápido (usuário tentando alternar entre BNB e Ethereum em sequência), o feedback genérico não permite ao usuário saber se foi a troca atual ou alguma anterior. Erro sem contexto temporal/objeto é alarme estéril.

Fix correto: "Couldn't switch to Ethereum" (com nome específico) — preciso, recuperável, e força o produto a saber qual chain falhou (o que ele sabe; só não comunica).

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target) Erros genéricos em troca de chain ("unexpected error", "something went wrong") são padrão entre Uniswap, 1inch, Pancake, SushiSwap — todos preferem mensagem catch-all a investir em copy específica por código de erro. Passa nas 4 perguntas: (1) convenção entre todos os concorrentes; (2) afeta iniciante, intermediário E avançado (erro é universal, mas iniciante sofre mais); (3) ninguém resolveu por priorizar simplicidade de implementação sobre clareza de comunicação (mapear códigos de erro pra copy específica dá trabalho contínuo de manutenção); (4) diferenciação perceptível imediatamente — usuário compara "esse outro DEX me disse exatamente o que estava errado" vs. "o Pancake só falou 'erro'".

Diferenciação Kotai: matriz de erros tipados por causa real (wallet rejeitou, rede ausente, RPC indisponível, gas insuficiente, etc.) com copy específica + CTA recuperador inline quando aplicável. Trade-off: mais copy pra manter (e localizar), e algumas causas de erro são opacas mesmo do lado da wallet (a wallet retorna "unknown" — nesses casos, o catch-all é honesto). Mas o ganho de confiança vale a manutenção.

Observação adicional (não é fricção, é decisão a monitorar): o painel My Wallet abaixo do toast continua refletindo a chain anterior — comportamento correto (não muda state se a operação falhou). Mas o chip de chain no topo precisa também voltar ao estado anterior visualmente; se ele ficar em "loading" travado, vira bug de sincronização. Vale verificar em sessão real.

^oportunidade-1

5. Painel Receber Cripto — Passo 1: Escolha de Chain-Family

Função: Painel direito que substitui o My Wallet após clique no CTA "Receive" (Análise 1). Passo intermediário onde o usuário escolhe em qual chain-family quer receber. UI já localizada em PT-BR ("Receber Cripto"), o que confirma cobertura do fluxo na localização brasileira.

Componentes

• Botão back (←) + título "Receber Cripto"
• Linha 1 (EVM): ícone cluster EVM + label "EVM" + endereço "0xd09B...618a" + chevron "›" (entra no detalhe)
• Linha 2 (Solana): ícone Solana + label "Solana" + status secundário "No Solana wallet" + botão "Connect" (cápsula teal)
• Sem campo de busca, sem agrupamento adicional, sem indicação de tokens suportados
• Botões/labels misturam EN ("Connect", "No Solana wallet") e PT-BR ("Receber Cripto") na mesma tela

Regras de negócio

• Click em EVM → avança pro passo 2 (endereço + QR, Análise 6)
• Click em Connect (Solana) → abre flow de conexão de wallet Solana (não documentado nesta tela)
• O mesmo endereço EVM é usado pra todas as redes EVM (Ethereum, BNB, Base, Arbitrum, etc.) — escolha de qual rede específica enviar fica por conta do remetente, não exposta aqui
• A chain-family não-conectada (Solana) tem CTA de conexão inline — funde fluxo de "conectar" com fluxo de "receber"

🟢 Insight Escolher chain-family antes de mostrar endereço é decisão crítica e correta: receber USDC ERC-20 num endereço Solana é perda total de fundos. Forçar o passo de chain-family obriga o usuário (ou quem vai mandar pra ele) a pensar sobre a rede antes do endereço — única defesa real contra erro destrutivo de cross-chain send.

Fundir "conectar Solana" com "receber em Solana" no mesmo painel é elegante: o usuário não precisa sair pra Accounts (Análise 2), conectar Solana, voltar pro Receive e escolher Solana — tudo acontece no contexto da intenção. Decisão de fluxo bem desenhada que reduz dropoff.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário, herdada da Análise 2) "EVM" como label primária reaparece aqui com piora: na Análise 2 era tela de gestão (onde EVM é metadata aceitável); aqui é tela de ação direta ("recebe seu dinheiro"). O usuário precisa decidir entre EVM e Solana num momento de risco (vai compartilhar endereço pra receber valor) e a label "EVM" não comunica que ela cobre Ethereum, BNB, Base, Arbitrum, etc. Iniciante que vai receber USDT na BNB Chain pode achar que precisa de "BNB Chain" como opção separada e não ver aqui, abandonando o fluxo achando que o produto não suporta.

Fix óbvio (renomear EVM para "Ethereum, BNB Chain, Base e outras") falha pelo comprimento. Fix correto: label primária = nome amigável ("Redes Ethereum" ou "Carteira principal"), secondary label lista as redes específicas ("Ethereum, BNB, Base, +5"), tooltip explica que é o mesmo endereço para todas. Termo "EVM" desaparece da UI primária.

Direcionamento Kotai: chain-family vira "grupo de redes" nomeado pela rede mais reconhecida do grupo + lista das demais inline. Vocabulário técnico sai do path de decisão financeira.

^friccao-1

🔴 Fricção 2 (estrutural — afeta iniciante, com risco de perda de fundos) A tela mostra o endereço EVM já antes do clique ("0xd09B...618a" inline na linha). Isso aparenta facilidade ("olha aí, é só copiar") mas é convite ao erro: o usuário pode copiar o endereço daqui sem entrar no detalhe e sem ler nenhum aviso sobre QUAL rede usar no momento do envio. Se ele mandar USDC pra Solana pensando que esse endereço serve, o dinheiro some.

Fix óbvio (esconder o endereço até o usuário entrar no detalhe) tem custo: é informação útil ali. Fix correto: mostrar endereço, mas com selecionável apenas após confirmação de rede de destino ("Pra qual rede vão te mandar?") no passo 2. Compartilhamento de endereço sem contexto de rede vira affordance secundária, não primária.

Direcionamento Kotai: receber sempre exibe a rede esperada como parte do mesmo objeto compartilhado (endereço + rede + QR), nunca endereço solto. Defesa contra cross-chain misdirect builds-in no compartilhamento.

^friccao-2

🔴 Fricção 3 (cosmética — afeta intermediário e avançado) Mistura de idiomas na mesma tela: título em PT-BR ("Receber Cripto"), labels EN ("Connect", "No Solana wallet"). Quebra de consistência sinaliza tradução parcial — em UI financeira, descuido de tradução cria dúvida sobre seriedade do produto ("o resto deve estar também pela metade?").

Fix correto: tradução completa, incluindo labels de botão e status. Trivial de corrigir; não é convenção da indústria, é descuido específico.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — anti-perda-de-fundos) Uniswap, 1inch, Pancake e outras DEXes que oferecem "Receive" no produto tipicamente mostram endereço + QR + lista de redes onde aquele endereço é válido, sem amarrar a rede de destino ao ato de compartilhamento. O "selecione a rede primeiro" da Pancake é um passo melhor que o status quo, mas ainda permite copiar endereço sem fixar a rede. Passa nas 4 perguntas: (1) convenção entre concorrentes é "endereço solto + QR"; (2) afeta iniciante diretamente (é exatamente quem mais perde fundos por cross-chain misdirect); (3) ninguém resolveu por priorizar facilidade de copiar (atrito é vendido como friction) e por dificuldade de fixar rede em QR (não há padrão universal); (4) diferenciação perceptível — "esse produto não me deixa errar" é mensagem forte de marca.

Diferenciação Kotai: receber é fluxo de 2 passos com rede de destino sempre travada ao endereço compartilhado. QR code embute a rede como query param (?network=base), wallet receptora valida; endereço em texto vem com etiqueta visual da rede ("USDC • Base"). Pode usar payment URI padronizada (EIP-681, BIP-21 análogo) onde a wallet do remetente reconhece. Trade-off: requer wallets que parseiem o payload com rede; degradação graciosa para wallets antigas (endereço puro + alerta de rede em copy adjacente).

Observação adicional (correção retroativa da Análise 2): essa tela confirma que o ícone copy da Análise 2 (na linha EVM da tela Accounts) copia o endereço sem contexto de rede. A Análise 2 já marcou isso como observação — agora se eleva a risco real, porque o fluxo Receive existe justamente pra resolver isso, e o atalho da Accounts contorna a defesa. Vale propagar: ação de copy de endereço em qualquer lugar do produto deveria sempre vir acompanhada de etiqueta de rede ou disclaimer.

^oportunidade-1

2. Submenu Accounts — Gestão Multi-Chain de Contas (popover)

Função: Popover acionado pelo avatar multichain (stack de 4 ícones) no topo do painel My Wallet. Lista as contas conectadas separadas por chain-family (EVM, Solana), com ações por conta e CTA pra conectar a chain-family ainda não conectada.

Componentes

• Botão back (←) + título "Accounts"
• Linha 1: ícone EVM (cluster de chains) + label "EVM" + endereço truncado "0xd09B...618a" + dois ícones (copy 📋 e disconnect → vermelho)
• Linha 2: ícone Solana + label "Solana" + status "Disconnected" + botão "Connect" (cápsula teal)
• Popover ancorado ao avatar, oculta o painel My Wallet enquanto aberto

Regras de negócio

• Modelo conceitual: 1 conta por chain-family (EVM = todas EVM chains compartilham endereço; Solana = endereço separado)
• EVM conectada → mostra endereço + ações (copy / disconnect)
• Solana desconectada → mostra estado + CTA pra conectar (não desconecta automaticamente, mantém estado independente)
• Disconnect é por chain-family (desconectar EVM mantém Solana se houver), não por wallet
• Back (←) volta pro estado padrão do painel My Wallet

🟢 Insight Decisão arquitetural forte: separar contas por chain-family em vez de por wallet ou por chain individual. Reflete a realidade técnica do multi-chain (Metamask cobre EVM inteiro com 1 endereço; Solana exige wallet/endereço separado) sem cobrar do usuário a conta de "em quantas wallets estou logado". O usuário enxerga "identidades por ecossistema", que é o mental model correto pra quem opera em mais de uma chain.

Ações de copy e disconnect inline (sem submenu intermediário) são acerto de pragmatismo — são as duas ações reais que o usuário precisa nessa tela. Não há over-design (deletar wallet, adicionar nickname, mudar avatar) — Pancake reconhece que isso é tela de gestão de sessão, não de identidade. Foco correto.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário) "EVM" como label primária pressupõe vocabulário que o iniciante não tem. Usuário vindo de Coinbase Wallet ou Trust Wallet vê "EVM" e "Solana" lado a lado e não consegue mapear: a wallet que ele acabou de conectar é EVM? Solana? Os dois? A ausência do nome da wallet (Metamask, Trust, Phantom) na linha aumenta a opacidade — o usuário não vê "qual wallet está conectada", só vê "qual chain-family está ativa".

Fix óbvio (renomear "EVM" pra "Ethereum + BNB + Base + ...") falha pelo tamanho da string e por sugerir falsamente que são contas separadas. Fix correto: hierarquia em duas linhas por entrada — linha superior com nome da wallet e ícone ("Trust Wallet • 0xd09B...618a"), linha inferior em texto secundário ("Active on Ethereum, BNB Chain, Base, +5"). O termo EVM, quando aparecer, fica em microcopy ou tooltip, não como label primária.

Direcionamento Kotai: identidade de conta é nomeada pela wallet, não pelo agrupamento técnico de chain. EVM/Solana viram secondary label ("funciona em X redes"), não primária.

^friccao-1

🔴 Fricção 2 (estrutural — afeta iniciante) O ícone vermelho de disconnect (→) está visualmente equivalente ao ícone de copy (📋) — mesmo tamanho, mesmo peso visual, lado a lado. Ações de severidade radicalmente diferente (copiar é reversível e trivial; desconectar quebra a sessão e exige refazer login + assinaturas) com affordance visual idêntica. Iniciante pode clicar no errado sem perceber.

Fix óbvio (aumentar o ícone de disconnect ou tornar vermelho mais saturado) ajuda parcialmente. Fix correto: copy fica inline imediato (1 clique = copia), disconnect entra em kebab (⋯) ou pede confirmação modal. Hierarquia de fricção alinhada com hierarquia de consequência — ações destrutivas merecem 1 clique a mais.

^friccao-2

🔴 Fricção 3 (cosmética — afeta iniciante) "Disconnected" como status puro ao lado de Solana não comunica o que isso significa pro usuário. Iniciante pode achar que está "offline", "quebrado", ou que precisa reconectar a wallet inteira pra usar Solana. Não há indicação de que basta um clique no Connect pra resolver, nem do que muda quando conecta (vai ter saldo Solana? swap Solana? ambos?).

Fix correto: substituir "Disconnected" por copy orientada à ação — "Connect to swap on Solana" ou "Not connected — add to use Solana tokens". Comunica o estado e o benefício de mudar de estado.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target multi-chain) Multi-chain identity é frente caótica entre os concorrentes: Uniswap mantém uma única "connected wallet" que muda de chain via dropdown (não separa Solana porque não tem); 1inch trata cada chain como contexto separado (precisa reconectar ao mudar de rede); SushiSwap/PancakeSwap até hoje conviviam em silos de subdomínio por chain. Passa nas 4 perguntas: (1) tratamento de identidade multi-chain como caos é convenção entre concorrentes; (2) afeta iniciante e intermediário diretamente — é o ponto onde o usuário se perde sobre "em qual rede estou e por que"; (3) ninguém resolveu por dificuldade arquitetural real (Solana ≠ EVM tecnicamente) e por priorizar single-chain experience; (4) diferenciação seria perceptível desde o primeiro multi-chain swap.

A Pancake já dá um passo certo separando EVM/Solana como entidades distintas no mesmo painel. A oportunidade Kotai é unificar a narrativa: uma única tela de "Minhas conexões" que mostre 1 linha por wallet (Trust, Phantom, Metamask) com badges das chain-families que ela cobre, e um único disconnect-all-or-by-wallet. Conta = wallet, não chain-family. Trade-off: requer mapeamento explícito wallet→chains suportadas (mas isso é metadata estável da própria wallet).

Observação adicional (escopo além desta tela): o ícone copy aqui copia o endereço EVM — mas qual endereço exatamente? O Pancake renderiza o mesmo endereço pra qualquer rede EVM (correto tecnicamente), mas o usuário não sabe disso. Em fluxo Receive (que ainda vou analisar) esse detalhe vira crítico: copiar endereço sem saber pra qual rede mandar pode causar perda de fundos (ex: enviar USDC ERC-20 pra um endereço que o usuário acha que é Base). Recordar essa observação ao analisar a tela Receive.

^oportunidade-1

3. Dropdown Chain Selector — Troca de Rede Ativa

Função: Dropdown acionado pelo chip de chain no topo direito do painel My Wallet (mostra a chain ativa — BNB Chain). Lista as redes disponíveis pra trocar o contexto operacional da carteira conectada (chain ativa do painel + chain default do swap).

Componentes

• Lista vertical de 10 redes, cada uma com ícone + nome
• BNB Chain destacado em roxo (estado selecionado)
• Demais redes em preto/cinza: Ethereum, Solana, Aptos, Base, Monad, Arbitrum One, ZKsync Era, Linea, opBNB
• Sem campo de busca, sem agrupamento (mainnet/L2), sem separação EVM/não-EVM
• Sem indicação de saldo por rede nem de rede recomendada

Regras de negócio

• Seleção troca o contexto da chain do painel My Wallet e o default From-token do Swap
• Mistura redes EVM (Ethereum, Base, Arbitrum, etc.) e não-EVM (Solana, Aptos) na mesma lista plana
• Algumas redes exigem wallet diferente (Solana, Aptos não funcionam com Metamask EVM) — mas a lista não diferencia
• A ordem não é alfabética, não é por TVL, não parece priorizada por uso do usuário

🟢 Insight Lista enxuta (10 redes) ao invés do catálogo completo (Pancake suporta mais redes — vide filtro de busca da Análise 8 com 9+ redes diferentes). Sinaliza decisão consciente de não inflar o seletor com long-tail chains, mantendo apenas as principais para o swap form. Estado selecionado (BNB Chain em roxo) é claro e auxilia orientação espacial. Iconografia de chain é familiar pra quem já usa o ecossistema — usuário avançado reconhece logos no scan rápido.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário) A lista mistura redes EVM (que compartilham endereço, são intercambiáveis com a mesma wallet) e não-EVM (Solana, Aptos — endereço separado, wallet separada) sem qualquer diferenciação visual. Iniciante com Metamask conectada que clica em Solana não tem como saber que essa seleção exige conectar uma wallet adicional (Phantom, Backpack) — só vai descobrir que algo está errado quando tentar swapar e o painel exigir conexão Solana.

O problema é arquitetural, não cosmético: o dropdown trata "chain" como dimensão única, mas chain tem duas dimensões reais (chain-family + chain específica) que afetam wallet e endereço. Iniciante não tem o mental model pra preencher essa lacuna sozinho.

Fix óbvio (separar dropdown em duas seções "EVM" / "Solana" / "Other") falha por dois motivos: (a) replica em UI a complexidade técnica que o usuário não quer ver; (b) cobra dele o vocabulário ("EVM") que ele não tem. Fix correto: agrupamento por estado do usuário — "Conectadas" (redes onde a wallet ativa já opera) e "Conectar nova wallet" (redes que exigirão wallet adicional, com nome da wallet sugerida ao lado: "Phantom", "Backpack"). Comunica a consequência da escolha antes do clique.

Direcionamento Kotai: chain selector mostra estado de conexão atual contextualmente. Mudança de chain que exige nova wallet vira fluxo guiado ("Para usar Solana, conecte uma Solana wallet"), não seleção silenciosa que quebra na próxima ação.

^friccao-1

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário) Ausência de saldo por rede na lista. Usuário que tem 0.5 ETH em Arbitrum e 0 em Linea vê os dois nomes idênticos visualmente, sem ajuda pra escolher "onde tenho dinheiro pra operar". A lista é catálogo de capabilities, não mapa de estado real do usuário.

Fix óbvio (mostrar saldo em USD ao lado de cada rede) tem custo: requer query de saldo em todas as redes da lista pra renderizar o dropdown — latência e custo de RPC. Fix viável: pre-cache de saldo (já buscado pra renderizar o painel My Wallet) reaproveitado no dropdown; redes sem saldo descem pro final ou ficam em cinza claro; redes com saldo > 0 sobem pro topo.

Direcionamento Kotai: lista de redes priorizada por saldo do usuário, com saldo visível na linha. Redes "vazias" como secondary section colapsável.

^friccao-2

🔴 Fricção 3 (cosmética — afeta iniciante) "Monad" e "opBNB" aparecem na lista plana ao lado de Ethereum e Base como se fossem equivalentes em maturidade/uso. Monad é mainnet recente e opBNB é L2 com pouco TVL relativo. Iniciante não tem critério pra entender que mudar pra Monad significa entrar em ecossistema com bem menos liquidez e ferramentas que Ethereum. O dropdown não diferencia maturidade nem risco operacional.

Fix correto: badge sutil ("Beta", "Low liquidity") em redes não-mainstream + ordenação por liquidez/TVL. Não esconde, mas calibra expectativa.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target multi-chain) Chain selector como lista plana sem agrupamento, sem saldo, sem maturidade é convenção entre Uniswap, 1inch, Pancake, SushiSwap. Passa nas 4 perguntas: (1) convenção entre todos os concorrentes diretos; (2) afeta iniciante e intermediário diretamente (escolha de chain é decisão constante na operação multi-chain, não evento único); (3) ninguém resolveu por priorizar parity de listagem (todos querem mostrar que suportam todas as chains) e por custo de RPC pra renderizar saldos; (4) diferenciação seria muito perceptível — usuário identifica "esse produto sabe onde eu tenho dinheiro" no primeiro uso.

Diferenciação Kotai: chain selector como mapa de estado, não catálogo. Redes ordenadas por saldo do usuário (descendente), com saldo em USD visível inline; redes vazias colapsadas em "+ outras redes"; chain-family declarada via badge discreto (não como agrupamento primário). Trade-off: latência adicional na abertura do dropdown (pre-cache pode mitigar); usuário avançado que quer ver "todas as chains que suportamos" precisa expandir — aceitável, ele faz isso 1× por novo onboarding e nunca mais.

Observação adicional (não é fricção desta tela, é decisão estratégica): o chip de chain ativa fica no painel My Wallet (lado direito), enquanto o swap form tem seus próprios seletores de chain por token (na linha From/To). Existem dois chain-contexts coexistindo na mesma tela — "chain do painel" e "chain do swap". Para iniciante, isso é confuso: mudar a chain do painel muda o que ele vê de saldo, mas não necessariamente bloqueia swap em outra chain. Vale analisar a relação entre os dois contextos quando chegarmos nas telas de Swap em saldo > 0.

^oportunidade-1

Consolidado — Carteira Conectada (PancakeSwap)

Caráter geral do fluxo

8 telas cobrindo: empty state de carteira não conectada → gestão de contas multi-chain → seleção de chain → tratamento de erro → fluxo de recebimento (Receive) → gift code → painel Accounts. A tensão central do fluxo: o PancakeSwap toma decisões arquiteturais corretas — separar chain-families, forçar escolha de chain antes de exibir endereço — mas depois expõe essas mesmas decisões como vocabulário técnico bruto ("EVM", "Bridge Crypto", agrupamento por chain-family) para um usuário que ainda não formou o modelo mental. A defesa existe, mas falha no ponto crítico: o endereço que sai para o mundo — em texto, via QR ou via copy direto do painel Accounts — não carrega o identificador de rede, contornando a proteção do passo 1.

O perfil mais afetado é o iniciante que chega sem saber a diferença entre wallet e exchange e sem conhecer vocabulário de infraestrutura on-chain. O intermediário enfrenta principalmente a fricção de endereço sem contexto de rede em #5, #6 e #8 — o momento de maior risco real de perda de fundos. Comparado ao Uniswap, o PancakeSwap avança em dois pontos concretos: empty state como jornada estruturada com 3 caminhos hierarquizados e gift code como vetor de aquisição viral P2P. Regride no scope de integrações de funding e compartilha todas as fricções estruturais — confirmando léxico técnico e affordances nivelados como padrões cross-concorrente.

🟢 Insights recorrentes

Arquitetura de chain-family como camada de proteção — telas 2, 5

Dois momentos em que a separação EVM/Solana revela-se decisão de produto correta em vez de convenção. Em #2, a separação de contas por chain-family (EVM vs Solana) reflete a realidade técnica — carteiras EVM e Solana são entidades não-intercambiáveis, e misturá-las no mesmo grupo geraria mais confusão, não menos. Em #5, forçar a escolha de chain-family antes de exibir o endereço impede que o usuário copie um endereço EVM pretendendo usá-lo em Solana. A defesa arquitetural existe; o problema é que ela falha no ponto de saída do endereço — veja fricção estrutural abaixo.

🔴 Fricções recorrentes

Estrutural — Léxico de infraestrutura como vocabulário de produto — telas 1, 2, 3, 5, 8

A fricção estrutural dominante do fluxo — presente em 5 das 8 telas. A causa raiz é única: o produto usa como vocabulário de produto termos que são vocabulário de infraestrutura. "Bridge Crypto" como atalho de navegação em #1, "EVM" como label de seção de contas em #2, separação EVM/não-EVM como critério de navegação em #3, "EVM" como label primária em momento de decisão de recebimento em #5, e novamente "EVM" como label no painel Accounts em #8.

O iniciante não sabe o que é EVM. Para ele, o termo pode significar "a carteira que eu conectei" ou "uma opção que não sei o que é" — não orienta, filtra por conhecimento prévio que é exatamente o que falta. A solução óbvia (tooltip explicando "EVM = redes como Ethereum, BNB Chain, Polygon...") cria ruído visual em toda tela onde aparece e não resolve o problema raiz, que é o critério de organização, não a palavra.

Alternativa concreta: reorganizar o vocabulário pela perspectiva do usuário — "Minhas carteiras" com badge das chains cobertas (ETH, BNB, SOL, etc.) em vez de seções "EVM" e "Solana". O usuário pensa "qual wallet app eu uso" e "em qual rede tenho saldo", não "quero minha seção EVM". Trade-off: perda de precisão técnica para avançados; ganho direto de orientação para iniciante e intermediário. Confirma a oportunidade competitiva de multi-chain identity via wallet (seção abaixo).

Perfil mais afetado: iniciante em todas as telas; intermediário em #3 e #5 (momentos de decisão de chain para recebimento).

Estrutural — Endereço sem identificador de rede em momento de compartilhamento — telas 5, 6, 8

O padrão de risco mais grave do fluxo. A arquitetura força a escolha de chain-family antes de exibir o endereço — decisão correta vista em #5 — mas o endereço que finalmente chega ao mundo não carrega nenhum identificador de rede. Em #6, o usuário que recebe um endereço EVM não sabe se deve enviá-lo em BNB Chain, Ethereum, Polygon ou qualquer outra rede EVM. O atalho de copy direto no painel Accounts em #8 agrava: contorna completamente a defesa do passo 1, permitindo copiar o endereço sem ter passado pelo filtro de chain-family.

A solução óbvia de adicionar apenas a label de rede no endereço resolve parcialmente mas não fecha o risco: um endereço EVM é tecnicamente válido em todas as redes EVM — o usuário ainda precisa garantir que a rede de origem coincide com a rede onde tem saldo. A alternativa mais robusta é o pedido de pagamento estruturado (ver oportunidade competitiva), mas a versão mínima viável já elimina o risco principal: exibir o endereço sempre acompanhado de badge de rede explícita ("BNB Chain", não "EVM") e bloquear o copy em #8 sem seleção de rede. Trade-off: adicionar uma camada de atrito ao copy no Accounts — funcionalidade hoje disponível em um toque; a alternativa é aceitar risco de perda de fundos por rede errada.

Perfil mais afetado: iniciante e intermediário igualmente — o erro de rede errada não é exclusivo de quem ainda está aprendendo.

Estrutural — Affordances nivelados para ações de risco diferente — telas 2, 8

Copy e disconnect recebem mesmo peso visual e tratamento de atalho em #2. No painel Accounts em #8, o problema escala: 4 ícones (2 copies + 2 disconnects) na mesma região sem diferenciação visual de risco. Copy é ação reversível; disconnect encerra a sessão e exige reconexão com aprovação da wallet. Tratá-los como equivalentes treina o usuário a ignorar a diferença — o mesmo efeito acumulado descrito no consolidado Uniswap, confirmando que o padrão é cross-concorrente.

Alternativa concreta: copy como ação inline (toque fácil, sem consequência); disconnect como ação secundária em contexto menu ou com confirmação inline mínima. Trade-off: perde-se simetria visual entre os ícones; ganha-se clareza de risco. Fricção estrutural porque o padrão de nivelamento aparece em todos os pontos de interação com multi-wallet — é sistêmico, não pontual.

Perfil mais afetado: iniciante que confunde copy com disconnect; intermediário que opera múltiplas wallets e depende da clareza das ações.

🟡 Oportunidades competitivas do fluxo

Multi-chain identity via wallet, não via chain-family — telas 2, 3, 5, 8

Padrão atual da indústria: Uniswap e PancakeSwap organizam contas por chain-family: seção EVM, seção Solana. A divisão é tecnicamente correta mas cognitivamente alienante — o usuário pensa em termos de qual wallet app ele usa (MetaMask, Trust Wallet, Phantom), não em qual "família de chains". Em #2, #3, #5 e #8 o vocabulário de infraestrutura aparece onde deveria estar o vocabulário do usuário.

Por que afeta nosso target: O iniciante conecta sua primeira wallet e vê "EVM" como label — um termo que não conhece, que não mapeia para nada concreto no seu modelo mental. O intermediário que usa MetaMask na BNB Chain e Phantom no Solana entende intuitivamente que são mundos separados, mas não pela label "EVM vs Solana".

Hipótese de diferenciação Kotai: Organizar contas por wallet app ("MetaMask", "Trust Wallet", "Phantom") com badge inline das chains cobertas (ETH, BNB, MATIC para EVM; SOL para Phantom). O usuário reconhece imediatamente a própria wallet. As chains aparecem como propriedades da wallet, não como critério de organização. Para o Kotai que começa multi-chain por design, isso é uma decisão de arquitetura de identidade — não cosmética.

Trade-off: Requer que o produto saiba qual wallet app está por trás de cada endereço — informação disponível na conexão via WalletConnect/injected, mas que demanda mapeamento e manutenção. Novas wallets ou casos edge (múltiplas wallets com o mesmo app) adicionam complexidade. Vale o investimento para o target iniciante que reconhece o ícone do app antes de decodificar "EVM".

Passa nas 4 perguntas-teste? (1) ✓ Uniswap e PancakeSwap ambos organizam por chain-family. (2) ✓ Afeta diretamente iniciante e intermediário. (3) ✓ Razão de ninguém ter resolvido: mapeamento wallet-app → chain-coverage é esforço de engenharia e manutenção, não impossibilidade técnica. (4) ✓ Diferença perceptível: ícone do app que o usuário conhece vs termo técnico que nunca ouviu.

Receive como pedido de pagamento estruturado — telas 5, 6

Padrão atual da indústria: DEXs exibem endereço + QR sem contexto de rede. O usuário que compartilha o endereço com alguém fora do produto transfere o risco de "rede certa" para quem vai enviar. Uniswap e PancakeSwap não têm mecanismo de pedido de pagamento estruturado — só endereço bruto.

Por que afeta nosso target: Em #5 e #6, o endereço exibido não carrega a rede. O iniciante que compartilha esse QR com quem vai fazer o primeiro depósito está colocando toda a carga de "rede certa" na outra ponta — que provavelmente também não sabe. Fundos enviados na rede errada podem ser irrecuperáveis ou requerer operações complexas de recuperação.

Hipótese de diferenciação Kotai: Receive como pedido de pagamento — rede pré-selecionada visível no card, opção de incluir token e valor (opcional), payload que quando scaneado gera uma transação pré-configurada na outra ponta. O QR carrega a rede, não só o endereço. Share via link gera página de confirmação para quem vai enviar. Versão mínima: badge de rede sempre visível junto do QR e do endereço, com copy estruturado "Meu endereço em BNB Chain: 0x...". Alinha com o gift code já presente no PancakeSwap (#7) — os dois apontam para a mesma direção de produto: "endereço + contexto", não endereço bruto.

Trade-off: Versão mínima (badge de rede) é trivial e elimina o risco principal; versão completa (pedido de pagamento com valor e token) exige protocolo, UI e UX de duas pontas. Recomendar lançar com versão mínima para eliminar risco e posicionar pedido de pagamento no roadmap de segundo round.

Passa nas 4 perguntas-teste? (1) ✓ Todos os concorrentes exibem endereço bruto sem contexto de rede estruturado. (2) ✓ Risco de perda de fundos afeta iniciante e intermediário diretamente. (3) ✓ Protocolo de pedido de pagamento + UX de duas pontas — investimento não trivial, não impossibilidade técnica. (4) ✓ "meu endereço BNB Chain" vs "endereço 0x..." é mudança imediatamente perceptível pelo iniciante.

Pontos isolados (1 tela)

• 🟢 Tela 1: Empty state como jornada estruturada com 3 caminhos em hierarquia de complexidade — PancakeSwap avança sobre Uniswap aqui; Kotai pode ir além com pergunta única de roteamento ("De onde vem seu primeiro depósito?").
• 🟢 Tela 7: Gift code como payload estruturado (endereço + rede + valor em um único objeto) — vetor de aquisição viral P2P ausente no Uniswap. Estratégico para roadmap de segundo round; alinha com a direção de "Receive como pedido de pagamento" acima.
• 🔴 Tela 3: Chain selector sem estado do usuário — lista plana sem saldo por rede, redes sem saldo indiferenciadas das redes com saldo. Iniciante não consegue identificar onde tem fundos.
• 🔴 Tela 4: "Unexpected error" genérico — sem causa tipada, sem chain identificada, sem CTA recuperador. Bloqueia o iniciante sem path de saída e sem pista do que fazer.
• 🟡 Tela 3: Chain selector como mapa de estado — saldo visível inline por rede, ordenado por saldo descendente, redes zeradas colapsadas. Todos os concorrentes têm lista plana sem saldo; diferença perceptível para quem opera múltiplas chains.
• 🟡 Tela 4: Erros tipados por causa real — matrix (wallet cancelou / rede ausente / RPC indisponível) com copy específica por tipo e CTA recuperador inline. Todos os concorrentes usam catch-all genérico; forte diferencial para o iniciante travado sem caminho de saída.

Comparação rápida com Uniswap

PancakeSwap avança em dois pontos concretos: empty state com 3 caminhos hierarquizados (tela 1) vs. abordagem mais genérica do Uniswap, e gift code como vetor viral P2P (tela 7) — recurso ausente no Uniswap. Regride em scope de funding: sem equivalente ao fluxo de trazer fundos de exchange (Coinbase) presente no Uniswap, e sem abordagem de "Ponte LatAm" identificada como oportunidade principal no consolidado Uniswap — diferença estrutural relevante entre os dois produtos. Compartilha as fricções estruturais de léxico técnico e affordances nivelados com o Uniswap, confirmando que ambos os padrões são cross-concorrente e representam oportunidades de diferenciação para o Kotai.

(Link: Consolidado Uniswap — Carteira Conectada)

6. Painel Receber Cripto — Passo 2: Endereço + QR (EVM)

Função: Tela final do fluxo Receive após escolha da chain-family EVM (Análise 5). Apresenta o endereço de recebimento em duas formas (texto copiável e QR Code) e oferece tab secundária "Resgatar presente" como modo alternativo de receber valor.

Componentes

• Botão back (←) + título "Receber Cripto"
• Tabs: "Endereço" (selecionado, underline) | "Resgatar presente"
• Linha com ícone EVM + label "EVM" + endereço truncado "0xd09B...618a" + ícone copy
• QR Code grande centralizado com mascote bunny da Pancake no centro (logo embutido no QR)
• Sem indicação da rede esperada para envio (BNB? Ethereum? Base?)
• Sem CTA "Share" (envio do endereço via link/sistema)
• Sem campo opcional de valor pra cobrar (payment request)

Regras de negócio

• Endereço EVM é único e serve para qualquer rede EVM — usuário precisa coordenar com remetente pra usar a rede correta
• QR Code codifica apenas o endereço cru (sem network identifier), wallets receptoras dependem da escolha de rede do remetente
• "Resgatar presente" é fluxo paralelo (presumível: redeem de gift card / link de envio Pancake) — separado mas exposto no mesmo painel
• Copy via ícone copia endereço puro pra clipboard (sem prefixo de rede, sem URI scheme)

🟢 Insight Entregar endereço + QR juntos é decisão correta — cobre os dois modos de uso reais (copiar pra colar em outra wallet em desktop; scan em mobile). O bunny no centro do QR é detalhe de marca bem aplicado: QR Codes aceitam ~30% de erro/correção, embutir logo aumenta reconhecimento de marca sem quebrar leitura. Decisão de design polido alinhada com identidade visual sem sacrificar função.

A tab "Resgatar presente" no mesmo painel sinaliza que a Pancake pensa Receive como hub de "entrada de valor" em sentido amplo (não só wallet-to-wallet) — gift cards / referral redemption / promo links como cidadãos de primeira classe. Decisão estratégica interessante de retenção/aquisição: o caminho de receber é também caminho de descoberta.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário, risco de perda de fundos) A tela mostra o endereço pronto para copiar/escanear, mas em momento algum diz "este endereço recebe USDT em Ethereum, BNB Chain, Base, Arbitrum etc. — confirme a rede com quem vai te enviar". Iniciante que repassa esse endereço pro remetente sem informação de rede e o remetente escolhe "Polygon" (que não está suportada) → fundos perdidos. Iniciante que repassa só o QR Code → wallet receptora decide a rede pelo padrão dela.

Isso é a fricção mais grave do fluxo de carteira conectada: a única defesa contra cross-chain misdirect é o passo de escolha de chain-family da Análise 5, mas o passo 2 não amarra essa escolha à informação compartilhada. Quem escolheu "EVM" no passo 1 sai daqui com a falsa sensação de que "selecionei a rede" — quando na verdade selecionou apenas um agrupamento.

Fix óbvio (adicionar texto "Funciona em Ethereum, BNB, Base, +5 redes EVM. Não funciona em Solana/Aptos") é melhoria mínima. Fix correto: forçar o usuário a escolher a rede ESPECÍFICA de destino antes do compartilhamento ("Em qual rede vão te enviar?"), e amarrar essa escolha tanto ao QR (com identifier de rede) quanto a uma label visível no endereço compartilhado ("USDC • Base" em vez de só hex). Para usuário que não sabe a rede, oferecer fluxo guiado ("Pergunte ao remetente em qual rede ele vai mandar").

Direcionamento Kotai: rede sempre travada ao endereço/QR compartilhado. Não existe "endereço solto" no produto. Se o usuário não souber a rede, o produto NÃO entrega o endereço — entrega um "link de pedido" que negocia a rede do lado do remetente. Trade-off: requer wallet do remetente que parseie o link; degradação graciosa via endereço + warning.

^friccao-1

🔴 Fricção 2 (cosmética → estrutural — afeta iniciante e intermediário) Endereço truncado "0xd09B...618a" é affordance ambígua: o usuário não sabe se o copy vai colar o endereço completo ou só o truncado. Iniciante pode tentar selecionar manualmente o texto truncado e colar parcial — perda total de fundos por endereço inválido.

Fix óbvio (mostrar endereço completo) ocupa real-estate. Fix correto: truncado na tela com label "Tap to view full" ou tooltip de confirmação após copy ("Endereço completo copiado: 0xd09B...618a — 42 caracteres"). Confirmação explícita do que foi copiado.

^friccao-2

🔴 Fricção 3 (cosmética — afeta iniciante) O ícone de copy fica sem feedback visível pós-clique (na captura). Iniciante que clica e não vê toast "copied!" pode clicar várias vezes inseguro, ou copiar outra coisa por engano e perder o endereço do clipboard. Padrão moderno é mostrar checkmark ou "Copied to clipboard" inline por 2-3s.

Fix trivial — feedback de copy é estado bem documentado (Material, Tailwind UI, etc.).

^friccao-3

🔴 Fricção 4 (estrutural — afeta intermediário e avançado) Falta CTA "Share" pra enviar endereço via sistema (WhatsApp, Telegram, email, AirDrop). Para iniciante que precisa mandar o endereço pra alguém da família, fluxo atual é: copy → abrir WhatsApp manualmente → colar → enviar. Cinco passos quando deveria ser um. Concorrentes mobile-first (Coinbase Wallet, Trust Wallet) já têm "Share" como botão primário neste contexto.

Fix correto: botão "Share" usando Web Share API (mobile) ou copy-with-message (desktop) que monta payload pronto: "Me manda [valor] em [rede] pro endereço: [link]". Reduz fluxo a 1 clique e embute contexto de rede no compartilhamento.

^friccao-4

🟡 Oportunidade competitiva (alta leverage no target — anti-perda + retenção via gifts) Fluxo Receive padrão em DEX/wallets é: endereço + QR + ícone copy. Sem context-binding de rede, sem share, sem amount request. Passa nas 4 perguntas: (1) convenção entre todos os concorrentes diretos; (2) afeta iniciante DIRETAMENTE no momento de maior risco (compartilhar endereço pra terceiros) e intermediário (que coordena receivers múltiplas vezes); (3) ninguém resolveu por priorizar simplicidade visual e por dificuldade técnica genuína (padrão de payment URI ainda fragmentado); (4) perceptível imediatamente — "esse produto me protegeu de mandar pra rede errada" vira testimonial.

Diferenciação Kotai: Receive como "pedido de pagamento" estruturado em vez de "endereço estático". Componentes do pedido: rede (obrigatória), token (opcional), valor (opcional), nota (opcional). Output: link curto + QR que carregam todo o contexto na wallet do remetente. Para wallets antigas, fallback elegante: endereço puro com warning de rede destacado.

A tab "Resgatar presente" da Pancake é também sinal de oportunidade adjacente: enviar valor como gift (link compartilhável que aceita resgate) é vetor de aquisição viral pouco explorado entre DEXes. Worth tracking pra produto Kotai como feature de segundo round.

Observação adicional (sobre o mascote no QR): o bunny no centro do QR é decisão de marca consistente, mas vale verificar acessibilidade: usuário com baixa visão pode confundir o logo com defeito de impressão e tentar scan repetidamente. Wallets de scan modernas lidam bem com QR-com-logo (Apple/Google Pay fazem igual), então provavelmente não-issue, mas vale testar com leitores básicos. Convenção válida bem aplicada (Apple Pay, WhatsApp, WeChat fazem o mesmo).

^oportunidade-1

8. Submenu Contas — Estado Multi-Chain Completo (EVM + Solana conectadas)

Função: Mesmo popover Accounts da Análise 2, agora no estado em que ambas chain-families (EVM e Solana) têm wallets conectadas. UI já localizada em PT-BR ("Contas"). Mostra a representação visual de identidade multi-chain plena no produto.

Componentes

• Botão back (←) + título "Contas"
• Linha 1 (EVM): ícone cluster EVM + label "EVM" + endereço "0xd09B...618a" + ícones (copy + disconnect vermelho)
• Linha 2 (Solana): ícone Solana + label "Solana" + endereço "EQp4bZ...BDxK" + ícones (copy + disconnect vermelho)
• Ambas linhas com affordances idênticas — copy e disconnect espelhados
• Endereços truncados no mesmo formato (8 chars + ellipsis + 5 chars), apesar de Ethereum/EVM (hex 0x-prefixado) e Solana (base58, ~44 chars) serem formatos totalmente diferentes
• Sem indicação de qual wallet/extension está conectada para cada chain

Regras de negócio

• Cada chain-family conecta a uma wallet independente (Metamask/Trust/Rabby para EVM; Phantom/Backpack/Solflare para Solana)
• Disconnect remove conexão apenas daquela chain-family; o painel My Wallet ajusta saldo e oculta tokens da chain desconectada
• Endereço EVM funciona em todas as redes EVM suportadas; endereço Solana é único da rede Solana
• Truncação padronizada (mesmo número de chars antes/depois) apesar dos formatos de endereço serem nativamente diferentes

🟢 Insight Visualização consistente das duas chain-families lado a lado treina o usuário a entender que ele tem "duas identidades" no produto, uma para cada ecossistema. Padronização visual (mesma estrutura de linha, mesmas ações) reduz carga cognitiva em comparação com tratamento bifurcado. Para usuário multi-chain ativo, é a tela mais informativa do produto sobre estado de sessão.

Disconnect por chain-family (em vez de "disconnect all") é decisão arquitetural correta: o usuário pode operar 100% em EVM em uma sessão e 100% em Solana em outra, sem fricção de reconexão completa.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante e intermediário, herdada e agravada da Análise 2) "EVM" e "Solana" como labels primárias são jargões técnicos que perdem ainda mais sentido aqui que na Análise 2: agora o usuário tem 2 endereços visíveis sem saber qual wallet conectou pra cada. Iniciante que conectou Metamask (EVM) + Phantom (Solana) não vê "Metamask" nem "Phantom" em lugar nenhum — só "EVM" e "Solana". Quando precisar trocar/desconectar uma wallet específica, vai cliciar no disconnect e re-conectar sem saber qual extensão será chamada de volta.

Fix óbvio (adicionar nome da wallet abaixo) cabe no espaço — duas linhas por entrada: "EVM • Metamask" / "Solana • Phantom". Fix correto: identidade primária = wallet ("Metamask • Active on Ethereum, BNB, Base, +5"), com chain-family como secondary label. Como argumentado na Análise 2: conta = wallet, não agrupamento técnico.

Direcionamento Kotai: nome da wallet sempre visível no painel de contas. Ícone do logo da wallet (Metamask raposa, Phantom fantasma, etc.) substitui o ícone genérico de chain-family. Reconhecimento visual antes de leitura.

^friccao-1

🔴 Fricção 2 (estrutural — afeta iniciante, agravada pelo formato dos endereços) Truncação visual idêntica para endereços de formatos diferentes esconde diferença crítica. "0xd09B...618a" é claramente Ethereum/EVM (prefixo 0x familiar pra quem usa); "EQp4bZ...BDxK" é Solana (base58, sem prefixo). Mas a truncação padronizada (8 chars + 5 chars) deleta o sinal mais reconhecível: o "0x" do endereço EVM fica truncado igual ao base58, então um iniciante poderia copiar o endereço errado achando que está copiando "o endereço dele" sem perceber qual chain.

Fix óbvio (preservar prefixo 0x na truncação EVM) ajuda. Fix correto: truncação contextual por formato — EVM mostra "0xd09B...618a" (prefixo + 6 chars + ellipsis + 4 chars), Solana mostra "EQp4bZ8...BDxK" (8 chars + ellipsis + 4 chars). Iniciante reconhece o padrão e associa visualmente cada endereço à sua chain-family.

^friccao-2

🔴 Fricção 3 (estrutural — risco de perda de fundos, herdada das Análises 2 e 6) Ambos endereços têm ícone copy direto, sem qualquer disclaimer de "para qual rede esse endereço serve". Iniciante que precisa receber USDC pode copiar daqui sem passar pelo fluxo Receive (Análises 5–6) — atalho que parece conveniente mas remove a única defesa contra cross-chain misdirect. Pior: copiar o endereço Solana ("EQp4bZ...") pra mandar USDC ERC-20 = perda total. O usuário leigo pode achar que "todo endereço serve pra todo token", e o produto não educa esse momento.

Fix óbvio (alerta antes do copy: "This is your Solana address. Don't use for EVM tokens.") atrapalha fluxo. Fix correto: copy sem aviso (não invadir cada interação), mas toast pós-copy com network reminder ("Endereço Solana copiado — use apenas para tokens na rede Solana"). Educação no momento do ato, não modal de bloqueio.

Direcionamento Kotai: toda copy de endereço gera toast com chain-family destacada. Não é warning agressivo; é confirmação útil que treina o mental model do usuário ao longo do uso.

^friccao-3

🔴 Fricção 4 (cosmética — afeta iniciante, herdada da Análise 2) Ícone de copy e ícone de disconnect com mesmo peso visual permanecem problema aqui. Agora duplicado: 4 ícones idênticos em estrutura visual (2 copies + 2 disconnects) competindo na mesma região. Risco de mis-click aumenta linearmente com número de linhas (já é problema com 1, vira mais com 2 e seria caos com 5+ chain-families).

Fix correto (já argumentado na Análise 2): copy fica como ação primária inline, disconnect entra em kebab (⋯) ou exige confirmação. Princípio: hierarquia de fricção alinhada com hierarquia de consequência.

^friccao-4

🟡 Oportunidade competitiva (alta leverage no target multi-chain) Gestão de identidade multi-chain como tela de catálogo (lista de endereços por chain-family) é convenção entre Uniswap, 1inch, Phantom, Backpack. Passa nas 4 perguntas: (1) convenção entre todos os concorrentes que oferecem multi-chain; (2) afeta iniciante e intermediário diretamente — é a tela onde se forma o mental model de "o que eu tenho conectado e onde"; (3) ninguém resolveu por priorizar exposição técnica honesta sobre clareza UX; (4) perceptível como diferencial — "esse produto me mostrou exatamente qual wallet estou usando em cada rede".

Diferenciação Kotai (consolidando Análises 2 e 8): tela "Minhas conexões" organizada por wallet (Metamask, Phantom, Trust), cada wallet listando as chain-families que cobre, com badge da chain ativa em destaque. Endereços com truncação contextual por formato. Copy gera toast com chain-family destacada. Disconnect com confirmação. Toda a tela vira mapa-de-identidade, não inventário-de-endereços.

Observação adicional (sobre o fechamento do fluxo Carteira Conectada): essa tela é o último ponto onde o produto pode educar o usuário sobre como sua identidade multi-chain funciona antes que ele entre nas operações (swap, pool, etc.). Investir nessa tela tem ROI desproporcional — não é tela de "settings" decorativo, é a tela onde o mental model do usuário se consolida. Tratá-la como inventário desperdiça oportunidade de onboarding contínuo. Vale considerar surface dedicada (rota /accounts, não só popover) com mais real-estate para educação visual.

^oportunidade-1

7. Painel Receber Cripto — Tab "Resgatar presente" (gift redeem)

Função: Tab alternativa dentro do painel Receber Cripto (Análises 5–6). Modo de "receber valor" via código de presente compartilhado por outro usuário Pancake — fluxo paralelo a receber por endereço.

Componentes

• Botão back (←) + título "Resgatar presente"
• Tabs: "Endereço" | "Resgatar presente" (selecionado, roxo)
• Card interno com:
  • Título "Resgatar presente"
  • Copy explicativa: "Se você tiver um código de presente de um amigo, insira-o aqui para resgatar seu token de presente."
  • Input vazio "Inserir código" (placeholder, borda roxa indicando estado focado)
  • Botão "Reivindicar" disabled (cinza, baixo contraste)
• Sem indicação de formato do código (alfanumérico? quantos caracteres?)
• Sem opção de scan QR ou colar de link
• Sem "Onde encontro um código de presente?" / aprendizado in-context

Regras de negócio

• Botão "Reivindicar" só habilita quando input passa validação (formato/checksum não exposto)
• Código presumivelmente único e single-use, gerado por outro usuário Pancake no fluxo de Send
• Tab "Resgatar presente" persistente no painel Receber, mesmo se usuário nunca participou de gift
• Resgatar credita o token diretamente na chain associada ao código (não exige usuário escolher rede)

🟢 Insight Gift redeem como cidadão de primeira classe no painel Receber é decisão estratégica forte: posiciona "valor entrante" como categoria que vai além de wallet-to-wallet. Para iniciante recebendo do amigo já-usuário-Pancake, o fluxo é radicalmente mais simples que copiar endereço, escolher rede, e depender da rede certa — o código entrega rede + token + valor amarrados num single payload. Resolve internamente o problema que o fluxo de endereço (Análises 5–6) não resolve: rede travada ao compartilhamento.

Estado disabled do botão "Reivindicar" com input vazio é correto — não convida clique até ter dado válido. Borda roxa do input com foco sinaliza estado interativo claro.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante) "Insira o código" sem mostrar formato é fricção de discoverability silenciosa. Iniciante que recebeu "PCKAKE-X9K2-7HJM" não sabe se cola com hífens, sem hífens, com prefixo, ou se essa string é mesmo o código (e não a URL de redenção). O input não dá pista de placeholder com formato esperado ("ABCD-1234-EFGH" como exemplo). Pior: validação parece ser binária (tudo certo → habilita botão; errado → continua disabled), sem mensagem orientadora.

Fix óbvio (adicionar placeholder com exemplo) ajuda mas é parcial. Fix correto: input aceita formatos múltiplos (com/sem hífens, com/sem prefixo, URL completa), normaliza no client; validação progressiva com microcopy ("Continue digitando…" / "Formato não reconhecido" / "Código válido"); paste-handler que detecta URL e extrai código automaticamente.

^friccao-1

🔴 Fricção 2 (estrutural — afeta iniciante e intermediário) A tab "Resgatar presente" não diferencia visualmente entre "você nunca usou" e "você tem um código pendente esperando resgate". Se o amigo mandou o código por WhatsApp há 2 dias e o usuário esquece, não há sinalização — a tab fica idêntica ao estado vazio. Pior: se o produto detectasse o código no clipboard do usuário (com permissão), poderia oferecer resgate proativo ("Detectamos um código no seu clipboard, quer resgatar?").

Fix óbvio (badge "1" sobre a tab pra códigos pendentes) requer que o sistema saiba que existe código pra o usuário — possível se o gift cria registro do lado do servidor com email/handle do receptor. Fix correto: notificação push/email do envio + tab com badge quando há pending; clipboard detection como opcional. Receive precisa parar de ser passivo.

^friccao-2

🔴 Fricção 3 (cosmética → estrutural — afeta iniciante) Ausência completa de "de onde vem um código". Iniciante na tab "Resgatar presente" sem nunca ter ouvido falar de gift codes Pancake fica perdido: precisa de "como funciona" inline, talvez link "Saiba mais sobre presentes" ou "Mande um presente você também" (cross-promo bidirecional). A tab existe sem onboarding, então só serve quem já sabe — viola a regra básica de feature discoverability.

Fix correto: empty state com 2-3 linhas de explicação ("Amigos podem te mandar tokens via código sem você precisar compartilhar endereço. Quando alguém te enviar, cole o código aqui.") + CTA secundário ("Mandar presente pra um amigo →") que vira loop viral. A tab sem código se transforma em superfície de descoberta.

^friccao-3

🔴 Fricção 4 (cosmética — afeta iniciante) Falta opção de "scan QR" ou "colar link" como input alternativo. O amigo provavelmente compartilhou um link ou QR (não um código alfanumérico avulso) — usuário tem que extrair o código manualmente. Em mobile especialmente, scan QR como input primário seria muito mais natural.

Fix correto: input com três modos de entrada — digitar/colar código, colar URL (extrai automaticamente), scan QR (mobile). Reduz fricção em todos os formatos possíveis de compartilhamento.

^friccao-4

🟡 Oportunidade competitiva (alta leverage — vetor de aquisição viral) Gift redemption embutida em DEX é raríssima: Uniswap, 1inch, SushiSwap não têm; Coinbase Wallet tem versão (gift links) mas não é canal primário. A Pancake já está à frente da curva ao expor a tab no painel Receber — mas trata o feature como "redeem-only side path". A oportunidade real é simétrica: o produto deveria expor "Send as gift" no mesmo nível que "Send" normal. Passa nas 4 perguntas: (1) ausência de gift como ação primária é convenção entre concorrentes diretos; (2) afeta iniciante diretamente (gift é o caso de uso mais natural pra alguém receber a primeira cripto da vida) e intermediário (que vira porta de entrada pra amigos); (3) ninguém resolveu porque exige infraestrutura backend (custódia temporária do gift até resgate, expiração, refund) que DEX puramente on-chain não tem; (4) perceptível como diferencial — "esse DEX me deixou mandar cripto pro meu amigo só com o nome dele" vira testimonial.

Diferenciação Kotai: gift como vetor primário de aquisição P2P (send para alguém ainda sem wallet → link de resgate → usuário cria wallet ao resgatar). Trade-off: complexidade backend significativa, regulação de "custódia temporária" pode aplicar em certas jurisdições. Vale tratar como roadmap de segundo round, não MVP.

Observação adicional (sobre o nome): "Resgatar presente" é tradução literal de "Redeem gift". Funciona em PT-BR mas perde a conotação de "recebimento de valor" que "redeem" tem em inglês. Vale testar alternativas: "Resgatar código", "Receber presente", "Receber via código". A copy é vetor pequeno de fricção mas vale revisar em testes com brasileiros.

^oportunidade-1

5. Widget — "Detalhes ocultos" expandido (breakdown de taxas)

Função: Estado pós-clique no link "Exibir detalhes" — exibe a decomposição do valor "Taxas totais est." em suas duas partes principais (provedor + Pancake).

Componentes: widget idêntico ao default + linha de fees agora com sub-itens visíveis: "Provider Fees — US$ 3,86" e "Pancake Fees — US$ 1,09"; copy do link muda para "Detalhes ocultos"; total permanece "US$ 4,95"; CTA "Comprar com Mercuryo" continua disponível.

Regras de negócio: o total exibido = provider fee + pancake fee. Network fee (gas BNB Chain) e spread cambial não aparecem explicitamente — provavelmente embutidos no preço cotado pelo provedor. O estado é toggleable na mesma sessão.

🟢 Insight: separar explicitamente a taxa do provedor da taxa da própria PancakeSwap é honesto e raro em DeFi UX — a maioria dos produtos embute fees no spread invisível. Para iniciante isso constrói confiança porque mostra que a plataforma cobra (e quanto), em vez de fingir que é "grátis".

^insight-1

🔴 Fricção (cosmética mas grave — copy): "Detalhes ocultos" é tradução literal de "Hide details" e fica gramaticalmente ambígua em PT-BR. O usuário lê como descritivo ("existem detalhes que estão ocultos") quando na verdade é o estado do botão ("ocultar detalhes"). Alternativa: par consistente "Exibir detalhes" / "Ocultar detalhes" (verbo no infinitivo, ação clara). Diagnóstico errado: trocar para "Esconder" — não corrige a ambiguidade.

^friccao-1

🔴 Fricção 2: "Provider Fees" e "Pancake Fees" permanecem em inglês num produto traduzido. Quebra a confiança ("o resto está em PT, isso parece bug ou string esquecida"). Alternativa: "Taxa do provedor" e "Taxa da PancakeSwap" — mantém paralelismo e remove jargão.

^friccao-2

🟡 Oportunidade competitiva: breakdown só agrega 2 linhas grossas. Faltam network fee (gas), spread cambial USD→cripto e margem do provedor sobre o spot. Uniswap, 1inch e KuCoin on-ramp fazem igual: agregam tudo num número opaco. Diferencial perceptível: breakdown em 4 camadas + linha "preço de mercado X • você paga Y • diferença Z". Trade-off: pode assustar pelo total visível; mitigar com disclosure de dois níveis (resumo padrão, detalhe granular sob clique).

^oportunidade-1

Consolidado — Conectar Carteira (Pancake)

Caráter geral do fluxo

O fluxo de Conectar Carteira da PancakeSwap é o mais abrangente dos concorrentes analisados: 13 telas cobrindo estados que a Uniswap sequer endereça — wallet não instalada, fallback QR, aguardando confirmação, multi-conexão EVM+Solana paralela, filtro por ecossistema, retorno de sessão. Essa amplitude é genuinamente positiva e indica que a Pancake investiu em cobrir casos reais de usuário, não só o caminho feliz. A tensão central do fluxo, no entanto, é amplitude com execução incompleta: a mesma tela #1 que posiciona Social Login no topo (reconhecendo o iniciante de CEX) amalgama Social Login com EOA sem distinguir modelos de custódia radicalmente diferentes. O fluxo repete esse padrão ao longo de 13 telas — decisões corretas de arquitetura envoltas em execução que transfere risco e responsabilidade ao usuário. O maior risco de abandono concentra-se nos estados de handoff (tela 6 e tela 9), onde o usuário é enviado para contextos externos sem rota de retorno nem feedback de progresso. Perfil mais afetado: iniciante nos estados de entrada e nos handoffs; intermediário na nomenclatura técnica e nos trust signals.

🟢 Insights recorrentes

Painel master/detail preserva contexto durante a escolha — telas 1, 2, 3, 4

A decisão de dividir o seletor em painel esquerdo (ação) + painel direito (contexto/educação) e atualizar o direito sem fechar o modal é o padrão mais poderoso do fluxo. Em #1, o painel direito acomoda mascote e links educacionais; em #3 e #4, exibe informações específicas da wallet selecionada (chains suportadas, capabilities). O usuário pode comparar wallets sequencialmente sem reabrir modal — painel esq. = ação, painel dir. = contexto. Princípio adotável no produto Kotai para qualquer seletor com múltiplas opções não trivialmente equivalentes.

Detecção proativa de estados não-triviais — telas 6, 9, 11

Em vez de jogar erro genérico, a Pancake reconhece estados intermediários e exibe contexto dedicado: wallet não instalada em #6, aguardando aprovação na wallet em #9, e conexão parcial (EVM conectado, Solana pendente) em #11. Esses estados correspondem às maiores causas de abandono no fluxo — e cobri-los proativamente é o acerto mais relevante da execução. A maioria dos DEXes não tem estados dedicados para esses casos e joga o usuário num erro genérico ou fecha o modal silenciosamente.

MEV protection como signal multi-touchpoint — telas 3, 11, 13

Trust signal de MEV protection aparece em três pontos do fluxo: tooltip no seletor em #3, chip persistente no Swap form em #11, e reforço no estado pós-conexão em #13. Redundância de signal de segurança é rara entre DEXes. Nota crítica: a leitura da tela 13 revelou que MEV protection vale para todas as wallets suportadas — não é exclusivo de Metamask como pareceria pela tela 3 isolada. O problema não é o signal inexistir, é ele ser hover-gated (ver fricção correspondente).

Progressive disclosure na curadoria de wallets — telas 1, 8

A hierarquia Top 4 → More Wallets (11+) aparece na abertura do seletor em #1 e se confirma no estado expanded em #8. A inclusão de WalletConnect em "More" (meta-protocolo como fallback, não como opção primária) é decisão arquitetural correta. Iniciante não vê 15 opções ao mesmo tempo; avançado chega facilmente às suas preferências. Padrão adotável com refinamento de critério de curadoria.

🔴 Fricções recorrentes

Estrutural — Abandono em handoff: usuário enviado para contexto externo sem rota de retorno — telas 6, 9

É o ponto de maior churn do fluxo e o atrito mais grave desta consolidação. Em #6, o botão Install abre nova aba de extensão sem qualquer mecanismo de retorno — sem deep link, sem listener de instalação, sem "volte aqui depois". Em #9, o spinner de "aguardando confirmação" não tem cancelar, não tem retry, não tem timeout explícito. Casos comuns onde isso vira armadilha: popup aberto atrás de outras janelas; popup bloqueado pelo browser; usuário fecha o popup sem confirmar. Nos três casos a Pancake fica esperando para sempre e o usuário precisa descobrir sozinho que deve fechar e reabrir o modal.

O padrão subjacente é o mesmo nas duas telas: o produto trata handoffs como eventos de uma via, não como transições com possibilidade de falha.

Por que solução óbvia falha: adicionar timeout com mensagem de erro resolve só o caso de timeout — ignora popup bloqueado e usuário que perdeu o contexto. Fix pontual de copy não substitui engenharia de estado.

Alternativa concreta: em #6, manter o modal aberto com polling do extension namespace e CTA contextual "Detectamos a wallet — Conectar agora" ao completar; em #9, adicionar "Não viu o popup? [Reabrir popup]" + "Mudou de ideia? [Voltar e escolher outra wallet]" + timeout visual com contagem. Trade-off: requer instrumentação por provider (cada wallet tem comportamento próprio de inject) — superfície de manutenção não-trivial.

Perfil afetado: iniciante (não sabe que popup abriu em segundo plano; não entende spinner indefinido como erro).

Estrutural — Custódia implícita: Social Login e EOA tratados como opções equivalentes — telas 1, 2, 5, 8

Ao longo de quatro telas, o fluxo coloca lado a lado opções com modelos de custódia radicalmente diferentes sem qualquer distinção visual ou textual. Em #1 e #2, Social Login (smart wallet/MPC, recovery via Google, dependência do OAuth) e EOA (chave privada própria) convivem no mesmo seletor com peso visual equivalente. Em #5, Binance Wallet (exchange-linked, sujeita a KYC e restrições geográficas da Binance) tem peso visual idêntico ao Metamask (independent). Em #8, Coinbase Wallet, WalletConnect, Rabby, TokenPocket e SafePal — modelos radicalmente diferentes — aparecem no mesmo grid sem diferenciação.

O risco real não é "o iniciante pode escolher errado" — é que o produto silenciosamente autoriza a escolha sem que o usuário entenda o que está aceitando. Implicações de recovery, gas, single point of failure e restrições geográficas são invisíveis na UI.

Por que solução óbvia falha: badge "Smart Wallet" ao lado do Social Login usa jargão. Tooltip de custódia não é ativado em momento de decisão. O signal precisa estar na hierarquia visual, não em camada de descoberta.

Alternativa concreta: bifurcação visual antes do seletor — seção "Crie sua wallet" (Social Login, smart wallet, sem seed phrase) separada de "Conecte sua wallet" (EOA, custódia própria), cada uma com microcopy de 1 linha sobre modelo de recuperação ("Recupere pelo Google" vs "Você controla a chave"). Em #8, badges de 2-3 atributos por card (exchange-linked / independent / hardware / mobile-first) eliminam comparação por ausência. Trade-off: bifurcação adiciona 1 clique para quem já decidiu; badges exigem manutenção de matriz de capability.

Perfil afetado: iniciante (risco maior, menor capacidade de recuperar de escolha errada); intermediário (pode escolher Binance Wallet sem entender implicações de exchange-linked).

Estrutural — MEV trust signal hover-gated: vantagem real desperdiçada em tooltip — telas 3, 11, 13

Reclassificação crítica cross-lote: a leitura da tela 13 revelou que a fricção original ("Trust Wallet sem tooltip MEV = capability gap") estava mal diagnosticada. Trust Wallet TEM MEV protection na Pancake; o signal simplesmente não estava visível no hover correto da tela 4. O problema real é UX gap de visibilidade, não gap de capability.

Em #3 (âncora no insight; fricção identificada em síntese cross-lote), #11 e #13, o conteúdo completo do trust signal depende de hover em pontos específicos do painel. O chip no Swap form de #11 mitiga parcialmente — é persistente — mas está semi-visível na primeira aparição. Iniciante que move o mouse rapidamente não descobre. A consequência de segunda ordem é estratégica: a Pancake tem vantagem real sobre a Uniswap (MEV por default vs ativação manual via UniswapX) e está desperdiçando esse diferencial em tooltips de hover.

Alternativa concreta: badge persistente "MEV protegido" ao lado do nome da wallet no seletor (não hover-only) + chip persistente e visível no Swap form + reforço plain-language na primeira aparição pós-conexão em #13: "Você está protegido contra bots que manipulam o preço do seu swap — não é necessário fazer nada". Tooltip de detalhamento vira segunda camada, não fonte primária. Trade-off: mais elementos visuais; em momento de decisão financeira, densidade adicional de trust signal é aceitável.

Perfil afetado: iniciante (nunca ativa tooltip; é quem mais precisa do reforço antes de agir).

Estrutural — Tooltip como patch na camada errada — telas 12, 13

Em #12, a Pancake criou tooltip on-demand para "EVM" — reconhecendo que a sigla não é autoexplicativa para iniciante. Em #13, tooltip para "MEV protection". Em ambos, o diagnóstico do time estava correto mas a solução foi implementada na camada errada: tooltips sobre labels problemáticos em vez de corrigir os labels primários. Layer-on-layer: a informação correta existe, mas escondida atrás de affordance que iniciante nem sempre ativa.

O sinal preocupante é que telas 12 e 13 mostram dois exemplos do mesmo anti-padrão em sequência — isso indica que adicionar tooltip virou procedimento padrão interno ao reconhecer um gap de copy, em vez de corrigir a fonte.

Alternativa concreta: corrigir o label primário diretamente. "EVM" → "Ethereum & compatíveis" no card de chain; "MEV protection" → "Protegido contra bots" no chip/badge, com tooltip opcional para quem quer detalhamento técnico. Trade-off: mudança no design system propaga para múltiplas telas; é o custo de não acumular debt de tooltip.

Perfil afetado: iniciante (nunca descobre o tooltip; recebe o label técnico como informação definitiva).

Estrutural — Nomenclatura técnica de ecossistemas: EVM como categoria abstrata ao lado de Solana como nome próprio — telas 3, 4, 5

A assimetria taxonomia/nome afeta as três telas de Select Chain com wallets multi-ecossistema. "EVM" é categoria técnica abstrata que agrupa Ethereum, BNB Chain, Base, Arbitrum e mais; "Solana" é nome próprio de uma chain específica. Iniciante pode interpretar EVM como chain alternativa a Solana — especialmente em #5 (Binance Wallet), onde Solana aparece com mesma proeminência que EVM, mas Binance Wallet quase nunca opera em Solana na prática.

Problema de design system: corrigir nas três wallets de uma vez. Fix correto: substituir "EVM" por "Ethereum & compatíveis (BNB, Polygon, Arbitrum...)" — Solana mantém o nome próprio. Em #5, reordenar prioridade do card conforme perfil da wallet (BNB Chain em destaque, Solana colapsado com "também suportado"). Trade-off: labels mais longos impactam layout; mitiga-se com hierarquia tipográfica.

Perfil afetado: iniciante (não sabe o que é EVM); intermediário de Solana (confusão sobre compatibilidade com outras chains).

Estrutural — Toggle SOLANA ONLY sem anúncio do estado ativo — telas 10, 11

Em #10, o chip "SOLANA ONLY" reordena o Top Wallets dinamicamente — feature correta. Mas em #11, o toggle persiste ativo após conexão EVM bem-sucedida, e não há announcement visual de que a lista está filtrada. Iniciante que aterrissa nesse estado vê Phantom/Solflare/Backpack como Top Wallets e não entende onde Metamask foi parar — conclui por lista aparentemente incompleta que Metamask não é suportada.

Alternativa concreta: banner/chip informativo quando toggle ativo: "Mostrando apenas wallets Solana · [Ver todas]" — estado do filtro vira primeiro-classe na hierarquia visual, não detalhe em chip de header. Após conexão bem-sucedida com wallet EVM, reset automático do filtro (ou prompt: "Conexão EVM feita. Manter filtro Solana?"). Trade-off: reset automático pode frustrar usuário que explicitamente quer conectar Solana depois; banner resolve sem precisar do reset.

Perfil afetado: iniciante e intermediário (filtro silencioso surpresa qualquer perfil que não leu o chip de header).

Cosmética — Copy boilerplate e copy técnica sem diferenciação (design system) — telas 3, 4, 5, 7, 9, 12

Mesmo padrão de design system em múltiplas telas: copy gerada pelo sistema ou reutilizada sem adaptação para o usuário. Em #3, #4 e #5, " supports multiple ecosystems" é literalmente a mesma frase com só o nome substituído — zero informação diferenciadora para quem compara as três wallets em sequência. Em #7, instrução com 4 condicionais numa frase quando o usuário precisa de 1 passo direto. Em #9, "confirm in Trust Wallet" sem referência espacial (onde? popup? extensão no canto superior direito?). Em #12, tooltip de EVM usa definição técnica correta mas em vocabulário de engenharia.

O padrão subjacente é consistente: copy escrita para o sistema ser preciso, não para o usuário agir. Fix cosmético em cada instância; fix sistêmico exige critério de copy review aplicado como parte do design system.

Perfil afetado: iniciante (mais dependente de copy para tomar a próxima ação).

Cosmética — Painel direito herdando estado obsoleto em transições — telas 8, 10

Em #8, expandir More Wallets mantém o painel direito mostrando estado anterior de OKX. Em #10, toggle Solana ativo com painel mostrando "Please confirm in Trust Wallet" — estados contraditórios convivendo sem reconciliação. Usuário que olha o painel direito antes de clicar vê informação de contexto inconsistente com a ação atual.

Fix trivial: reset do painel ao trocar de grupo ou ao ativar filtro que reorganiza o seletor. Se estado anterior for relevante preservar, sinalizar explicitamente ("Conexão Trust Wallet pendente — quer cancelar?"). Trade-off: possível flicker visual no reset; mitigável com fade curto.

Perfil afetado: todos os perfis; cosmético mas gera sensação de bug.

🟡 Oportunidades competitivas do fluxo

Seletor contextual de wallet: bifurcação de jornada + detecção — telas 1, 2, 8

Padrão atual da indústria: Uniswap, PancakeSwap e 1inch apresentam o mesmo seletor estático de wallets para qualquer usuário, independentemente do contexto. Pancake posiciona Social Login no topo (correto), mas sem distinguir jornada de criação da de conexão. Uniswap destaca wallet proprietária em rosa independentemente do contexto. Nenhum DEX principal oferece seletor que responda ao perfil detectado do usuário.

Por que afeta nosso target: o iniciante que vem de CEX chega sem wallet — encontra o mesmo seletor que o power user com 3 wallets instaladas. Em #1, criar wallet via Google (modelo de custódia vinculado ao OAuth) e conectar Metamask (EOA, custódia própria) aparecem lado a lado sem distinção. Em #2, o seletor estático se mantém numa sub-tela — a ausência de bifurcação não é singular à abertura do modal mas se repete na navegação interna. Em #8, o intermediário que retorna precisa de busca visual para encontrar a wallet que já usou na sessão anterior. A jornada "ainda não tenho wallet" e "já tenho wallet" compartilham exatamente o mesmo UI.

Hipótese de diferenciação Kotai: seletor com três estados automáticos: (1) nenhuma wallet detectada → primeiro CTA é "Crie sua wallet" com distinção de custódia; "Já tenho wallet" colapsado abaixo; (2) wallet(s) detectada(s) → wallet instalada promovida ao topo com CTA contextual "Continuar com MetaMask"; outras opções colapsadas; (3) reconexão → última wallet usada como CTA primário, resto colapsado. Detecção via window.ethereum, window.solana, e namespaces conhecidos.

Trade-off: requer detecção client-side de extensões instaladas; estados diferentes por sessão podem confundir usuário que nota a diferença. Compensado pelo ganho de velocity de conexão e pelo sinal implícito "este produto trabalha a favor do usuário, não do funil da casa".

Passa nas 4 perguntas-teste?

1. ✓ Todos os DEXes principais tratam o seletor de wallets como lista estática ou com hierarquia comercial.
2. ✓ Afeta iniciante (barreira de entrada) e intermediário retornante (fricção de reconnect).
3. ✓ Razão de ninguém ter resolvido: custo de arquitetura de seletor contextual + sacrifício de superfície de funil para wallet própria.
4. ✓ Diferença perceptível: "1 clique certeiro" vs "busca visual na lista".

Nomenclatura de chains para humanos — telas 3, 4, 5

Padrão atual da indústria: todos os DEXes e wallets multi-ecossistema (Uniswap, PancakeSwap, 1inch, MetaMask) usam taxonomia técnica ("EVM", "SVM", "Cosmos") nos seletores de chain e ecossistema. Convenção de engenharia vazando para UI de produto.

Por que afeta nosso target: em #3, #4 e #5, a escolha de ecossistema é a primeira decisão técnica pós-seleção de wallet. Iniciante reconhece "Ethereum, BNB Chain, Base" — não reconhece "EVM". A sigla cria barreira cognitiva antes de qualquer ação. A Pancake chegou perto ao criar tooltip de EVM em tela 12, mas resolveu na camada errada.

Hipótese de diferenciação Kotai: no card Select Chain, substituir "EVM" por nomes de chains específicas com collapse inteligente — "Ethereum, BNB Chain, Base e mais 4" — mantendo o tooltip como detalhamento técnico opcional. Em wallets com perfil claro (Binance Wallet → BNB-first), reordenar prioridade do card conforme contexto.

Trade-off: labels mais longos impactam layout de cards; lista de chains "e mais N" precisa ser atualizada conforme suporte expande. Compensado por clareza imediata para o target principal.

Passa nas 4 perguntas-teste?

1. ✓ Taxonomia técnica é padrão universal em DEXes multi-ecossistema.
2. ✓ Afeta iniciante diretamente — é a primeira escolha de ecossistema no fluxo.
3. ✓ Ninguém resolveu por inércia de design system (vocabulário interno reaproveitado), não impossibilidade.
4. ✓ "Ethereum, BNB Chain" vs "EVM" é diferença de reconhecimento imediata para o iniciante.

Hierarquia das oportunidades por leverage no iniciante: Seletor contextual > Nomenclatura de chains. (Guardrails ativos reclassificado para pontos isolados — 1 tela; ver abaixo.)

Pontos isolados (1 tela)

• 🟢 Tela 5: Binance Wallet no Top 4 — posicionamento honesto para target BNB-first; iniciante de ecossistema Binance encontra opção familiar sem buscar.
• 🟢 Tela 7: QR fallback mobile-to-desktop para OKX — cobre caso real de usuário com app mobile mas sem extension de desktop; concorrentes tendem a oferecer só Install.
• 🟢 Tela 10: Filtro SOLANA ONLY com reordenação dinâmica do Top Wallets — diferencial real sobre concorrentes; Uniswap e 1inch não oferecem filtragem contextual no seletor. Feature correta enterrada em chip de header pequeno.
• 🟢 Tela 11: PREVIOUSLY USED como section dedicada — acelerador de re-engagement para retornante; mais explícito que o badge "Detectada" da Uniswap.
• 🟢 Tela 11: estado de conexão parcial (EVM conectado + Solana pendente) reconhecido como legítimo — botão Connect de Solana permanece sem forçar desconexão da EVM. Sofisticação rara em DEXes multi-ecossistema.
• 🔴 (estrutural, 1 tela) Tela 1: ausência de "contrato de confiança" pré-conexão — o modal abre sem explicar o que acontece depois (produto vê saldo e endereço; transações exigem assinatura separada). "Manage and store your private keys and assets securely" é ambíguo — sujeito gramatical pode ser lido como "Pancake vai guardar". Iniciante com ceticismo pode abortar.
• 🔴 (estrutural, 1 tela) Tela 2: aviso "May cause permanent loss" em linguagem condicional hedgeada — lista 6 chains por nome técnico sem explicar o que o produto faz ativamente para prevenir. Disclaimer legal em vez de guardrail. Ver 🟡 oportunidade abaixo nesta seção.
• 🔴 (estrutural, 1 tela) Tela 7: restrição técnica (Solana via mobile OKX não suportada) apresentada sem justificativa nem alternativa — usuário que quer Solana + OKX mobile fica sem rota.
• 🔴 (estrutural, 1 tela) Tela 11: estado conectado sem detalhe suficiente — check verde único sinal de sucesso; sem chain específica ativa (URL indica BSC mas UI só diz "EVM"), sem endereço truncado. Painel direito poderia ser mini-dashboard de status pós-conexão.
• 🔴 (cosmética, 1 tela) Tela 6: bug de template "OKX Wallet wallet" — string ${walletName} wallet não verifica se o nome já contém "Wallet". Sinal de pipeline QA fraco em strings template-driven; provavelmente afeta outras wallets com "Wallet" no nome.
• 🔴 (cosmética, 1 tela) Tela 6: hierarquia de CTAs invertida — "Setup Guide" como botão primário cheio quando a ação indicada pelo contexto é "Install". Iniciante é orientado pelo visual, vai para documentação quando deveria ir para instalação.
• 🟡 (oportunidade, 1 tela) Tela 2: Guardrails ativos em vez de disclaimers textuais — validação client-side antes de habilitar CTA se chain não suportada; botão desabilitado com mensagem inline ("Sua wallet está em Ethereum mainnet — mude para BSC para continuar") substitui disclaimer hedgeado. Passa nas 4 perguntas-teste com reserva em Q3 — custo de bloquear o fluxo é trade-off de UX ativo, mitigado por escape hatch "Prosseguir assim mesmo". Oportunidade de maior custo de implementação deste fluxo; avaliar ganho de proteção do iniciante vs restrição do avançado antes de priorizar.

Comparação rápida com Uniswap

Ver consolidado equivalente: Conectar Carteira — Uniswap.

Pancake à frente:

• Social Login como on-ramp — Uniswap exige wallet instalada como pré-requisito; Pancake reconhece o iniciante de CEX na porta de entrada.
• MEV protection por default e multi-touchpoint — Uniswap exige ativação manual via UniswapX.
• Cobertura de estados não-triviais (wallet não instalada em #6, aguardando confirmação em #9, conexão parcial em #11) — Uniswap não endereça nenhum desses estados; simplesmente não cobre.
• Filtro SOLANA ONLY com reordenação dinâmica — Uniswap não tem equivalente.
• PREVIOUSLY USED como section dedicada — mais explícito que badge "Detectada" da Uniswap.

Uniswap à frente:

• Fluxo mais enxuto (6 vs 13 telas): menos opções, menos ruído cognitivo para quem só quer conectar Metamask rápido.
• Badge "Detectada" promove wallet instalada ao topo de forma mais cirúrgica — sem reorganizar o seletor inteiro.
• Hierarquia comercial mais contida na Pancake: Uniswap empurra wallet proprietária em rosa em todos os estados; Pancake empurra ecossistema BNB-first de forma mais contextual.

Ambos falham igualmente — oportunidades abertas para Kotai:

• Paridade visual entre wallets de modelos radicalmente diferentes (exchange-linked vs independent vs smart wallet).
• Copy técnica sem tradução para benefício nos tooltips.
• Estados de espera passivos sem retry ou rota de abandono.
• Nenhum bifurca "tenho wallet" vs "não tenho" — a oportunidade de maior leverage no iniciante permanece aberta.

1. Comprar cripto — Widget on-ramp (estado default)

Função: Ponto de entrada do fluxo fiat→cripto. Permite ao usuário definir valor em moeda fiduciária, escolher token de destino e ver cotação agregada de provedores on-ramp antes de seguir ao checkout externo.

Componentes: título "Comprar cripto" + subtítulo descritivo; input de valor fiat (150) com seletor de moeda (USD); seta direcional; output calculado em cripto (95.35276 CAKE) com label "em binance"; seletor de provedor (Mercuryo) com badge "Melhor cotação"; chip de rede (BNB Chain); linha "Taxas totais est. US$ 4,95" com link "Exibir detalhes"; CTA primário "Comprar com Mercuryo"; nota de termos de serviço.

Regras de negócio: o produto opera como agregador de on-ramps de terceiros, não como processador direto. A cotação muda em função de (a) moeda fiat, (b) token destino, (c) rede, (d) provedor ativo. "Melhor cotação" é selecionada automaticamente pelo menor custo total agregado, mas o usuário pode trocar. O checkout final acontece no provedor (KYC, pagamento, custódia inicial).

🟢 Insight: o agregador remove uma decisão de alto custo cognitivo do iniciante ("qual provedor on-ramp usar"). Ranquear por "Melhor cotação" + mostrar fee agregado antes do CTA é o comportamento correto — o iniciante consegue tomar a decisão sem precisar comparar manualmente.

^insight-1

🔴 Fricção (estrutural — afeta iniciante): o rótulo "CAKE em binance" no output é ambíguo de forma perigosa. "em binance" refere-se à BNB Smart Chain (rede), mas iniciante vindo de CEX lê como "será creditado na minha conta Binance". A confusão exchange/blockchain é justamente o ponto onde iniciante mais erra. Trocar para "CAKE na BSC" mantém o jargão. Alternativa: espelhar o chip "BNB Chain" que já existe abaixo — usar a mesma string em ambos os lugares ("CAKE • BNB Chain"). Trade-off: aumenta levemente o comprimento do label.

^friccao-1

🟡 Oportunidade competitiva: "Taxas totais est. US$ 4,95 — Exibir detalhes" condensa spread do provedor, network fee e FX num único número opaco. Uniswap, 1inch e Pancake fazem igual. Para nosso target, breakdown sempre visível em linguagem humana (ex.: "Provedor cobra X • Rede Y • Câmbio Z") com comparativo informal contra CEX (sem prometer paridade) é diferencial perceptível. Trade-off: maior verticalidade e risco de abandono por "parecer caro" — mitigar com hierarquia visual (total grande, breakdown menor).

^oportunidade-1

Observação adicional: expor o nome do provedor no CTA ("Comprar com Mercuryo") é decisão deliberada de transparência, não fricção. Mas introduz uma marca desconhecida no momento de maior tensão. Para nosso target, vale testar prefixo de confiança ("Pagar via Mercuryo — processado por…") sem esconder o provedor.

2. Modal "Selecione uma moeda" — Seletor de fiat

Função: Submodal aberto a partir do seletor de moeda do widget. Define a denominação fiat de entrada (input do valor de compra) e consequentemente toda a cotação seguinte.

Componentes: título "Selecione uma moeda"; campo de busca "Procurar nome" (com foco visível); section header em ciano "selecionar uma moeda"; lista vertical de fiats com ícone circular, código (USD/EUR/GBP/HKD/CAD/AUD/BRL…), nome completo e chevron de avanço; modal sem botão fechar explícito (dismiss por overlay).

Regras de negócio: lista de fiats limitada às moedas suportadas pelos provedores on-ramp integrados. Selecionar moeda fecha o modal e recotiza valor de destino + provedor + taxa. Não há favoritação nem "moedas recentes". A ordenação parece seguir popularidade global, não geo-localização.

🟢 Insight: BRL aparece dentro dos primeiros 7 itens sem necessidade de scroll/busca — para o target brasileiro isso é relevante e provavelmente intencional. A busca proeminente reconhece que a lista pode crescer e prepara o usuário para inputar.

^insight-1

🔴 Fricção (cosmética mas recorrente — afeta iniciante): o label "selecionar uma moeda" em ciano está formatado com a mesma cor e peso usados em CTAs e links do produto ("Exibir detalhes", "termos de serviço"), mas é apenas section header inativo. Iniciante tenta clicar esperando ação. Diagnóstico errado seria "trocar de ciano" e perder hierarquia. Alternativa: reservar ciano para elementos interativos; usar CAPS pequeno em cinza para section headings — convenção que já existe em outros pontos do produto, falta consistência.

^friccao-1

🔴 Fricção secundária: background com "purple haze" em vez de dim escurecedor reduz a separação modal/fundo. Usuário com baixa visão pode não perceber que está num modal, especialmente porque não há botão fechar visível.

^friccao-2

🟡 Oportunidade competitiva: ordenação global única ignora geo-contexto. Para usuário brasileiro, BRL deveria ser a primeira opção (ou pelo menos uma seção "Sugerida para você"). Pancake, Uniswap e 1inch fazem lista global única. Critério: afeta iniciante diretamente; razão de ninguém ter resolvido é falta de investimento em geo-detection no front (não impossibilidade); diferença é perceptível ("já apareceu BRL no topo"). Trade-off: geo por IP falha em VPN e viagem — mitigar com "Sugerido" + lista completa abaixo, nunca esconder opções.

^oportunidade-1

4. Modal "Escolha um provedor" — Comparação de on-ramps

Função: Permitir ao usuário alternar entre provedores on-ramp suportados para o mesmo par fiat/cripto, com cotação calculada para cada um.

Componentes: título "Escolha um provedor"; lista vertical com 2 itens — Mercuryo (≈ 95,353 CAKE) com badge "Melhor cotação" e Topper (≈ 91,182 CAKE); ícone circular por provedor; sem busca; sem botão fechar (dismiss por overlay); backdrop em purple haze sobre o widget atrás.

Regras de negócio: a cotação por provedor é função do par + valor + rede + momento. O ranqueamento "Melhor cotação" é automático pelo maior output em cripto (não por menor fee absoluta). A lista varia com a moeda fiat e o token escolhidos — provedores que não suportam o par são omitidos.

🟢 Insight: comparar provedores pelo output em cripto (não pela taxa) é a unidade certa para o iniciante — é o que ele vai receber. O delta entre 95,353 e 91,182 CAKE (~4,4%) torna a decisão tangível sem exigir cálculo. Badge "Melhor cotação" automatiza para iniciante e preserva controle para intermediário.

^insight-1

🔴 Fricção (afeta iniciante): Topper aparece sem nenhuma justificativa de existência se Mercuryo é "Melhor cotação". Iniciante pensa "tem motivo pra eu escolher o pior?". Diagnóstico errado: remover Topper — mata a opção válida (talvez aceite método de pagamento diferente). Alternativa: segunda linha por provedor com dimensões secundárias relevantes ("Cartão • Apple Pay • EU/BR" vs "Cartão • SEPA"). Resolve a pergunta real do usuário: "por que escolheria este?".

^friccao-1

🔴 Fricção 2: ausência de fee exibida por provedor — só output em cripto. Para ver custo é preciso fechar o modal e abrir "Detalhes". Alternativa: mostrar fee total ao lado do output ("≈ 95,353 CAKE • taxa US$ 4,95").

^friccao-2

🟡 Oportunidade competitiva: nomes Mercuryo/Topper são opacos para iniciante — a única âncora de confiança é o badge automático. Pancake/Uniswap fazem igual. Diferencial: linha secundária com método aceito + faixa de tempo de processamento + indicador soft de confiança ("usado por X compradores este mês"). Trade-off: risco de virar marketing-vibe — manter discreto, cinza, peso secundário.

^oportunidade-1

6. Tooltip do "?" sobre "Taxas totais est."

Função: Disclaimer contextual que avisa o usuário que o valor de taxa exibido é estimativa, podendo variar no checkout final do provedor on-ramp.

Componentes: tooltip preto/dark com cauda apontando para o ícone "?" ao lado de "US$ 4,95"; texto único — "Observe que as taxas são apenas uma estimativa e podem variar ligeiramente ao concluir uma compra"; sem afordância de fechar (dismiss por mouseout); sem versão equivalente óbvia em mobile.

Regras de negócio: o valor da taxa pode mudar entre a cotação do widget e o checkout do provedor por (a) volatilidade do par cripto/fiat, (b) ajustes de spread do provedor, (c) variação de network fee. O disclaimer cobre essa diferença juridicamente e operacionalmente.

🟢 Insight: disclosure proativo acima do CTA (antes do click) é boa prática — evita que o usuário sinta-se enganado quando o provedor cobrar um valor diferente. Posicionar como tooltip do "?" (e não banner permanente) preserva limpeza visual e respeita a hierarquia "informação avançada sob demanda".

^insight-1

🔴 Fricção (estrutural — afeta iniciante mobile): o tooltip depende de hover, comportamento ausente em mobile — onde o iniciante provavelmente está. O "?" minúsculo exige toque preciso e nem sempre aciona o estado equivalente. Resultado: o disclaimer existe só para a fatia desktop. Diagnóstico errado: mover para banner permanente — polui o widget. Alternativa: tap-and-hold com feedback haptic em mobile; ou converter o "?" em chip clicável que abre bottom sheet curto.

^friccao-1

🔴 Fricção 2 (copy): "variar ligeiramente" não quantifica. Iniciante que vê US$ 4,95 e paga US$ 7,20 no checkout sente fraude. Alternativa: faixa explícita ("a estimativa pode variar até ~X% — confirme o valor final na tela do provedor"). Trade-off: comprometer-se com faixa exige medição real; sem dado, manter o copy genérico mas adicionar "valor final aparecerá antes do pagamento" para deslocar a ansiedade.

^friccao-2

🟡 Oportunidade competitiva: o tooltip é o único momento de educação contextual no fluxo. Indústria usa esses microcopies só para cobrir liability ("estimativa", "pode variar"), não para ensinar mecanismo. Diferencial: microcopy que explique o porquê — "o preço da cripto oscila; o valor final é fixado quando o provedor receber seu pagamento". Usuário sai entendendo o sistema. Trade-off: mais texto = mais leitura — usar 1 linha visível + "saiba mais" expandido.

^oportunidade-1

Observação adicional: na captura, o tooltip cobre o seletor de provedor e parte do chip "BNB Chain" — colisão de z-index/positioning. Se reprodutível, é fricção cosmética separada que vale registrar.

3. Modal "Selecione um token para comprar" — Seletor de token destino

Função: Define qual ativo cripto será adquirido. Determina rede, contrato e elegibilidade junto aos provedores on-ramp. É o passo de maior densidade técnica do fluxo.

Componentes: título "Selecione um token para comprar"; busca "Procurar nome" (com foco visível); section header em ciano "Todos os tokens"; primeiro item BTC com toggle desabilitado, label "Rede Bitcoin" e ícone "?"; lista vertical de tokens, vários ETH em redes diferentes (Ethereum, Arbitrum One, ZKsync Era, Linea, Base) e BNB na BNB Smart Chain; link inferior "Selecione tokens por rede" em ciano.

Regras de negócio: elegibilidade de cada par token/rede depende do que cada provedor on-ramp integrado suporta. BTC nativo provavelmente está desabilitado porque o agregador atual não opera on-ramp para a rede Bitcoin. Toggle desabilitado preserva visibilidade do item para não confundir quem busca por BTC, mas bloqueia seleção.

🟢 Insight: oferecer dois mental models — "Todos os tokens" (achatado) e "Selecione tokens por rede" (agrupado) — reconhece que multi-chain é confuso e dá ao usuário a saída que ele prefere. Manter BTC visível com toggle (em vez de removê-lo silenciosamente) também é correto: iniciante procura BTC primeiro, esconder pioraria.

^insight-1

🔴 Fricção 1 (estrutural — afeta iniciante): o BTC desabilitado não explica o porquê em primeira leitura. O motivo está escondido atrás de um "?" minúsculo. O iniciante interpreta como "BTC indisponível na PancakeSwap" e abandona. Diagnóstico errado seria "remover BTC" — pioraria. Alternativa: texto inline curto no item ("BTC nativo indisponível — comprar WBTC?") com atalho direto para o equivalente wrapped. Trade-off: lista fica menos uniforme, mas resolve um abandono concreto.

^friccao-1

🔴 Fricção 2 (estrutural — afeta iniciante): "ETH" repetido 5+ vezes diferenciado apenas por label de rede pequeno cria scanning ruim. Quem quer "comprar ETH" não sabe qual escolher e a decisão errada (comprar em Linea quando vai usar em Arbitrum) gera bridge depois — custo real. Diagnóstico errado: "deixar só mainnet". Alternativa: agrupamento visual com ETH em Ethereum como item-pai e L2s recolhidas; ou pré-seleção pela rede já ativa no contexto (chip "BNB Chain" do widget).

^friccao-2

🟡 Oportunidade competitiva: o ônus de escolher rede recai 100% sobre o usuário, sem recomendação. Pancake/Uniswap/1inch fazem igual. Para iniciante, rede pré-sugerida com aviso ("você está operando em BNB Chain — comprar em outra rede exige bridge depois") evita o erro mais caro do fluxo on-ramp. Critério: afeta iniciante; ninguém resolveu por falta de investimento em UX contextual, não impossibilidade; usuário perceberia a diferença. Trade-off: intermediário pode achar paternalista — manter sugestão como default, não como bloqueio.

^oportunidade-1

15. Swap Widget — Resumo expandido (rota + métricas)

Função: Estado pós-quote com o painel de resumo expandido, expondo as métricas de transação que o iniciante e o intermediário precisam para decidir conscientemente.

Componentes adicionais (em relação ao relatório 14)

• Linha resumo expandida (chevron ▴ apontando para cima)
• Métricas listadas:
  • Minimum received: 411.8 CAKE
  • Price Impact: <0.01% (verde)
  • Trading Fee: $0.314
  • Route: chip "BNB > CAKE" + ícone settings (=) à direita
• Cada label sublinhada (presumível link/tooltip de explicação)
• CAKE no card To agora mostra 413.903 (diferente de 413.907 do relatório 14 — número se atualiza durante o tempo que o quote vive, antes de execução)

Regras de negócio

• Minimum received = valor garantido se slippage for esgotado completamente (411.8 ≈ 413.903 × (1 − 0.5%))
• Price Impact <0.01% indica que a trade não move o preço da pool significativamente — par muito líquido
• Trading Fee é mostrado em USD (não em BNB como o resumo colapsado do relatório 14)
• Route mostra path direto (BNB → CAKE, sem hops intermediários) — ícone settings sugere customização de rota
• Quote tem TTL — número de To muda enquanto o painel está aberto (413.907 → 413.903), refletindo movimento de preço

🟢 Insight Duas decisões fortes: (1) métricas progressivas — quem não quer ver, vê só a linha resumo; quem precisa, expande e tem tudo. Não polui o estado colapsado para iniciante mas dá ao intermediário/avançado o detalhe que ele precisa para decidir; (2) cada label sublinhada (Minimum received, Price Impact, Trading Fee, Route) sugere explicação — pedagogia colocada no momento de uso, não em página separada de docs. Padrão arquitetural a herdar.

^insight-1

🔴 Fricção 1 (estrutural — Trading Fee em USD, fee total do gas em BNB, separados, afeta iniciante) O painel expandido mostra Trading Fee em USD ($0.314) — boa decisão. Mas o resumo colapsado (relatório 14) mostra fee em BNB ("Fee 0.0004666 BNB"). São o mesmo número? São diferentes (trading fee é da pool, gas é da chain)? A inconsistência cria confusão e exige cálculo mental. Pior: gas de execução não está exposto separadamente em nenhum dos dois estados — o iniciante não sabe quanto vai pagar de gas para confirmar a transação. Solução óbvia que falha: somar tudo em um número ("Custo total: $X") esconde a composição. Alternativa: separar Trading Fee + Gas Estimate + Total — cada um em USD para legibilidade, com toggle para ver em token nativo se desejar. Trade-off: mais linhas no painel, mas honestidade sobre composição do custo. Perfil afetado: iniciante (não decompõe gas vs fee), intermediário (precisa fazer mental math para auditar).

^friccao-1

🔴 Fricção 2 (estrutural — Price Impact <0.01% sem âncora qualitativa) "<0.01%" em verde sugere que está bom, mas sem âncora qualitativa o iniciante não sabe o que constitui "bom". 0.5% é bom ou ruim? 2% é alarmante? O texto numérico sem range categórico falha em comunicar significado. Direcionamento: adicionar tag qualitativa inline ("<0.01% — Excelente" verde / "0.5% — Aceitável" amarelo / ">2% — Alto risco de perda" vermelho), ou barra visual que mostra onde aquele valor cai no espectro. Iniciante aprende o range; intermediário tem feedback acelerado.

^friccao-2

🔴 Fricção 3 (cosmética — Route só mostra path, não a comparação com alternativas) O chip Route mostra "BNB > CAKE" — path único. Mas se a busca "For The Best Price" (relatório 13) comparou múltiplas rotas, a UI deveria expor que comparação foi feita e qual venceu. "Route: BNB > CAKE (melhor entre 3 alternativas encontradas)" + ícone (i) que abre breakdown seria trust signal real. O ícone settings (=) ao lado sugere customização — affordance forte para avançado, sem prejudicar iniciante.

^friccao-3

🔴 Fricção 4 (estrutural — quote sem TTL/refresh visível, afeta todos) O valor de To mudou silenciosamente entre relatório 14 (413.907) e 15 (413.903) — quote está vivo, recebe updates do preço em tempo real. Mas a UI não comunica: não há timer ("Quote expira em 12s"), não há indicador de "atualizado agora", não há botão de refresh manual. Se o user demora para confirmar, o número pode ficar significativamente diferente, e ele não sabe se isso é normal ou bug. Direcionamento: timer/timestamp pequeno ("atualizado há 2s" ou "expira em 25s") + ação manual de refresh quando expirar.

^friccao-4

🟡 Oportunidade competitiva (alta leverage no target — Price Impact qualitativo + composição de custo transparente) Uniswap, Pancake e 1inch expõem Price Impact, Trading Fee e Minimum Received como números brutos, sem ancoragem qualitativa e sem somatória explícita do custo. Para iniciante, é tabela de auditoria, não decisão informada. Passa as 4 perguntas: (1) padrão indústria (todos mostram números crus); (2) afeta iniciante diretamente — é o painel de decisão mais importante do swap; (3) ninguém resolveu por viés de "densidade técnica = sério", não por impossibilidade; (4) ancoragem qualitativa + soma fechada do custo é claramente perceptível. Diferenciação Kotai: cada métrica numérica acompanhada de (a) tag qualitativa colorida (excelente/aceitável/atenção/risco), (b) tooltip de 1 linha explicando o que aquele número significa, (c) linha-soma final ("Custo total deste swap: $X — Trading fee $A + Gas estimado $B"). Trade-off: copy precisa ser bem calibrada — falsa segurança ("Excelente") em caso de risco real seria pior que silêncio.

Observação adicional (Route customization para avançado): o ícone settings (=) ao lado do chip de rota sugere customização manual ("force route via V2 apenas", "evite pools com baixa liquidez", etc.). Para o target Kotai (iniciante/intermediário), essa feature é overkill e provavelmente nem deveria existir no MVP — manter rota como leitura, sem affordance de customização. Para avançado eventual, vira opt-in via flag de "modo avançado".

^oportunidade-1

5. Manage Tokens — Tab "Tokens" (import manual)

Função: Importar token individual por endereço de contrato. Caminho para tokens que não constam de nenhuma lista ativa.

Componentes

• Header "Manage Tokens" + seta back + X
• Tabs Lists / Tokens (Tokens ativa)
• Input único com placeholder "0x0000"
• Texto "0 Imported Tokens" abaixo
• Sem CTA primário, sem botão Importar
• Background do Swap aparece atrás (BNB selecionado, From: 0.00, Slippage 0.50%, botão Connect Wallet)

Regras de negócio

• Input aceita endereço hex do contrato (formato 0x… 40 hex chars)
• Importar adiciona token à lista "Imported" do usuário (presumível localStorage)
• "Imported Tokens" = contagem dos manualmente adicionados
• Sem verificação visível de existência do contrato antes do submit
• Sem busca por nome — apenas address

🟢 Insight A tela existe — e isso por si só é honestidade técnica importante. A Pancake reconhece que listas curadas não cobrem o universo de tokens e dá ao usuário uma saída legítima (import por contrato). Para quem é avançado, é caminho rápido. Para o produto, é forma de não bloquear arbitrariamente tokens emergentes ou de baixa liquidez sem entrar no jogo da censura — decisão arquitetural defensável.

^insight-1

🔴 Fricção 1 (estrutural — caminho perigoso sem proteção, afeta iniciante e intermediário) O fluxo mais comum que leva o usuário aqui é: "não achei o token que queria → vou colar o endereço". Mas "endereço de contrato" como input mínimo é a vulnerabilidade primária do DeFi — scam tokens com nome USDC, USDT, ETH proliferam, e o endereço errado leva a perda irrecuperável. A tela atual NÃO tem: (a) preview do token resolvido (nome, símbolo, decimals, supply); (b) checagem se o nome bate com token canônico conhecido; (c) badge de aviso para tokens recém-criados ou sem liquidez; (d) confronto com listas existentes ("este endereço já existe na lista X — você queria aquele?"). É input → submit cego. Solução óbvia que falha: bloquear import de tokens não-verificados resolve o problema mas mata a função — vira whitelist disfarçada e quebra a promessa de DEX permissionless. Alternativa: manter o import, mas inserir um step intermediário entre "colar endereço" e "adicionar à wallet" — preview com metadados on-chain (nome resolvido, decimals, supply, idade do contrato, contagem de holders, similaridade de nome com canônicos) + aviso de risco contextual. Perfil afetado: iniciante (não sabe o que importa), intermediário (sabe que importa mas não tem ferramenta de verificação).

^friccao-1

🔴 Fricção 2 (cosmética — placeholder pobre) "0x0000" como placeholder é mais críptico do que ajudar. Usuário não sabe se quer endereço completo (40 hex) ou só prefixo, se aceita ENS (vitalik.eth) ou só hex. Hint "Ex: 0x55d398326f99059ff775485246999027B3197955" (40 hex completos, USDT canônico BNB) educa o formato esperado em 1 linha.

^friccao-2

🔴 Fricção 3 (estrutural — "0 Imported Tokens" como estado vazio mudo) A contagem é informação técnica, não orientação. Estado vazio deveria educar: "Imports são tokens que você adiciona manualmente por endereço de contrato — eles ficam disponíveis no seletor de tokens. Use isso quando o token que você quer não aparece na busca padrão." Sem isso, o usuário não sabe o que esperar nem para que serve o que está vendo.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — preview com risk signaling no import) Uniswap, Pancake e 1inch fazem import por contrato sem preview de risco. O usuário cola endereço, e o token é adicionado se o contrato existe — não importa se é scam, recém-criado, ou tem nome igual a token canônico. É vetor primário de perda para iniciante DeFi: a parte mais perigosa do produto fica sem proteção. Passa as 4 perguntas-teste: (1) todos os DEXes principais fazem igual; (2) afeta iniciante diretamente — é o passo onde ele decide adicionar token desconhecido; (3) ninguém resolveu por falta de investimento em metadados on-chain + heurísticas de scam, não por impossibilidade técnica (dados estão na chain); (4) preview com aviso é claramente perceptível. Diferenciação Kotai: passo de confirmação obrigatório com (i) nome/símbolo/decimals resolvidos on-chain, (ii) idade do contrato, (iii) contagem de holders, (iv) similaridade de nome com canônicos ("você está prestes a importar USDC — mas este NÃO é o USDC oficial da Circle. Tem 12 dias e 47 holders."), (v) badge de risco (alto/médio/baixo). Usuário ainda pode importar, mas decisão é consciente. Trade-off: exige indexador on-chain com dados frescos e heurísticas mantidas (similaridade fonética, distância de Levenshtein nos nomes, lista de canônicos por chain). Falsos positivos (token legítimo recém-criado bloqueado) confundem; falsos negativos deixam scam passar. Mas o custo de NÃO ter isso para o target é alto demais.

Observação adicional (consistência com a tab Lists): a tab Tokens é a resposta correta para a pergunta-do-iniciante ("não estou achando o token"), mas vem em segundo lugar nas tabs e tem menos affordance visual que Lists. Inverter a ordem (Tokens primeiro, Lists segundo) atende melhor o caso comum, sem prejudicar quem já sabe o caminho. Vale teste rápido.

^oportunidade-1

4. Manage Tokens — Popover do cog (See / Remove)

Função: Popover acionado pelo cog ao lado do nome da lista, expondo metadados e ações de gestão (ver versão, abrir source, remover).

Componentes

• Tooltip flutuante posicionado sobre o card da lista
• Linha 1: versão ("v2.16.745") — texto branco
• Linha 2: "See ↗" — link com ícone external
• Linha 3: badge rosa "Remove"
• Restante da tela permanece igual (lists abaixo: CoinGecko, Ondo, xStocks ainda visíveis)

Regras de negócio

• Versão = release semver do JSON da token list
• See ↗ abre source da lista em nova aba (presumível URL do JSON)
• Remove deleta a lista do produto — diferente de toggle off (que só desativa)
• Popover aparece em qualquer lista — incluindo as 4 default

🟢 Insight Mostrar versão da token list é trust signal técnico genuíno: permite ao avançado verificar se a curadoria está atualizada antes de confiar. "See" como link ao source ↗ é honestidade radical ("este é o arquivo que está alimentando seu seletor — confira"). Decisão correta para perfil técnico: mostra a tubulação para quem quiser auditar.

^insight-1

🔴 Fricção 1 (estrutural — ação destrutiva sem proteção, afeta intermediário) "Remove" deleta a lista do produto, ação mais destrutiva que o toggle off. Mas o botão é só uma pílula rosa sem confirmação, sem aviso de impacto (923 tokens desaparecem permanentemente da configuração) e sem distinção visual de "este é o link que destrói algo". Pior: o popover é o mesmo para listas custom (que faz sentido remover) e para a lista padrão da casa, PancakeSwap Extended — remover acidentalmente requer ir até o Manage Tokens > Lists > input de URL e colar a URL canônica, que o usuário nem conhece. Solução óbvia que falha: confirmação modal ("Remover lista?") para todo Remove é fricção desnecessária para listas custom que o usuário acabou de adicionar. Alternativa: diferenciar visualmente Remove em listas "padrão" (cor mais opaca + confirmação de duas etapas) vs listas "custom" (cor normal + confirmação simples). Reconhecer que destruir o default é caso diferente de destruir o que você adicionou. Perfil afetado: intermediário exploratório (ação irreversível ao alcance de 1 clique).

^friccao-1

🔴 Fricção 2 (cosmética — popover apaga o nome da lista) A caixa flutuante cobre exatamente o nome da lista e o ícone — o usuário perde a referência visual de qual lista está prestes a remover enquanto lê "Remove". Em popover de ação destrutiva, esconder a identidade do alvo é problema clássico. Alternativa: ancorar o popover ao lado do card, não em cima dele; ou repetir o nome da lista no topo do popover ("PancakeSwap Extended" + versão).

^friccao-2

🔴 Fricção 3 (cosmética — copy ambíguo "See") "See" sem objeto não comunica o que abre. É a URL do JSON da token list, do site da fonte, da documentação? "See source ↗" ou "Ver JSON ↗" seria explícito sem ocupar mais espaço.

^friccao-3

🟡 Oportunidade competitiva (média leverage — versionamento exposto) Uniswap, 1inch, SushiSwap escondem versão das token lists; só Pancake mostra. Isso é diferencial técnico de transparência, mas não é diferencial perceptível para o target Kotai (iniciante/intermediário não decodifica semver). Logo, NÃO é oportunidade competitiva — é overkill para o nosso target. A oportunidade real está fora desta tela (curadoria opinionada Kotai, já levantada no relatório 2).

Observação adicional (consistência terminológica): Remove em uma tela e toggle off em outra significam coisas diferentes (deletar permanentemente vs pausar). O modelo conceitual não é óbvio para o usuário — qual escolher? O produto deveria comunicar que toggle = pausar (volta ON e tudo reaparece), Remove = apagar (vai precisar recolar URL para voltar). Hoje a diferença só aparece depois do erro.

^oportunidade-1

6. Modal "From" — Popover "+3" (redes overflow)

Função: Popover revela as redes adicionais que não cabem no cluster principal, acionado pelo chip "+3 ▾".

Componentes

• Popover ancorado abaixo do chip "+3 ▾"
• Lista de 3 redes, cada uma com ícone + nome:
  • Linea
  • opBNB
  • Monad Testnet
• Sem search, sem ícones de status, sem badge "Novo"
• Modal From permanece visível atrás

Regras de negócio

• "+3" = 3 redes que não cabem no cluster visível (no momento: Linea, opBNB, Monad Testnet)
• Clicar em uma rede troca "Network: BNB Chain" e refiltra Popular Tokens
• Monad Testnet listado junto com mainnets — sem distinção visual
• Não há indicação de quantas redes ainda existem além das 3 mostradas

🟢 Insight Popover overflow é solução pragmática: mantém o cluster principal com as 7 redes mais relevantes para o caso de uso típico (BNB-centric) e empurra long-tail para o "+3". Decisão de density consciente — não infla a UI primária com redes pouco usadas pelo target. Reconhecimento honesto de que multi-chain tem cauda longa.

^insight-1

🔴 Fricção 1 (estrutural — testnet misturada com mainnet, afeta iniciante) "Monad Testnet" aparece na mesma lista que Linea e opBNB sem nenhum disclaimer. Testnet é rede sem valor real — usuário iniciante que selecionar achando que é mainnet vai (a) tentar swap e ficar confuso porque os tokens são fake, ou (b) achar que descobriu uma chain barata, importar tokens de testnet e tratá-los como reais. "Testnet" no nome ajuda quem sabe o que isso significa; para iniciante, é palavra técnica sem peso de aviso. Solução óbvia que falha: esconder testnets resolve para iniciante, mas tira ferramenta de quem precisa (devs testando). Alternativa: badge visual "Testnet — sem valor real" em vermelho/laranja ao lado do nome + tooltip; ou seção separada ("Testnets" como subgrupo) com header explicativo. Trade-off: adiciona linha de copy/badge, mas elimina classe inteira de erro caro. Perfil afetado: iniciante (não sabe o que é testnet); intermediário sem contexto cripto-dev também afetado.

^friccao-1

🔴 Fricção 2 (cosmética — sem hierarquia entre overflow) Linea (L2 estabelecida da ConsenSys), opBNB (L2 da própria BNB Chain) e Monad Testnet (rede experimental sem mainnet) são tratadas com peso visual idêntico. Listar a L2 da própria casa (opBNB) abaixo de Linea, sem badge "Made by BNB" ou similar, perde oportunidade de comunicar afinidade técnica que beneficia o usuário (gas mais barato, ponte nativa).

^friccao-2

🔴 Fricção 3 (escopo — popover não tem search nem filtro) No Uniswap, o seletor de rede tem search no topo. No Pancake, o cluster + popover "+3" cobre o caso atual (10 redes), mas se a Pancake adicionar mais 10 chains amanhã, a UI escala mal — popover overflow sem search vira lista interminável. Decisão arquitetural que envelhece mal.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — testnet signaling) Uniswap, Pancake e 1inch listam testnets em produção com indicador tímido ou nenhum (só o nome "Testnet"). Para iniciante DeFi, testnet é categoria desconhecida — ele não sabe que existe um "shadow universe" de redes sem valor real, e a UI não educa. Passa as 4 perguntas-teste: (1) padrão indústria (todos os DEXes listam testnets sem disclaimer forte); (2) afeta iniciante diretamente — escolha errada é silenciosa até quebrar a transação; (3) ninguém resolveu por descuido, não por impossibilidade (informação está no nome da rede, é só transformar em badge); (4) badge visual evidente é mudança que o usuário percebe. Diferenciação Kotai: badge vermelho "Testnet — sem valor real" em qualquer rede de teste + microcopy de 1 linha no destino quando o usuário seleciona uma ("Você selecionou uma testnet. Tokens aqui não valem dinheiro real. Útil para devs; não use para trading."). Ou, mais radical, esconder testnets do seletor padrão e exigir opt-in em settings ("Mostrar testnets"). Trade-off: produto perde affordance imediata para dev, mas iniciante fica protegido. Dado o target Kotai, esconder por default é a aposta correta.

Observação adicional (Monad como cross-promo "chain do momento"): Monad é narrativa quente em 2025-2026 — listar Monad Testnet pode ser cross-promo ("a Pancake já está lá") sem necessariamente ser uso real. Decisão de marketing vs decisão de funcionalidade. Vale ter consciência: o seletor de rede é vetor de marketing, não só de utilidade técnica.

^oportunidade-1

Codex Consolidado — Home (pancake)

Caráter geral do fluxo

A Home da Pancake é tecnicamente rica e relativamente honesta: expõe listas de tokens, import manual, slippage, roteamento, route diagram, explorer, MEV, auditorias, modo trader e configurações avançadas. O problema recorrente é que essa transparência chega codificada em linguagem e padrões de power user. O fluxo mostra dados, mas frequentemente não traduz consequência, risco, custo ou escopo da decisão.

Para iniciantes e intermediários, a experiência alterna entre simplicidade aparente e controle técnico sem fronteira clara. O usuário consegue fazer um swap, mas precisa montar sozinho o significado de token list, contrato, testnet, Auto slippage, route, gas, trading fee, price impact, MEV Protected e Aggregate Pricing. A oportunidade para Kotai não é esconder DeFi, e sim criar uma camada padrão mais legível, com disclosure progressivo para auditoria e modo avançado.

🟢 Insights recorrentes

A Pancake tem boas bases de utilidade e confiança: copiar endereço e abrir explorer direto no item de token em tela 7 e tela 8, Auto slippage em tela 9, warning externo ao popover em tela 10, resumo expandido de custos/rota em tela 15 e route diagram em tela 17. O produto não esconde totalmente a complexidade; ele oferece material para auditoria.

Também há uma arquitetura permissionless consistente: token lists, import por contrato e routing settings preservam controle avançado em tela 2, tela 5 e tela 16. Isso é valor real para usuários experientes, desde que não vire o caminho padrão de quem só quer entender e executar uma troca com segurança.

🔴 Fricções recorrentes

1. Infraestrutura poderosa delega interpretação demais ao usuário. Token lists, source, toggles, import manual, explorer, route, TradingView e settings aparecem como objetos técnicos, não como decisões guiadas. Em tela 2, o usuário que procura um token cai em URLs/IPFS; em tela 5, importar contrato é quase um input cru; em tela 17 e tela 20, rota e gráfico avançado exigem repertório. O padrão recorrente é exposição sem tradução suficiente de “o que é”, “por que importa” e “o que muda no seu swap”.

2. Sinais de risco aparecem fracos nos pontos de decisão. Tokens pegged/wrapped/canônicos ficam pouco diferenciados em tela 1, contrato importado não recebe preview robusto em tela 5, testnet aparece junto de mainnets em tela 6 e explorer vira destino de auditoria sem metadados inline em tela 8. Para Kotai, badges como “wrapped”, “pegado”, “testnet”, “não verificado”, “similar a token conhecido” e “fonte curada” precisam aparecer antes da escolha, não depois.

3. Consequências semidestrutivas ou persistentes ficam subcomunicadas. Desativar listas em tela 2 e tela 3 muda o universo de tokens sem delta claro; remover lista em tela 4 apaga uma fonte relevante sem proteção proporcional; desligar Auto slippage em tela 11 transforma adaptação dinâmica em valor fixo com pouca diferença visual. O problema não é falta de modal genérico, mas ausência de modelo de consequência: antes/depois, escopo, persistência e rollback.

4. Slippage, custos e quote são tratados como números, não como decisão econômica. Nas telas 9, 10 e 11, slippage não explica causa, custo de falha nem perda de adaptação do Auto. Em tela 14 e tela 15, fee, gas, trading fee, price impact e diferença entre USD pago/recebido aparecem fragmentados. O usuário recebe métricas, mas não uma conta fechada.

5. Claims de confiança e performance carecem de lastro operacional. “MEV Protected” em tela 12, “Searching For The Best Price” em tela 13, “gas free swaps” em tela 16 e “Aggregate Pricing” em tela 20 comunicam benefício, mas pouco mecanismo. A tradução mínima deveria dizer critério, fonte ou custo embutido: comparando quantas rotas, proteção por qual via, custo incluído onde.

6. Descoberta depende demais de hover, footer ou padrões pouco móveis. Copy/explorer surgem em hover em tela 7 e tela 8, explicações de rota dependem de tooltip em tela 18, auditorias e suporte ficam diluídos no footer em tela 19. Funções de confiança existem, mas são pouco acessíveis para mobile e para quem não sabe que precisa delas.

7. Modo básico, auditoria e modo trader se misturam sem contrato claro. Ações comuns como trocar destino são sutis em tela 12, enquanto routing settings avançado fica próximo do fluxo principal em tela 16. O gráfico trader em tela 20 e a Home desconectada com banner/Buy CAKE em tela 21 reforçam a mistura entre primeira troca, auditoria, trading e promoção.

🟡 Oportunidades competitivas do fluxo

1. Transparência econômica do swap como camada padrão. Validada por recorrência entre tela 9, tela 10, tela 14 e tela 15. Kotai pode transformar números crus em uma explicação fechada: trading fee + gas estimado + slippage/price impact + diferença de preço = custo total estimado, sempre com equivalente em USD e detalhe técnico sob demanda. Isso é difícil o suficiente para exigir sistema de dados/copy, relevante para iniciantes e intermediários, visível no momento do swap e diferente do padrão de apenas listar métricas.

2. Risk signaling e curadoria legível antes da ação. Validada por tela 1, tela 5, tela 6 e tela 8. Em vez de mandar o usuário interpretar explorer/listas, Kotai pode mostrar metadados mínimos inline: verificação, idade do contrato, holders, origem da lista, similaridade com token canônico, wrapped/pegged/testnet e risco de importação. O trade-off é manter taxonomia e dados frescos; sem critérios públicos, a curadoria vira opacidade.

3. Modo padrão simples com avanço explícito para auditoria/power user. Validada por recorrência em token lists/import, route settings e trader mode: tela 2, tela 3, tela 16 e tela 20. A tese: default orientado à tarefa, com labels e recomendações; modo avançado opt-in para listas, fontes, multihop, split routing, gráfico e auditoria detalhada. Isso preserva controle sem convidar iniciante a operar parâmetros que não entende.

Pontos isolados (1 tela)

Em tela 1, o cluster de redes é icônico demais para quem não reconhece logos. Em tela 4, o popover cobre o nome da lista antes de ação destrutiva. Em tela 7, falta feedback após copy. Em tela 12, CAKE pré-selecionado parece default promocional. Em tela 14, saldo insuficiente oferece on-ramp como saída dominante, sem caminho equivalente para depósito de exchange/outra wallet. Em tela 21, “AI” aparece como promessa vaga sem hint.

Nota de auditoria Codex

Consolidado derivado exclusivamente dos quatro drafts fornecidos. Candidatos marcados como hipótese nos drafts foram mantidos como fricções, pontos isolados ou suporte contextual quando não passaram pela régua de recorrência e quatro perguntas-teste. Oportunidades promovidas apenas quando havia recorrência em múltiplas telas e impacto claro no momento de decisão do swap.

2. Manage Tokens — Tab "Lists" (todas ativas)

Função: Curadoria das token lists que alimentam o seletor de tokens. Permite ativar/desativar fontes pré-instaladas e adicionar listas externas via URL/IPFS.

Componentes

• Header "Manage Tokens" + seta de back + X
• Tabs Lists / Tokens (Lists ativo)
• Input "https:// or ipfs://" para colar URL de token list externa
• 4 cards de lista, todos com toggle ON e borda teal:
  • PancakeSwap Extended — 923 tokens + cog
  • CoinGecko — 3.292 tokens + cog
  • Ondo Token List for PCS — 265 tokens + cog
  • xStocks for PancakeSwap — 152 tokens + cog

Regras de negócio

• Toggle ON/OFF inclui ou exclui aquela fonte do seletor de tokens
• Cog presumivelmente abre detalhes da lista (URL, versão, remover)
• Input aceita HTTPS ou IPFS — espera apontar para arquivo JSON de token list
• Borda teal = lista ativa; sem borda = inativa
• Sem confirmação ao desativar — toggle é instantâneo

🟢 Insight Expor a curadoria de listas como objeto de primeira classe é honestidade técnica rara: a Pancake declara nominalmente que o universo de tokens disponível vem de fontes específicas (PancakeSwap Extended, CoinGecko, Ondo, xStocks), e permite ao avançado escolher em quem confiar. Trust signal real para quem entende — o usuário pode auditar a fonte. Boa arquitetura para perfil técnico.

^insight-1

🔴 Fricção 1 (estrutural — tela errada para o problema do iniciante) O caminho mais provável para chegar nesta tela é o cog ao lado do search (Modal From). O iniciante chega com o problema "não estou achando o token X". A solução do problema dele NÃO é "ative outra lista" — é "cole o endereço do contrato na tab Tokens". Mas a tab Lists abre primeiro e absorve a expectativa errada: usuário cola endereço de contrato no campo "https:// or ipfs://" (primeiro input visível) e nada acontece, ou começa a mexer nos toggles para "ver se aparece". Solução óbvia que falha: trocar a ordem das tabs (Tokens primeiro) ajuda o caso do contrato, mas frustra avançado. Alternativa: hint inline no Modal From quando search não retorna resultado ("Não achou o token? Cole o endereço do contrato → [link direto pra tab Tokens]"), tornando esta tela destino dirigido em vez de exploração. Perfil afetado: iniciante (modelo mental errado), intermediário (perde tempo).

^friccao-1

🔴 Fricção 2 (estrutural — toggles destrutivos sem warning, afeta todos) Desativar "PancakeSwap Extended" remove 923 tokens da curadoria interna do produto. Desativar "CoinGecko" remove 3.292. A ação é cega (não há indicador do total geral disponível depois do toggle) e instantânea (sem confirmação). Quem entra para "explorar" pode acabar com seletor quase vazio e não entender por quê. Pior: a tela não dá rollback explícito — só relembrar de voltar e religar a lista. Direcionamento Kotai: ao desativar uma lista, mostrar inline o delta ("-923 tokens deixarão de aparecer no seletor") e badge de aviso quando uma lista é a principal fonte de uma chain.

^friccao-2

🔴 Fricção 3 (cosmética — input sem hint de formato) "https:// or ipfs://" diz o protocolo, não o formato. Intermediário não sabe o que colar — URL de site? URL de contrato? Hint inline ("ex: https://tokens.coingecko.com/uniswap/all.json") tornaria a feature usável para quem tem o conhecimento mas não memoriza convenções.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — assumir curadoria, não delegar) Uniswap, Pancake e SushiSwap herdaram o paradigma de "o usuário escolhe em quais fontes confia" (token lists configuráveis). Para o usuário técnico isso é poder; para o iniciante DeFi (target Kotai), é abandono de responsabilidade: ele quer que o produto diga o que é seguro, não receber a tarefa de auditar listas. Passa as 4 perguntas: (1) todos os DEXes principais fazem igual; (2) afeta iniciante diretamente — ele é exposto a centenas de tokens não-verificados; (3) ninguém resolveu porque assumir curadoria implica responsabilidade legal e operacional contínua, não impossibilidade técnica; (4) presença de uma lista "Verificada Kotai" com critérios públicos é diferencial visível. Diferenciação Kotai: lista default opinionada e bem comunicada ("Tokens verificados pela Kotai — critérios: liquidez mínima, contrato auditado, sem nome similar a token canônico"), com modo avançado opt-in que aproxima a UX atual da Pancake. Trade-off: Kotai assume responsabilidade de manter a curadoria — exige equipe, processo e disclaimer legal claro. Sem isso, vira fonte de litigation.

Observação adicional (paridade visual injusta): as 4 listas têm peso visual idêntico, mas CoinGecko (agregador público, 3.292 tokens, curadoria baixa para low-cap) e PancakeSwap Extended (curadoria interna, 923 tokens) representam confianças muito diferentes. xStocks (152, nichada em ações tokenizadas) e Ondo (265, RWA) também são casos específicos. Sem hierarquia visual ou rótulo de natureza, o iniciante não tem como saber qual lista controla "tokens seguros do mainstream" vs "tudo que existe".

^oportunidade-1

1. Modal "From" — Seletor de Token (Swap)

Função: Seletor do token de origem no widget de Swap. Concentra busca, escolha de rede e atalho para curadoria de listas.

Componentes

• Header "From" + X
• Search input "Search name / address" + ícone de cog à direita
• Label "Network: BNB Chain"
• Cluster de 7 ícones de redes (BNB selecionado com borda) + chip "+3 ▾"
• Section "Popular Tokens": USDT, WBNB, USD1, USDC, BILL, BTCB — cada item com ícone, ticker, nome longo e tag "BNB Chain" abaixo, chevron → à direita
• Mascote "Need Help? Quick start now on How to Swap! [Details]" no canto

Regras de negócio

• BNB Chain como rede default (home network)
• "Popular Tokens" filtrado pela rede selecionada — trocar de rede troca a lista
• Search aceita nome ou endereço de contrato
• Cog ao lado do search abre Manage Tokens (custom lists)
• "+3" indica redes adicionais não exibidas no cluster

🟢 Insight Três decisões corretas: (1) placeholder "Search name / address" educa iniciante de que ele pode colar contrato — onboarding implícito útil; (2) tag de rede explícita em cada item ("BNB Chain") tira a chain da implicitude, ao contrário do Uniswap onde a rede dilui no contexto global; (3) defaultar BNB Chain é honesto sobre quem é o usuário-alvo (não fingem ser chain-neutral), reduz fricção do caso de uso dominante.

^insight-1

🔴 Fricção 1 (estrutural — cluster de redes sem label, afeta iniciante) O cluster de logos abaixo de "Network: BNB Chain" é puramente icônico — só o BNB tem borda indicando ativo. Os outros 6 logos são switches mudos. Para iniciante que não reconhece logos de Ethereum/Solana/Base de cabeça, o cluster é decoração: ele lê "Network: BNB Chain" e não percebe que os ícones ao lado são opções clicáveis para trocar a rede. "+3 ▾" também não dá pista do que vai abrir. Solução óbvia que falha: adicionar rótulo embaixo de cada logo polui a linha e quebra densidade. Alternativa: manter o cluster mas com tooltip no hover, e expandir o chip do logo ativo ("BNB Chain ▾") para que ele soe como dropdown, não como ícone decorativo. Trade-off: assimetria visual (um chip largo + 6 ícones), mas comunica função. Perfil afetado: iniciante (não decodifica logos).

^friccao-1

🔴 Fricção 2 (estrutural — pegged vs canônico sem distinção, afeta iniciante e intermediário) A lista de Popular Tokens mistura USDC e USDT "Binance-Pegged" com WBNB (wrapped nativo) sem diferenciar visualmente. "USDC Binance Pegged USD Coin" não é o USDC canônico da Circle — é um peg emitido por outro custodiante em outra chain. O nome longo dá a pista, mas a tag "BNB Chain" cinza pequena não destaca o risco: para iniciante, USDC é USDC. Trocar BNB para USDC achando que está comprando o dólar digital da Circle é decisão tomada com modelo mental errado. Direcionamento Kotai: badge de tipo explícito no item ("Canônico", "Pegged via Binance", "Wrapped") + tooltip de 1 linha explicando o que isso significa. Não esconder o token pegged — informar.

^friccao-2

🔴 Fricção 3 (cosmética — cog sem descoberta) O cog ao lado do search abre Manage Tokens, função crítica para qualquer usuário que queira negociar token fora das listas default. Iniciante não sabe que existe, intermediário descobre por exploração. Falta label/tooltip ("Configurar listas").

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — risk signaling no seletor) Uniswap, Pancake e 1inch listam tokens ordenados por popularidade/volume sem distinção entre canônico, wrapped, pegged ou bridged. Para iniciante DeFi, todo USDC é USDC — a diferença entre o USDC oficial e o USDC pegado por exchange só aparece após perda real (depegging quando o emissor falha, ou impossibilidade de resgatar fora daquela chain). Passa as 4 perguntas-teste: (1) todos os concorrentes fazem igual; (2) afeta iniciante diretamente — é onde escolhe o que vai comprar; (3) ninguém resolveu por falta de investimento em taxonomia, não por impossibilidade técnica; (4) badge claro é diferença perceptível, não polish invisível. Diferenciação Kotai: badge de tipo de emissão visível no item da lista + microcopy de 1 linha no destino ("Este é um USDC pegado via Binance, não o USDC oficial da Circle. O peg depende da Binance manter reservas."). Trade-off: exige manter taxonomia atualizada por chain e por emissor; falsos positivos confundem mais do que ajudam.

Observação adicional (mascote Need Help): o CTA "Details" no card do coelho é o canal de educação contextual da Pancake, mas convive com o modal de seleção competindo por atenção em momento de decisão. O mascote fica visualmente atrás do modal — ok; mas mascote como canal de educação pressupõe que o usuário clica em "Details" no momento certo. Vale checar telemetria desse banner; provável que seja baixíssima.

^oportunidade-1

3. Manage Tokens — Tab "Lists" (PancakeSwap Extended OFF)

Função: Mesma tela do relatório 2, agora com a lista "PancakeSwap Extended" desativada — captura o estado pós-toggle.

Componentes adicionais (em relação ao relatório 2)

• Card "PancakeSwap Extended" sem borda teal (estado off)
• Toggle cinza (à esquerda)
• Demais 3 cards (CoinGecko, Ondo, xStocks) permanecem ON com borda teal
• Nenhum aviso, badge ou contador de tokens disponíveis no agregado

Regras de negócio

• Toggle persiste (provavelmente em localStorage do navegador)
• Sem confirmação na ação, sem rollback explícito
• A lista PancakeSwap Extended é presumivelmente a curadoria interna do próprio produto — desativá-la esconde tokens que o produto reconhece como seus
• Não há feedback de quantos tokens permanecem no seletor após o toggle

🟢 Insight O feedback visual do toggle é claro: a borda teal some, o slider muda de lado. Estado consistente — usuário vê que algo mudou. Para quem entende a função, é controle direto e previsível.

^insight-1

🔴 Fricção 1 (estrutural — consequência invisível, afeta iniciante e intermediário) Desativar "PancakeSwap Extended" é a remoção mais consequente das 4 listas: ela é a curadoria interna do produto e a mais provável de conter tokens recém-listados pela Pancake. O estado mostrado é exatamente o cenário onde o usuário tem maior chance de perder tokens que esperaria encontrar — e nada na UI sinaliza isso. Nem badge "curadoria oficial", nem contagem agregada ("tokens disponíveis: 3.709 → 2.786"), nem aviso "esta é a lista padrão da Pancake". Solução óbvia que falha: bloquear o toggle ("esta lista é obrigatória") tira poder do usuário avançado e fere o princípio de a Pancake declarar que tudo é configurável. Alternativa: manter o toggle, mas adicionar badge "Lista padrão" no card e contagem agregada de tokens disponíveis no header da tela — assim a consequência fica visível sem remover poder.

^friccao-1

🔴 Fricção 2 (estrutural — dimensão errada no controle, afeta iniciante) A UI trata token list como dimensão de confiança ("ative quem confia"). Mas a dimensão real do toggle é cobertura de inventário ("quantos tokens consigo ver"). Confundir as duas dimensões no mesmo controle é o que torna esta tela perigosa: o usuário pensa "vou desativar quem não conheço" (CoinGecko, por exemplo) e perde 3.292 tokens de visibilidade — incluindo possivelmente o token que ele queria buscar. O atrito real não é "o toggle não tem confirmação"; é "o toggle mistura dois conceitos que deveriam ser controles separados". Direcionamento Kotai: separar visibilidade ("mostre tokens dessa fonte na busca") de confiança ("trate como verificado, sem badge de risco"). Cada token entra com risk-score baseado em quantas listas confirmam, em vez de existir ou não-existir conforme o ON/OFF binário.

^friccao-2

🟡 Oportunidade competitiva (média leverage — separar visibilidade de confiança) Padrão indústria conflagra os dois eixos em um controle só. Iniciante não consegue expressar "quero ver com aviso de risco" vs "quero ver só verificados sem aviso" — só tem mostrar tudo / esconder tudo por fonte. Passa as 4 perguntas: (1) padrão herdado de Uniswap em todos os DEX principais; (2) afeta iniciante diretamente (controle vira armadilha); (3) ninguém resolveu porque exige modelo de risk-scoring contínuo (não whitelist binária) — investimento técnico, não impossibilidade; (4) a diferença seria visível ao usuário (resultado da busca passa a incluir badges, não a desaparecer). Diferenciação Kotai: modelo de score contínuo por token (somatório ponderado de fontes que confirmam + sinais on-chain de liquidez/idade do contrato) que se reflete em badges no resultado, não em filtros binários. Trade-off: exige pipeline de dados sempre rodando + critério público e auditável para evitar acusação de "censura" de tokens legítimos.

Observação adicional (impacto cumulativo dos toggles): o usuário que aterrissa nesta tela já com uma lista desligada não vê esse estado como "alteração que fiz" se voltou depois de tempo — não há indicador "você customizou esta tela" nem botão "restaurar padrão". Estado divergente do default fica invisível, e usuário pode passar dias atribuindo o sumiço de tokens a bug do produto.

^oportunidade-1

13. Swap Widget — Loading state ("Searching For The Best Price")

Função: Estado intermediário após o usuário digitar o valor From ("1" BNB → ~$628.76 USD). Sistema está buscando rota de cotação; To ainda não resolveu.

Componentes adicionais (em relação ao relatório 12)

• From: valor "1" digitado, USD estimado "~628,76 USD" preenchido instantaneamente
• To: CAKE ainda mostra "0.00" + spinner pequeno abaixo (cinza claro, animação circular)
• CTA mudou: agora mostra "Searching For The Best Price.." em cinza (ainda desabilitado)
• Demais elementos idênticos (Slippage, MEV Protected)

Regras de negócio

• USD do From é estimado localmente via preço cached (não depende da rota de cotação)
• USD de To só aparece quando rota é encontrada
• Loading do To = chamada ao router/agregador de DEXes para encontrar melhor preço entre múltiplas pools
• CTA reflete estado da operação em texto, não em loader genérico
• Durante loading, o usuário pode mudar From — presumível debounce que cancela request anterior

🟢 Insight Três decisões fortes: (1) USD estimado do From aparece instantaneamente — não bloqueia a percepção do valor enquanto a rota é calculada; (2) CTA textualmente descreve o que está acontecendo ("Searching For The Best Price..") em vez de loader genérico — comunica processo, não estado abstrato; (3) loading apenas em To preserva contexto visual — usuário não vê toda a UI em skeleton, só a parte que efetivamente está sendo computada. Padrão de loading granular bem feito.

^insight-1

🔴 Fricção 1 (estrutural — "Best Price" sem definição, afeta iniciante e intermediário) "Searching For The Best Price" é claim forte sem qualificador. Best por qual critério? Menor slippage? Maior valor recebido? Menor fee? Melhor combinação? E entre quais fontes — apenas pools internas da Pancake? Roteamento cross-DEX (agregador)? Para iniciante isso é fé cega no produto; para intermediário, é frustração (ele quer ver o critério). Decisão de copy que comunica menos do que parece. Solução óbvia que falha: detalhar critério em copy longo ("Comparando rotas Pancake V2, V3 e StableSwap por valor recebido após gas") polui o CTA. Alternativa: "Buscando rota" como CTA neutro + tooltip/ícone (?) que ao clicar revela o critério; ou painel "Route" expandido por default mostrando "comparando N pools". Trade-off: copy mais sóbria, mas honesta. Perfil afetado: iniciante (recebe claim que não verifica), intermediário (quer saber o critério).

^friccao-1

🔴 Fricção 2 (estrutural — sem tempo máximo nem timeout visível, afeta todos) Loading sem indicação de quanto pode demorar. Em rede congestionada, busca de rota pode ficar 10-30 segundos. Sem timeout exposto, usuário não sabe se deve esperar, refresh, ou desconectar. Direcionamento: timeout silencioso de 15-30s + estado de erro ("Não encontramos rota agora — tente de novo") em vez de loading infinito.

^friccao-2

🔴 Fricção 3 (cosmética — spinner do To em posição ambígua) O spinner abaixo do valor 0.00 do To pode ser confundido com elemento decorativo do card. Posição mais óbvia seria sobreposta ao valor 0.00 (substituindo-o) ou ao lado dele em destaque.

^friccao-3

🟡 Oportunidade competitiva (média leverage — transparência da busca de rota) Uniswap, Pancake e 1inch fazem busca de rota como caixa-preta: "loading" → "resultado". Para intermediário curioso, isso é caixa selada que ele não confia plenamente. Mas o conjunto de DEXes/pools sondado e o critério de comparação são informação útil para construir confiança. Passa as 4 perguntas: (1) padrão indústria; (2) afeta intermediário e avançado, parcialmente iniciante; (3) ninguém resolveu por convenção (UI minimalista é cool), não por impossibilidade técnica; (4) painel "Route" expandido (já existe em estado pós-loading — ver relatório 15) durante o loading é diferença visível. Diferenciação Kotai: painel de Route expandido durante o loading, mostrando "comparando: Pool A, Pool B, Pool C…" em texto sutil. Mesmo se a info não for útil no detalhe, o gesto comunica que o produto não é caixa-preta. Trade-off: implementação exige indexar as pools candidatas em tempo real e gerar markup textual; risco de info-overflow se mal feita.

Observação adicional (USD do From estimado vs To real): o USD do From (~628,76 USD) é estimado, o USD de To virá da rota encontrada. Em par com slippage não-trivial, eles vão divergir levemente — usuário pode comparar e pensar "perdi dinheiro" sem entender que a diferença é fee + slippage. Vale ter consciência no design Kotai: a tensão entre "mostrar USD imediatamente" (UX) e "mostrar USD honesto após rota" (precisão) precisa ser resolvida com comunicação clara dos dois números.

^oportunidade-1

11. Slippage Setting — preset 0.5% (estado seguro sem aviso)

Função: Mesmo popover, agora com 0.5% selecionado — estado equivalente ao default do Auto, mas explicitamente travado pelo usuário.

Componentes adicionais (em relação ao relatórios 9 e 10)

• Preset 0.5% destacado em roxo (selecionado)
• Input custom mostra "0.50"
• Pill "Slippage Tolerance" abaixo mostra "0.50%" (SEM ícone de warning, sem "Auto:")
• Nenhum bloco de aviso amarelo — estado considerado seguro pela heurística do produto

Regras de negócio

• 0.5% está dentro da faixa considerada segura pelo produto
• Diferença sutil com Auto: aqui o valor está travado (não se ajusta a par/volatilidade); no Auto, recalcula
• Pill perde o prefixo "Auto:" — comunica que a decisão é manual agora

🟢 Insight A mudança visual entre Auto (com prefixo "Auto: 0.50%") e manual (só "0.50%") é a melhor decisão escondida do popover. Mesmo com o mesmo valor numérico, o produto comunica que mudou o modo — automático vs travado. Esse detalhe permite ao intermediário saber que está agora responsável pelo valor (não há mais adaptação dinâmica). Sutileza acertada.

^insight-1

🔴 Fricção 1 (estrutural — usuário não percebe a perda do Auto, afeta intermediário) A remoção do prefixo "Auto:" é mudança de estado importante (perda da adaptação dinâmica), mas comunicada apenas pela ausência da palavra. Intermediário que quis "confirmar" o valor que o Auto mostrava clicando em 0.5% manual NÃO sabe que acabou de desligar a adaptação. Em pares de liquidez baixa ou volatilidade alta, isso significa que 0.5% manual vai falhar onde Auto teria subido para 1.2% e completado a transação. Solução óbvia que falha: avisar toda hora que mudou de Auto vira ruído. Alternativa: mostrar microcopy no chip Auto ("Recomendado") + microcopy embaixo dos presets numéricos quando o usuário muda ("Você desativou o ajuste automático — Pancake usará 0.5% fixo nesta e nas próximas transações até você mudar."). Trade-off: copy ocupa espaço. Perfil afetado: intermediário (faz movimento sem perceber a consequência).

^friccao-1

🔴 Fricção 2 (estrutural — persistência do slippage entre transações, afeta todos) A decisão de slippage 0.5% manual provavelmente persiste em localStorage e se aplica à próxima transação. Mas o usuário pode estar configurando esse valor para um par específico (USDC/USDT, super líquido) e depois fazer swap em par diferente (token recém-listado, baixa liquidez) — onde 0.5% fixo vai falhar. O popover não comunica nem o escopo ("esta transação ou todas?") nem oferece reset automático ao trocar de par. Solução: chip de opção ("Aplicar a todas as transações ▾ / Só esta"); ou Auto como reset automático ao detectar troca de par.

^friccao-2

🔴 Fricção 3 (cosmética — preset numérico e input custom não comunicam serem o mesmo) Quando o user clica em 0.5% (chip), o input custom à direita mostra "0.50". Visualmente são dois elementos competindo — qual é "o controle"? Iniciante pode ficar confuso achando que precisa preencher o input mesmo tendo clicado no preset. Vale unificar visualmente (input desabilitado quando preset selecionado, ou input só aparece com chip "Custom" selecionado).

^friccao-3

🟡 Oportunidade competitiva (média leverage — escopo da configuração explícito) Uniswap, Pancake e 1inch configuram slippage como variável global persistente por sessão, sem escopo explícito. Para iniciante, isso significa que decisões tomadas em um contexto se aplicam silenciosamente em outro. Passa as 4 perguntas: (1) padrão indústria; (2) afeta iniciante e intermediário diretamente; (3) ninguém resolveu por design tradição (slippage sempre foi global), não por impossibilidade; (4) chip de escopo é diferença perceptível. Diferenciação Kotai: scope explícito no popover de configuração ("Aplicar esta tolerância a: ◉ Esta transação ○ Esta sessão ○ Sempre, até eu mudar"), com default na opção mais conservadora ("Esta transação") para iniciante. Auto como reset implícito quando detectar par com perfil de liquidez radicalmente diferente. Trade-off: adiciona complexidade ao popover; risco de paralisia de escolha. Mitigação: opção "Esta transação" + microcopy curto + colapso visual após primeira seleção.

Observação adicional (estado 0.5% manual = Auto numericamente, mas não semanticamente): vale destacar que NA SCREENSHOT o valor manual e o Auto coincidem (0.50%), mas isso é coincidência do par/momento. A próxima transação pode ter Auto recomendando 0.30% ou 0.80% — e o usuário que travou em 0.5% manual perdeu essa adaptação. Decisão de produto Kotai: o caminho de menor risco para iniciante é Auto sempre, com a opção manual apresentada de forma honesta sobre o trade-off ("você ganha controle, perde adaptação dinâmica").

^oportunidade-1

12. Swap Widget — wallet conectada, valores zerados (light theme)

Função: Estado inicial do widget de swap após conexão de wallet, sem valor digitado. Captura todo o chrome do widget pronto para input.

Componentes

• Tabs Swap / TWAP / Limit + ícone gráfico
• Section From: label "0xd09B…618a" + ícone wallet + contador "$0" à direita
• Card token From: BNB ▾, "BNB Chain", valor 0.00, ~0 USD
• Botão swap ↓ (centralizado, teal)
• Section To: label "0xd09B…618a" + ícone wallet + contador "$0" à direita
• Card token To: CAKE ▾, "BNB Chain", valor 0.00, ~0 USD
• Linha "Slippage Tolerance — Auto: 0.50% ✎"
• CTA desabilitado em cinza: "Enter an amount"
• Badge verde inferior: ✓ "MEV Protected" (sublinhado, link)
• Tema: light (background pastel azul-claro)

Regras de negócio

• Wallet conectada → exibe endereço encurtado em From e To (default: mesma wallet recebe)
• Endereço de To é editável (presumível clique no endereço abre input — typical DEX pattern)
• $0 ao lado do endereço = balance daquele token na wallet
• CAKE pré-selecionado como To por default (cross-promo do token nativo)
• Slippage 0.50% via Auto (já analisado nos relatórios 9-11)
• MEV Protection ativada por default — sublinhada como link, presumível abre explicação
• Tema light vs dark (relatório 9-11 mostra dark) — usuário pode alternar

🟢 Insight Duas decisões fortes: (1) endereço de destino visível e (presumivelmente) editável já no estado inicial — onboarding implícito para o caso de uso "enviar para outra wallet" sem precisar abrir menu avançado; (2) badge "MEV Protected" como propriedade declarada do produto, não como configuração que o usuário precisa ativar — proteção é default, não opt-in. Em um mercado onde MEV é vetor real de perda, declarar proteção como propriedade institucional é trust signal forte e legítimo.

^insight-1

🔴 Fricção 1 (estrutural — "To" pré-preenchido com CAKE como cross-promo silencioso, afeta iniciante) O token de destino vem pré-selecionado como CAKE — token de governança da própria Pancake. Para iniciante que abriu a tela com a intenção "quero trocar BNB por algo", o sistema responde "trocar por CAKE" sem perguntar. É funneling de produto disfarçado de default neutro. O resultado é que parte dos usuários completa o swap em CAKE sem ter conscientemente escolhido — comprando o token de governança sem entender que está fazendo isso. Solução óbvia que falha: defaultar To em branco força mais um clique e quebra o "experimentar antes de conectar" se houver herança desse pattern. Alternativa: defaultar To para o último token que o user trocou (ou USDC/USDT como neutros estáveis), e mover CAKE para chip de "Sugerido pela Pancake" — explícito, não silencioso. Trade-off: a Pancake perde canal gratuito de aquisição de holders CAKE; ganho é confiança. Perfil afetado: iniciante (não percebe a escolha imposta).

^friccao-1

🔴 Fricção 2 (estrutural — endereço To editável mas sem affordance, afeta intermediário) O endereço de To é (presumivelmente) editável para enviar swap a uma wallet diferente da conectada. Mas a UI não comunica essa capacidade — o endereço aparece como texto, não como input. Iniciante não descobre. Intermediário que sabe que a feature deveria existir tenta clicar para testar. Direcionamento: ícone pequeno de edit (✎) ao lado do endereço quando o cursor está próximo, ou texto inline "Trocar destino" como link. Trade-off: mais elemento, mas a feature passa a existir conscientemente.

^friccao-2

🔴 Fricção 3 (cosmética — labels "From / To" não comunicam direção a iniciante) From / To é convenção bem estabelecida em câmbio, mas para iniciante DeFi pode soar como "enviar de / para" (transferência) em vez de "pagar com / receber" (swap). "Você paga / Você recebe" é alternativa que comunica natureza econômica. Trade-off de localização (PT-BR vs EN) e de tradição (toda DEX usa From/To).

^friccao-3

🟡 Oportunidade competitiva (média leverage — token To não imposto) Uniswap, Pancake e 1inch defaultam o token To com cross-promo (Uniswap usa nada, Pancake usa CAKE, 1inch usa 1INCH). Para iniciante, isso polui o primeiro toque com decisão tomada pelo produto, não pelo user. Passa as 4 perguntas: (1) padrão indústria de cross-promo silencioso; (2) afeta iniciante diretamente — primeira impressão é "comprar token da casa"; (3) ninguém resolveu por incentivos comerciais (DEX ganha holders do próprio token), não por dificuldade técnica; (4) o iniciante percebe diferença ao chegar em uma tela que pergunta em vez de impor. Diferenciação Kotai: To em branco no primeiro uso, ou último-usado em retornos. Sugestões aparecem como chip explícito ("Sugeridos: USDC, ETH, ...") sem impor escolha. Trade-off: perde-se canal de cross-promo do token nativo Kotai (se houver) — alinhado ao posicionamento de "DEX para iniciante".

Observação adicional (MEV Protection como propriedade do produto): vale mapear o que "MEV Protected" significa exatamente para a Pancake (provavelmente roteamento via private mempool / RPC privado) e checar se o badge é apenas marketing ou se há mudança real no fluxo. Em Kotai, se a proteção for default, ela deve sobreviver à validação técnica — claim sem mecanismo vira marketing vazio.

^oportunidade-1

14. Swap Widget — Quote resolvido + insuficiência de saldo

Função: Estado pós-loading: rota encontrada, valores preenchidos, mas wallet não tem BNB suficiente para executar. Mostra também o card de on-ramp cross-sell.

Componentes adicionais (em relação ao relatório 13)

• To: CAKE = 413.907 com USD estimado "~628,11 USD"
• Card cross-sell entre o swap e o slippage: ícone ⓘ + texto "Need Crypto? Buy with the best price!" + CTA teal "Get it Now"
• CTA principal mudou: "Insufficient BNB balance" (cinza, desabilitado)
• Linha resumo abaixo do MEV Protected: "1 CAKE ↔ 0.002416 BNB | Fee 0.0004666 BNB" com chevron ▾ para expandir (analisado no relatório 15)

Regras de negócio

• Rota encontrada com diferença ~$0.65 entre From e To (slippage + fee internalizados)
• USD de To (628,11) menor que From (628,76) — diferença é o custo real do swap
• Card on-ramp aparece automaticamente quando o produto detecta saldo insuficiente — funnel para conversão fiat→crypto
• CTA descreve o bloqueio em texto ("Insufficient BNB balance") em vez de "Swap disabled"
• Linha resumo expõe taxa de câmbio + fee total (em BNB)
• Linha resumo está colapsada por default — só a info essencial visível

🟢 Insight CTA descreve o bloqueio de forma específica ("Insufficient BNB balance") em vez de mensagem genérica ("Swap disabled"). Iniciante recebe a causa exata da impossibilidade no único lugar onde está olhando. Padrão de error-state que rotula a causa: barato em copy e alto em clareza.

^insight-1

🔴 Fricção 1 (estrutural — on-ramp injetado em momento ambíguo, afeta iniciante) O card "Need Crypto? Buy with the best price! [Get it Now]" aparece quando o saldo é insuficiente — sugerindo on-ramp como solução. Mas há ambiguidade: o usuário pode estar sem saldo porque (a) ainda não comprou cripto e o produto está sugerindo a rota correta (on-ramp ajuda), ou (b) já tem cripto em outra wallet/exchange e precisa transferir (on-ramp é redundante e mais caro do que sacar). O card oferece um caminho sem perguntar qual é o caso — funneling para parceiro fiat (com KYC + fees próprias) como se fosse a única saída. Solução óbvia que falha: bloquear o card frustra quem realmente é caso (a). Alternativa: card com 2 opções explícitas ("Comprar com cartão / fiat" vs "Já tenho em outra wallet — depositar") — primeira leva ao on-ramp, segunda mostra endereço de depósito da wallet conectada. Trade-off: card mais denso, mas usuário não é empurrado para o caminho mais caro silenciosamente. Perfil afetado: iniciante (não sabe que existem alternativas além de "comprar agora").

^friccao-1

🔴 Fricção 2 (estrutural — fee em BNB sem equivalente em USD, afeta iniciante) "Fee 0.0004666 BNB" é número que não comunica custo real para iniciante. Vale (com BNB = $628) ~$0,29. Mas exigir do user calcular essa multiplicação em segundos é trabalho cognitivo desnecessário. Convenção "valor em token + USD entre parênteses" ("0.0004666 BNB ≈ $0,29") elimina cálculo mental. Direcionamento: USD entre parênteses ou abaixo, para todo número "em token" que represente custo (fee, slippage, gas estimado). Já que o produto tem o preço cached (vimos no relatório 13), o cálculo é trivial.

^friccao-2

🔴 Fricção 3 (estrutural — "1 CAKE ↔ 0.002416 BNB" é direção ambígua) "1 CAKE = 0.002416 BNB" é a leitura intuitiva, mas a seta dupla (↔) sugere bidirecionalidade. Para iniciante, leitura ambígua: "então 1 BNB = 0.002416 CAKE?" (errado — inversão da taxa). Convenção mais segura: "1 CAKE = 0.002416 BNB" ou um ícone de troca lateral (toggle de inversão), sem direção ambígua.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — on-ramp não imposto como único caminho) DEXes em geral injetam CTAs de on-ramp parceiro quando detectam saldo insuficiente. Para iniciante que já tem cripto em CEX (Binance, Coinbase) ou em outra wallet, o caminho do on-ramp é o mais caro e burocrático (KYC + spread + fee). Mas é apresentado como única solução. Passa as 4 perguntas: (1) padrão indústria (Uniswap, Pancake, 1inch); (2) afeta iniciante diretamente — ele segue o caminho sugerido; (3) ninguém resolveu por incentivo de revenue-share com on-ramp parceiro, não por dificuldade técnica; (4) UX diferenciada com opção explícita é claramente perceptível. Diferenciação Kotai: card de "saldo insuficiente" sempre com duas saídas ("Comprar com fiat" vs "Depositar de outra wallet/exchange"), com a segunda opção mostrando o endereço da wallet conectada e QR. Quando integrar on-ramp parceiro, ser honesto sobre fee (Kotai recebe X% como kickback). Trade-off: menos conversão direta para o parceiro fiat; ganho de confiança a longo prazo.

Observação adicional (proporção quote-vs-USD): From 1 BNB ~628,76 USD, To 413,907 CAKE ~628,11 USD — diferença ~$0,65 representa a soma de slippage + fee internalizados. Mas o usuário não vê o slippage e o fee somando para $0,65 — vê dois números USD próximos e a fee de "0,0004666 BNB". Recomendação Kotai: mostrar explicitamente "você paga X, recebe Y, fee Z (= W em USD), diferença = $K" — soma fechada e transparente. Hoje a Pancake esconde o custo total no detalhe.

^oportunidade-1

18. Route — tooltip do (?) "Routing through these tokens resulted in the best price for your trade"

Função: Mesmo popover Route do relatório 17, agora com hover sobre o ícone (?) no header — revela tooltip explicativa da função da tela.

Componentes adicionais (em relação ao relatório 17)

• Tooltip preto flutuante ancorado no (?)
• Texto: "Routing through these tokens resulted in the best price for your trade."
• Popover Route permanece visível abaixo

Regras de negócio

• Tooltip aparece em hover (presumível delay ~300ms)
• Texto é estático (não personalizado pela rota específica que foi escolhida)
• (?) é o único ponto pedagógico da tela — sem microcopy fixa

🟢 Insight A existência da explicação é positiva — o produto reconhece que "Route" é termo técnico que merece glossário inline, e oferece resposta em 1 frase. Esforço pedagógico que muitos DEX nem fazem. Decisão correta de assumir que parte dos usuários precisa do contexto.

^insight-1

🔴 Fricção 1 (estrutural — copy do tooltip explica o resultado, não a função, afeta iniciante) "Routing through these tokens resulted in the best price for your trade" é declarativa de resultado ("deu certo"), não explicação da função. Iniciante que abre essa tela tem a pergunta: "o que é Route? Por que isso existe? Para que serve?". A tooltip responde uma quarta pergunta ("essa rota é boa?") em vez das três primeiras. É como abrir o menu "Slippage" e o tooltip dizer "seu slippage está bom" — não ensina o conceito. Solução óbvia que falha: copy maior vira parágrafo desconfortável em tooltip. Alternativa: copy em duas linhas — (1) o que é: "Rota é o caminho que o seu swap percorre entre pools de liquidez para chegar do token de origem ao destino." (2) por que importa: "Rotas diferentes geram preços diferentes — o produto escolhe a que entrega mais token de destino." Trade-off: tooltip cresce ~2x; mas resposta efetivamente educa. Perfil afetado: iniciante (recebe afirmação, não aprendizado).

^friccao-1

🔴 Fricção 2 (estrutural — tooltip não personalizada com a rota visualizada) "these tokens" no tooltip presumivelmente se refere aos tokens visualizados no diagrama (BNB, V3 BNB/CAKE, CAKE), mas o texto é genérico — funciona para qualquer rota, qualquer trade. Perde oportunidade de explicar a rota específica que está visível: "O produto cotou direto na pool BNB/CAKE (V3, fee 0.05%) — entregou mais CAKE do que qualquer outra rota considerada". Tooltip personalizado vira insight contextual. Direcionamento: tooltip dinâmica que se adapta à rota visualizada — explicação genérica como fallback se a rota for muito complexa para descrever em 2 linhas.

^friccao-2

🔴 Fricção 3 (cosmética — descoberta via hover, padrão recorrente) Mesmo problema dos relatórios 7 e 8: a explicação fica atrás de hover, que não existe em mobile. Para iniciante em mobile, a tooltip não existe — o termo "Route" fica sem explicação acessível. Direcionamento: em mobile, transformar (?) em botão tap-to-reveal que abre uma camada de explicação inline. Em desktop, manter hover mas com delay curto + fallback de focus (acessibilidade).

^friccao-3

🟡 Oportunidade competitiva (média leverage — tooltips contextuais que explicam função, não resultado) DEXes em geral usam tooltips genéricas afirmativas ("this is the best route", "this slippage is safe") em vez de tooltips explicativas ("o que é isso, por que importa"). Para target Kotai (iniciante/intermediário), a diferença entre "o produto me afirma que está bom" e "o produto me explica o conceito" é a diferença entre confiar cegamente e entender o que está fazendo. Passa as 4 perguntas: (1) padrão indústria (tooltips DeFi são quase todas afirmativas); (2) afeta iniciante diretamente (é onde aprende ou não aprende); (3) ninguém resolveu por inércia de copywriting, não por dificuldade técnica; (4) tooltip que ensina é diferença perceptível e útil. Diferenciação Kotai: padrão sistemático para tooltips — sempre estrutura "O que é + Por que importa". "Slippage: máximo de diferença que você aceita entre o preço cotado e o executado. Quanto menor, mais chance de a transação falhar; maior, mais chance de aceitar preço pior." Aplicar isso a todos os (?) do produto. Trade-off: copy mais longa exige curadoria e tradução; mas é investimento amortizado em toda a UX.

Observação adicional (consistência cross-tela do padrão (?)): vale checar se a tooltip dos (?) em outras telas da Pancake segue o mesmo padrão afirmativo ou se há variedade. Se todas são genéricas, há oportunidade enorme de Kotai diferenciar com pedagogia sistemática; se há mistura, o pattern já existe parcialmente e basta consolidar.

^oportunidade-1

7. Modal "From" — Hover token (tooltip "Copy token address")

Função: Estado de hover sobre um item da lista de tokens revela dois micro-ícones de utility: copiar endereço e abrir no explorer (analisado no relatório 8). Esta tela captura o tooltip do primeiro.

Componentes

• Item USDT em hover (background highlight sutil)
• Após o nome "Tether USD", aparecem 2 ícones pequenos: clipboard e external link
• Tooltip preto "Copy token address" sobre o ícone clipboard
• Chevron → continua à direita
• Demais items da lista (WBNB, USD1, USDC, BILL, BTCB) em estado normal

Regras de negócio

• Ícones só aparecem on hover — escondidos por default
• Copy clipboard copia endereço do contrato do token na rede ativa (BNB Chain)
• Sem feedback de confirmação visível na screenshot (presumível toast "Copiado!")
• Função paralela ao chevron → (que provavelmente leva à seleção do token para o swap)

🟢 Insight Utility inline (copiar address sem sair da lista) é decisão correta de cohabitação: o user que precisa do endereço para auditar/colar em explorer/MetaMask não tem que sair, abrir tela do token, scrollar até a área de address, copiar, voltar. É micro-economia de cliques que importa para usuário intermediário/avançado fazendo due diligence inline. Decisão arquitetural a herdar para Kotai.

^insight-1

🔴 Fricção 1 (estrutural — ação escondida atrás de hover, afeta iniciante e mobile) Os ícones (clipboard e external) só aparecem no hover. Iniciante que não conhece o pattern "passa o mouse para revelar" nunca encontra a função. Pior: hover não existe em mobile — onde a Pancake também é entregue (PWA / Pancake mobile). Funcionalidade útil que não chega ao usuário que mais precisa de affordance explícita. Solução óbvia que falha: mostrar ícones sempre polui visualmente a linha do token (já tem ícone, nome, ticker, nome longo, tag de rede, chevron). Alternativa: ícones sempre visíveis MAS em opacidade reduzida (~40%) com tooltip on hover/long-press; ou um ícone único de "⋯" que abre menu com Copy + Explorer. Trade-off: levemente mais ruído visual, mas funções descobríveis em qualquer dispositivo. Perfil afetado: iniciante (não descobre), qualquer usuário em mobile (não tem hover).

^friccao-1

🔴 Fricção 2 (cosmética — falta confirmação visual do copy) Clipboard sem feedback explícito ("Copiado!") deixa o user inseguro sobre se a ação aconteceu. Web pattern moderno é toast de 1.5s confirmando — barato e elimina ansiedade.

^friccao-2

🟡 Oportunidade competitiva (média leverage — utility sempre visível no item) Uniswap, 1inch e Pancake escondem utility (copy address, ver no explorer) atrás de hover/cliques extras na tela do token. Para usuário intermediário fazendo due diligence inline, isso quebra fluxo. Passa as 4 perguntas: (1) todos os DEXes hidam; (2) afeta intermediário e iniciante curioso; (3) ninguém resolveu por densidade visual percebida, não por impossibilidade; (4) ícones visíveis (mesmo que em baixa opacidade) são diferença perceptível. Diferenciação Kotai: utility persistente no item (mesmo que sutil) + menu "⋯" como fallback de baixa proeminência. Mais radical: linha do token expansível inline com card de metadados (preço, market cap, contagem de holders, address, links para explorer) sem precisar abrir tela cheia. Trade-off: aumenta densidade, exige decisão de qual metadado é primário (não dá pra colocar tudo).

Observação adicional (consistência cross-screen): o pattern "hover revela utility" deveria ser consistente em toda a aplicação. Vale checar se outras telas da Pancake usam o mesmo gesto — caso usem mas com layout diferente, há fragmentação de pattern. Caso sejam as únicas duas (ícones aqui), o gesto é exceção isolada, ainda mais difícil de descobrir.

^oportunidade-1

8. Modal "From" — Hover token (tooltip "Open on Explorer")

Função: Estado de hover sobre o segundo micro-ícone do item de token: abrir o contrato no explorer da chain ativa (BscScan para BNB Chain).

Componentes

• Item USDT em hover, com clipboard + external link visíveis
• Tooltip preto "Open on Explorer" sobre o ícone external
• Barra de status do browser mostra a URL alvo: "https://bscscan.com/token/0x55d398326f99059fF775485246999027B3197955"
• Demais elementos idênticos ao relatório 7

Regras de negócio

• Link abre em nova aba (presumível target="_blank")
• URL é construída dinamicamente: explorer + path /token/ + endereço do contrato
• Explorer depende da rede ativa (BscScan, Etherscan, Arbiscan, etc.)
• Path conhecido (/token/) — convenção dos explorers EVM (Etherscan-family)

🟢 Insight Link para o explorer com URL pré-construída + endereço correto + página /token/ específica (não só /address/) é integração feita com cuidado. /token/ traz info contextualizada (supply, holders, transfers, source code do contrato), enquanto /address/ é genérico. Pancake escolheu a rota mais informativa — decisão técnica honesta para quem quer auditar.

^insight-1

🔴 Fricção 1 (estrutural — onboarding zero para explorer, afeta iniciante) "Open on Explorer" pressupõe que o usuário sabe o que é um block explorer, o que ele vai encontrar lá, e por que isso ajuda. Iniciante DeFi clica e cai em uma página da BscScan densa de dados técnicos (contagem de holders, ABI, transações, decimals) sem nenhum modelo mental para interpretar. Resultado: clica, fica perdido, fecha. Função tecnicamente correta, pedagogicamente vazia. Solução óbvia que falha: tutorial sobre block explorer dentro do produto da DEX é fora de escopo (transforma DEX em escola). Alternativa: mostrar dentro do próprio modal, antes de chutar para o explorer externo, os 3-4 metadados que o iniciante precisa para decidir (holders, idade do contrato, verificado/não verificado, link para o ToS). "Open on Explorer" continua existindo para quem quer mais; mas a decisão básica é tomada sem sair do contexto. Perfil afetado: iniciante (não decodifica explorer).

^friccao-1

🔴 Fricção 2 (mesmo problema do relatório 7 — descoberta via hover) Ícone external aparece apenas no hover. Vale o que foi dito no relatório 7: hover não existe em mobile, iniciante não descobre. Não duplico o argumento — observar como pattern consistente.

^friccao-2

🔴 Fricção 3 (cosmética — copy genérico) "Open on Explorer" não nomeia o explorer. "Open on BscScan" (com o nome real da chain ativa) seria mais específico e ensina ao iniciante que existe ferramenta nomeada. Custo zero, ganho de familiaridade.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — metadados inline antes de empurrar pro explorer) Uniswap, Pancake e 1inch tratam o explorer como saída final ("se quer info, vá lá"). Para iniciante isso é beco sem saída — ele chega num site externo que não fala a língua dele. Os 4-5 metadados que importam para decisão (holders, idade do contrato, verificado/não verificado, similaridade de nome com canônicos, presença em listas curadas) são triviais de buscar do explorer/indexer e exibir inline. Mas nenhuma DEX investe nisso. Passa as 4 perguntas-teste: (1) todos os DEXes oferecem só link cego pro explorer; (2) afeta iniciante diretamente — é a checagem que deveria ser feita antes de comprar; (3) ninguém resolveu por falta de investimento em indexação on-chain mais simples (dados existem); (4) card de metadados inline é diferença perceptível e útil. Diferenciação Kotai: card expandível no item de token (sem ir para o explorer) com: idade do contrato, holders, verificado on-chain (sim/não), checagem de similaridade de nome com canônicos, presença em listas curadas. Link "Ver tudo no [BscScan/Etherscan]" continua existindo como escape para quem quer mais. Trade-off: exige indexador on-chain + dashboard de metadados — investimento real, mas é o mesmo investimento já necessário para o risk signaling no import (relatório 5) e no seletor (relatório 1). Custo amortizado entre múltiplas oportunidades.

Observação adicional (URL exposta como trust signal): o fato da barra de status mostrar a URL completa antes do clique é convenção do browser, não decisão da Pancake — mas é trust signal real ("você está prestes a sair para bscscan.com, com este endereço de contrato específico"). Em Kotai, vale preservar links externos com target visível e nunca abrir em iframe — manter a fricção de "sair do produto" é honestidade que constrói confiança no longo prazo.

^oportunidade-1

9. Slippage Setting — estado default (Auto)

Função: Popover de configuração da tolerância de slippage no swap. Acionado pelo pencil ao lado de "Slippage Tolerance Auto: 0.50%" no widget.

Componentes

• Header "Slippage Setting" + ícone (?) + X
• Linha única de presets em chips: Auto (selecionado, roxo) / 0.1% / 0.5% / 1.0%
• Input custom "Auto | %" à direita dos presets
• Sem CTA primário — selecionar um valor já aplica
• USDT como token de origem (USDT BNB Chain, valor 0.00, ~0 USD)
• Mascote Need Help no canto inferior direito

Regras de negócio

• Slippage = tolerância máxima de desvio entre preço cotado e executado (em %)
• Auto = produto decide com base na liquidez do par e volatilidade recente
• Presets cobrem 0.1% / 0.5% / 1.0% como atalhos
• Input custom aceita qualquer valor (com gatilhos de warning para extremos — visto no relatório 10)
• Valor aplicado refletido no pill "Auto: 0.50%" abaixo do widget
• Alteração persiste na sessão (presumível localStorage)

🟢 Insight Duas decisões fortes: (1) "Auto" como default em vez de número fixo — alivia o iniciante de tomar decisão técnica que ele não tem como tomar, e ainda mostra o valor calculado (0.50%) para quem quer auditar; (2) presets contemplam os 3 valores que cobrem ~95% dos casos reais, com input custom como escape para quem precisa de granularidade. Arquitetura correta de "defaults inteligentes + escape para avançado".

^insight-1

🔴 Fricção 1 (estrutural — "slippage" como conceito não explicado, afeta iniciante) O header é "Slippage Setting" — termo técnico sem definição inline. Há ícone (?) ao lado, mas é affordance secundária. Iniciante que abriu o popover não sabe o que está prestes a configurar: o que acontece se eu mudar de Auto para 0.1%? Para 1.0%? O que é "tolerância"? Sem microcopy de 1 linha no topo ("Tolerância de desvio entre o preço cotado e o executado — quanto maior, mais chance de aceitar pior preço; menor, mais chance da transação falhar."), o popover é trap: usuário toca em "0.1%" achando que está economizando taxa e cai na trava do relatório 10. Solução óbvia que falha: tooltip no (?) resolve só para quem clica; e tooltip exige hover, que não funciona em mobile. Alternativa: linha de explicação curta abaixo do header, sempre visível. Trade-off: adiciona ~30px de altura ao popover. Perfil afetado: iniciante. Intermediário sabe o que é slippage e pula.

^friccao-1

🔴 Fricção 2 (estrutural — Auto sem mostrar a regra, afeta intermediário) "Auto" mostra que resulta em 0.50%, mas não diz por quê. Intermediário que quer entender se confia no Auto antes de migrar para custom não tem como — é caixa-preta. "Auto (0.50% — par ETH/USDC tem liquidez profunda, volatilidade baixa)" seria diferencial real de transparência. Hoje, intermediário desconfiado migra para 0.5% manual achando que está "no controle", mas tecnicamente está fazendo exatamente o que o Auto fez — só perdeu a adaptação dinâmica. Perfil afetado: intermediário (perde adaptabilidade do Auto sem perceber que está perdendo).

^friccao-2

🔴 Fricção 3 (cosmética — input custom com placeholder "Auto" é ambíguo) O input à direita tem placeholder "Auto | %". "Auto" como hint num input numérico é confuso — é o valor atual? É o que vai acontecer se eu deixar vazio? É o nome do modo? Hint mais claro: placeholder "Custom %" ou "Ex: 0.50".

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — slippage explicado no momento da decisão) Uniswap, Pancake e 1inch expõem slippage como número configurável sem ensinar o conceito no momento do uso. O resultado é o mesmo padrão observado no mercado: ou o usuário deixa default e funciona, ou ele "explora" e quebra a transação sem entender por quê. Passa as 4 perguntas-teste: (1) padrão indústria; (2) afeta iniciante diretamente — slippage é um dos 3-4 conceitos que separam "sei trocar token" de "sei usar DEX"; (3) ninguém resolveu por inércia de design (vale-tudo técnico em copy), não por impossibilidade; (4) microcopy explicativa é claramente perceptível e útil. Diferenciação Kotai: microcopy contextual em 1 linha no topo do popover, sempre visível + explicação dinâmica embaixo de cada preset quando o usuário hover/seleciona ("0.1% — só funciona em pares de altíssima liquidez (ex: USDC/USDT). Em outros pares, sua transação vai falhar."). Trade-off: copy precisa ser mantida em sincronia se a mecânica mudar (intent-based swaps mudam a relação preço/slippage).

Observação adicional (mecânica do Auto): vale checar (em telemetria/AB test) se Auto realmente performa melhor que 0.5% manual para o usuário típico — se a diferença é mínima, Auto é UX ("não pense") mais que técnica. Em Kotai, vale a mesma decisão arquitetural (defaultar Auto), mas com transparência sobre a regra que o Auto está aplicando.

^oportunidade-1

10. Slippage Setting — preset 0.1% (warning)

Função: Mesmo popover do relatório 9, agora com o preset 0.1% selecionado, disparando warning de risco de falha de transação.

Componentes adicionais (em relação ao relatório 9)

• Preset 0.1% destacado em roxo (selecionado)
• Bloco de warning amarelo abaixo dos presets:
  • Ícone ⚠ laranja
  • Texto "Your transaction may fail."
  • Link sublinhado "Reset slippage settings" + "to avoid potential loss."
• Input custom mostra "0.10" (valor refletido do preset)
• Pill "Slippage Tolerance" abaixo do widget agora mostra "⚠ 0.10%" em laranja (não mais "Auto: 0.50%")

Regras de negócio

• 0.1% é considerado abaixo do limiar seguro para a maioria dos pares — produto dispara warning automático
• "Reset slippage settings" reverte para Auto
• Warning é apenas informativo — não bloqueia o swap
• Pill no widget herda ícone de warning para reforçar fora do popover

🟢 Insight O warning não bloqueia — apenas avisa e oferece o caminho de volta ("Reset slippage settings"). É a balança correta entre proteger usuário e respeitar autonomia (o slippage baixo pode ser intencional em pares de altíssima liquidez). O ícone ⚠ no pill propaga o aviso para fora do popover, então quem fecha o popover sem mexer continua vendo que está em estado anômalo. Boa propagação de estado entre componentes.

^insight-1

🔴 Fricção 1 (estrutural — warning fala sintoma, não causa, afeta iniciante) "Your transaction may fail" é o sintoma. A causa é: "0.1% é tão estreito que qualquer microvariação de preço entre o quote e a execução faz o smart contract reverter por proteção". Iniciante lê "may fail" sem entender por quê — ele pensa "o produto está com bug?", "a rede está congestionada?", "o token tem problema?". Sem ligar a causa, ele provavelmente clica "Reset" sem aprender nada — só sabe que 0.1% é "o ruim". Solução óbvia que falha: explicar tudo no warning vira parágrafo no popover, polui. Alternativa: 1 linha de causa + link "Saiba mais" → modal/sidebar com explicação completa de slippage. "Slippage muito baixo para esse par. Variações pequenas de preço durante a execução farão sua transação reverter, e você paga gas mesmo assim." — em 2 linhas, ensina mecânica + custo. Perfil afetado: iniciante (aprende a evitar sem aprender por quê).

^friccao-1

🔴 Fricção 2 (estrutural — falta consequência financeira, afeta todos) O warning fala em "failure" mas não em "você paga gas mesmo se falhar". Transação revertida na chain ainda consome gas — é perda real, não "tentei e não aconteceu nada". O iniciante que clica em swap com slippage 0.1% pode perder $1-$5 em gas (BNB Chain) ou $20-$50 (Ethereum) por tentativa sem entender. O warning deveria comunicar essa consequência financeira concreta.

^friccao-2

🔴 Fricção 3 (cosmética — "Reset slippage settings" é wordy) "Reset slippage settings to avoid potential loss" tem 6 palavras antes do CTA real. "Voltar para Auto" ou "Restaurar padrão (0.50%)" é mais direto e mostra para onde vai voltar.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — warnings explicam causa + consequência, não só sintoma) DEXes em geral mostram warnings genéricos ("may fail", "transaction unlikely to succeed") sem ensinar o porquê e sem expor o custo concreto. Para iniciante, é repreensão sem aula — ele evita o gesto, mas não internaliza a regra. Passa as 4 perguntas-teste: (1) padrão indústria (UI de warning DeFi é quase toda assim); (2) afeta iniciante diretamente — é onde ele aprende ou não aprende DeFi; (3) ninguém resolveu por preguiça de copy, não por dificuldade técnica; (4) warning bem escrito é diferença perceptível e útil em todas as telas. Diferenciação Kotai: padrão de warning sempre com 3 camadas — (a) sintoma em 1 linha, (b) causa em 1 linha, (c) custo concreto em 1 linha ("você paga ~$X em gas mesmo se a transação falhar"). Aplicável não só a slippage, mas a aprovações infinitas, MEV, deadline expirado, etc. Trade-off: copy mais densa exige curadoria e tradução; copy mal escrita vira ruído pior que silêncio.

Observação adicional (warning persistente fora do popover): o ⚠ no pill é correto, mas iniciante pode fechar o popover sem mexer e tentar swap mesmo assim — o warning some atrás de um clique de novo. Vale propagar a causa também no momento de confirmar o swap, não só no momento de configurar. Defesa em profundidade: avisar de novo na hora que importa.

^oportunidade-1

17. Route — popover de visualização da rota

Função: Visualização gráfica da rota que o roteador escolheu — token origem, pools intermediárias e token destino, com proporções e fees.

Componentes

• Header "Route" + ícone (?) ao lado (tooltip analisado no relatório 18)
• Visualização em 3 nós conectados por linha pontilhada:
  • Nó 1: ícone BNB amarelo, label "100%" abaixo (toda a ordem segue esta rota)
  • Nó 2: par BNB+CAKE (ícones sobrepostos), label "V3 (0.05%)" abaixo
  • Nó 3: ícone CAKE rosa (token destino)
• Background do widget atrás permanece visível (Slippage, fee em resumo expandido)

Regras de negócio

• 100% = não há split routing nesta trade (toda a ordem passa pela mesma pool)
• V3 (0.05%) = pool da Pancake V3 com tier de fee de 0.05% (mais baixa em V3, ideal para pares líquidos)
• Ausência de hop intermediário = swap direto BNB→CAKE sem token-ponte
• Visualização vem de dados de roteamento estruturados (não imagem) — escalaria para mostrar splits e multihops

🟢 Insight Visualização gráfica em vez de texto técnico é decisão arquitetural forte. "BNB → V3 (0.05%) → CAKE" como diagrama com ícones comunica em 1 olhada o que um trecho de JSON ou string técnica precisaria de parágrafos. Para intermediário que quer auditar a rota, essa tela é radicalmente mais legível que a alternativa em texto. Padrão a herdar para Kotai.

^insight-1

🔴 Fricção 1 (estrutural — semântica do diagrama é parcialmente decifrável, afeta iniciante) O usuário-target Kotai (iniciante/intermediário) precisa interpretar 3 coisas: (a) que 100% é proporção de splitting (não distância ou completude); (b) que "V3 (0.05%)" significa pool Pancake V3 com fee tier 0.05% (e não V3 "versão 3 de algo"); (c) que ausência de nó intermediário entre os dois pares de ícones significa swap direto sem token-ponte. Cada um desses elementos é trivial se o user sabe o contexto, opaco se não. Iniciante olha e entende "tem BNB e CAKE no meio do nada". Solução óbvia que falha: legenda dentro do popover polui visualmente. Alternativa: microcopy de 1-2 linhas no rodapé do popover ("Rota direta: 100% da sua ordem foi cotada na pool BNB/CAKE da Pancake V3, fee 0.05%. Sem token-ponte."). Trade-off: copy maior; mas a visualização ganha tradução em palavras para quem não decodifica os símbolos. Perfil afetado: iniciante (não decodifica símbolos), intermediário (decodifica parcialmente, sente que falta algo).

^friccao-1

🔴 Fricção 2 (estrutural — Route popover sem comparação com alternativas) A visualização mostra a rota escolhida, mas não mostra as rotas rejeitadas e por quê. Para intermediário que quer auditar, a pergunta natural é "por que essa e não outra?" — informação que existe no agregador (ele comparou múltiplas) mas não chega à UI. Trust signal desperdiçado. Direcionamento: lista colapsada abaixo da visualização — "Outras rotas consideradas: V2 (0.25%) BNB→CAKE direto (recebeu 0.2% menos); V3 (1%) BNB→USDT→CAKE (recebeu 0.05% menos por causa do hop)". Iniciante ignora; intermediário audita; avançado tem material para tunar configuração.

^friccao-2

🔴 Fricção 3 (cosmética — "100%" abaixo do nó de origem é ambíguo) O label "100%" abaixo do BNB poderia ser interpretado de várias formas (100% da posição da wallet? 100% do swap?). É proporção do split routing — claro para quem conhece a feature, ambíguo para quem não. "100% via esta rota" ou simplesmente omitir quando não há split (mostrar split labels só quando split ocorrer) seria mais econômico de cognição.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — visualização de rota + comparação implícita) DEXes mostram rota como texto ou diagrama sem contextualização. Para intermediário que quer entender "o produto está realmente fazendo o melhor para mim?", a única opção é confiar — não há mecanismo visível de auditoria. Passa as 4 perguntas: (1) padrão indústria (nenhum DEX mostra rotas rejeitadas); (2) afeta intermediário e avançado diretamente; (3) ninguém resolveu por excesso de minimalismo, não por dificuldade técnica (dado existe no agregador); (4) lista colapsada de alternativas é claramente perceptível como trust signal. Diferenciação Kotai: visualização principal (diagrama) + lista colapsada de "alternativas consideradas" abaixo, mostrando por que cada uma perdeu. Tradução para o iniciante: copy curta "Comparamos 3 rotas e escolhemos a que entrega mais CAKE pra você". Mesma info, duas leituras. Trade-off: requer que o roteador exponha estado de alternativas (não só vencedora); pode aumentar custo de query.

Observação adicional (icon language vs text): ícones de tokens funcionam como linguagem visual eficiente para quem reconhece (BNB amarelo, CAKE rosa), mas falham para tokens menos populares (mesmo ícone-genérico para 10 tokens diferentes). Garantir que a visualização tenha fallback textual ("BNB → CAKE") legível para tokens novos é importante — caso contrário, tokens emergentes virgens de ícone curado aparecem todos como esfera cinza-genérica indistinguível.

^oportunidade-1

16. Routing Settings — popover de configuração de roteamento

Função: Configuração avançada de roteamento — controla quais fontes de liquidez e estratégias o produto pode usar para encontrar a melhor cotação.

Componentes

• Header "Routing Settings" + X
• Section "LIQUIDITY SOURCE" (subhead em roxo)
  • PancakeSwap X (chip teal destacado, toggle ON com ícone de panqueca laranja sobreposto)
  • Subtexto: "When applicable, aggregates liquidity to provide better price, more token options, and gas free swaps."
  • PancakeSwap Infinity (?) — toggle ON
  • PancakeSwap V3 (?) — toggle ON
  • PancakeSwap V2 (?) — toggle ON
  • PancakeSwap StableSwap (?) — toggle ON
• Section "ROUTING PREFERENCE" (subhead em roxo)
  • Fast routing (BETA) (?) — toggle ON
  • Allow Multihops (?) — toggle ON
  • Allow Split Routing (?) — toggle ON

Regras de negócio

• 4 versões da Pancake (Infinity, V3, V2, StableSwap) representam pools com mecânicas distintas — desligar uma exclui ela da busca de rota
• PancakeSwap X destacado é o agregador externo (intent-based + liquidez fora das pools da Pancake)
• Multihops = permitir rota com token intermediário (BNB → USDT → CAKE em vez de só BNB → CAKE)
• Split Routing = dividir a ordem em múltiplas rotas em paralelo (50% Pool A, 50% Pool B)
• Fast routing (BETA) = otimização de latência da busca, possivelmente custo em precisão
• Cada toggle vem ON por default — produto assume que avançado restringe, não permite

🟢 Insight Destaque visual do PancakeSwap X com chip colorido + subtexto explicativo é decisão correta — comunica que é a fonte mais poderosa sem esconder atrás de label técnico igual aos outros. É a única fonte que tem explicação inline; as demais são jargão mudo. Reconhecimento implícito de que essa é a opção que mais beneficia o usuário típico.

^insight-1

🔴 Fricção 1 (estrutural — tela inteira é overkill para o target, afeta iniciante e intermediário) O popover inteiro é configuração de avançado: distinguir Infinity / V3 / V2 / StableSwap exige modelo mental do que cada versão é (concentrated liquidity, fórmulas de AMM, slippage curves). Multihops e Split Routing são otimizações que iniciante não compreende. Mesmo intermediário não tem chance de tomar decisão informada — desligar Multihops melhora preço? Piora? Depende? A tela existe, é potente, e é trap se o usuário mexer. Solução óbvia que falha: esconder essa tela tira ferramenta de avançado. Alternativa: manter como opt-in via flag de modo avançado em settings (a tela só aparece se o user ativou modo avançado). Para iniciante/intermediário do target Kotai, esta tela não deveria existir no fluxo principal. Perfil afetado: iniciante (não entende e não deveria estar aqui), intermediário (entende parcialmente, mexe sem dimensão de impacto).

^friccao-1

🔴 Fricção 2 (estrutural — tooltips (?) como única pedagogia, afeta intermediário) Cada toggle tem ícone (?) ao lado do nome, presumivelmente abrindo tooltip. Mas tooltip exige hover (não funciona em mobile), e "V3 (?)" só faz sentido se o usuário sabe que V3 é versão diferente de V2 — informação que (?) não consegue compactar em frase curta. A pedagogia como utility secundária presume conhecimento que o usuário não tem. Direcionamento Kotai: se houver tela equivalente em modo avançado, microcopy abaixo de cada toggle (não atrás de hover): "V3 — pools com liquidez concentrada, melhor para pares estáveis" / "V2 — pools clássicas, melhor cobertura de tokens novos". Trade-off: popover maior, mas usuário decide com base em informação.

^friccao-2

🔴 Fricção 3 (estrutural — toggles destrutivos cumulativos sem aviso) Desligar V2 + V3 + Infinity + StableSwap deixa apenas PancakeSwap X — pode falhar para certos pares. Desligar X mantém só pools internas — perde liquidez externa. Nenhuma combinação é validada no momento do toggle ("Atenção: você desativou todas as pools V2/V3, certos pares deixarão de ter cotação"). Iniciante exploratório pode quebrar a função do swap inteira sem entender que foi ele.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — modo avançado como opt-in explícito) Uniswap, Pancake e 1inch oferecem configurações de roteamento avançado dentro do fluxo padrão, sem distinguir nível de usuário. Para iniciante, é fonte de ansiedade ("vou mexer no errado e quebrar?"); para intermediário, é gatilho de exploração descontrolada. Passa as 4 perguntas: (1) padrão indústria; (2) afeta iniciante diretamente (existência da tela já é fricção); (3) ninguém resolveu porque "tirar features de avançado" parece regredir, mas é fricção real; (4) tela ausente no fluxo padrão é diferença perceptível ("é simples"). Diferenciação Kotai: roteamento como decisão totalmente delegada ao produto no fluxo padrão. Sem tela "Routing Settings" visível por default. Modo avançado opt-in em settings globais — quando ativo, abre acesso a essa tela + outras (slippage manual sem warnings, custom RPCs, etc.). Trade-off: avançado sente o produto "infantilizado" se não souber do modo avançado; mitigação: link discreto no rodapé de cada tela ("Modo avançado: desativado — ativar").

Observação adicional (gas-free swaps via PancakeSwap X): "gas free" no subtexto é claim alto que merece verificação. Tipicamente, gas-free em intent-based DEX significa que o solver/filler paga o gas e cobra de volta no spread — o usuário não paga gas explicitamente, mas paga via preço pior. Vale auditar se a Pancake comunica isso honestamente em outra tela; se não, é claim que aproxima a fronteira do marketing enganoso. Em Kotai, vale aprender: "gas-free" é palavra-armadilha; preferir "sem gas explícito (custo incluído no preço da operação)".

^oportunidade-1

20. Swap com Gráfico — modo trader

Função: Layout alternativo do swap com gráfico de preço (candlesticks) à esquerda e widget compacto à direita. Ativado por toggle no canto superior direito do widget (ícone de barras).

Componentes

• Coluna esquerda — gráfico (TradingView embedado):
  • Header: ícone do par + "BNB/CAKE" + ícone de switch (↔)
  • Métricas 24h: 24h Change -0.6% (rosa), 24h High 417.04, 24h Low 416.91, preço atual 413.77
  • Timeframe selector "15m" + ícones (toolbox, indicators "fx Indicators", "Aggregate Pricing")
  • Candlesticks rosa/teal, eixo Y direito mostrando 412-421
  • OHLC do candle atual: O 414.11404 / H 414.54890 / L 412.27727 / C 413.77340 / -0.34064 (-0.08%)
  • Logo TradingView no canto inferior esquerdo (atribuição)
  • Ícones de zoom / settings no canto inferior direito
• Coluna direita — widget compacto:
  • Tabs Swap / TWAP / Limit + ícone gráfico (agora destacado, indicando que o chart está aberto)
  • From: BNB ▾ valor 0 ~0 USD
  • To: CAKE ▾ valor 0.00 ~0 USD
  • Slippage Auto 0.50%, CTA "Enter an amount", MEV Protected
• Layout: split horizontal (chart ~60%, widget ~40%)

Regras de negócio

• Toggle do ícone gráfico alterna entre modo "só widget" (centralizado) e "chart + widget" (split)
• Gráfico é embed TradingView com toolset reduzido (Indicators, Aggregate Pricing)
• "Aggregate Pricing" sugere que o preço mostrado é média entre fontes (não preço de uma pool específica)
• Indicadores técnicos disponíveis via menu (RSI, MACD, etc.)

🟢 Insight Gráfico embedado dentro do produto sem forçar saída para terceiro (DexScreener, Coingecko, TradingView.com) é decisão arquitetural forte para o intermediário. "Aggregate Pricing" como toggle no chart é trust signal técnico — comunica que o preço plotado é média entre fontes (não preço de uma pool isolada que pode ser manipulada). Decisão de transparência que diferencia DEX de "DEX-com-chart-fake".

^insight-1

🔴 Fricção 1 (estrutural — modo trader habilitado para iniciante, afeta iniciante) O toggle de chart está visível no widget desde o estado inicial — qualquer usuário pode ativar e cair no modo trader. Para iniciante DeFi (target Kotai), candlestick + indicadores + OHLC é fonte de paralisia: ele vê informação que não decodifica e pode (a) ficar inseguro de tomar a decisão de swap, (b) tentar "timing the market" sem ter ferramental. Solução óbvia que falha: esconder o chart resolve para iniciante mas tira ferramenta de quem sabe usar. Alternativa: modo trader como opt-in via flag de "modo avançado" em settings (mesmo gancho do relatório 16 sobre Routing Settings). Ou, mais sutil: chart visível mas com toggle de simplificação ("Mostrar apenas tendência de 24h" como default, full chart como avançado). Perfil afetado: iniciante (paralisia, ou pior, decisão de timing baseada em chart que não decodifica).

^friccao-1

🔴 Fricção 2 (estrutural — "Aggregate Pricing" como toggle ambíguo) "Aggregate Pricing" é botão/toggle no header do chart, mas a UI não comunica o estado atual: está ON ou OFF? E se OFF, qual fonte está sendo plotada (qual pool, qual DEX)? Iniciante vê "Aggregate Pricing" e não sabe se isso é bom ou ruim, ligado ou desligado. Intermediário sabe o conceito mas não decifra estado. Direcionamento: rótulo de estado explícito ("Pricing: Aggregate ▾" ou chip ON/OFF) + tooltip de 1 linha explicando o que muda.

^friccao-2

🔴 Fricção 3 (cosmética — métricas 24h sem âncora qualitativa) "-0.6%" em rosa, "417.04 / 416.91" como High/Low sem contexto (range típico do par? volatilidade percebida?). Iniciante olha "-0.6%" e não sabe se é dia calmo, volátil, normal. Mesmo problema do Price Impact no relatório 15 — números crus sem âncora. Direcionamento: tag qualitativa por métrica quando relevante ("Volatilidade baixa — variação dentro do esperado") + linha discreta de contexto.

^friccao-3

🟡 Oportunidade competitiva (média leverage — modo trader como opt-in, não exposto por default) Uniswap, Pancake e 1inch oferecem chart embedado por default. Para iniciante DeFi, é distração cognitiva e fonte de viés ("se está caindo, espero; se está subindo, compro agora" — comportamento de trader que não serve para quem só quer trocar token). Passa as 4 perguntas: (1) padrão indústria (todos oferecem chart); (2) afeta iniciante diretamente — induz comportamento de trader em quem não é trader; (3) ninguém resolveu por crença de que "mais info = produto melhor", não por dificuldade técnica; (4) ausência de chart no fluxo padrão é claramente perceptível ("é simples"). Diferenciação Kotai: chart escondido por default; ativável em modo avançado. Para target iniciante, mostrar apenas indicador discreto de "tendência de 24h" (seta + percentual + range) sem entrar em candlestick. Trade-off: intermediário que valoriza chart vê o produto como "básico" se não souber do modo avançado; mitigação: link discreto "Ver gráfico" perto do par de tokens.

Observação adicional (TradingView embed): usar embed do TradingView é decisão pragmática (não reinventar charting), mas leva o usuário a depender de uma empresa terceira (cookies do TradingView no domínio da Pancake, branding TradingView visível). Em Kotai vale avaliar trade-off de embed vs charting próprio simplificado — embed dá poder, mas charting próprio dá controle de UX e privacidade.

^oportunidade-1

19. Swap Widget — Resumo colapsado + footer institucional

Função: Captura a tela após rolar abaixo do widget, revelando o footer institucional do produto. Resumo do swap fica colapsado na parte de cima (chevron ▾).

Componentes

• Topo da tela: card To (CAKE 413.829, ~628,28 USD), card on-ramp "Need Crypto? Buy with the best price! [Get it Now]", Slippage Tolerance Auto 0.50%, CTA "Insufficient BNB balance", badge MEV Protected
• Linha resumo colapsada: "1 BNB ↔ 413.829 CAKE | Fee 0.0005 BNB" + chevron ▾
• Footer institucional em 5 colunas + logo PancakeSwap:
  • ECOSYSTEM: Trade, Earn, Play
  • BUSINESS: CAKE Incentives, Staking Pools, Token Launches, Brand Assets
  • DEVELOPERS: Contributing, Github, Developer Doc, Bug Bounty
  • SUPPORT: Get Help, Troubleshooting, Documentation, Audits, Legacy products
  • ABOUT: Tokenomics, CAKE Emission Projection, Blog, Careers, Terms Of Service
• Background light com tons pastéis

Regras de negócio

• Footer aparece a partir do scroll do widget — não é fixed
• Cada coluna agrupa links por audiência: usuário final / acionista de token / dev / suporte / corporativo
• Quote do swap continua viva mesmo durante scroll — número de CAKE muda (413.829 vs 413.907 em telas anteriores)
• "Audits" como categoria de Support, não About — decisão arquitetural notável

🟢 Insight A segmentação do footer por audiência (Ecosystem / Business / Developers / Support / About) é decisão de organização clara: cada user encontra o que importa para o perfil dele sem ruído. Em particular, "Audits" como item próprio em Support — não escondido em About — é trust signal forte: a Pancake declara que auditoria é informação relevante para o usuário final, não só para investidor. Pattern que herda bem.

^insight-1

🔴 Fricção 1 (cosmética — "Audits" sob Support é decisão correta mas perdida na densidade) O ponto positivo do insight também é o problema: "Audits" é UM item entre 5 da coluna Support, com peso visual idêntico a "Get Help" e "Troubleshooting". O signal de "este produto é auditado, clique para ver" se dilui. Para iniciante DeFi, audit é um dos 2-3 critérios para decidir confiar dinheiro — vale mais elevação visual. Direcionamento Kotai: trust signals (auditorias, certificações, bug bounty) merecem destaque próprio em vez de virar item de lista. Badge persistente no header ou tile dedicado em "Trust & Security" eleva o sinal sem perder a leveza do footer. Perfil afetado: iniciante (não decifra que Audits é sinal forte misturado em lista de FAQ).

^friccao-1

🔴 Fricção 2 (estrutural — segmentação por audiência sem rótulo de audiência) As colunas têm headers de "natureza do conteúdo" (Business, Developers, Support, About) mas não rotulam a audiência alvo. Iniciante DeFi olha "Business" e pode pensar "isso é pra mim?" sem saber que é cross-promo de tokenomics / staking. "Developers" comunica audiência (sou dev ou não?); "Business" não — quem é o usuário-business? Holder de CAKE? Empresa cliente da API? Ambíguo. Direcionamento: rotular pela audiência ("Para você", "Para holders", "Para devs", "Suporte", "Sobre a empresa") em vez de pela natureza interna.

^friccao-2

🔴 Fricção 3 (cosmética — footer aparece só com scroll, não com transação completa) Footer aparece apenas quando o usuário rola abaixo do widget. Para o caso de uso primário (executar swap), o usuário nunca chega no footer — toda a wayfinding institucional (audits, suporte, docs) fica invisível. Em mobile a fricção é pior (scroll é mais custoso). Header ou drawer lateral podem complementar o footer com links críticos sempre acessíveis (Audits, Get Help).

^friccao-3

🟡 Oportunidade competitiva (média leverage — trust signals fora do footer) Uniswap, Pancake e 1inch escondem audits/security/bug bounty no footer institucional. Para target Kotai, esses são exatamente os signals que o iniciante precisa para decidir confiar pela primeira vez — mas estão geograficamente longe do momento de decisão (header da tela do swap). Passa as 4 perguntas: (1) padrão indústria (todas escondem); (2) afeta iniciante diretamente — é o que constrói confiança inicial; (3) ninguém resolveu por convenção web (footer é "institucional"), não por dificuldade; (4) badge "Auditado por Certik / Trail of Bits" no header próximo à wallet é claramente perceptível. Diferenciação Kotai: badge persistente "Auditado" + ícone do auditor no header, sempre visível, clicável para ver relatório. Sem inflar o header — uma linha discreta na altura do logo. Trade-off: aumenta densidade do header; mas trust signal contínuo vale a fricção visual.

Observação adicional ("Legacy products" como item): declarar publicamente que existem produtos legados ("Legacy products" no Support) é honestidade técnica rara — admite que houve sucessões, sem esconder. Sinaliza maturidade de produto que pensa em ciclo de vida. Vale herdar para Kotai quando houver versões substituídas: rota de migração explícita, não site quebrado nem feature removida em silêncio.

^oportunidade-1

21. Home desconectada — vista completa com footer e banner cross-promo

Função: Página inicial inteira em estado wallet-desconectada, mostrando o widget de swap centralizado + footer institucional completo + banner cross-promo de chain (Monad) + utilities globais (theme toggle, preço CAKE).

Componentes

• Header: logo PancakeSwap, nav (Trade, Perps, Earn, Play, AI), Search /, ícone settings, Connect Wallet (CTA teal)
• Widget central: Swap / TWAP / Limit, From BNB 0.00, To CAKE 0.00, Slippage Auto 0.50%, CTA "Connect Wallet" (teal)
• Banner cross-promo flutuante no canto inferior direito: "Monad Now Live on PancakeSwap — Learn More — [Swap Now ↗]" com mascote-mascarado verde + paginação de carrossel (5 dots)
• Botão X dismiss no banner
• Footer institucional completo (Ecosystem / Business / Developers / Support / About — já mapeado no relatório 19)
• Linha de social icons (X, Telegram, Reddit, Instagram, Github, Discord, YouTube)
• Rodapé final do footer:
  • Esquerda: toggle sun ☀ / moon ☾ (theme light/dark)
  • Direita: preço CAKE "$1.497" + CTA "Buy CAKE →"

Regras de negócio

• CTA "Connect Wallet" duplicado: header + widget — ambos abrem o mesmo modal de conexão
• Banner de cross-promo é rotativo (5 dots) — mostra Monad, Solana, Tokenized Assets, etc. (visto em outras telas)
• Toggle de tema no rodapé do footer — não no header
• Preço CAKE persistente no rodapé com CTA de compra — funnel constante para o token nativo
• "AI" como entrada no nav é nova (não comum em DEX) — sinaliza investimento em features AI-driven

🟢 Insight Visão completa da página comunica três decisões consistentes do produto: (1) CTA primário (Connect Wallet) duplicado para garantir conversão — entra pelo widget se está focado em fazer swap, entra pelo header se está navegando; (2) tema light/dark como utility do footer (não preferência crítica que mereça destaque) — calibração correta da hierarquia; (3) presença explícita de "AI" no nav top sinaliza diferenciação de produto, não só comodity DEX. Pancake assume identidade de produto evolutivo.

^insight-1

🔴 Fricção 1 (estrutural — "Buy CAKE" persistente no footer + banner + widget é cross-promo agressivo, afeta iniciante) O usuário desconectado encontra CAKE pre-selecionado no widget (relatório 12), banner rotativo cross-promo (Monad/Solana), e CTA persistente "Buy CAKE → $1.497" no rodapé. Para iniciante que entrou para entender o que é a Pancake, é exposição constante a oferta comercial — passa a impressão de que CAKE é o produto principal, não o swap. Pior: o preço CAKE no rodapé sem contexto temporal ("$1.497 — quanto era ontem?") sugere oportunidade urgente. Solução óbvia que falha: tirar CAKE do widget e do rodapé limpa demais — não comunica que existe o token. Alternativa: pre-selecionar CAKE no widget só em retornos do usuário (depois que ele já fez 1 swap); banner cross-promo limitado a 1 dismissível por sessão; CTA Buy CAKE como item secundário (não persistente). Perfil afetado: iniciante (não distingue produto de cross-promo).

^friccao-1

🔴 Fricção 2 (cosmética — "AI" no nav sem definição visível) O item "AI" no nav é novidade comparado aos concorrentes (Uniswap, 1inch), e está logo após Play (gamificação/farming). Mas o que é "AI" no contexto de DEX? Sugestão de tokens? Chatbot de suporte? Trader automation? Sem hint, o item é gancho de curiosidade sem destino claro — pode atrair o iniciante errado ("AI vai me ajudar a investir?") com expectativa não-cumprida. Direcionamento: badge "BETA" ou "NEW" + tooltip de 1 linha sobre o que é ("Assistente AI da Pancake — explica termos e sugere ações"). Reduz surpresa de aterrissagem.

^friccao-2

🔴 Fricção 3 (estrutural — theme toggle escondido no footer) Theme toggle (sun/moon) é uma das preferências mais usadas em qualquer produto — mas está no rodapé final do footer, descobrível só com scroll completo. Usuário em dark mode/light mode involuntário precisa scrollar a página inteira para encontrar o controle. Em mobile é especialmente custoso. Direcionamento: theme toggle como item do menu de settings (cog do header) ou drawer lateral — sempre acessível. Footer pode manter o toggle como atalho redundante.

^friccao-3

🟡 Oportunidade competitiva (alta leverage no target — wallet-desconectada como tour, não como muro) Uniswap, Pancake e 1inch tratam o estado "wallet desconectada" como muro para conectar (CTA "Connect Wallet" como bloqueio). Para iniciante que ainda não tem wallet ou está avaliando se confia, a única saída é conectar — passo psicológico grande sem ter visto valor primeiro. Passa as 4 perguntas: (1) padrão indústria (todos forçam connect cedo); (2) afeta iniciante diretamente — taxa de conversão de "primeiro contato → wallet conectada" é o gargalo do funil; (3) ninguém resolveu plenamente porque "try before connect" exige cotação sem wallet (overhead técnico) e expõe roteamento sem incentivo financeiro (gas calc, etc.); (4) widget que cota com valores reais SEM exigir wallet é claramente perceptível. Diferenciação Kotai: widget funcional com cotação real e tudo que isso exige (rota, fee, slippage) sem conexão — só pede wallet no momento de confirmar a transação. Plus: estimativa de gas inline mostrando ao iniciante "você vai pagar X em gas para esse swap" antes de conectar — ajuda na decisão de "vale a pena". Trade-off: roteamento de cotação sem wallet exige gas estimate genérico (não personalizado pela wallet), levemente menos preciso. Observação importante: Uniswap já implementa "try before connect" — a Pancake mostrada nesta tela NÃO implementa, exige Connect Wallet para começar. Logo, a oportunidade existe, mas o diferencial sobre Uniswap especificamente é menor — vale só onde Pancake é o concorrente.

Observação adicional (banner Monad como pattern de promoção de chain): o banner "Monad Now Live on PancakeSwap" rotaciona entre 5 promos (visível pelos dots). É vetor de comunicação ativa de novas chains/features. Para Kotai, vale ter consciência: banner rotativo é canal de marketing flexível mas exige curadoria contínua — se rotacionar promos antigas ou irrelevantes, vira ruído. E rotação 5+ em mesma sessão satura.

^oportunidade-1

Codex Consolidado — Adicionar Liquidez (pancake)

Caráter geral do fluxo

O fluxo de Adicionar Liquidez da Pancake tem uma arquitetura tecnicamente consistente, mas orientada demais ao modelo interno do protocolo. A interface antecipa escolhas como Infinity, V3, V2, StableSwap, rede e tipo de pool antes de traduzir o objetivo do usuário em uma recomendação prática. Para quem só quer fornecer liquidez para um par, o primeiro esforço não é operacional; é entender uma taxonomia financeira.

Há boas decisões de proteção contra erro: opções parecem ser filtradas por compatibilidade, e campos não aplicáveis somem conforme o protocolo. O problema recorrente é que a regra por trás dessas mudanças quase nunca aparece. Assim, reduções de lista, desaparecimento de etapas e filtros com poucas opções podem ser interpretados como limitação, bug, simplificação ou decisão financeira, sem que a UI diferencie esses casos.

O risco maior é que escolhas visualmente parecidas representam consequências financeiras diferentes. O fluxo trata seleção de protocolo, tipo de pool e filtro como configuração neutra, mas essas decisões alteram complexidade de gestão, adequação do par, risco e expectativa de uso de capital.

🟢 Insights recorrentes

1. Pancake reduz combinações inválidas antes do usuário avançar

Os drafts indicam que a UI filtra opções conforme protocolo e rede. Em Infinity, o dropdown de rede mostra apenas redes compatíveis em tela 5. Em StableSwap, a árvore de tipo de pool é reduzida para “Classic” em tela 7. Isso evita o padrão mais frustrante de permitir uma seleção para só depois rejeitá-la.

O insight é positivo: existe uma camada de compatibilidade ativa no produto. A fragilidade está na comunicação dessa camada, não necessariamente na regra.

2. A UI tenta adaptar o formulário ao protocolo escolhido

Em vez de manter todos os campos sempre visíveis, Pancake muda a estrutura do card conforme a versão. O passo 3 desaparece em V3/V2 e reaparece em StableSwap, como visto em tela 2 e tela 4. Esconder campos não aplicáveis reduz ruído permanente e sugere que o produto tenta modular o fluxo.

O ganho, porém, depende de explicar o que mudou. Sem feedback contextual, a adaptação parece rearranjo visual, não mudança de regra financeira.

🔴 Fricções recorrentes

1. A escolha de protocolo aparece cedo demais e sem recomendação

A fricção mais estrutural aparece em tela 1, tela 2 e tela 3. O usuário precisa escolher entre Infinity, V3, V2 e StableSwap antes de receber orientação sobre qual versão faz sentido para o par, o perfil de gestão e o risco.

Para iniciantes, isso cria bloqueio cognitivo logo no início. Para intermediários, transfere para o usuário uma comparação que a interface poderia apoiar com sinais de liquidez disponível, volatilidade do par, complexidade e compatibilidade. Tooltips isolados não resolvem totalmente, porque adicionam explicação técnica sobre uma decisão que está mal posicionada.

2. Mudanças dinâmicas de opções e campos não explicam a regra subjacente

O fluxo altera campos e listas conforme protocolo, mas não explicita a causa. O passo 3 some em tela 2 e reaparece em tela 4. A lista de redes fica restrita em tela 5. O filtro de StableSwap conserva uma árvore com um único filho em tela 7.

O padrão recorrente é a UI mostrar o resultado da regra, mas não a regra. Isso força o usuário a inferir se a ausência de opções é normal, se depende do protocolo, se é uma restrição temporária ou se ele fez algo errado. Melhor seria usar microcopy contextual no próprio componente: “Infinity está disponível nestas redes”, “V3 usa taxa/faixa na próxima etapa”, ou substituir filtros sem escolha real por texto informativo.

3. Taxonomias internas e labels técnicos escondem hierarquia de decisão

Em tela 1, tela 4, tela 6 e tela 7, termos como “Tipo de Pool”, “Classic”, “CLAMM”, “LBAMM”, “Dynamic Fees”, “Liquidity Incentivisation” e “Yield Optimisation” aparecem sem camada semântica suficiente.

O problema não é simplesmente haver inglês ou siglas. Alguns termos são reconhecíveis para usuários avançados. A fricção é que categoria, valor, jargão e consequência financeira ficam misturados. Uma camada melhor separaria label primária orientada ao significado, termo técnico como sublabel e, quando houver risco, definição curta com exemplo.

4. Componentes interativos comunicam clique, mas não comunicam peso, estado e obrigatoriedade

O padrão aparece nos dropdowns e filtros. A rede atual não tem destaque claro em tela 5. A árvore de checkboxes mistura níveis hierárquicos em tela 6. A ausência de “opcional” no filtro de StableSwap sugere obrigatoriedade em tela 7, embora a própria escolha pareça sem efeito prático.

Esses sinais compõem uma fricção maior: controles parecem acionáveis, mas não deixam claro o estado atual, a hierarquia entre opções e a relevância real da decisão.

5. Escolhas visualmente parecidas podem levar a decisões financeiramente inadequadas

Tela 3 e tela 4 mostram que versões diferentes podem parecer equivalentes no início do fluxo, embora impliquem gestão, risco e adequação distintos. O caso mais crítico é StableSwap aceitar BNB+CAKE sem alerta em tela 4, apesar de StableSwap ser associado a ativos correlacionados.

Aqui a fricção deixa de ser só compreensão e passa a tocar perda financeira potencial. O alerta precisa aparecer no momento da escolha, com validação de adequação par↔protocolo e override explícito quando fizer sentido.

🟡 Oportunidades competitivas

1. Entrada por intenção com recomendação de protocolo

A oportunidade mais forte é inverter a ordem mental do fluxo: começar pelo que o usuário quer fazer, pelo par escolhido e pelo perfil de gestão, e só então recomendar Infinity, V3, V2 ou StableSwap. A fonte de tela 1 indica que essa oportunidade passa nas quatro perguntas-teste: concorrentes tendem a expor a mesma taxonomia cedo, o problema afeta iniciantes e intermediários, a lacuna persiste porque os produtos priorizam o modelo interno do protocolo, e a diferença seria perceptível no uso.

A vantagem competitiva não seria apenas explicar melhor cada versão. Seria transformar uma escolha técnica em uma decisão assistida: “para este par e este objetivo, esta opção tende a ser mais adequada”. Isso reduziria paralisia inicial e criaria uma experiência mais consultiva sem remover controle de usuários avançados.

2. Validação de adequação entre par e protocolo

A segunda oportunidade é validar a compatibilidade econômica do par com o protocolo escolhido antes de o usuário avançar. Em tela 4, o caso BNB+CAKE em StableSwap concentra o risco: a interface permite uma combinação que pode ser inadequada para a expectativa associada a StableSwap, sem alerta proporcional.

Essa oportunidade também passa nas quatro perguntas-teste nas fontes: o padrão de mercado ainda trata a escolha como configuração, afeta diretamente usuários que não dominam diferenças entre pools, não é resolvido porque exige traduzir regra financeira em UX, e seria percebido imediatamente quando o produto sinalizasse “este par não parece adequado para StableSwap” com opção de override explícito. É uma melhoria de alto leverage porque atua antes da perda potencial, não depois da confirmação.

Pontos isolados (1 tela)

• Tela 3: “V2/V3” pode sugerir progressão linear e fazer V3 parecer automaticamente superior. Forte como hipótese, mas não recorrência autônoma nos drafts.
• Tela 4: mistura PT-EN em “StableSwap” e “Classic” tem peso baixo quando o termo é nome de produto, mas “Classic” poderia ser tratado como valor traduzível.
• Tela 6: filtro avançado marcado como opcional ainda intimida, porque abrir o controle revela uma árvore técnica difícil de avaliar.
• Tela 7: filtro com uma única opção é dead UI; a solução mais forte é esconder o passo enquanto não houver escolha real.

Nota de auditoria Codex

Este consolidado preserva a estrutura geral aprovada no review, corrige os wikilinks que miravam anchors inexistentes e incorpora a camada estratégica 🟡 exigida pela régua. As oportunidades competitivas foram adicionadas quando as fontes indicavam passagem nas quatro perguntas-teste; demais recomendações permanecem como direções de correção dentro das fricções.