14. Posição Populada — Ajuste de Max price recalcula ratio dinamicamente

Função: demonstra a relação range ↔ ratio de capital ao vivo. User aumentou Max price de 2504,9182 (Tela 13) pra 2942,466 (~32% acima do preço atual). USDC permanece em 1000, mas ETH subiu de 0,205 pra 0,458 — produto recalculou automaticamente. Chart no topo mostra banda azul estendida pra direita (Max maior = mais espaço acima do preço). Provavelmente capturado pra evidenciar a mecânica de re-cálculo.

Componentes (diff em relação à Tela 13)

• Chart visível no topo (com toggles 1D / 1W / 1M / 1Y / All time + Reset) — banda azul mais larga pra direita que na Tela 13.
• Current price na header do chart: 2.233,08 USDC/WETH ($2.233,08) (inalterado).
• Section Price strategies colapsada/visível na transição.
• Inputs de range:
  • Min price = 1706,2113 (inalterado, −24% do preço atual).
  • Max price = 2942,466 (mudou, +32%).
• Section Deposit tokens:
  • 1000 USDC (inalterado, $1.000,00).
  • 0,45830405644617936 ETH (recalculado, ~`$1.082,29`).
• CTA Review ativo.

Regras de negócio

• USDC = âncora, ETH = derivado. O input que não foi tocado (USDC = 1000) é tratado como fixado; ETH recalcula pra manter ratio coerente com novo range.
• Aumentar Max (mais espaço acima do preço atual) → mais ETH necessário. Lado-ETH da curva agora cobre faixa maior → mais token-de-cima é depositado.
• Total de capital sobe ($1.487 → $2.082) porque ETH dobrou; user pode reduzir USDC pra rebalancear.
• Re-cálculo é instantâneo (sem botão "Recalcular") — sem latência percebida.

---

🟢 Insight 1 — Re-cálculo ao vivo torna a relação range ↔ exposição em token evidente sem texto. Tela 13 mostrava 0,205 ETH; Tela 14 mostra 0,458 ETH após aumentar Max. User decoda em 1 segundo: "quanto mais espaço pra cima, mais ETH preciso". Sem tooltip, sem FAQ. Padrão a herdar pra Kotai — feature mecânica complexa virou pedagogia por demonstração (a mesma lógica do Insight 1 da Tela 13, agora observável em sequência).

🟢 Insight 2 — Latência zero do re-cálculo carrega sinal de qualidade técnica. Mudar input de Max e ver o ETH ajustar instantaneamente (sem spinner, sem "recalculando…") sinaliza que o cálculo é client-side. User power percebe e confia; user iniciante não percebe mas se beneficia da fluidez. Padrão a herdar — cálculos de produto financeiro devem rodar client-side quando matematicamente possível.

🟢 Insight 3 — Chart sincroniza com input numérico — banda azul redesenha conforme Max price muda. Não há "Atualizar chart" — mudar input redesenha visualização. As 3 vias de input (chart-drag, preset, input numérico) compartilham estado único. Padrão a herdar — múltiplas vias de input devem refletir mesmo estado bidirecional, sempre.

---

🔴 Fricção 1 — Ao aumentar Max, ETH subiu silenciosamente de $487 pra $1.082 — user precisa reagir (estrutural — re-cálculo modifica capital sem alerta)

• Atrito real: user tinha definido depósito como $1.487 total ($1.000 + $487). Ao mover Max pra cima, o produto aumentou o custo total pra $2.082 ($1.000 + $1.082) sem alerta. User pode não ter $2.082 em wallet — vai descobrir só no Review (Tela 16 presumível) ou pior, em "insufficient balance" no submit. Insight 1 (educativo) tem custo invisível.
• Por que a solução óbvia falha: travar o capital total impede explorar ranges (cada mudança de range é mudança de capital — é a feature); modal "Você precisará de mais $595" toda vez é fricção pesada.
• Alternativa: mostrar o total dinamicamente com delta visível — header colapsado acima dos inputs com Total a depositar: $2.082,29 (+$595 vs antes). Delta colorido (vermelho se aumentou, verde se diminuiu). User vê instantaneamente o impacto financeiro de cada ajuste de range. Trade-off: mais um number na tela; ganho: zero surpresa de capital no Review.
• Perfil afetado: iniciante (principal — único que perde controle de capital ao explorar range) + intermediário descuidado.
• Família com 🔴 "Sticky footer com resumo" (PosPop #13) — extensão direta: o footer deveria mostrar delta a cada mudança, não só total estático.

🔴 Fricção 2 — 0,45830405644617936 ETH em 17 casas decimais é honestidade que vira ruído visual (cosmética — precisão sem propósito visível pro user)

• Atrito real: Tela 13 tinha esse number como Insight 2 (precisão honesta). Aqui, com user explorando ranges (não finalizando), o number gigante distrai. User está em modo "experimentar", e ler 0,45830405644617936 é trabalho cognitivo. Iniciante pode pensar "preciso digitar isso tudo? esse é o number real?".
• Por que a solução óbvia falha: truncar pra 0,4583 perde precisão de Insight 2 da Tela 13; mostrar só ($1.082,29) esconde o token amount.
• Alternativa: mostrar ETH amount truncado por default (5 casas: 0,45830) com tooltip on-hover mostrando precisão completa. Botão "Copiar valor exato" no tooltip pra avançado. Trade-off: esconde precisão real; ganho: foco no ($1.082,29) que é a leitura humana.
• Perfil afetado: iniciante (principal) + intermediário em modo exploratório.
• Família invertendo Insight 2 da Tela 13 — mesma feature (precisão completa) é insight num contexto (finalização) e fricção em outro (exploração).

🔴 Fricção 3 — Não há "snapshot" do estado anterior pra comparar configs (estrutural — produto não oferece comparação entre escolhas)

• Atrito real: user testou Tela 13 (Max 2504, ETH 0,205, total $1.487) e agora testa Tela 14 (Max 2942, ETH 0,458, total $2.082). Pra comparar qual é melhor, precisa lembrar dos numbers da config anterior de cabeça. Nenhum "histórico de tentativas" ou "fixar essa config". Decisão final fica por intuição do que ele lembra.
• Por que a solução óbvia falha: histórico completo polui; só botão Undo é insuficiente.
• Alternativa: botão Salvar esta config que cria card-comparador lateral. User pode salvar 2–3 configs, ver lado a lado: Config A: ±12% range, $1.487, APR estimado X% / Config B: ±32% range, $2.082, APR estimado Y%. Escolhe a melhor antes de Review. Trade-off: mais UI; ganho: decisão informada por comparação concreta, não memória.
• Perfil afetado: iniciante (principal) + intermediário explorando.
• Família com 🟡 "Backtest visual" (PosPop #12), "Slider probabilístico" (PosPop #11), "Brushable curve" (PosPop #3). Todas as oportunidades convergem em "produto deve suportar exploração comparativa, não só decisão linear".

---

🟡 Oportunidade competitiva — Modo "Capital fixo" como inversão do default

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3 — default = ratio fixado pelo range. User define range, capital recalcula. Em outros produtos cripto (Aave, Compound), default é o oposto: user define capital, sistema otimiza alocação. Uniswap não oferece esse modo.
• Por que afeta o target: iniciante chega com mental model "tenho $X — onde aporto?". Forçar ele a definir range primeiro (e ver capital flutuar) inverte o problema dele. Intermediário com tese de range vai bem; iniciante com tese de capital se confunde.
• 4 perguntas-teste: (1) ✓ todos os concorrentes v3 usam mesmo paradigma "range define capital" (2) ✓ afeta iniciante direto (3) ✓ razão = paradigma herdado da semântica matemática de v3, não da intenção do user (4) ✓ ganho perceptível — user define Total $1.000, sistema sugere range que cabe com APR ótimo.
• Hipótese de diferenciação: toggle "Modo de exploração" no topo do Step 2 — Por range (avançado) (default Uniswap) vs Por capital (sugerido) (Kotai default). Em modo "Por capital", user define $X total + perfil de risco (conservador/equilibrado/agressivo), sistema sugere range ótimo. User vê range no chart e pode ajustar. Inversão respeita mental model fiat.
• Trade-off: segundo paradigma exige UI duplicado; modo "Por capital" precisa de heurística (qual range maximiza APR pra $X?) — pode ser otimista demais. Aceitar com caveat.
• Leverage estrutural alto — converte produto v3 em produto acessível a quem pensa em $, não em ticks. Família consolidada "decisão em linguagem do user, não do protocolo". Diferenciador grande contra Uniswap.

---

Observação adicional — Tela 14 confirma que Min ficou inalterado entre 13→14. User só mexeu em Max. Isso valida a hipótese de re-cálculo one-at-a-time: editar um input fixa outro, recalcula o terceiro. Padrão arquitetural simples (input editado = âncora; tokens recalculam) que evita o problema clássico de "todos os campos dançam em loop". Kotai deve herdar — em formulários acoplados matematicamente, definir explicitamente qual input é âncora a cada momento.

13. Posição Populada — Step 2 com Min/Max + Deposit tokens (ratio calculado)

Função: continuação do Step 2 com range custom finalizado via inputs numéricos (Min price / Max price preenchidos) e section Deposit tokens revelada abaixo. Esta é a tela onde a decisão de range vira decisão de capital — produto calcula o ratio de USDC e ETH automaticamente com base no range escolhido + preço atual. CTA Review ativo (rosa) — Step 2 está pronto pra revisar.

Componentes

• Stepper: Step 1 e Step 2 ambos com check (Step 2 marcado completo).
• Section Price strategies ainda visível acima (vide Tela 11/12).
• Inputs de range:
  • Min price = 1706,2113 + controles − +.
  • Max price = 2504,9182 + controles − + + sufixo +12,17% (delta vs preço atual? vide Observação).
• Section Deposit tokens com subcopy "Specify the token amounts for your liquidity contribution":
  • Input 1: 1000 + ($1.000,00) + ícone USDC + ticker USDC.
  • Input 2: 0,20528138691144813 + (~$487,10) + ícone ETH + ticker ETH.
• CTA primário: Review (rosa, ativo) ocupando full-width no rodapé.

Regras de negócio

• Range definido por inputs numéricos = 3ª via (além de drag-no-chart e preset). Funciona em par-ordem USDC/WETH (preço de WETH em USDC, leitura humana de $/ETH — o user inverteu via toggle na Tela 11).
• Ratio é função do range, não do user. Editar 1 input recalcula o outro. Capital total = soma livre, mas proporção é fixa pelo range + preço atual.
• Em range assimétrico (1706 / 2504 com preço atual ~$2.233), a fórmula privilegia o lado com mais espaço. Aqui Max está mais distante do preço atual (~12% acima) que Min (~24% abaixo), então mais USDC entra por unidade de ETH.
• Min price aceita −/+ em incrementos discretos (tick mínimo). Trocar via input livre arredonda pro tick mais próximo.
• Botão Review ativa quando: range válido (min < max) + pelo menos 1 input de token > 0.

---

🟢 Insight 1 — Ratio calculado automaticamente é a melhor pedagogia possível sobre concentrated liquidity. Iniciante não precisa entender a fórmula (L = sqrt(P) · ...) — vê na prática: "se eu colocar $1000 USDC, preciso de $487 em ETH pra esse range". A relação range ↔ exposição vira evidente via observação, não via texto. Padrão a herdar pra Kotai: feature matemática complexa que pode ser demonstrada por re-cálculo ao vivo > feature explicada por tooltip.

🟢 Insight 2 — 0,20528138691144813 ETH em 17 casas decimais é honestidade brutal sobre precisão de cálculo. Number completo expõe que o produto não arredondou — você está depositando exatamente isso. Avançado aprecia (sem surpresa downstream); iniciante estranha mas não sofre (($487,10) ao lado dá a leitura humana). Padrão a herdar — exibir precisão completa + alias humano em paralelo. Esconder casas decimais introduz dúvida ("o produto está arredondando o que cobra de mim?").

🟢 Insight 3 — ($1.000,00) e (~$487,10) em USD ao lado dos amounts ancora o user em moeda fiat. Iniciante pensa em "$1000", não em "1000 USDC". Cripto-nativo já sabe que USDC ≈ $1, mas pares como ETH/WBTC precisam disso desesperadamente. Padrão a herdar — todo input de token exibe equivalente USD ao lado, mesmo em pares que parecem óbvios (USDC).

🟢 Insight 4 — Review em vez de Confirm no CTA primário sinaliza que ainda haverá tela de revisão. Step 2 termina em "Review", não em "Approve" ou "Sign". User sabe que tem mais 1 passo antes do compromisso on-chain. Reduz ansiedade de "esse é o botão final?". Padrão a herdar — labels de CTA devem refletir consequência (review ≠ commit).

---

🔴 Fricção 1 — Ratio calculado automaticamente sem explicar por que os números são esses (estrutural — re-cálculo ao vivo sem narração)

• Atrito real: user vê 1000 USDC + 0,205 ETH. Por que 0,205? Por que não 0,447 (50/50 em valor)? Por que não 0,1 (range muito assimétrico privilegia USDC)? Insight 1 acima é verdadeiro mas incompleto — o user vê o resultado, não entende o mecanismo. Em range balanceado parece 50/50; em range assimétrico parece arbitrário. Iniciante pensa "o produto está me fazendo comprar menos ETH do que eu queria — bug?".
• Por que a solução óbvia falha: explicar fórmula L = sqrt(P) · (1 - sqrt(Pa)/sqrt(Pb)) afasta iniciante; mostrar tooltip "É calculado automaticamente" não explica nada.
• Alternativa: microcopy contextual sobre o ratio — uma frase abaixo dos inputs: "Seu range está mais largo pra baixo do preço atual — por isso a posição usa mais USDC que ETH. Como o preço atual é ~$2.233, capital se distribui automaticamente." Texto adaptativo ao range escolhido. Trade-off: exige geração dinâmica de texto; ganho: iniciante decoda o "por quê" sem precisar de FAQ.
• Perfil afetado: iniciante (principal) + intermediário sem mental model de concentrated liquidity.
• Família com 🔴 "Default por TVL sem amarrar a estratégia" (PosPop #7) — mesma raiz: produto computa decisão correta mas não narra o raciocínio.

🔴 *Fricção 2 — Botão Review full-width no rodapé sem resumo do que está sendo revisado (cosmética-estrutural — transição abrupta entre input e review)

• Atrito real: user preenche inputs, clica Review, vai pra próxima tela. Mas e se ele errou? Review deveria implicar "vou conferir antes" — mas a passagem é cega, sem preview. Iniciante pode clicar achando que já depositou (CTA primário rosa parece "commit").
• Por que a solução óbvia falha: mostrar tela de review é exatamente o que vem depois (Tela 16/17 presumidamente); transformar Review em sticky-footer-with-summary infla UI.
• Alternativa: sticky footer compacto que aparece quando inputs estão completos — mostra Total: ~$1.487,10 · Range: ±12% · APR estimado: X% · [Review →]. User vê o resumo na própria tela de input, antes de ir pra próxima. Reduz medo de "essa transição é final?". Trade-off: mais real estate no rodapé; ganho: zero clique de review puro pra checar.
• Perfil afetado: iniciante (principal — único que confunde Review com Submit).
• Família com 🟡 "Card de pré-visualização" (Nova Posição #2) — mesma raiz: produto deveria mostrar contrato implícito (o que vai acontecer) antes de cada transição.

🔴 Fricção 3 — Inputs Min price e Max price ficam separados da section Deposit tokens sem amarração visual explícita (cosmética — relação acoplada mostrada em sections desconectadas)

• Atrito real: Min price / Max price (range) e 1000 USDC / 0,205 ETH (depósito) são acoplados matematicamente (mudar range muda ratio). Mas estão em sections visuais separadas: range no meio, deposit abaixo. User pode mudar range no input e não notar que o depósito recalculou. Re-cálculo ao vivo (Insight 1) perde efeito se o user não está olhando pros dois ao mesmo tempo.
• Por que a solução óbvia falha: mover tudo pra section única gera lista longa; manter separado preserva legibilidade.
• Alternativa: flash animado (pulse rosa) no input de token toda vez que ele recalcula em resposta a mudança de range. Sinal visual de "atenção: esse number mudou por causa daquilo". Trade-off: animação pode irritar em uso power; oferecer toggle em settings.
• Perfil afetado: iniciante (principal).

---

🟡 Oportunidade competitiva — Mostrar capital eficiency vs full range ao lado do ratio

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3, KyberSwap — calculam ratio mas não comparam com baseline. User não sabe se "0,205 ETH + 1000 USDC = $1487" é caro ou barato pra cobrir esse range. Sem âncora.
• Por que afeta o target: iniciante quer saber "estou economizando capital vs full range?". Concentrated liquidity tem como principal vantagem menor capital pra mesma cobertura. Produto não comunica esse ganho.
• 4 perguntas-teste: (1) ✓ todos os concorrentes mostram ratio sem comparação (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = comparação exige cálculo de baseline + caveat; falta de investimento (4) ✓ ganho perceptível — user vê "Esse range usa $1.487 — em full range, equivalente custaria $14.000 (10× capital)".
• Hipótese de diferenciação: linha extra abaixo do total — "Capital eficiency: 10× vs full range" + mini-bar comparando o capital escolhido ($1.487) vs equivalente full range ($14.000). User decoda "esse range concentra meu capital em 10×" — entende valor de v3 em concreto.
• Trade-off: baseline "full range" é uma abstração; user pode confundir com "se eu colocar $1.487 em full range, rendo o mesmo?". Microcopy precisa clarificar: "Pra cobrir esse range em full range, precisaria de 10× mais capital".
• Leverage estrutural — converte feature técnica (concentrated) em number persuasivo. Família consolidada com 🟡 "APR estimado por range" (PosPop #1), "Slider probabilístico" (PosPop #11), "Health Score" (PosPop #5). Aqui é a manifestação no momento de commitment de capital — last point of education antes de depositar.

---

Observação adicional — +12,17% ao lado do Max price. Indicador delta vs preço atual: max é 12,17% acima de $2.233. Decisão de produto boa — ancora o user em "quanto acima/abaixo" sem precisar fazer conta. Vale herdar pra Kotai: inputs de range numéricos sempre exibem delta vs preço atual ao lado (como já fizemos via markers no chart, agora também no input). Coerência visual em dois lugares (chart + input) reforça mental model.

16. Posição Populada — Modal "Create position" (review pré-submit on-chain)

Função: modal de revisão final que sobrepõe (overlay translúcido sobre o Step 2) ao clicar Review na Tela 13/14/15. É o último ponto de checagem antes da transação on-chain — depois do Create aqui, vai pra confirmação da wallet (Tela 17). O modal agrupa em um card único: header com par/fee, mini-thumbnail do range, recap de Min/Max, recap de Deposit amounts, e botão Create rosa. Mantém Step 2 visível por trás (com chart e inputs) — user pode dispensar e ajustar sem perder estado.

Componentes

• Background: Step 2 visível atrás (chart + inputs) em translucidez (overlay escuro).
• Modal centralizado com header:
  • Par + ícones: USDC / ETH + version + fee tier.
• Mini-thumbnail do range (chart compacto repetindo a visualização do Step 2 com banda azul) — preview do range escolhido.
• Linha de Min/Max abaixo do thumbnail:
  • Min Price: valor numérico (presumivelmente 1.706,21 USDC/WETH herdado da Tela 13).
  • Max Price: valor numérico (presumivelmente 2.504,92 ou 2.607,14 herdado).
• Section Depositing:
  • 1000 USDC + ícone USDC.
  • 0,237682839… ETH + ícone ETH (note: difere ligeiramente dos valores das Telas 13–15 — provavelmente o user re-ajustou range pra Max realista antes do Review; ver Observação).
• Toggle ou ação de Create rosa primário.
• Abaixo, blocos repetidos de inputs (1000 USDC / 0,237682834929249…ETH) com CTA Review ainda visível — provavelmente o modal está empilhado sobre o Step 2, ambos parcialmente visíveis na captura.

Regras de negócio

• Modal não chama transação ainda — clicar Create dispara o prompt da wallet (Tela 17), só então a transação é assinada.
• Mini-thumbnail do range serve de "double-check visual" pra evitar erro de range em texto/number — leitura geométrica > leitura numérica em momento de commit.
• Tokens depositados aparecem como número exato (igual ao Step 2) — produto não arredonda pra exibir números "redondos".
• Modal preserva contexto: Step 2 fica atrás (overlay) pra user poder cancelar e voltar com tudo preenchido.

---

🟢 Insight 1 — Mini-thumbnail do range no modal é tradução de número em geometria — exatamente o que iniciante precisa no momento de commit. Iniciante leu Min 1706 / Max 2504 no Step 2; aqui vê o range como forma. Se ele errou range na Tela 13 (digitou Max errado), o thumbnail denuncia visualmente. Pedagogia anti-typo. Padrão a herdar pra Kotai — toda confirmação de transação deve incluir representação visual da decisão (chart, ícone, badge), não só números repetidos.

🟢 Insight 2 — Step 2 visível por trás do modal preserva escape e contexto. User pode "voltar" mentalmente pra checar input específico sem fechar o modal. Diferente de full-screen review (que apaga contexto). Decisão deliberada — modal sem perder estado. Padrão a herdar — overlay translúcido > nav transition em ações reversíveis.

🟢 Insight 3 — Create como CTA primário, não Submit ou Confirm. Vocabulário do produto: você está criando uma posição, não "submetendo uma ordem". Reforça mental model de LP (long-term, é seu) vs trader (transação isolada). Padrão a herdar — labels de CTA devem traduzir intent semântica, não verbo genérico.

🟢 Insight 4 — Modal centralizado e estreito (não full-screen) sinaliza "isso é uma decisão, não um destino". Full-screen review (típico de checkout fintech) implica "você está numa nova página"; modal centrado implica "é um modal de confirmação — clique e siga". Reduz ansiedade. Padrão a herdar — escolha modal vs full-page reflete peso percebido da ação.

---

🔴 Fricção 1 — Modal de review não mostra APR estimado, fees esperados, ou impermanent loss projetado — apenas restate dos inputs (estrutural — último ponto educativo desperdiçado em mero recap)

• Atrito real: o modal mostra 1000 USDC + 0,237 ETH no range 1706–2504. User já viu isso no Step 2. O modal não adiciona informação nova — só repete. Mas esse é literalmente o último ponto em que o produto pode educar antes do commit on-chain. Numbers críticos ausentes: APR estimado pra esse range, fees esperados em 30d, % chance de ficar in-range, IL estimado se preço se mover ±X%. Em vez disso, o modal serve só pra confirmar que o user não errou typing. Oportunidade perdida.
• Por que a solução óbvia falha: adicionar todas as métricas infla modal e mata clareza do "olha o que você está prestes a fazer"; calcular APR/IL exige modelo.
• Alternativa: adicionar 1 bloco "What to expect" abaixo do Deposit com 3 numbers ancorados: "APR estimado: X% / Fees esperados (30d): ~$Y / % chance in-range (24h): Z%". Não decora o modal; ancora expectativa. Trade-off: exige cálculo client-side; risco de promessa quebrada. Aceitar com caveat "Estimativa baseada em últimos 30 dias".
• Perfil afetado: iniciante (principal — único que confia no produto pra trazer essas estimativas) + intermediário sem ferramenta externa.
• Família com 🟡 "APR estimado por range" (PosPop #1), "Health Score" (PosPop #5), "Capital efficiency vs full range" (PosPop #13). O modal de review é o slot natural pra todas essas oportunidades convergirem — é onde o user mais precisa da informação completa e onde ele tem ciclo cognitivo dedicado a absorver.

🔴 Fricção 2 — Create é label ambíguo na fronteira on-chain — não diz se aciona wallet sign ou se deposita diretamente (estrutural — verbo de commit não esclarece se há mais uma etapa)

• Atrito real: user clica Create. O que acontece? (a) Wallet abre prompt de assinatura (correto — Tela 17). (b) Posição é criada direto. (c) Tx é enviada e some sem feedback. Sem antecipação, user pode (a) clicar pensando que é commit final e se assustar com prompt da wallet (especialmente em mobile, onde o switch de contexto é abrupto), (b) clicar duas vezes pensando que não funcionou. Vocabulário cripto-nativo cobre esse caso com Sign in wallet → ou Confirm in wallet →.
• Por que a solução óbvia falha: Sign in wallet é jargão pra iniciante (o que é wallet sign?); Create é claro mas omite a etapa intermediária.
• Alternativa: Create position (1 wallet signature required) → — label autodescritivo + indicação do próximo passo. Trade-off: label longo; ganho: zero surpresa.
• Perfil afetado: iniciante (principal — primeira vez com wallet prompt).
• Família com 🔴 "Review como CTA sem resumo" (PosPop #13) — mesma raiz: produto deveria antecipar próxima etapa no label do CTA atual.

🔴 Fricção 3 — Captura mostra dois CTAs primários simultâneos (Create no modal + Review no Step 2 atrás) (cosmética-estrutural — overlay translúcido revela ambiguidade visual)

• Atrito real: com overlay translúcido (Insight 2), Step 2 fica visível por trás com Review rosa ainda renderizado. User vê dois botões rosa primários ao mesmo tempo: Create (modal) e Review (background). Iniciante pode clicar no errado — especialmente em viewport mobile onde os dois ficam próximos visualmente. Modal deveria escurecer ou desabilitar visualmente o CTA do background.
• Por que a solução óbvia falha: opacar 100% o background perde Insight 2 (escape contextual); manter como está cria ambiguidade.
• Alternativa: desaturar o Review background (cinza translúcido em vez de rosa) — visível mas "desligado". Modal foreground mantém rosa pleno. Trade-off: exige re-render condicional; ganho: zero ambiguidade de CTA.
• Perfil afetado: iniciante (principal).

---

🟡 Oportunidade competitiva — Review como "contrato visual" do que vai acontecer (incluindo cenários adversos)

• Padrão da indústria: Uniswap (esta tela), PancakeSwap, Curve — review é recap de inputs + CTA. Não simulam consequência. User confirma os números, assina wallet, posição é criada. Se preço se mover 10% no dia seguinte, user descobre IL no portfolio.
• Por que afeta o target: iniciante não tem mental model de "o que acontece com minha posição se preço sobe/cai/explode/cai 50%". Produto pode mostrar 3 cenários simulados antes do commit.
• 4 perguntas-teste: (1) ✓ todos os concorrentes fazem review como recap (2) ✓ afeta iniciante e intermediário (3) ✓ razão = simulação de cenários exige modelo + UI extra; falta de investimento (4) ✓ ganho perceptível — user vê 3 cards: "Se preço fica estável: você ganha $X em fees / Se preço sobe 30%: posição vira 100% USDC, IL ~$Y / Se preço cai 20%: posição vira 100% ETH, IL ~$Z".
• Hipótese de diferenciação: section "Cenários (próximos 30 dias)" dentro do modal — 3 cards com (a) estável, (b) +20%, (c) -20%. Cada card mostra valor final da posição + ganho/perda em fees + IL. Não substitui o Create, complementa. User commit com mental model calibrado.
• Trade-off: simulação pode dar overconfidence ou underconfidence (qual cenário "ancorar"?); risco de assustar iniciante ("vou perder dinheiro se preço cair?") — mas isso é honestidade necessária.
• Leverage estrutural alto — converte commit de "assinar contrato cego" em "assinar contrato com expectativa calibrada". Família consolidada "honestidade ativa" (PosPop #5, #10, #11). É o ponto mais estratégico do flow pra Kotai diferenciar — quem entrega cenários antes do commit ganha o usuário pro longo prazo.

---

Observação adicional — depósito de 0,237682834… ETH no modal indica que user re-ajustou Max entre Tela 15 e Tela 16. Tela 13 = 0,205 ETH; Tela 14 = 0,458 ETH; Tela 15 = 0,274 ETH. Modal = 0,237 ETH. Trajetória de exploração: aumentou Max → diminuiu → re-calibrou. Sinal valioso: o flow real tem múltiplas idas-e-voltas no Step 2 antes de chegar no Review. Vale herdar pra Kotai: o "Modo de exploração" (PosPop #14 oportunidade) deve suportar essa pingue-pongue sem fricção. Histórico de tentativas (PosPop #14 fricção 3) seria o complemento perfeito — user veria "você testou 3 configs antes, qual quer reusar?".

15. Posição Populada — Max price extremamente alto (range degenera em "one-sided lower")

Função: user definiu Max price em valor extremo (26071406 — provavelmente 2.607,1406 com vírgula perdida no display, ou input absurdo testando limite). Min permanece em 1706,2113. Re-cálculo: ETH caiu de 0,458 (Tela 14) pra 0,27425… (~$648). Comportamento contraintuitivo se lido como "Max maior → mais ETH" — mas matematicamente correto: range tão largo pra cima vira quase one-sided lower, capital concentra em USDC (lado abaixo do preço atual), ETH-side fica diluído por uma faixa enorme.

Componentes (diff em relação à Tela 14)

• Chart no topo (igual setup que Tela 14): banda azul agora se estende muito mais à direita.
• Inputs de range:
  • Min price = 1706,2113 (inalterado).
  • Max price = 26071406 (input ambíguo — vide nota abaixo) ou plausivelmente 2.607,1406 com separador removido no render.
• Section Deposit tokens:
  • 1000 USDC (inalterado).
  • 0,27425424248181698196… ETH (recalculado para baixo).
• CTA Review permanece ativo (range válido — só absurdo).

Regras de negócio

• Em concentrated liquidity, ratio depende de sqrt(P) em relação aos sqrt(Pa)/sqrt(Pb) (bounds). Quando Pb (Max) → ∞, ratio tende a "tudo USDC" pq lado-ETH cobre faixa quase infinita — capital fica diluído.
• Min 1706 está abaixo do preço atual $2.233 → range cobre território onde ainda há USDC (preço caindo deixa o pool comprando ETH com USDC). Max extremo → ETH-side fica residual.
• Re-cálculo aceita qualquer Max válido (Max > preço atual, Max > Min). Não há cap de plausibilidade.
• Total a depositar: $1.000 + $648 = $1.648 — menor que Tela 14 ($2.082) apesar de range mais largo. Contraintuitivo.

---

🟢 Insight 1 — Re-cálculo aceita inputs extremos sem quebrar — robustez técnica. User pode digitar Max=∞ (ou número absurdo) e o cálculo entrega resultado coerente (ETH residual, capital concentrado em USDC). Sem crash, sem erro, sem "valor inválido". Padrão a herdar pra Kotai — calculadora financeira deve ser robusta a inputs ruins, mesmo quando o usuário está errando.

🟢 Insight 2 — Total cai ($2.082 → $1.648) ao aumentar Max, demonstrando que range maior ≠ capital maior. Comportamento contraintuitivo é também pedagógico: user vê que ETH residual = posição one-sided lower = menos capital pra cobrir lado-ETH. Mostra na prática a forma da curva. Padrão a herdar — quando matemática é contraintuitiva, o produto deve deixar o user experimentar (não bloquear, não esconder); experiência ensina mais que tooltip.

---

🔴 Fricção 1 — Produto aceita Max = 26.071.406 sem questionar plausibilidade (estrutural — guard-rail ausente em input com consequência real)

• Atrito real: Max = 26 milhões de USDC por ETH é absurdo (ETH a $26M = market cap maior que ouro). Quase certamente erro de typing (faltou vírgula, ponto, ou backspace). User aperta Review (ainda ativo!), passa pra tela final, deposita capital, e fica com posição que nunca atinge o lado-ETH — ETH no pool fica congelado até preço chegar a $26M (nunca). Capital travado. Pior caso de UX em DeFi: silêncio do produto + decisão irreversível.
• Por que a solução óbvia falha: validação rígida (Max ≤ 10× preço atual) elimina apostas legítimas extremas (LP com tese de "ETH a $50K em 5 anos"); modal "Tem certeza?" toda vez é fricção.
• Alternativa: warning inline contextual quando Max excede heurística de plausibilidade — "⚠ Max = $26.071.406 é mais de 1.000× o preço atual. Tem certeza? Provavelmente sua liquidez no lado-ETH nunca será usada." + botão Manter valor / Reduzir pra 10× / Editar. Não bloqueia, mas exige confirmação informada. Trade-off: exige heurística de "absurdo"; risco de falsos positivos em apostas legítimas. Aceitar com toggle "Não mostrar de novo".
• Perfil afetado: iniciante (crítico — único que entra com typo) + intermediário descuidado.
• Família com 🔴 "Range assimétrico mal-balanceado aceito sem comentário" (PosPop #11) — mesma raiz: produto valida sintaxe (min < max), não valida semântica (range faz sentido?). Em produto financeiro com consequência on-chain, validação semântica é guard-rail essencial.

🔴 Fricção 2 — Display de Max price sem separadores de milhar transforma erro em ambiguidade (cosmética — formatação numérica pobre)

• Atrito real: 26071406 é lido como (a) 26 milhões, (b) 2,6 milhões, ou (c) 2607.1406? Sem separador (26.071.406 ou 26,071,406 ou 2.607,1406), o user que digitou erra duas vezes: na entrada e na revisão. Em locale PT-BR, . é milhar; em EN, , é milhar. O display nu é ambíguo.
• Por que a solução óbvia falha: formatação automática durante input atrapalha (cursor pula); sem formatação, leitura erra.
• Alternativa: input numérico com formatação on-blur — durante digitação, mostra raw; ao perder foco, formata (26.071.406 em PT-BR, 26,071,406 em EN). Display do Max price exibido sempre formatado com separador local. Trade-off: exige detecção de locale + formatação ao salvar; ganho: zero ambiguidade visual.
• Perfil afetado: todos os perfis.
• Família com 🔴 "i18n EN/PT-BR descosturado" — extensão: formatação numérica é parte da i18n, não só tradução de strings.

🔴 Fricção 3 — ETH em 20 casas decimais (0,27425424248181698196…) ultrapassa precisão útil em pixel screen (cosmética — overflow textual)

• Atrito real: 0,27425424248181698196 excede largura do input mobile e desktop em grande parte dos viewports; o número vaza, é truncado com …, ou quebra layout. Em modo exploratório (user mexendo em range), o input dança visualmente cada vez que ETH recalcula. Distração estética em momento crítico.
• Por que a solução óbvia falha: truncar arbitrariamente esconde valor real; expandir input quebra grid.
• Alternativa: truncar display pra 0,2742542424… (10 casas) com … clicável que expande para precisão completa em popover. Aceita "Copiar valor exato" no popover. Trade-off: esconde precisão visualmente; aceitar pela legibilidade — quem precisa do exato clica.
• Perfil afetado: todos os perfis.
• Família com 🔴 "17 casas decimais como ruído" (PosPop #14) — extensão: o problema piora quando re-cálculos ficam mais extremos. Trunca + expand on-demand é o padrão correto.

---

🟡 Oportunidade competitiva — Validação semântica + sanity check em inputs de range/capital

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3, KyberSwap — validam só sintaxe dos inputs (min < max, valor > 0). Não validam semântica ("esse range faz sentido?", "esse Max é absurdo?"). Resultado: user comete erros caros (capital travado, range degenerado, fee tier desalinhado) sem aviso.
• Por que afeta o target: iniciante e intermediário cometem typos, erros de unidade (% vs $), erros de zero ($1.000 vs $10.000), erros de magnitude. Em DeFi tudo é irreversível. Produto que valida só sintaxe transfere todo o custo de erro pro user.
• 4 perguntas-teste: (1) ✓ todos os concorrentes validam só sintaxe (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = falta de investimento + receio de "atrapalhar" power user (4) ✓ ganho perceptível — user com typo vê warning, reverte; sem warning, perde capital.
• Hipótese de diferenciação: Sanity Layer — sistema de warnings inline ativados por heurísticas específicas: (a) Max > 100× preço atual; (b) Min < 0,01× preço atual; (c) range assimétrico maior que 10× (+500% / -2%); (d) total > 80% do saldo da wallet; (e) fee tier desalinhado com range escolhido (vide PosPop #7); (f) APR estimado < 0 (IL maior que fees projetadas). Cada warning vem com explicação + ação sugerida. Override sempre disponível, mas com fricção de confirmação.
• Trade-off: heurísticas podem ser intrusivas; risco de "produto que reclama de tudo". Aceitar com toggle "Modo silencioso" pra avançado + memória de overrides ("você confirmou esse warning antes — não mostrar de novo").
• Leverage estrutural alto — define posicionamento "Kotai te protege de erros que Uniswap te deixa cometer". Reputacionalmente diferencial em mercado onde "perdi capital em swap/LP" é meme. Família consolidada "transparência ativa + guard-rails ativos" com 🟡 "Health Score" (PosPop #5), "Slider probabilístico" (PosPop #11), "Backtest visual" (PosPop #12), "Capital eficiency" (PosPop #13). Sanity Layer é o gatekeeper antes do commit on-chain — última oportunidade de evitar erro caro.

---

Observação adicional — interpretação do number 26071406 é incerta. Pode ser (a) 26.071.406 (vinte e seis milhões — absurdo legítimo, user testou limite), (b) 2.607,1406 (duas mil e seiscentas — sensato; render perdeu separadores), ou (c) outro typo. A própria ambiguidade valida a Fricção 2 acima — se eu, analisando o screenshot com calma, não consigo decidir qual é o número, o user na hora do depósito também não consegue. Vale registrar essa observação como evidência empírica da fricção (o problema apareceu durante o próprio benchmark). Independente da interpretação correta, o aprendizado vale: formatação numérica sem separador é falha de UX, e em produto financeiro é falha estrutural.

17. Posição Populada — Wallet sign (prompt externo de Phantom/MetaMask)

Função: popup externo à Uniswap disparado pela wallet (provavelmente Phantom, dado o estilo do UI, ou MetaMask) ao clicar Create na Tela 16. É o ponto de transferência de soberania: a UX deixa de ser do produto Uniswap e passa pra UX da carteira. Mostra: origin (https://app.uniswap.org), Simulation Results (impacto em saldo), bloco Add Liquidity com parâmetros decodificados (chain, tokens, prices, contrato, protocolo), Advanced Settings colapsado, e fee de gás + CTAs Begin signing process / Cancel.

Componentes

• Header: ícone MetaMask/Phantom + URL https://app.uniswap.org (origin do request).
• Section Simulation Results (simulação pré-execução pela wallet):
  • -1,000.0000 USDC com label ≈ $999.50 (linha vermelha = vai sair).
  • -0.2377 ETH com label ≈ $529.02 (linha vermelha = vai sair).
  • +1 unknown com badge NFT (linha verde = vai entrar; é o NFT da posição v3).
• Section Add Liquidity (decodificação semântica da call):
  • View Raw (link à direita — pra dev/avançado).
  • Chain: Ethereum (com ícone).
  • Add Token 1: 1,000.0000 USDC.
  • Add Token 2: 0.2377 WETH.
  • Pool Price: 1 USDC ≈ 0.0004 WETH.
  • Market Price: 1 USDC ≈ 0.0004 WETH.
  • Price Diff: 0.0056%.
  • Interact contract: 0xc36442…11e88 (link expandível).
  • Protocol: Uniswap V3 (com ícone).
  • Interacted before: Yes (badge implicitamente verde = trust signal).
• Section colapsada: Advanced Settings (chevron).
• Footer da wallet:
  • Fee de gás: ícone ETH + $0.67 -0.000303 ETH + dropdown Normal v.
  • Wallet ativa: Jake's Port… + endereço 0x2de4f7…0bb01a + saldo $108,460.97.
• CTAs primários:
  • Begin signing process (rosa primário — unusual label).
  • Cancel (secundário).

Regras de negócio

• Wallet simula a transação antes de mostrar — Simulation Results é renderização do estado pós-execução (estimado). Reduz risco de "achei que ia perder $100 e perdi $500".
• +1 unknown com badge NFT é o NFT da posição v3 (Uniswap v3 emite NFT ERC-721 por posição — diferente de v2, que era ERC-20). Wallet não reconhece o NFT (ainda não está em registro padrão) → unknown.
• Pool Price vs Market Price + Price Diff 0.0056% é check de manipulação/sandwich: se diff for grande (>1%), wallet pode flaggar como suspeito.
• Interacted before: Yes é trust signal — wallet sabe que essa wallet já interagiu com esse contrato antes (não é primeira vez, então provável ser legítimo).
• Fee de gás é editável (Normal v dropdown: Normal/Fast/Aggressive/Custom).
• Begin signing process em vez de Confirm ou Sign é vocabulário da wallet específica.

---

🟢 Insight 1 — Wallet faz simulação pré-execução e mostra o resultado antes da assinatura. "Você vai perder 1000 USDC, 0.2377 ETH, e receber 1 NFT" — em vermelho/verde, antes de assinar. Reduz a fenomenologia da "transação cega" típica de DeFi pré-simulação. Vitória de UX da wallet, não da Uniswap. Padrão a herdar pra Kotai (lado da Uniswap) — ainda que a wallet faça simulação, a Uniswap pode pré-mostrar o mesmo conteúdo dentro do modal de review (Tela 16), antes mesmo de chegar na wallet. Não fica refém de qual wallet o user tem.

🟢 Insight 2 — Decodificação semântica de Add Liquidity (chain, tokens, prices, protocol) substitui hex bruto. Sem essa decodificação, user veria 0xc36442…11e88::multicall(0x...) — incompreensível. Wallet conhece ABI do Uniswap v3 e traduz pra humano. Padrão a herdar — qualquer agent/wallet/produto que renderiza tx on-chain deve carregar ABI registry pra traduzir bytecode em texto.

🟢 Insight 3 — Pool Price vs Market Price + Price Diff 0.0056% é check anti-MEV embutido na wallet. Wallet compara cotação interna do pool com cotação de mercado (provavelmente CEX agregado) e mostra diff. User vê "o pool está a 0,0056% do preço de mercado" — confiança de que não vai ser sandwiched. Padrão a herdar — qualquer flow de swap/add-liquidity deve incluir este check (não só na wallet; também no produto).

🟢 Insight 4 — Interacted before: Yes é trust signal contextualizado. Wallet sabe a história da própria wallet com o contrato. "Você já fez add liquidity nesse contrato antes — não é primeira vez" reduz ansiedade de "isso é phishing?". Padrão a herdar — produto pode mostrar trust signals baseados em histórico do user ("você já fez essa ação 3 vezes") sem violar privacidade.

🟢 Insight 5 — Fee de gás editável com tier visual (Normal v) e equivalente USD ao lado ($0.67). User vê custo em fiat instantaneamente; pode subir pra Fast se pressa. Convenção madura de wallets. Padrão a herdar — qualquer custo de transação deve ter (a) tier nomeado, (b) valor em token, (c) equivalente USD, (d) override custom.

---

🔴 Fricção 1 — Transferência de UX Uniswap → Wallet é abrupta e rompe o "fio mental" do flow (estrutural — fronteira de produto rompe pedagogia construída)

• Atrito real: user passou 15+ telas no flow Uniswap. Aprendeu vocabulário (pool, range, fee tier, USDC/WETH). Modal de review (Tela 16) reforça esse vocabulário. Agora wallet abre com vocabulário diferente: Simulation Results, Add Token 1, Interact contract, Interacted before. Termos similares mas estrutura visual diferente, sem mapeamento explícito. Iniciante precisa re-traduzir o que entendeu na Uniswap pro que está vendo aqui. Risco: ele não reconhece que "Add Token 1: 1000 USDC" é o mesmo 1000 USDC da Tela 16. Hesitação no momento crítico = abandono.
• Por que a solução óbvia falha: Uniswap não controla UX da wallet (Phantom/MetaMask renderizam como quiserem); modificar wallet é fora do escopo da Uniswap.
• Alternativa: adicionar microcopy no modal de review (Tela 16, antes do Create) que antecipa o vocabulário da wallet — "Ao clicar Create, sua carteira mostrará: 'Add Liquidity', 'Simulation Results', e um NFT como retorno (esse NFT é a sua posição). Esse vocabulário é da carteira, não da Uniswap.". Pequena ponte semântica que prepara o user. Trade-off: texto extra no modal; ganho: zero choque cultural na transição.
• Perfil afetado: iniciante (principal — única vez que abre wallet em flow novo).
• Família com 🔴 "Create como label ambíguo" (PosPop #16) — mesma raiz: produto deveria antecipar mais a próxima etapa, especialmente quando a próxima etapa é em outro produto.

🔴 Fricção 2 — +1 unknown com badge NFT rotula a posição v3 como "desconhecido" — semanticamente errado e potencialmente assustador (estrutural — wallet não reconhece NFT do produto core)

• Atrito real: o NFT que o user vai receber é a posição v3 — é o título de propriedade da liquidez aportada. Mas a wallet rotula como unknown (porque o NFT ainda não está em registro padrão de tokens da wallet). Iniciante lê "você vai receber 1 NFT desconhecido" e pensa: "o quê? não pedi NFT, isso é golpe?". Em flow legítimo de DeFi, um trust signal vira alerta. Pior caso: user clica Cancel. Causa raiz: gap entre o protocolo (que emite NFT) e os registros padrão da wallet (que demoram pra indexar novos contratos).
• Por que a solução óbvia falha: Uniswap não controla o que a wallet rotula; cadastrar NFT em todas as wallets exige cross-chain coordination.
• Alternativa (dupla):
  • (a) Uniswap mantém microcopy explicativa no modal de review (Tela 16): "Sua posição será representada por um NFT na sua carteira (essa é a forma como Uniswap v3 funciona — não é colecionável)." Antecipa o unknown da wallet.
  • (b) Uniswap + wallets parceiras podem coordenar registro do NFT no token list das wallets principais. Esforço único, benefício recorrente.
• Trade-off: (a) é unilateral, fácil, mas paliativo; (b) é correto mas exige coordenação cross-product.
• Perfil afetado: iniciante (principal — único que se assusta com unknown).
• Família com 🔴 "Mudança silenciosa que perde feature" (PosPop #7, #10) — extensão: aqui é a wallet (sistema externo) que muda semântica sem aviso.

🔴 Fricção 3 — Begin signing process como CTA primário é redundante e atípico (cosmética — label longo onde Sign ou Confirm cobriria)

• Atrito real: "Begin signing process" — 3 palavras pra dizer "Assinar". Convenção universal de wallet (MetaMask, Phantom, Rainbow) é Confirm ou Sign. O label longo pode ser tradução literal de variável interna ou A/B test, mas adiciona ruído. Pra iniciante, "begin a process" sugere múltiplos passos seguintes ("vou assinar e depois...?"); na verdade é o único clique.
• Por que a solução óbvia falha: Uniswap não controla.
• Alternativa: observação ao fabricante da wallet (Phantom?) — Sign ou Confirm é o canonical. Fora do escopo da Uniswap; vale registrar como observação.
• Perfil afetado: iniciante.

---

🟡 Oportunidade competitiva — Pré-simulação da transação dentro do modal de Review (Uniswap-side, antes da wallet)

• Padrão da indústria: Uniswap (modais Telas 16 e 17), PancakeSwap, Curve — review do produto = recap de inputs; simulação real = só na wallet. User vê resultado simulado só depois de clicar Create e abrir wallet. Decisão de produto vs wallet: produto não duplica trabalho de simulação que a wallet vai fazer.
• Por que afeta o target: iniciante pode descobrir só na wallet que vai gastar $0.67 de gás, ou que vai receber um NFT, ou que Price Diff é 0.0056%. Toda essa info podia estar antes, no momento de "ainda posso voltar e ajustar". Pós-wallet, voltar é re-clicar tudo.
• 4 perguntas-teste: (1) ✓ todos os concorrentes adiam simulação pra wallet (2) ✓ afeta iniciante diretamente (3) ✓ razão = duplicação de trabalho de simulação + custo de chamar RPC do client (4) ✓ ganho perceptível — user vê "Gás estimado: $0.67 / NFT a receber: representa sua posição (não é colecionável) / Price Diff: 0.0056% (seguro)" dentro do modal de Review, antes de chamar a wallet.
• Hipótese de diferenciação: section "Pré-execução" no modal de Review (Tela 16) — Uniswap chama RPC e mostra o mesmo conteúdo de Simulation Results + decode da call que a wallet vai mostrar. User confirma tudo no Uniswap; wallet vira mero "assinador" sem surpresa. Reduz ansiedade da fronteira.
• Trade-off: custo de RPC chamada (latência); risco de divergência entre simulação do produto e simulação da wallet (gás muda em segundos). Aceitar com caveat "Estimativa — valor final confirmado pela sua carteira".
• Leverage estrutural alto — converte fronteira "produto vs wallet" em "produto controla a expectativa". Família consolidada "honestidade ativa" com PosPop #5, #10, #11, #16. É a peça final do sistema — produto Kotai entrega tudo o que a wallet entregaria, antes da wallet, dentro da própria UX.

🟡 Oportunidade competitiva — Onboarding "primeira vez com wallet sign" embutido no Uniswap

• Padrão da indústria: Uniswap, PancakeSwap, Curve — assumem que o user sabe usar wallet. Sem onboarding de "isso é o que vai aparecer, isso é o que cada campo significa, isso é por que tem 1 NFT". Iniciante primeira vez fica perdido na Tela 17.
• Por que afeta o target: iniciante saindo de CEX vê wallet UI primeira vez no momento do commit financeiro — pior momento possível pra aprender.
• 4 perguntas-teste: (1) ✓ todos os concorrentes assumem fluência em wallet (2) ✓ afeta exclusivamente iniciante (3) ✓ razão = produto não controla wallet, e onboarding "fora do produto" parece intrusivo (4) ✓ ganho perceptível — user vê "É sua primeira vez? Aqui vai um tour rápido das 4 informações que sua carteira vai mostrar" antes de clicar Create.
• Hipótese de diferenciação: modal opcional "Primeira vez aportando? 30s pra entender o que vai aparecer" no modal de Review (Tela 16) — só aparece pra wallets sem histórico de add liquidity. Tour com 4 cards: (1) Simulation Results = "preview do que vai mudar na sua carteira", (2) Add Liquidity = "Uniswap traduziu sua ação pra humano", (3) NFT = "sua posição vira NFT — é o título dela", (4) Gas fee = "custo da rede pra registrar isso, não é taxa da Uniswap". Dismiss = "Pular, sei o que faço".
• Trade-off: modal extra antes de modal extra; risco de inflar fluxo. Aceitar pelo target iniciante.
• Leverage médio-alto — diferenciador específico pro target iniciante saindo de CEX. Família "onboarding contextual" — primeira vez sempre tem tooltip explicativo (PosPop #1 fricção 2 do Tab Liquidity).

---

Observação adicional — wallet ativa "Jake's Port…" sugere que captura é de wallet de teste/demo. Endereço 0x2de4f7…0bb01a + saldo $108,460.97 + nickname "Jake's Port" indicam wallet de benchmark, não wallet real de produção. Não é fricção — é só registro do contexto de captura. Vale notar: capturas com wallet de demo são úteis pro benchmark (sem risco real), mas perdem realismo em fricções que dependem de saldo limítrofe ou primeira interação real. Pra completude do estudo, seria útil ter print de mesmo flow com wallet "vazia" (user iniciante real, sem histórico) — aí Interacted before: No viraria sinal de alerta da wallet, e a Fricção 1 (transferência abrupta) ficaria ainda mais visível.

---

Observação final do flow PosicaoPopulada (17 telas). Esse modal de wallet é o último ponto do flow capturado. Não há tela 18 confirmando "posição criada com sucesso" no canvas — o flow termina antes da confirmação on-chain. Sugestão pra completude: adicionar captura pós-sign (Uniswap mostrando "Position created", redirect pra /pool com nova posição visível na lista) — fechamento de loop importante pra avaliar UX de feedback de sucesso (componente que muitas DEXes fazem mal — confirmação fraca, sem CTA "ver minha posição agora"). Sem isso, o flow analisado é de decisão+commit, não de decisão+commit+confirmação — falta a última peça pra ciclo completo de LP onboarding.

Consolidado — Nova Posição (Uniswap)

Caráter geral do fluxo

O fluxo de Nova Posição entrega decisões pedagógicas acertadas na superfície — stepper vertical que sinaliza progressão desde a entrada (1), microcopy inline que educa sem exigir tooltip (1, 2), defaults do caso 90% (1) — mas é dominado por uma fricção estrutural transversal: a escolha de versão (v2/v3/v4) é o controle mais consequente do fluxo inteiro e recebe o menor investimento pedagógico. Aparece como chip discreto no canto (1), lança cross-sell desbalanceado quando o usuário já decidiu por v2 (2), expõe lista nua de opções sem trade-off (4) — e nunca orienta o iniciante sobre o que a decisão significa em termos de capital, risco e esforço de gestão. Perfis mais afetados: iniciante (cria posição em versão errada, enfrenta range concentrado sem conceito de price tick) e intermediário (percebe o erro tarde, já na Etapa 2).

🟢 Insights recorrentes

Stepper pedagógico e contextual — telas 1, 2

O stepper vertical com 2 etapas visível desde a entrada (1) não é decorativo — é contrato com o usuário: "este processo tem dois passos, você está no primeiro". O refinamento aparece na Tela 2 (2): os labels se adaptam conforme a versão escolhida. Em v4: "Definir faixa de preço e valores de depósito"; em v2: "Inserir valores de depósito". O stepper comunica diferença arquitetural sem precisar de explicação extra — o usuário vê em segundos o que vai ser exigido no próximo passo. Concorrentes como PancakeSwap jogam tudo num formulário único; aqui o usuário tem âncora de progressão antes de começar a decidir. Padrão a herdar para Kotai: qualquer fluxo com >3 decisões interdependentes ganha stepper visível com labels que reflitam o que realmente vai acontecer em cada passo — não labels genéricos.

Microcopy pedagógica inline — telas 1, 2

Instrução de campo vive abaixo do label, sempre visível, em linguagem que evita jargão técnico (1): "Escolha os tokens para os quais você deseja fornecer liquidez" em vez de esconder em tooltip ⓘ que iniciante não passa o mouse. O padrão se sofistica na Tela 2 (2): quando a escolha de v2 elimina o campo de fee tier, a section permanece visível com microcopy que explica o motivo — "Todos os pools v2 têm tarifa fixa de 0,3%. Para mais opções, oferte liquidez no v4." Manter a section visível e explicar o motivo é mais pedagógico do que remover silenciosamente (o que geraria "cadê o nível de tarifa?"). Padrão a herdar: quando uma decisão é eliminada por contexto, manter a section visível e usar o espaço para educar.

Feedback visual explícito de estado — telas 2, 3, 4

Múltiplas manifestações de transparência sobre o que o sistema está fazendo ou o que uma ação vai causar. O botão Continuar muda de outline cinza para preenchimento sólido quando habilitado (2) — sem texto auxiliar redundante, só mudança visual. O chip "Auto" exibe o valor calculado (2,5%), não esconde a heurística por trás de caixa-preta (3). O label "Nova posição de Vx" no dropdown sinaliza que clicar = redefinir o formulário, não ajustar in-place (4) — o verbo carrega a semântica da consequência. Padrão a herdar: estado e próxima ação sempre visíveis sem exigir que o usuário infira; quando uma ação é destrutiva ou irreversível, o label deve refletir isso.

🔴 Fricções recorrentes

Estrutural — Versão (v2/v3/v4) como caixa-preta técnica sem pedagogia — telas 1, 2, 2, 4

Diagnóstico do atrito real: o controle de maior consequência do fluxo — versão define toda a arquitetura abaixo: range, fee tier, hooks, label do stepper, URL — recebe hierarquia visual de configuração secundária: chip no canto superior direito no mesmo eixo de Redefinir e ⚙ (1). No dropdown que expõe as alternativas, as opções aparecem como labels nus sem qualquer descrição do trade-off (4). Quando o usuário já decidiu por v2, uma frase de cross-sell unidirecional o empurra de volta para v4 sem oferecer o contra-argumento simétrico (2). A palavra "v2" se repete no chip, no stepper e na microcopy — nunca traduzida para o que significa em termos de comportamento para o usuário (2).

Consequências de segunda ordem: (a) iniciante defaultado em v4 enfrenta Etapa 2 com range concentrado — conceito que pressupõe entender price tick; (b) iniciante que "corrige" para v2 via dropdown pode perder os campos já preenchidos sem aviso (4); (c) o cross-sell "Para mais opções, oferte em v4" (2) incentiva o retorno à versão mais complexa exatamente quando o usuário tinha saído dela.

Por que a solução óbvia falha: promover versão para cartões hero na entrada impõe decisão técnica imediata — exatamente o que a UX atual evita ao defaultar v4. Mas o esconderijo cria a cascata acima.

Alternativa em dois planos:

• Incremental: eyebrow line entre breadcrumb e título com versão atual + links de troca; rotular com adjetivo descritivo ("Posição simples (v2) ▾"); micro-descrições em 1 linha no dropdown. Baixo custo, ganho imediato.
• Estratégico: ver 🟡 Oportunidade 1.

Perfil afetado: iniciante (principal — cria posição em versão errada, enfrenta range sem ferramenta) + intermediário sem familiaridade com LP.

---

Estrutural — Ausência de estado do pool destino na janela de decisão de aporte — tela 2 (estrutural, 1 tela)

Diagnóstico do atrito real: o usuário completa par + versão + fee e o botão Continuar fica habilitado (2) — sem nunca ver o estado do pool para o qual está aportando capital. Em v2, par + fee = pool único; não há fee tier alternativa para escapar para um pool mais saudável. Um pool morto (WISE/ETH v2 0,3%: APR 0,00%, Volume 24h ↓81,84%) é armadilha invisível: o usuário aporta capital, acumula impermanent loss sem compensação de fee, não entende por quê, e interpreta como "o produto está me fazendo perder dinheiro".

Consequência de segunda ordem: o dano é assimétrico com o swap. Um swap em pool morto gera slippage pontual e discreto. Um aporte em pool morto mantém posição aberta com IL crescente — o usuário continua exposto enquanto não entender que deve sair.

Por que a solução óbvia falha: bloquear aporte em pool inativo é editorial e fere neutralidade de protocolo; aviso genérico no botão Continuar replica banner blindness.

Alternativa: card de estado do pool inline assim que par + versão ficam definidos: TVL + Volume 24h + APR + badge de atividade em pool existente. Em pool ainda inexistente: "Você será o primeiro provedor — você define o preço inicial" com warning de risco de arbitragem (caso de semântica completamente diferente, vide Observações adicionais). Colapsável em pool saudável; expandido forçado em pool morto ou pool novo.

Trade-off: adiciona altura ao formulário na Etapa 1; risco de overwhelming. Mitigação: colapsável default em pool ativo, expandido forçado em pool crítico.

Perfil afetado: iniciante (principal — não tem heurística de pool health) + intermediário descuidado.

---

Estrutural-leve — Affordance e semântica ambígua em campos de decisão financeira — telas 1, 3

Diagnóstico do atrito real: dois campos em telas distintas compartilham o mesmo padrão de ambiguidade na leitura do componente ou na semântica do label. Campo "Nível de tarifas" (1): caixa cinza com placeholder -- nível de tarifas + botão lateral "Mais ▾" — não fica claro se clicar no campo ou no botão abre a lista; a decisão de fee tier em v4 é estratégica (tier baixo = mais volume, menos fee/swap; tier alto = ao contrário) e a UI não orienta exploração. Label "Prazo final da transação" (3): sugere deadline absoluto (ponto no tempo), mas o valor "30 minutes" é janela relativa (30 minutos depois da submissão) — quando a transação expira, o iniciante não sabe se pode reenviar ou perdeu o trem.

Alternativas:

• Fee tier: segmented control com 3-4 chips horizontais (0,01% / 0,05% / 0,3% / 1%) + chip "Outros ▾" para exóticos. Decisão explícita, opções visíveis lado a lado.
• Prazo: label "Sua transação expira após" + valor "30 minutos" — a preposição "após" elimina ambiguidade relativo/absoluto sem jargão técnico.

Perfil afetado: iniciante (principal) + intermediário sem familiaridade.

---

🟡 Oportunidades competitivas do fluxo

Pedagogia de versão: do dropdown técnico à assistência baseada em perfil — telas 1, 4

Padrão atual da indústria: Uniswap (chip discreto + dropdown de labels nus, (1) e (4)), PancakeSwap (toggle v2/v3 minúsculo no topo), 1inch (não expõe versão pra LP) — todos tratam versão como seleção de string técnica, não como decisão entre arquiteturas de LP com trade-offs distintos de risco e gestão.

Por que afeta nosso target: iniciante não sabe que v2 = constant product (deposite e esqueça), v3 = concentrated range (sai do range → para de ganhar fee → gestão ativa necessária), v4 = hooks + concentrated (ainda mais complexo). Default v4 (1) expõe o perfil mais vulnerável à versão que exige mais competência. O resultado é posições mal configuradas: range muito estreito, saída prematura, fees zero por semanas, abandono confuso.

Hipótese de diferenciação Kotai — três paths possíveis:

• Path A (incremental): micro-descrições em 1 linha no dropdown (4) + eyebrow com versão atual e links de troca (1). Custo baixo, ganho imediato, mas não é diferenciador forte.
• Path B (estratégico): modal de seleção com 3 cartões de trade-off como primeira decisão do fluxo — "Simples e passiva (LP clássico)" → v2, "Concentrada num range (mais eficiência, gestão ativa)" → v3, "Customizável com lógica programável" → v4. Default sugerido = v2 para iniciante. Chip "Pular — usar v4" para power user.
• Path C (radical): esconder versão completamente; decidir por heurística (par estável → v2, par volátil com position manager → v3); "Configuração avançada" para quem quer controle. Máximo de redução de cognitive load; perde controle granular e exige heurística bem calibrada.

A solução atual — exposição técnica sem pedagogia — é a pior das três: expõe a decisão sem ajudar a tomá-la.

Trade-off: Path B adiciona 1 passo ao funil e frustra power user que sabe o que quer (mitigação: chip "Pular"). Path C depende de heurística acertada e perde controle explícito. Path A é seguro mas não é diferenciador.

Passa nas 4 perguntas-teste? (1) ✓ todos os DEX expõem versão como seleção técnica sem pedagogia; (2) ✓ afeta iniciante diretamente — posição mal configurada, fees zero, abandono; (3) ✓ razão = falta de investimento em UX pedagógica + cross-promo de versão mais nova; (4) ✓ ganho perceptível — iniciante vê "Simples" e escolhe v2; posição melhora.

Leverage estrutural — posicionamento "DEX que orienta iniciante na decisão arquitetural mais importante de LP".

---

Card de pré-visualização do pool destino antes do depósito — tela 2 (estrutural, 1 tela)

Padrão atual da indústria: Uniswap (2), PancakeSwap, Curve — fluxo de criação de posição não exibe estado do pool destino na Etapa 1. A informação (TVL, Volume, APR) chega na Etapa 2, quando o usuário já está com mindset de "vou aportar", não de "devo aportar aqui?".

Por que afeta nosso target: usuário completa par + versão com base no nome do par, não na saúde do pool. Pool morto é armadilha invisível de IL sem compensação (ver Fricção 2 desta seção). O dano é maior para iniciante, que não tem heurística de pool health e interpreta IL como "o produto está me fazendo perder dinheiro".

Hipótese de diferenciação Kotai: card inline de estado do pool (TVL + Volume 24h + APR + badge de atividade) assim que par + versão ficam definidos — reusando componente de detalhe de pool (já existente no fluxo VisualizarPool). Colapsável por default em pool saudável ("Ver detalhes do pool ▾"); expandido forçado em pool inativo ou pool novo.

Trade-off: adiciona altura ao formulário na Etapa 1; pode sobrecarregar visualmente. Mitigação: colapsável em pool saudável, forçado expandido quando importa.

Passa nas 4 perguntas-teste? (1) ✓ todos os DEX adiam a info para Etapa 2; (2) ✓ afeta iniciante e intermediário direto; (3) ✓ arquitetura de funil herdada + receio de sobrecarregar Etapa 1; (4) ✓ ganho perceptível — "APR 0,00% / Volume ↓82%" aparece na janela de decisão de aporte.

Família cross-fluxo: Pools #1, #4 (sinalização de pool inativa), VisualizarPool 1. Leverage estrutural — posicionamento "Kotai te mostra onde você está aportando antes de aportar".

---

Slippage adaptativo ao par/pool — tela 3 (estrutural, 1 tela)

Padrão atual da indústria: Uniswap (Auto com valor fixo 2,5% sem critério exposto, (3)), PancakeSwap, 1inch — todos usam "Auto" como constante interna ou caixa-preta sem critério visível.

Por que afeta nosso target: em WISE/ETH (pool morto, profundidade baixa), 2,5% pode ser insuficiente → transação falha, usuário não entende por quê. Em USDC/ETH (pool líquido), 2,5% é absurdamente generoso → exposição a MEV. Iniciante não tem heurística por par e confia cegamente em "Auto".

Hipótese de diferenciação Kotai: "Auto" calcula slippage por profundidade do pool + volatilidade 24h + tamanho da transação. Tooltip do ⓘ existente expande com 1 frase do critério ativo: "Auto: calculado com base na profundidade do pool e na volatilidade recente. Para este par, 2,5%." Em par estável: Auto sugere 0,1%. Em pool morto: Auto sugere 5% + warning. Em pool líquido grande: Auto sugere 0,5%.

Trade-off: pricing engine inline é custo de engenharia real; dependência de oráculo externo cria latência; critério exposto gera reclamações se estiver "errado" — trade-off de implementação mais pesado que nas oportunidades anteriores.

Passa nas 4 perguntas-teste? (1) ✓ todos os DEX usam Auto opaco; (2) ✓ afeta iniciante e intermediário; (3) ✓ falta de investimento em pricing engine inline; (4) ✓ transação falha menos e absorve menos slippage — ganho perceptível.

Família cross-fluxo: 🟡 pré-visualização rica de transação DeFi (Swap), sinalização de pool inativa. Slippage adaptativo é a manifestação prática dessas oportunidades no momento do submit. Leverage médio-alto — afeta toda submissão de transação no produto.

Pontos isolados (1 tela)

• 🟢 Tela 1: ETH pré-selecionado como Token A — default do caso 90% sem forçar (user pode trocar); padrão a herdar: defaults pegam o caso comum, não o caso neutro.
• 🟢 Tela 3: Settings de slippage/deadline em popover ancorado no contexto do fluxo — não navega para página de Preferências separada; mudança fina não merece navegação dedicada.
• 🔴 Tela 1: "Adicionar um hook (Avançado) ⓘ" — jargão técnico invasivo entre campos pedagógicos; "(Avançado)" ambíguo sobre se é opcional; link parece passo do formulário. Alternativa: toggle desligado com label descritivo. Manifestação pontual da fricção estrutural de versão como caixa-preta.
• 🔴 Tela 3: "Auto = 2,5%" sem critério exposto — "Auto" semântico (sugere adaptação ao par) vs "Auto" estático (pode ser constante interna). Conecta à 🟡 Slippage adaptativo.
• 🔴 Tela 3: "30 minutes" não traduzido — fix trivial; a perda de confiança gerada é desproporcional ao tamanho do problema.
• 🔴 Tela 4: v2 omitido do dropdown gera dúvida "em qual versão estou?" — convenção de select (esconder estado atual) inadequada em decisão de alta consequência. Alternativa: listar as 3 versões com a atual marcada com ✓.
• 🔴 Tela 4: Troca de versão pode redefinir formulário silenciosamente — ação destrutiva camuflada de navegação. Alternativa: preservar par + warning inline sobre o que será redefinido ao trocar.

Observações adicionais

• 📝 URL como state machine (Telas 1 e 2): toda a configuração do formulário (par, rede, fee tier, versão como path segment) é parametrizada na URL. Decisão de produto a herdar para Kotai: em fluxos compartilháveis (LP, swap, leilão), URL parametrizada permite linkar setups específicos diretamente.
• 📝 Caso "pool ainda não existe" (Tela 2): o primeiro LP de um par define o preço inicial — semântica e risco radicalmente diferentes do aporte em pool existente (risco de arbitragem imediata que drena valor no primeiro bloco). A UI atual não distingue os dois casos. Kotai deve ter UX dedicada para o caso "novo pool" com warning explícito de definição de preço e risco.
• 📝 Popover de settings sem confirmação (Tela 3): mudanças em slippage e deadline aplicam ao perder foco — convenção válida em settings reversíveis (Notion, Linear, Figma), mas settings que alteram parâmetros financeiros podem merecer padrão diferente. Não há prova de problema nesta captura; vale registrar para testes de usabilidade.

Comparação rápida com PancakeSwap

Não há consolidado equivalente de PancakeSwap para este fluxo. O mais próximo seria adicionar-liquidez, ainda sem análise consolidada. Comparação a completar após análise de adicionar-liquidez do PancakeSwap. Link futuro: Consolidado PancakeSwap — Adicionar Liquidez.

1. Posição Populada — Pool Detail em Volume (entrypoint do flow LP)

Função: página de detalhe da pool ETH/USDC v3 0,05% (0x88e6…c5C7) servindo como entrypoint do flow de criação de posição. Diferente de VisualizarPool (pool WISE/ETH v2 morto), aqui o pool é live e saudável — usado pelo benchmark exatamente pra mostrar a UX no estado "vale aportar". O user está na fase de avaliar a pool antes de clicar em "Add liquidity".

Componentes

• Breadcrumb: Pools › ETH / USDC.
• Header: par ETH / USDC + version v3 + fee 0,05% + setinha de inverter par + endereço encurtado 0x88e6…c5C7 + ícones (chart toggle, share, "…").
• Big stat à esquerda: $805.2K + data Apr 12, 2026, 8:43 PM (volume do dia destacado no chart).
• Chart de Volume (histogram bar) com pico no início de Apr (~$50K) e barras menores ao longo do mês. Tooltip flutuante visível mostra "Fees: $2.4K" no bar selecionado.
• Tabs de tipo de chart: Price / Volume ✓ / Liquidity (Volume ativo).
• CTAs no topo direito: Swap (outline, secundário) + + Add liquidity (rosa, primário).
• Card destacado: Total APR 47,16% (fonte gigante).
• Card Stats:
  • Pool balances com barra de proporção: 30.6K ETH | 59.7M USDC.
  • TVL: $111.0M ↑2.0%.
  • 24h volume: $47.8M ↑76.6%.
  • 24h fees: $143.4K.
• Tabela Transactions abaixo: Time / Type (Sell WETH em vermelho / Buy WETH em verde) / USD / ETH / USDC / Wallet.

Regras de negócio

• Total APR = (24h fees × 365) / TVL — yield observado anualizado da pool inteira. Não reflete APR específico de range escolhido em v3.
• Tab Liquidity só existe em pools v3+ (v2 só tem Price/Volume). Decisão arquitetural — distribuição de liquidez por tick é conceito específico de concentrated liquidity.
• CTA primário é + Add liquidity (não Swap), sinalizando que essa página foi pensada como entrypoint do LP, não do trader.
• UI em inglês (Trade / Explore / Pool / Portfolio / Swap / Add liquidity / Transactions / Wallet / Time / Type) — diferente da UI PT-BR do flow Nova Posição. Captura presumidamente feita em build EN ou em conta com locale EN.

---

🟢 Insight 1 — Pool detail bem populado vira "argumento de venda" do LP, não só relatório. O contraste com WISE/ETH (VisualizarPool, APR 0,00% / Volume ↓81%) é gritante: aqui o mesmo template entrega APR 47% / Volume ↑76% / Fees $143K. Mesma estética, mesmos slots, mensagem totalmente oposta. Padrão a herdar pra Kotai — o componente "Pool Stats" deve resistir ao caso bom e ao caso ruim sem precisar de tratamento gráfico diferente; o number é quem fala. Quando o template não diferencia, a UI escala.

🟢 Insight 2 — CTA primário é + Add liquidity, não Swap. Decisão deliberada de hierarquia: o user que aterrissa numa pool detail é mais provavelmente um candidato a LP (chegou via Pools List, breadcrumb explícito) do que um trader (que iria pelo /swap direto). Hierarquia visual reflete intenção. Padrão a herdar — CTA primário herda a intenção do funil que trouxe o user, não o "verbo mais agressivo" possível.

🟢 Insight 3 — Tooltip "Fees: $2.4K" no bar do chart conecta volume e fee. Ao passar o mouse no bar de volume, o user vê quanto aquele volume gerou de fee — entrega o loop pedagógico Volume → Fees → APR sem precisar de relatório separado. Família com 🟡 "Narrativa do chart" (VisualizarPool #2) — aqui o produto já entrega narrativa local, sem precisar de caption.

🟢 Insight 4 — Tab Liquidity como dimensão extra em v3. Pool v3 ganha view de distribuição de liquidez (que vira a Tela 2 deste flow). Não é decoração — é a ferramenta principal de decisão de range pra LP de v3. Padrão a herdar pra Kotai — quando a arquitetura adiciona dimensão (range, hook, etc.), a página de detalhe ganha tab dedicada, não popup secundário.

---

🔴 Fricção 1 — Total APR 47,16% em fonte gigante é o APR médio da pool, não o APR do range que o user vai escolher (estrutural — vetor de FOMO direto em v3)

• Atrito real: em v3 (concentrated liquidity), o APR real de uma posição depende fortemente do range escolhido. LP em range tight (preço ±0,5%) que fica in-range ganha múltiplo do APR médio da pool, porque o capital dele compete só com a fatia de capital naquele tick. LP em full range ganha menos que o APR médio (porque a maior parte do capital dele fica ociosa fora do tick ativo). O number 47,16% é a média ponderada — não promete nada a uma posição específica. Mas a fonte gigante + label "Total APR" sem qualificador induz iniciante a pensar "vou ganhar 47% se aportar aqui". Erro de leitura é o mais perigoso de v3: user aporta full range esperando 47% e ganha 8%, ou aporta tight range esperando 47%, fica out-of-range em 2h e ganha zero.
• Por que a solução óbvia falha: esconder o Total APR médio remove a comparação grosseira útil entre pools; trocar pra "APR médio (varia por range)" em letra menor não muda o peso visual; tooltip ⓘ é dismissado.
• Alternativa: substituir o single number por dois numbers em par — "APR full range: 8,5% / APR tight range (±1%): 92%" lado a lado, mesmo peso visual, com microcopy "O APR da sua posição depende do range que você escolher". O user vê de cara que escolha de range = decisão de retorno. Trade-off: mais largura no card; cálculo de "tight range" precisa de definição (qual é o range "tight" canônico — ±0,5%? ±1%?). Aceitar com âncora explícita.
• Perfil afetado: iniciante (principal — único alvo direto de FOMO por number opaco em v3) + intermediário sem heurística de concentrated liquidity.
• Família com 🟡 "Renda anual como APR opaco" de Pools #1 — aqui é o agravante específico de v3: o number existe, é calculado corretamente, mas é semanticamente inaplicável à decisão que o user está prestes a tomar.

🔴 Fricção 2 — Tab Liquidity aparece sem affordance de que é específica de v3 (cosmética-estrutural — feature avançada disfarçada de "mais uma view")

• Atrito real: as tabs Price / Volume / Liquidity aparecem como peers visuais — mesma altura, mesmo peso, mesma cor. Mas Liquidity é dimensão exclusiva de v3+ (vide regras de negócio); user que migrou de v2 nunca viu essa tab antes. Sem onboarding inline (badge "Novo", "Específico de v3", ou tooltip), o user clica esperando "outra visualização do mesmo dado" e cai na curva de liquidez (Tela 2) — gráfico abstrato que precisa de pedagogia (vide Fricção 1 da Tela 2).
• Por que a solução óbvia falha: badge "Específico de v3" permanente polui as tabs; remover a tab condicionalmente esconde a feature que diferencia v3.
• Alternativa: primeira vez que o user clica em Liquidity, tooltip inline aparece com 1 frase explicando o conceito + link "Saiba mais" — onboarding contextual de feature avançada. Sessões subsequentes não mostram. Trade-off: exige state de "user já viu" (cookie/localStorage); ganho: feature explicada no momento do primeiro contato, não em manual separado.
• Perfil afetado: iniciante (principal) + intermediário vindo de v2.
• Família com 🟡 "Educação inline para features DeFi" — extensão pro nível de componente de navegação (tab), não só de label ou number.

🔴 Fricção 3 — UI em inglês quebra continuidade com o resto do produto (PT-BR) (estrutural — fricção de i18n de captura ou de produto)

• Atrito real: esta tela mostra Trade / Explore / Pool / Portfolio / Swap / Add liquidity / Transactions / Time / Type / Wallet / Total APR / Pool balances / TVL / 24h volume / 24h fees. O flow Nova Posição (analisado em outras telas) está em PT-BR (Negociar / Explorar / Pool / Portfólio / Fazer swap / Nova posição / Continuar). Duas possibilidades: (a) a captura foi feita em locale diferente do resto (problema do benchmark, não do produto); (b) o produto realmente serve a página detail em EN e o flow Nova Posição em PT-BR (inconsistência real). Se for (b), é fricção grave — o user que navega Pools › ETH/USDC em PT-BR vê de repente cabeçalho EN, perde âncora de "estou no mesmo produto?".
• Por que a solução óbvia falha: sem mais capturas é impossível distinguir (a) de (b); o cuidado da análise é registrar e marcar como pendente.
• Alternativa: verificar build/conta da captura. Se for (b), corrigir traduzindo a página inteira (mesmo eixo da fricção "Wallets em EN" mencionada no CLAUDE.md como exemplo canônico, e da fricção "30 minutes" em settings de Nova Posição).
• Perfil afetado: todos os PT-BR.
• Família consolidada "i18n EN/PT-BR descosturado" — Wallets (CLAUDE.md), 30 minutes (Nova Posição #3 settings), e potencialmente página inteira aqui.

---

🟡 Oportunidade competitiva — APR estimado por range simulado direto na pool detail

• Padrão da indústria: Uniswap (esta tela), PancakeSwap, Curve — exibem Total APR (médio da pool) como number único na pool detail. APR estimado por range só aparece dentro do flow de criação de posição, quando o user já está com mindset de aportar. A janela de decisão "vou aportar aqui? em que range?" não recebe info — só o number médio.
• Por que afeta o target: iniciante v3 não sabe que APR varia com range; intermediário sabe mas precisa abrir o flow pra simular. Resultado: decisão de range é tomada com base em "qual chart parece bom?" em vez de "qual range estima yield X?". Sub-utilização de v3 (full range em pool concentrada) é endêmica — vide qualquer estudo de yield real vs APR projetado em LP v3.
• 4 perguntas-teste: (1) ✓ todos os concorrentes adiam APR-por-range pro flow de criação (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = arquitetura de funil + custo de simulação em tempo real (4) ✓ ganho perceptível — user vê "APR estimado se range = ±1%: 92%" antes mesmo de clicar em "Add liquidity".
• Hipótese de diferenciação: slider de range embutido na sidebar de Stats, com APR estimado atualizando ao deslizar. User compara "full range → 8%" vs "±2% → 45%" vs "±0,5% → 180%" sem sair da página. Vira ferramenta de exploração antes do funil de criação.
• Trade-off: simulação em tempo real exige pricing engine no client; APR estimado precisa caveat ("assume distribuição de volume constante, ignora IL"); user power vai querer overrides.
• Leverage estrutural — define posicionamento "Kotai te mostra o yield antes de você se comprometer". Família consolidada "transparência ativa para iniciante" (Pools #1/#4, VisualizarPool #1, Nova Posição #2, e agora PosPop #1) + complementa diretamente a 🟡 "Card de pré-visualização do pool destino antes do depósito" (Nova Posição #2).

---

Observação adicional — + Add liquidity como CTA na pool detail aterrissa no flow Nova Posição com par já pré-preenchido. Decisão de produto importante: o user que clica daqui pula a Etapa 1 do Nova Posição (Selecionar par) ou cai nela com ETH/USDC já preenchido. Em qualquer dos dois, a versão default (v4 segundo Nova Posição #1) pode não coincidir com a versão da pool em que o user estava (v3 nesta tela). Fricção potencial: user clicou em "Add liquidity" numa pool v3 e o flow abre em v4. Não consigo confirmar com esta captura isolada, mas é decisão a verificar — herdar versão do contexto de origem (v3 aqui → flow começa em v3) é a expectativa do user.

4. Posição Populada — Captura idêntica à Tela 3 (artefato de benchmark)

Função: captura nomeada PosicaoPopulada4.png que, em pixels, é idêntica à Tela 3 — mesmas dimensões (1920×1080), ImageChops.difference() retorna bbox vazio. Diferem só no encoding PNG (md5 diferente, mesmos pixels). Portanto não é um novo estado de UI da Uniswap; é uma duplicata do print da Tela 3 dentro da pasta de captura. Registro aqui como artefato de benchmark a corrigir, não como fricção do produto.

Componentes

• (Iguais à Tela 3 em todos os elementos: pool detail ETH/USDC v3 0,05% em tab Liquidity, marker "Active tick range", conversões 1 WETH = 2,235 USDC, sidebar Stats com Total APR 47,16%, tabela Transactions com Add/Remove/Buy/Sell, section Links no rodapé.)

Regras de negócio

• Nenhuma adicional à Tela 3.

---

🟢 Insight — Decisão correta: não inventar análise quando não há sinal. Per CLAUDE.md ("Não invente fricção pra preencher campo — se a tela genuinamente não tiver atrito relevante, diga isso e justifique"). Aqui não há tela, há cópia. A análise crítica é admitir isso e propor saneamento do dataset.

---

🔴 Fricção (de benchmark, não de produto) — Slot de captura ocupado por duplicata cega o flow (cosmética, escopo: organização do canvas)

• Atrito real: a sequência narrativa do flow (1 = entrypoint Volume → 2 = Liquidity inicial → 3 = Active tick + Links → 4 = ? → 5 = Your positions) tem um buraco analítico aqui. Se 4 fosse o scroll completo da page com Links + tokens individuais (corrigindo a Fricção 3 da Tela 3), ou o estado pós-clique em "+ Add liquidity" (transição pro flow Nova Posição), o canvas teria continuidade. Como está, salta de "pool detail" pra "Your positions com posição populada" (Tela 5) sem o gancho do meio — como o user chegou de uma na outra.
• Por que a solução óbvia falha: apagar o slot 4 do canvas reduz o índice (renumera 5–17 → 4–16) e quebra referência cruzada que outros relatórios podem ter feito.
• Alternativa: recapturar PP4 com um dos dois candidatos abaixo, mantendo o slot:
  • (a) Scroll completo da pool detail até section Links com tokens individuais visíveis — fecha a Fricção 3 da Tela 3 com evidência.
  • (b) Estado de transição "+ Add liquidity" clicado / Nova Posição abrindo com par pré-preenchido — fecha a Observação adicional da Tela 1 (versão herdada do contexto: v3 da pool → flow começa em v3 ou v4?).
• Perfil afetado: o analista do canvas (nós), não o user final. Por isso é fricção de benchmark, não de produto.

---

Observação adicional — protocolo pra detectar duplicatas no resto do flow. Vale rodar md5 + PIL ImageChops.difference() em todo o BenchmarkUniswap antes de continuar a análise. Se há uma duplicata sutil aqui, pode haver outra entre as 17 capturas. O custo de detectar é um script de 5 linhas; o custo de analisar duas vezes a mesma tela é proporcional ao detalhe do relatório (vide Telas 1–3, que somam ~3k palavras cada).

3. Posição Populada — Pool Detail com Active Tick + Section Links

Função: mesma view de Liquidity da Tela 2, agora com marker do tick ativo sobreposto à curva + section Links revelada no rodapé. Estado capturado em momento posterior à Tela 2 (preço caiu de $2.359 pra $2.235; Pool balances ajustados — vide observação da Tela 2). A page exibe simultaneamente "onde está o capital depositado" (curva) + "onde está o preço agora" (marker) + "fundamentos on-chain" (links de contrato).

Componentes (diff em relação à Tela 2)

• Conversões atualizadas: 1 WETH = 2,235 USDC / 1 USDC = 0,0004474 WETH.
• Sobre a curva: linha vertical rosa + label "Active tick range" + ponto de ancoragem visível.
• Sidebar Pool balances ajustada: 33,0K ETH | 59,7M USDC (mais ETH no pool porque preço caiu — relação esperada de constant product em torno do tick atual).
• Tabela Transactions com tipos diferentes da Tela 1: agora aparece "Add" (em verde, ações de LP add) + "Remove" misturado com Sell/Buy — mostra que o pool tem fluxo bidirecional (LP-side e trader-side).
• Section Links no rodapé (visível após scroll): label ETH / USDC + endereço 0x88e6…0572 + ícones copy/abrir.

Regras de negócio

• Marker "Active tick range" = tick onde swaps estão acontecendo agora (current price tick) — não é posição do user (o user nesta captura não tem posição populada ainda; está em fase de avaliação).
• Quando preço cai, pool absorve mais lado do token que caiu (ETH baixou → ETH subiu como reserva); a sidebar reflete em tempo real.
• Tabela de Transactions captura LP-side (Add/Remove) e trader-side (Sell/Buy) na mesma stream, sem filtro default.
• Section Links contém só pool (não detalha tokens individuais como em VisualizarPool #3 — possível inconsistência entre templates).

---

🟢 Insight 1 — Marker "Active tick range" sobre a curva conecta liquidez e preço no mesmo eixo visual. Tela 2 mostra a curva, Tela 3 anota onde o preço está. Iniciante decoda em 1 segundo: "o pico de liquidez está exatamente onde o preço está agora — então a maior parte dos LPs colocou tight range em torno deste preço". Sem o marker, a curva é um gráfico abstrato; com o marker, vira mapa. Padrão a herdar pra Kotai: visualizações pesadas de v3 precisam de âncora de localização explícita; sem ela, o gráfico se autocomenta mal.

🟢 Insight 2 — Tabela de Transactions mistura LP-side (Add/Remove) e trader-side (Sell/Buy) na mesma stream. Decisão pedagógica importante — sinaliza que o pool tem dois tipos de fluxo: gente entrando/saindo como LP (Add/Remove muda reservas e curva), e gente fazendo swap (Sell/Buy muda preço). Mesma tabela exposição combinada permite o user observar correlações ("um Remove grande antes do preço cair" — sinal de LP saindo antecipando movimento). Padrão a herdar — separar essas streams em tabelas distintas perde a correlação temporal.

🟢 Insight 3 — Atualização live de Pool balances revela a mecânica do AMM. Preço caiu de $2.359 pra $2.235 → ETH subiu de 30,6K pra 33,0K no pool. O user que vê os dois prints lado a lado decoda intuitivamente "quando ETH cai, o pool absorve mais ETH" — mecânica de constant product entendida por observação, não por leitura de whitepaper. Padrão a herdar — produto cripto deve revelar mecânica protocolar pela observação, não pela explicação textual.

---

🔴 Fricção 1 — Label "Active tick range" é ambígua: pode significar (a) tick atual da pool ou (b) range ativo da posição do user (estrutural — vetor de leitura errada)

• Atrito real: "Active tick range" em inglês carrega duas leituras possíveis. (a) Faixa de tick ativa do pool — o tick onde os swaps estão acontecendo agora (sentido correto desta captura, já que o user não tem posição). (b) Faixa ativa da minha posição — onde minha liquidez está fornecendo fee (sentido se eu tivesse posição). A captura está no estado (a), mas o label não exclui (b). A análise rasa anterior do canvas inclusive diagnosticou errado essa label como "posição do user sobreposta à curva" — o que confirma a ambiguidade. Em produto onde o user às vezes tem posição e às vezes não, a mesma label significa coisas diferentes — modelo mental quebra na transição.
• Por que a solução óbvia falha: trocar pra "Current price tick" perde o conceito de "range" (que é central em v3); trocar pra "Your active range" é mentira quando o user não tem posição.
• Alternativa: label dinâmica conforme estado do user — quando user não tem posição: "Preço atual" + tick em pequeno; quando user tem posição in-range: "Sua posição (in-range)" + range visível em color overlay; quando user tem posição out-of-range: "Sua posição (fora do range)" + cor de alerta. A mesma marca visual carrega significado diferente, sinalizado por copy explícito. Trade-off: lógica de estado mais complexa; ganho: zero ambiguidade.
• Perfil afetado: iniciante (principal — alvo direto de má leitura) + intermediário descuidado.
• Família com 🔴 Fricção 1 de VisualizarPool #2 (ordem do par invertida sem âncora) — mesma raiz: produto carrega rótulo único para estados semanticamente diferentes.

🔴 Fricção 2 — Mudança de preço entre Tela 2 e Tela 3 (2.359 → 2.235, queda de 5,3%) sem âncora temporal (cosmética — para uso analítico do canvas; estrutural — para user real)

• Atrito real: prints sequenciais mostram preço diferente. Pra leitura analítica do canvas, isso é ruído (capturas em momentos diferentes). Pra user real, isso significa que a página atualiza em tempo real e o que ele leu há 1 minuto pode estar desatualizado. Em decisão de aportar, queda de 5% em segundos é movimento relevante — o user precisa saber "esse preço é de quando?". Não há timestamp visível indicando frescor do dado.
• Por que a solução óbvia falha: timestamp "Última atualização: 8:43 PM" em letra pequena é dismissado; refresh visual constante (pulse) é distraente.
• Alternativa: timestamp relativo discreto colado às conversões — "1 WETH = 2,235 USDC · há 3 seg" — atualiza ao tempo real, sinaliza frescor sem distrair. Trade-off: mais texto perto da conversão; aceitar pelo trust signal.
• Perfil afetado: iniciante + intermediário em sessão prolongada.

🔴 Fricção 3 — Section "Links" tem só pool address; tokens individuais não estão listados (estrutural — inconsistência com VisualizarPool #3)

• Atrito real: em VisualizarPool #3 a section Links lista 3 entradas: pool (WISE/ETH), token WISE, token WETH. Aqui só aparece 1 entrada (pool ETH/USDC). Provavelmente os tokens estão abaixo na page (corte da captura) ou — pior — a section foi simplificada nesta versão da pool detail e perde a separação pedagógica que VisualizarPool #3 acerta. Sem confirmação de scroll completo, não posso afirmar qual; mas se for o segundo caso, é regressão da pedagogia "pool ≠ token" identificada como Insight 4 de VisualizarPool #3.
• Por que a solução óbvia falha: se a omissão é intencional (page de pool live só mostra pool, page de pool morto mostra tudo), é decisão editorial estranha; mais provável é inconsistência de template entre v2 (VisualizarPool) e v3 (PosPop).
• Alternativa: padronizar — sempre mostrar pool + token A + token B em qualquer pool detail. Pareado com 🟡 "Header POOL / TOKEN como eyebrow" (VisualizarPool #3 oportunidade 2).
• Perfil afetado: iniciante.
• Família com Insight 4 + Fricção 3 + 🟡 Oportunidade 2 de VisualizarPool #3 (rotulagem semântica de contratos).

---

🟡 Oportunidade competitiva — Simulador de posição direto na curva (clicar na curva = "se eu colocasse range aqui...")

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3, KyberSwap — exibem a curva de liquidez como objeto de leitura, não de interação. User clica? Nada acontece. Para simular, precisa abrir o flow de criar posição.
• Por que afeta o target: iniciante quer experimentar "e se eu colocasse aqui?" antes de se comprometer com o flow de criação. A curva é a ferramenta perfeita pra essa exploração — ela já mostra onde tem competição e onde não. Mas é estática. Toda a capacidade exploratória existe; só a interação está faltando.
• 4 perguntas-teste: (1) ✓ todos os concorrentes tratam curva como leitura (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = curva é normalmente componente de visualização (D3, recharts), interação exige rebuild como tool (4) ✓ ganho perceptível — clicar na curva mostra "se você colocasse range aqui (entre X e Y), capital necessário = Z, APR estimado = W%".
• Hipótese de diferenciação: brushable curve — drag horizontal sobre a curva define um range candidato; popover flutuante mostra APR estimado + capital necessário + chance de ficar in-range próximas 24h (baseado em volatilidade histórica). Botão "Criar essa posição" pula direto pra Etapa 2 do Nova Posição com range já preenchido.
• Trade-off: custo de UI alto (interação + cálculo + popup); risco de simulação errada gerar promessa quebrada.
• Leverage estrutural — vira ferramenta de descoberta de range, não só de visualização. Família consolidada com 🟡 "APR estimado por range" (PosPop #1) + "Anotações pedagógicas inline" (PosPop #2) + "Card de pré-visualização" (Nova Posição #2). As três peças formam um sistema: anotações descrevem zonas, APR-por-range quantifica retorno, brushable curve permite exploração. Implementadas juntas, viram tese de produto "Kotai te deixa simular antes de aportar" — diferenciação clara contra Uniswap/PancakeSwap.

---

Observação adicional — flow capturado é "user sem posição". As 3 telas todas mostram o pool detail no estado "user não tem posição neste pool" (não há LP overlay no chart, não há card "Suas posições" na sidebar). Pra uma pasta chamada "PosicaoPopulada", isso é estranho semanticamente — o nome sugere "user já tem posição populada", mas as 3 primeiras capturas mostram o pré-aporte. Provavelmente o flow inteiro (1–17) é "como populamos uma posição neste pool", e 1–3 = entrypoint, 6–15 = criação, 16–17 = confirmação. Faz sentido como rebobinamento, mas vale registrar pra futura organização do canvas — a pasta poderia se chamar "FlowLPv3" ou "CriacaoPosicao" pra refletir o flow completo, não só o estado final.

2. Posição Populada — Pool Detail em Liquidity (curva de distribuição)

Função: mesma page de detail, agora com tab Liquidity ativa. Substitui o histogram de Volume da Tela 1 pela curva de distribuição de liquidez por tick — ferramenta canônica de v3 pra LP decidir range. Big stat de Volume sai; conversões de preço atual entram no topo.

Componentes (diff em relação à Tela 1)

• Tabs: Price / Volume / **Liquidity** ✓ (mudou).
• Saiu: big stat $805.2K + data.
• Entrou no topo do chart: conversões 1 WETH = 2,359 USDC + 1 USDC = 0,0004239 WETH.
• Chart agora é curva de liquidez em forma de "agulha alta + cauda à direita" — distribuição com pico estreito no tick atual e densidade decaindo conforme distância do preço corrente. Eixo X = preço; eixo Y = quantidade de liquidez por tick.
• Sidebar idêntica (Total APR 47,16% / Pool balances 30,6K ETH | 59,7M USDC / TVL / Volume / Fees).
• Tabela Transactions idêntica.

Regras de negócio

• Curva = soma de todas as posições v3 ativas no pool, agrupadas por tick.
• Picos altos = ranges populares onde muitos LPs concentraram capital (mais competição por fee, mas mais chance de estar in-range).
• Vales = ranges com pouca liquidez (menos competição, mas se preço chegar lá, fee dispara — e o LP precisa estar lá no momento certo).
• Conversões duplicadas (WETH→USDC e USDC→WETH) garantem que o user não precisa inverter mentalmente o ratio.

---

🟢 Insight 1 — Conversões bidirecionais (1 WETH = 2,359 USDC + 1 USDC = 0,0004239 WETH) eliminam o cálculo mental. Iniciante que pensa "tenho 100 USDC, quanto é em WETH?" não precisa inverter 2,359 — vê direto 0,0004239 × 100 = 0,042 WETH. Decisão de copy aparentemente pequena que economiza fricção real. Padrão a herdar pra Kotai: quando uma razão pode ser lida em duas direções (preço/preço inverso), exibir ambas é mais barato que assumir que o user inverte mentalmente.

🟢 Insight 2 — Curva em "agulha" comunica visualmente que esse pool é hiper-concentrado no preço atual. A forma do gráfico é a mensagem: pico estreito = capital concentrado no tick atual; cauda longa = pouca liquidez nas margens. LP novo vê em 1 segundo: "a maior parte dos LPs apostou aqui mesmo". Não precisa ler eixo nem entender unidade pra absorver a informação principal. Padrão a herdar — gráfico cuja forma carrega a primeira camada de informação reduz dependência de legibilidade técnica.

---

🔴 Fricção 1 — Curva de liquidez sem legenda explicando o que cada eixo significa (estrutural — visualização poderosa mas ilegível pra iniciante)

• Atrito real: o user vê uma curva com pico altíssimo e cauda longa, mas sem rótulos nos eixos. Y é quantidade de liquidez em USD? Em token A? Em token B? X é preço de ETH em USDC? Em ticks? Em log? Sem legenda, o iniciante absorve só a forma (Insight 2 acima) — mas não consegue ler magnitudes. "O pico tem 100 milhões ou 10 milhões? A cauda à direita vai até 5,000 USDC ou 3,000?". A diferença é decisória — define se o user aporta full range, tight, ou em algum vale específico.
• Por que a solução óbvia falha: rótulos cheios nos eixos (Liquidity (USD), Price (USDC per ETH)) com gridlines numeradas poluem o gráfico abstrato; perdem a leveza da "agulha".
• Alternativa: eixo X com 3 ticks numerados (preço mínimo visível, preço atual marcado com setinha, preço máximo visível) — não polui mas ancora a leitura horizontal. Eixo Y só com valor do pico ("máx: $X em liquidez") como anotação no próprio pico, não como gridline. Trade-off: ainda não é gráfico totalmente legível tecnicamente, mas dá o suficiente para decoda "quanto" + "onde".
• Perfil afetado: iniciante (principal — ele é quem mais precisa ler magnitudes) + intermediário sem familiaridade com v3.
• Família com 🟡 "Pedagogia narrativa do chart" (VisualizarPool #2) — aqui o gráfico precisa de pedagogia estrutural (eixos + ancoragem), não só narrativa (caption). Mesma raiz, dimensão diferente.

🔴 Fricção 2 — Sem marcador visível do preço atual sobreposto à curva (estrutural — informação ausente no momento crítico)

• Atrito real: a curva existe, mas onde está o preço atual nela? Na Tela 3 do mesmo flow aparece uma linha vertical rosa cortando o pico — marcador claro. Nesta Tela 2 esse marcador não está visível (ou é muito sutil). Sem marker, a "agulha" perde âncora — o user não sabe se o preço atual está exatamente no topo do pico, ligeiramente à direita, ou já entrando na cauda. Em v3 essa diferença é decisória: posição que abrange o preço atual está in-range (ganha fee); posição que não abrange está out-of-range (não ganha nada).
• Por que a solução óbvia falha: marker permanente pode poluir; marker animado distrai.
• Alternativa: linha vertical fina com a cor do tema (rosa Uniswap) sempre visível + label ~$2.359 colado no topo da linha. Igual à Tela 3, que já tem isso — então a fricção pode ser na verdade inconsistência entre Tela 2 e Tela 3 do mesmo template (a Tela 3 mostra a curva com marker, esta não — possivelmente porque foram capturadas em momentos diferentes do mesmo carregamento). Vide observação adicional.
• Perfil afetado: iniciante (principal).

🔴 Fricção 3 — Tab Liquidity muda o chart e o stat principal sem aviso visual (cosmética; quebra de modelo de tabs)

• Atrito real: convenção universal de tabs é "muda só o conteúdo do painel, mantém o resto". Aqui ao trocar de Volume pra Liquidity, sai também o big stat $805.2K do canto superior do chart e entra as conversões 1 WETH = 2,359 USDC. User espera que mudar tab só mude o gráfico, e percebe (ou não) que o KPI grande sumiu. Tela 1 = Volume + número do dia; Tela 2 = Liquidity + conversões; provavelmente Tela Price = Preço + preço atual. Cada tab tem sua "âncora numérica" — decisão arquitetural defensável mas não anunciada.
• Por que a solução óbvia falha: manter $805.2K em todas as tabs perde semântica (volume não faz sentido como hero em Liquidity); manter o slot vazio em Liquidity vira buraco visual.
• Alternativa: manter o mesmo slot mas com label dinâmica — Volume tab: $805.2K Apr 12 volume; Liquidity tab: ~$2.359 preço atual; Price tab: idem. A "âncora numérica" muda com a tab, mas o slot permanece previsível. Trade-off: exige decisão de "qual é o number representativo de cada tab" (já existe implicitamente; só precisa formalizar).
• Perfil afetado: intermediário (principal — quem usa as 3 tabs em sequência) + iniciante que confunde "perdi um dado".

---

🟡 Oportunidade competitiva — Anotações pedagógicas inline na curva de liquidez

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3, KyberSwap Elastic — exibem curva de liquidez como visualização técnica nua. Sem anotações, sem zonas de oportunidade, sem indicação de "onde os bots dominam vs onde tem espaço". A curva entrega informação correta mas a leitura fica por conta do user.
• Por que afeta o target: iniciante v3 não sabe que (a) pico altíssimo = muita competição → fees individuais menores; (b) vales = pouca competição → se preço chegar lá, fee é desproporcional; (c) cauda longa direita = otimismo dos LPs com preço subindo. Esses três insights são o que faz LP profissional ganhar 5–10× LP amador. Sem pedagogia, o iniciante interpreta "pico alto = lugar bom" (errado) ou "vou colocar no pico" (errado pela mesma razão).
• 4 perguntas-teste: (1) ✓ todos os concorrentes deixam a curva crua (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = receio de soar editorial sobre estratégia de LP + custo de heurística (4) ✓ ganho perceptível — anotações tipo "Capital concentrado: ±$50 do preço atual" e "Espaço com pouca competição: $2,500–3,000" mudam a leitura imediatamente.
• Hipótese de diferenciação: sobre a curva, 3-4 anotações em badges discretos (sem cobrir o gráfico) — "Tick atual: $2.359" / "Range mais populado: ±0,5%" / "Cauda otimista: $2.500–3.500" / "Vale de pouca competição: $1.800–2.000". Cada badge clicável vira filtro/modo de exploração.
• Trade-off: anotações são opinião sobre o gráfico (mesmo eixo da 🟡 "narrativa do chart" do VisualizarPool #2). Risco editorial: chamar zona de "otimista" carrega valor. Aceitar com label técnica neutra ("LPs apostaram acima do preço atual") em vez de adjetivo carregado.
• Leverage alto — diferenciador específico de v3 LP. Família consolidada "transparência ativa para iniciante" + "narrativa do chart" — aqui é a manifestação mais avançada (chart pesado, opinião editorial, alta densidade de informação implícita).

---

Observação adicional — capturas Tela 1 / Tela 2 / Tela 3 são prints em momentos diferentes, não estados do mesmo momento. O preço passa de $2.359 (Tela 2) pra $2.235 (Tela 3) com Pool balances mudando de 30,6K ETH pra 33,0K ETH. Esses dados não podem ser todos do mesmo instante. Pra análise do canvas/benchmark, isso é ruído de captura (não fricção do produto); pra Kotai vale registrar que prints sequenciais de telas live carregam armadilha analítica: comparações entre telas podem confundir mudança real do mercado com mudança de estado de UI.

Consolidado — Posição Populada (Uniswap)

Caráter geral do fluxo

O flow "Posição Populada" cobre o ciclo completo de LP v3 — avaliação de pool (1–3), hub de posições existentes (5), criação em stepper de 2 etapas (6–15), modal de revisão (16) e assinatura na wallet (17). É o flow mais longo e mais rico em decisões financeiras do benchmark Uniswap.

O produto é arquiteturalmente sofisticado: progressive disclosure em todas as camadas, defaults informados por comportamento agregado, re-cálculo client-side instantâneo, wizard não-destrutivo que preserva estado em todas as transições. Para o avançado, o flow é coerente.

Para iniciante e intermediário (nosso target), o atrito se concentra em três eixos que se repetem do início ao fim: variáveis acopladas (fee × range × APR × denominação) tratadas como decisões independentes em steps sequenciais; ausência de guard-rails semânticos (produto valida sintaxe, nunca plausibilidade); transições que avançam sem antecipar o passo seguinte. O iniciante entra com confiança — entrypoint limpo (1), CTA correto — encontra o maior atrito no Step 2 (9–12) e chega ao commit (16–17) sem calibração de expectativa.

O flow concentra a maior densidade de oportunidades competitivas de qualquer flow Uniswap analisado — especialmente no eixo "simulação antes de commit", onde múltiplas peças formam um sistema coerente de diferenciação.

---

🟢 Insights recorrentes

Progressive disclosure sistemática em todas as camadas de decisão — telas 1, 2, 3, 7, 8, 9, 10, 11, 13

Progressive disclosure não é recurso pontual — é o padrão arquitetural dominante do produto em todos os níveis. Na pool detail, as três tabs Volume → Liquidity → Active Tick (1, 2, 3) adicionam camadas sem quebrar as anteriores. No fee tier, 1 linha colapsada (7) expande em 4 cards com 3 dimensões de evidência (8). No range, Full/Custom como tabs de entrada (9) se desdobram em presets (10), drag no chart, e inputs textuais (11). Cada decisão tem superfície mínima no default e superfície máxima sob demanda. Padrão sistemático a herdar pra Kotai: feature complexa não precisa de tab dedicada — precisa de camada de disclosure sob demanda.

Hierarquia de CTA e vocabulário alinhados à intenção do funil — telas 1, 6, 9, 13, 16

O produto posiciona ações e vocabulário consistentemente pelo contexto de chegada, não pelo "verbo mais agressivo". Na pool detail, CTA primário é + Add liquidity (não Swap) porque quem aterrissa via Pools veio pra LP (1). No Step 2, default é Custom range (não Full range) porque o user escolheu v3 — concentrated liquidity é o ponto (9). No fim do Step 2, o botão diz Review (não Submit) — sinalizando que há mais um passo (13). No modal, diz Create (não Confirm) — vocabulário do LP, não do trader (16). Padrão a herdar: CTA primário herda a intenção do funil; label de CTA reflete a consequência, não o verbo técnico.

Equivalente USD e informações bidirecionais eliminando cálculo mental — telas 2, 5, 13, 14, 16, 17

Decisão de copy aparentemente pequena mas com impacto real: conversões bidirecionais 1 WETH = 2,359 USDC + 1 USDC = 0,0004239 WETH na pool detail (2) eliminam inversão mental. Min/Max em quote token (WETH/wTAO) no card de posição (5) é convenção saudável de par heterogêneo. Equivalente USD ao lado de todos os token amounts — ($1.000,00) / (~$487,10) no Step 2 (13) e $0.67 de gás na wallet (17) — ancora o usuário em fiat em todos os momentos críticos. Padrão a herdar pra Kotai: quando uma razão pode ser lida em duas direções, mostrar ambas; todo token amount exibe equivalente USD ao lado.

Múltiplas vias de input bidirecional com estado compartilhado — telas 7, 8, 9, 10, 11, 13, 14

Decisões críticas têm múltiplas vias de entrada sem poluir UI, porque coexistem na mesma tela e compartilham estado bidirecional. Fee tier: badge resumido (7) → 4 cards expandidos com label + TVL + share (8). Range: tab Full/Custom (9) → presets (10) → drag no chart → inputs textuais (11). Deposit: editar Min price no input numérico recalcula ETH no campo de depósito (13) — estado único, zero dessincronização (14). Padrão a herdar: decisão crítica com múltiplas vias de input, cada perfil tem caminho, todas as vias convergem no mesmo estado.

Escape contextual preservado — wizard não-destrutivo — telas 9, 10, 12, 13, 16

Em nenhuma transição o flow destrói o estado do user. Edit no header do Step 2 volta ao Step 1 sem limpar o range configurado (9). Reset está disponível pra desfazer range e zoom (12). Modal de review mantém o Step 2 visível por trás em overlay translúcido (16) — user pode cancelar e voltar com tudo preenchido. A Tela 16 confirma que o user explorou múltiplas configs de range antes de chegar no Review (16) — sinal de que o flow suporta exploração não-linear. Padrão a herdar: flows multistep preservam estado em toda etapa e oferecem re-entry contextual (Edit), não Back/Cancel.

Defaults informados por comportamento agregado, não opinião editorial — telas 7, 8

Quando o produto pré-seleciona, o critério é fato observável, não julgamento editorial. Fee tier default = tier de maior TVL no par (7). Badge Highest TVL em vez de Recommended ou Best — descritivo, não prescritivo (8). Distribuição completa de share (77,985% select / 16,685% / 5,715% / 0,007%) devolve agência ao user — ele vê a convenção, decide se segue. Padrão a herdar: quando produto pré-seleciona por popularidade, mostrar a distribuição completa (não só o vencedor) preserva escolha informada.

---

🔴 Fricções recorrentes

Estrutural — APR semanticamente inaplicável à decisão real — telas 1, 5, 7, 8

O flow apresenta múltiplos APRs — todos calculados corretamente, todos com semântica inaplicável à decisão que o user está prestes a tomar.

Total APR 47,16% em fonte gigante na pool detail (1) é média ponderada da pool inteira. Em v3 (concentrated liquidity), o APR real de uma posição depende fortemente do range escolhido: LP tight pode ganhar 10× o APR médio se ficar in-range; LP full range ganha menos que a média. O number 47% não promete nada a uma posição específica — mas a fonte gigante induz FOMO no iniciante. Na Tela 5, APR 40,06% no card de posição (5) ignora impermanent loss — posição pode ter ganhado $1.142 em fees e perdido $2.000 em IL. No Step 1, o fee tier default 0,05% é o de maior TVL (7), mas 0,05% é o tier de menor fee por trade — ideal pra LP full range, subótimo pra LP tight. O default "correto" em TVL é incorreto em APR para a estratégia de range que o iniciante provavelmente vai escolher. Na expansão dos fee tiers (8), o APR histórico por tier está ausente — o user vê TVL e share, mas não retorno.

Nota: os blocos das telas 5 e 8 são 🟡 (oportunidade) nos drafts de origem — a fricção de APR opaco emerge do contexto das oportunidades identificadas nessas telas; a atribuição cruzada é intencional.

Raiz comum: produto apresenta APR como métrica isolada, mas APR em v3 é uma função de três variáveis acopladas — range, fee tier e capital. Apresentar qualquer das três sem as outras duas é entregar número correto com semântica errada.

Solução estrutural: substituir Total APR na pool detail por par de numbers — "APR full range: X% / APR tight (±1%): Y%" (1). No card de posição, acrescentar IL estimado ao APR (5). No Step 1, vincular a sugestão de fee tier à estratégia de range que o user vai escolher no Step 2 (7). Trade-off: cálculo de APR por range exige pricing engine client-side + caveat de variabilidade. Aceitar com caveat explícito. Perfil afetado: iniciante (principal — único alvo direto de FOMO por número opaco) + intermediário sem heurística de concentrated liquidity.

Estrutural sistêmico — Produto aceita configuração subótima silenciosamente — telas 10, 11, 14, 15

A fricção de maior frequência do flow, com 4 manifestações cross-lote e raiz única: produto valida sintaxe (min < max, valor > 0) mas nunca valida semântica ("essa config faz sentido financeiramente?").

Manifestações em sequência: (1) clicar em preset Stable (±3 ticks) estando na tab Full range muda a tab para Custom silenciosamente (10); (2) range assimétrico -1,85% / +124% — bound inferior muito tight (preço sai em horas), bound superior absurdo (124% acima) — aceito sem comentário (11); (3) aumentar Max price aumenta o capital necessário em ETH silenciosamente — user tinha $1.487, agora precisa de $2.082, sem alerta de delta (14); (4) Max price = 26.071.406 (ETH a $26M, provavelmente typo) aceito com Review ativo — depositaria capital que nunca alcançaria o lado-ETH (15).

Em produto financeiro com transações on-chain irreversíveis, validação semântica não é detalhe de UX — é guard-rail essencial. O custo de um warning indevido (usuário power confirmando config intencional) é mínimo; o custo de ausência de warning (iniciante travando capital em range absurdo) é o capital em si.

Solução estrutural: Sanity Layer — sistema de warnings inline contextuais, ativados por heurísticas específicas: Max > 100× preço atual; range assimétrico > 10×; fee tier desalinhado com range (0,05% + tight = subótimo); capital a depositar > 80% do saldo da wallet; APR estimado < 0 (IL > fees projetadas). Cada warning com explicação + ação sugerida + override disponível. Trade-off: heurísticas podem ter falsos positivos em apostas legítimas (aceitar com toggle "Não mostrar de novo"). Perfil afetado: iniciante (crítico — único que comete typos e aceita configs quebradas sem perceber) + intermediário descuidado. Avançado: override sempre disponível, impacto nulo.

Estrutural — Decisões acopladas tratadas como independentes em steps sequenciais — telas 7, 9, 11, 12, 13, 14

O padrão estrutural de maior peso analítico do flow. Fee, range, APR, denominação e capital são variáveis matematicamente acopladas — mudar uma muda todas. O produto as apresenta como decisões sequenciais independentes.

Fee tier é escolhido no Step 1 (7) sem que o user saiba ainda qual será o range. Mas 0,05% (default) é subótimo para range tight; 0,3% é melhor para moderate; 1% para tight. Decisão de fee feita antes de decisão de range = acoplamento invertido. A denominação default no Step 2 (USDC ✓, mostrando 0,00045 WETH/USDC) é contraintuitiva para iniciante que pensa em $/ETH — confirmado empiricamente: o user trocou para ETH ✓ dentro do próprio flow (9), o que reflete em USDC/WETH = $2.233 na Tela 11 (11). Os markers de range são exibidos em % relativo (11) enquanto os inputs Min/Max price são em $ absoluto (12) — dois sistemas de coordenada na mesma tela. Ao ajustar Max price, o capital necessário muda (14) e a relação range↔deposit é exibida em sections visuais separadas (13) — user precisa olhar dois lugares ao mesmo tempo para entender o acoplamento.

Raiz arquitetural: o flow é herdado da semântica matemática de v3 (fee tier é propriedade da pool; range é propriedade da posição — são layers diferentes). O produto os expõe na mesma sequência da construção técnica, não da intenção do user.

Solução estrutural: inverter a ordem do Step 1 — perguntar estratégia (Full range / Moderate / Tight) primeiro, derivar fee tier como consequência. Denominação default = stablecoin-as-quote em pares com stablecoin (regra de roteamento). Markers com dual-label $ primário + % secundário. Sticky footer com total dinâmico + delta à cada mudança de range. Trade-offs: quebra paridade com Uniswap; requer regra de "stablecoin detection" para denominação. Perfil afetado: iniciante (principal) + intermediário sem heurística de concentrated liquidity.

Estrutural — Transições entre etapas sem antecipação do próximo passo — telas 6, 13, 16, 17

Padrão recorrente em todas as transições do flow. Continue no Step 1 não diz o que falta para habilitá-lo — botão cinza silencioso (6). Review no Step 2 não mostra resumo do que está sendo levado para revisão — user clica sem ter certeza do total (13). Create no modal não antecipa que abrirá um prompt externo de wallet — usuário se assusta com a mudança de contexto (16). A wallet recebe o user com vocabulário diferente (Simulation Results, Add Token 1, unknown NFT) sem mapeamento explícito do que ele configurou na Uniswap (17).

Raiz comum: produto trata cada tela como unidade autônoma em vez de etapa de uma cadeia com promessa implícita. CTAs avançam sem antecipar consequências.

Solução estrutural: label dinâmico no Continue descrevendo o que falta (Selecione o segundo token → / Escolha o fee tier →) (6); sticky footer com total + APR estimado antes do Review (13); Create position (1 wallet signature required) como label do CTA no modal (16); microcopy de bridge semântica antes do Create — "Sua carteira mostrará 'Add Liquidity', 'Simulation Results' e 1 NFT representando sua posição" (17). Perfil afetado: iniciante (principal em todas as manifestações).

Estrutural — Versão como atributo invisível — telas 1, 6, 7

O produto empurra conceitos de versão (v2/v3/v4) sem dar contexto para decidir. Tab Liquidity na pool detail (1) aparece como peer visual das tabs Volume e Price, sem badge "Exclusivo de v3" — usuário de v2 não sabe que está entrando em território novo. No flow de criação, o dropdown v4 position no header global compete com o stepper Step 1: Select token pair como "primeiro passo" (6) — dois sistemas de navegação no mesmo nível visual, sem hierarquia. Trocar de v4 para v3 remove affordances silenciosamente: + Add a Hook (Advanced) some sem microcopy explicando a perda de capacidade (7).

Solução: onboarding contextual na primeira vez que o user clica em Liquidity (tooltip com 1 frase + link "Saiba mais") (1); card-comparador de versões no início do flow de criação em vez de dropdown nu (6); microcopy dinâmica embaixo do dropdown descrevendo o que cada versão inclui ou perde (7). Perfil afetado: iniciante (principal) + intermediário vindo de v2.

Estrutural — Labels ambíguas por estado do produto — telas 1, 3, 5, 17

Produto reutiliza label único para estados semanticamente diferentes, transferindo o custo de decodificação para o user. Total APR não qualifica se é APR médio da pool ou APR de posição específica (1). Active tick range na curva de liquidez (3) pode significar (a) tick atual da pool (correto nessa captura — user sem posição) ou (b) range ativo da posição do user (quando user tem posição) — a análise prévia do canvas diagnosticou errado por exatamente essa ambiguidade, confirmando o problema. + New no header da seção de posições (5) diz apenas "Novo" — nova posição? novo pool? nova carteira? Em outro ponto do mesmo produto (/pool/nova) o label é + Nova posição. Na wallet, +1 unknown com badge NFT (17) rotula como desconhecido o NFT que é a posição LP — causa raiz na wallet, mas mitigável por antecipação no modal de review.

Solução: label dinâmico por estado (Active tick range → Preço atual quando user sem posição; Sua posição (in-range) / Sua posição (fora do range) quando user tem posição); + New position completo com movimentação de filtros para ícone colapsado; antecipação do NFT no modal de review. Perfil afetado: iniciante (principal).

Estrutural — Denominação contraintuitiva como default (evidência empírica) — telas 9, 11

O Step 2 abre com toggle USDC ✓ como default (9), mostrando 0,00045 WETH/USDC — i.e., quantos WETH por 1 USDC. Em par com stablecoin, a direção convencional cripto-nativa é $X por ETH (stablecoin como quote), que o toggle ETH ✓ entregaria como $2.233 USDC/WETH. Essa fricção não é hipótese: o user trocou o toggle dentro do próprio flow — a Tela 11 (11) mostra ETH ✓ ativo e USDC/WETH ($2.233,08) como denominação, evidência observacional direta de que o default era contraintuitivo. Raiz: produto usa token0 do contrato (USDC) como referência padrão — decisão arquitetural correta internamente, semanticamente confusa para usuário.

Solução: default de denominação = stablecoin-as-quote em pares com stablecoin; regra de roteamento detecta stablecoin no par e inverte automaticamente. Trade-off: requer detecção de stablecoin no client; ganho: iniciante vê o preço que ele conhece desde a Tela 1. Perfil afetado: iniciante (principal) + intermediário em pares heterogêneos.

Estrutural — Jargão técnico não-traduzido e i18n descosturado — telas 1, 8, 11, 15

Família de fricções com raiz comum: produto não faz layer de tradução de terminologia técnica para o mental model do usuário-alvo. Toda a pool detail está em inglês (1) enquanto o flow de criação aparece em PT-BR — inconsistência de locale que quebra a âncora "estou no mesmo produto". % select nos cards de fee tier (8) é número preciso (4 casas decimais) sem unidade definida — % de posições? de TVL? de fluxo recente? As 3 interpretações existem e levam a decisões diferentes. Preset Stable: ±3 ticks (11) usa unidade tick — conceito de discretização de preço em v3 que iniciante nunca encontrou; os outros presets usam % humano (inconsistência de unidade entre peers visuais). Input de Max price sem separador de milhar (15) cria ambiguidade entre 26.071.406 e 2.607,1406 — ambiguidade que não se resolve visualmente e que o analista do próprio benchmark não conseguiu dirimir.

Solução: garantir locale consistente (ambos EN ou ambos PT-BR); % select → dos LPs escolhem este tier (explícito); ±3 ticks → ±0,03% com tooltip "equivalente a ±3 ticks"; formatação numérica on-blur com separadores de milhar conforme locale. Perfil afetado: iniciante (principal para jargão e locale) + todos (formatação numérica).

Estrutural — Produto confessa limitação via caption pequena em vez de resolver na arquitetura — telas 3, 5

Em dois pontos o produto usa o rodapé como confessionário. Na pool detail (3), a seção Links mostra só o endereço do pool sem os tokens individuais — enquanto em VisualizarPool #3 mostra pool + token A + token B. Provavelmente inconsistência de template v2 vs v3. Na hub de posições (5), caption pequena no rodapé admite "Some v3 positions aren't displayed automatically" + link "Import V2 positions" — dois problemas misturados (v3 com discovery automática falha; v2 exige import manual) sem ação concreta para o user entender se a posição dele está completa. Iniciante lê e perde confiança no dashboard: "será que falta algo?".

Solução: padronizar seção Links em todos os pool details (pool + token A + token B); separar as duas mensagens da caption em banners condicionais com contexto explícito e ação direta. Perfil afetado: iniciante (principal).

Cosmética — Precisão excessiva de token amounts em modo exploratório — telas 14, 15

0,45830405644617936 ETH (14) e 0,27425424248181698196… ETH (15) em contexto de exploração de range. Diferente da Tela 13 (finalização — onde precisão honesta é trust signal), aqui o user está em modo iterativo, ajustando range e vendo o ETH dançar com 17+ casas. Distração visual em momento crítico. Solução: display truncado (5 casas) por default com expand-on-hover para precisão completa + "Copiar valor exato". Perfil afetado: iniciante + intermediário em modo exploratório.

Cosmética — Reset com escopo ambíguo — telas 10, 12

Reset em Full range (10) é inerte (já está no máximo) mas presente — affordance que não faz nada quebra contrato implícito. No zoom-out (12) com range custom configurado, Reset pode resetar só o zoom, só o range, ou ambos — nenhuma das três é óbvia. Solução: Reset com dropdown inline ao clicar: [Resetar zoom] / [Resetar range] / [Resetar tudo]. Desabilitar em Full range com tooltip. Perfil afetado: todos os perfis.

---

🟡 Oportunidades competitivas do fluxo

Sistema I — "Kotai te deixa simular antes de aportar" — vistas em telas 1, 2, 3, 9, 11, 12, 13, 14

Padrão atual da indústria: Uniswap, PancakeSwap, KyberSwap, Curve — em todos, a simulação de APR/IL/probabilidade de in-range acontece depois do commit ou não acontece. APR estimado por range só existe dentro do flow de criação, nunca na pool detail. Presets de range são nomeados por forma geométrica (Stable/Wide/One-sided), não por resultado esperado. O chart histórico é estático — leitura passiva, não interação exploratória.

Por que afeta nosso target: o iniciante e intermediário tomam a decisão de range com base em "parece largo o suficiente?" — heurística que falha em par volátil. A sub-utilização de v3 (full range em pool concentrada) é endêmica e resulta em "v3 não rende como diziam". Ninguém resolveu porque exige investimento em modelo de volatilidade + engine de simulação client-side.

As 8 peças do sistema:

A1 — APR estimado por range na pool detail (1): slider de range embutido na sidebar de Stats da pool detail, com APR estimado atualizando ao deslizar. User compara full range → 8% vs ±2% → 45% sem entrar no flow. Diferenciação desde o entrypoint.

A2 — Anotações pedagógicas inline na curva de liquidez (2): sobre a curva, 3–4 badges discretos — "Tick atual: $2.359" / "Range mais populado: ±0,5%" / "Cauda com pouca competição: $2.500–3.500". Cada badge clicável vira filtro de exploração. Transforma visualização passiva em mapa de decisão.

A3 — Brushable curve / Simulador na curva (3): drag horizontal sobre a curva define range candidato; popover mostra APR estimado + capital necessário + chance de in-range nas próximas 24h (baseado em volatilidade). Botão "Criar essa posição" pré-preenche o flow. Converte leitura em exploração.

A4 — Presets probabilísticos de range (9): substituir presets por forma (Stable/Wide) por presets por risco — Conservador (95% in-range 24h) / Equilibrado (80%) / Agressivo (50%). Range como decisão de risco, não de geometria.

A5 — Slider probabilístico com tooltip vivo (11): ao arrastar marker de range, popover mostra em tempo real: Probabilidade in-range (24h) + APR estimado + IL estimado no pior cenário. Cada adjusto tem consequência quantificada.

A6 — Backtest visual do range contra histórico (12): botão Simular nesse histórico no chart — roda backtest do range escolhido contra a janela visível. Resultado: fees acumuladas, IL final, % in-range, número de reposicionamentos necessários. Validação passada antes do commit.

A7 — Capital efficiency vs full range (13): linha extra abaixo do total — "Capital efficiency: 10× vs full range" + mini-bar comparando capital escolhido ($1.487) vs equivalente full range ($14.000). User entende v3 em número concreto no momento de commitment.

A8 — Modo "Capital fixo" (14): toggle Por range (avançado) vs Por capital (sugerido). User define $X total + perfil de risco, sistema sugere range ótimo. Inverte o paradigma para quem pensa em fiat, não em ticks.

Passa nas 4 perguntas-teste (cada peça individualmente): (1) ✓ todos os concorrentes adiam simulação para o flow ou omitem completamente; (2) ✓ afeta iniciante e intermediário diretamente; (3) ✓ razão = investimento em modelo de volatilidade + engine client-side; (4) ✓ ganho perceptível — user vê probabilidade e APR estimado antes de clicar "Create".

Trade-off: todas as peças dependem de pricing engine client-side; APR estimado carrega risco de promessa quebrada (aceitar com caveat "baseado em últimos 30 dias"). Implementação incremental recomendada: A1 (slider na pool detail) primeiro — menor custo, maior visibilidade de diferenciação.

Leverage estrutural máximo — define o posicionamento "Kotai te deixa simular antes de aportar" como tese de produto. Junto com o Sistema II, forma a narrativa "Kotai é o DeFi que te diz a verdade".

---

Sistema II — "Kotai te diz a verdade, mesmo quando ela é não-aportar" — vistas em telas 5, 10

Padrão atual da indústria: Uniswap, PancakeSwap, Balancer — cards de posição exibem fees acumuladas e APR sem IL (5). O comparativo LP vs hold está ausente em todas as plataformas (10). Razão não-técnica: mostrar que "talvez hold seja melhor" reduz TVL — conflito de interesse sistêmico.

B1 — Health Score de posição (5): score 1–10 no card de posição agregando in-range %, fees acumuladas, IL atual e adequação do range para a volatilidade observada. Tooltip detalhando componentes. Score baixo dispara CTA "Otimizar posição →" com sugestão de range corrigido. Converte dado bruto em julgamento acionável.

B2 — Comparativo LP vs hold (10): mini-tabela abaixo dos presets — 3 linhas: Hold simples ETH+USDC 50/50, LP Full range, LP Custom (sugerido) — com APR estimado e % chance de perder vs hold. Honestidade radical: produto admite que LP não é sempre a resposta.

Passa nas 4 perguntas-teste: (1) ✓ todos os concorrentes evitam o comparativo (conflito comercial); (2) ✓ afeta iniciante e intermediário; (3) ✓ razão = conflito de interesse, não impossibilidade; (4) ✓ ganho perceptível e diferencial reputacional enorme.

Trade-off: B1 exige custódia de preço de entrada para calcular IL (dados históricos do user). B2 é estrategicamente perigoso (produto recomenda não usar o produto quando não vale a pena) mas reputacionalmente diferencial — mesma jogada do Vanguard contra fundos ativos.

Leverage estrutural alto — define posicionamento "Kotai é o único DEX que te diz quando não vale a pena ser LP".

---

Sistema III — "Kotai te protege de erros que Uniswap deixa você cometer" — vistas em telas 11, 15, 16, 17

Padrão atual da indústria: Uniswap, PancakeSwap, KyberSwap — validam sintaxe de inputs, fazem recap de inputs no review, delegam simulação para a wallet. Ninguém faz guard-rails semânticos ou antecipa o conteúdo da wallet dentro do produto.

C1 — Sanity Layer (validação semântica de inputs) (15): sistema de warnings inline ativados por heurísticas: Max > 100× preço atual; range assimétrico > 10×; fee tier desalinhado com range; total > 80% do saldo; APR estimado < 0. Cada warning com explicação + ação sugerida + override sempre disponível. Último guard-rail antes do commit on-chain irreversível.

C2 — Modal de review como "contrato visual" com expectativas calibradas (16): acrescentar ao modal de review uma seção "What to expect" — APR estimado, fees esperadas (30d), % chance de in-range — e 3 cards de cenário (preço estável / +20% / −20%) mostrando valor final da posição + ganho/perda. User assina com mental model calibrado.

C3 — Pré-simulação da tx dentro do produto (17): antes de chamar a wallet, Uniswap chama RPC e mostra o mesmo conteúdo de Simulation Results + decode da call que a wallet mostrará — gás estimado, NFT explicado ("representa sua posição, não é colecionável"), Price Diff. Produto controla a expectativa; wallet vira mero assinador sem surpresa.

Passa nas 4 perguntas-teste: (1) ✓ todos os concorrentes validam só sintaxe e fazem recap no review; (2) ✓ afeta iniciante e intermediário; (3) ✓ razão = investimento em heurísticas + custo de RPC; (4) ✓ ganho perceptível — zero capital travado em range absurdo, zero choque cultural na transição para wallet.

Trade-off: C1 pode ter falsos positivos em apostas legítimas (aceitar com override e "não mostrar de novo"). C3 tem custo de RPC e risco de divergência de gás (aceitar com caveat).

Leverage estrutural alto — define posicionamento "Kotai é o DEX que não te deixa cometer erros caros".

---

Card-comparador de versões no início do flow — tela 6

Padrão da indústria: Uniswap, PancakeSwap, Curve — múltiplas versões/tipos via dropdown nu (label + label + label), sem contexto comparativo (6). Iniciante não sabe que v4 = hooks + custom logic, v3 = concentrated liquidity, v2 = full range.

Hipótese de diferenciação: modal "Escolha sua versão" no início do flow — 3 cards lado a lado com 1 frase resumo + caso de uso + indicador de complexidade (1–3 estrelas). Default pode continuar v4, mas com escolha informada.

Passa nas 4 perguntas-teste: (1) ✓ todos usam dropdown nu; (2) ✓ afeta iniciante e intermediário; (3) ✓ razão = produto trata versão como detalhe técnico; (4) ✓ ganho perceptível.

Trade-off: mais 1 step antes do flow real. Risco editorial de "qual versão recomendar" (Uniswap empurra v4; Kotai pode empurrar v2 ou v3 como mais seguro para iniciante).

---

Fee tier vinculado à estratégia de range — tela 7

Padrão da indústria: Uniswap, PancakeSwap, KyberSwap — fee tier escolhido no Step 1, antes do range, via TVL ou share (7). Decisão de fee feita antes de decisão de range inverte a dependência real.

Hipótese de diferenciação: inverter o Step 1 — perguntar "Qual estratégia?" com 3 cards (Full range — fee 0,05% / Moderate — fee 0,3% / Tight — fee 1%). Fee como consequência da estratégia, não escolha primária. Override "Custom fee tier" para avançado.

Passa nas 4 perguntas-teste: (1) ✓ todos separam fee de range; (2) ✓ afeta iniciante e intermediário; (3) ✓ razão = arquitetura herdada de v3 launch; (4) ✓ ganho perceptível.

Trade-off: quebra paridade com Uniswap; risco de ancorar usuários em 3 estratégias rígidas. Aceitar com escapatória para power user.

---

APR histórico por tier nos cards de fee — tela 8

Padrão da indústria: Uniswap, PancakeSwap, KyberSwap — cards de fee tier mostram TVL e share, não APR histórico (8). Decisão de fee por proxy (liquidez) em vez de retorno direto.

Hipótese de diferenciação: 4ª linha em cada card — "APR médio (30d): X%" usando mediana de posições de cada tier. CTA "Simular APR no meu range →" no card.

Passa nas 4 perguntas-teste: (1) ✓; (2) ✓; (3) ✓ razão = APR depende de range, custo de cálculo; (4) ✓ com caveat — o "APR médio por tier" carrega a mesma armadilha do "Total APR" da Tela 1 (número único mascara variabilidade por range). Esta é a pergunta mais fraca — aceitar com caveat explícito + entrada para simulação personalizada.

Trade-off: risco de reintroduzir a Fricção 1 ("APR opaco") em outro nível. Aceitar somente se acompanhado de caveat visível e link pra simulação por range.

---

Pontos isolados (1 tela)

• 🟢 Tela 3: marker "Active tick range" sobre a curva de liquidez conecta curva e preço no mesmo eixo — âncora visual que transforma gráfico abstrato em mapa de decisão.
• 🟢 Tela 7: fee tier pré-selecionado por Highest TVL com badge descritivo (não prescritivo) — default sensato sem mentira editorial.
• 🟢 Tela 13: 0,20528138691144813 ETH em 17 casas decimais ao finalizar — honestidade sobre precisão de cálculo; user sabe que o produto não arredondou o que cobra.
• 🟢 Tela 14: re-cálculo one-at-a-time (input editado = âncora, token recalcula) — evita loop de "todos os campos dançam". Padrão a herdar em formulários acoplados.
• 🟢 Tela 17: wallet faz simulação pré-execução + decodificação semântica da call — UX de wallet madura; Kotai deve antecipar o mesmo conteúdo dentro do modal de review (vide Sistema III).
• 🔴 Tela 5 (estrutural, 1 tela) — Hierarquia visual invertida: promoção de protocolo acima de gestão de posição. Slot prime da hub de posições (acima do fold, antes de "Your positions") ocupado pelo card 0 UNI / Rewards earned sem valor para o user com 0 rewards. Inversão condicional: quando user tem 0 rewards E posição existente, Your positions vira hero e card de rewards colapsa para linha de descoberta ("Você pode ganhar UNI em algumas pools — explorar →"). Quando user tem rewards (1 UNI+), card retoma slot prime. Perfil afetado: iniciante + intermediário com posição populada.
• 🔴 Tela 10: microcopy "continuous market participation" glamouriza full range sem comparar com hold simples — em pares voláteis, LP full range frequentemente perde para hold. Estrutural, mas isolada a esta tela.
• 🟡 Tela 5: Banner Migrate to v4 quantificado com APR atual vs estimado v4 + custo de gás + payback. Leverage médio-alto, temporário (só enquanto v4 é nova).
• 🟡 Tela 17: Onboarding "primeira vez com wallet sign" — modal opcional antes de clicar Create explicando os 4 campos que a wallet mostrará, só para wallets sem histórico de add liquidity. Leverage médio, exclusivo para iniciante.

---

Drafts de lote em analises/uniswap/_consolidado/_drafts/posicao-populada-lote-1.md, -lote-2.md, -lote-3.md — mantidos como audit trail.

4. Etapa 2 — Estratégias de preço + presets de range

Função: Step 2 com chart histórico, presets de estratégia e inputs de preço Min/Max. User define a faixa de preço dentro da qual sua liquidez será ativa. Decisão central de v3 — onde concentrar capital.

Componentes

• Stepper à esquerda: Etapa 1 ✓ (concluída) / Etapa 2 ✓ (ativa) — Definir faixa de preço e valores de depósito.
• Chart de preço histórico com eixos Jan 17 / Jan 19 / Jan 21 / Jan 23 (4 datas visíveis).
• Toggle temporal: 1 dia / 1 semana ✓ / 1 mês / Todo o período + zoom in/out + Redefinir.
• Section Estratégias de preço com 4 cards horizontais:
  • Estável ± 3 ticks — "Indicado para estabelecer ou pares de baixa volatilidade".
  • Ampla -50% — +100% — "Indicado para pares voláteis".
  • Unilateral inferior -50% — "Fornecer liquidez se o preço cair".
  • Unilateral superior +100% — "Fornecer liquidez se o preço subir".
• Inputs:
  • Preço mínimo: 0,85 + (-0,45%) em vermelho + botões +/-.
  • Preço máximo: 1,0707927 + (+25,20%) em verde + botões +/-.
• Section abaixo: Depositar tokens + microcopy "Especifique os valores de token para sua contribuição de liquidez" + chips de % do saldo (0% / 25% / 50% / 75% parcialmente visíveis).

Regras de negócio

• 4 presets cobrem 4 teses de mercado: HODL estável / Growth volátil / DCA buy (cair) / DCA sell (subir).
• ± 3 ticks é unidade técnica v3 (≈ ±0,03% em pool 0,01%).
• % delta no input é relativa ao preço atual (0,85 ≈ -0,45% do preço atual; 1,07 ≈ +25,20%).
• Cor: vermelho = abaixo do preço atual (negativo), verde = acima (positivo).
• Inputs aceitam +/- ticks (incremento de tick boundary, não % livre).
• Botões +/- ajustam preço em 1 tick.
• Toggle temporal redimensiona o chart histórico, não muda janela de cálculo do range.

---

🟢 Insight 1 — 4 presets traduzem tese de mercado em geometria de range. User com tese ("acho que ETH vai subir") encontra Unilateral superior direto. Sem preset, decisão de range seria abstrata. Padrão a herdar pra Kotai — preset deve falar a língua da tese ("se o preço cair"), não da mecânica ("range one-sided lower").

🟢 Insight 2 — Cor + % delta no input dá ancoragem dupla. 0,85 (-0,45%) permite ler em preço absoluto OU em % relativo ao preço atual. Iniciante lê o number; intermediário usa o %. Padrão a herdar — input financeiro deve carregar 2 representações (absoluto + relativo).

🟢 Insight 3 — Chart histórico acoplado ao input de range materializa decisão geométrica. User vê "meu range cobre janeiro inteiro?" diretamente no chart. Sem visualização, decisão de range é cega. Padrão a herdar — input numérico crítico deve ter representação gráfica adjacente.

🟢 Insight 4 — Estratégias de preço como section dedicada (não dropdown) eleva presets a affordance principal. User vê os 4 simultaneamente, compara. Padrão a herdar — opções editoriais críticas devem competir em paralelo, não em dropdown sequencial.

---

🔴 Fricção 1 — Estável: ±3 ticks mistura unidade técnica com unidades % dos outros presets (estrutural — inconsistência de unidade entre presets do mesmo conjunto)

• Atrito real: os outros 3 presets usam % (-50% / +100%); apenas Estável usa ticks. User compara ± 3 ticks (incompreensível pra iniciante) com -50% — +100% (compreensível) e fica perdido. "Tick" é unidade de discretização do pool — implementation detail vazando pra UI. Iniciante não decoda; intermediário sabe que tick existe mas não sabe quanto vale em %.
• Por que a solução óbvia falha: traduzir pra ±0,03% perde a precisão de "boundary tick" (range precisa cair em tick boundary); manter ticks confunde majoritariamente.
• Alternativa: Estável: ±0,03% como label visível + tooltip "Equivalente a ±3 ticks (unidade mínima do pool)" pra avançado. Unidade % uniforme entre presets. Trade-off: perde tecnicidade em label; ganho: comparabilidade.
• Perfil afetado: iniciante (principal) + intermediário sem familiaridade v3.
• Família com fricção Stable: ± 3 ticks da PosPop #11 — mesma raiz, mesma alternativa.

🔴 Fricção 2 — Microcopy dos presets Unilateral inferior/superior invertem mental model do user (estrutural — copy técnica contra-intuitiva)

• Atrito real: "Unilateral inferior: -50% — Fornecer liquidez se o preço cair". Se eu acho que o preço vai cair, eu quero comprar barato = quero meu USDC vire VIRTUAL conforme o preço cai. Mas "unilateral inferior" pode ser lido como "aposto que vai cair" OU "meu range está abaixo do preço". A microcopy ajuda ("se o preço cair"), mas o nome do preset ainda exige decode. Para iniciante, "Unilateral superior +100%" pode soar como "+100% de retorno" — armadilha grave.
• Por que a solução óbvia falha: renomear pra "Aposta de alta / Aposta de baixa" carrega conotação especulativa que produto pode evitar; "Range acima / Range abaixo" perde a semântica de tese.
• Alternativa: renomear pra Acumular cripto (se cair) / Vender em alta (se subir) — descreve o resultado da posição, não a geometria. Iniciante entende imediatamente. Trade-off: labels mais longos; cabem se o card crescer 1 linha.
• Perfil afetado: iniciante (principal — único que confunde "+100%" com retorno).

🔴 Fricção 3 — Preço mínimo / Preço máximo em unidades brutas (0,85 / 1,07) sem indicar denominação ativa (cosmética — labels sem unidade explícita do par)

• Atrito real: 0,85 é USDC por VIRTUAL ou VIRTUAL por USDC? Pra par VIRTUAL/USDC com preço de mercado ~$0,85, o number 0,85 faz sentido como "USDC por VIRTUAL". Mas em pares ETH/USDC (preço $2000+), o user precisa decidir se o range é em ETH/USDC ou USDC/ETH — produto não exibe a denominação no label. Erro de denominação inverte a estratégia inteira (range que cobre alta de ETH vira range que cobre baixa).
• Por que a solução óbvia falha: label Preço mínimo (USDC por VIRTUAL) polui visualmente; tooltip é dismissado.
• Alternativa: adicionar sufixo USDC/VIRTUAL cinza pequeno abaixo do input + toggle pra inverter denominação no header da section. Trade-off: mais 1 linha; ganho: zero ambiguidade.
• Perfil afetado: iniciante e intermediário em pares não-óbvios (par estável-volátil como VIRTUAL/USDC é menos crítico que ETH/USDC).

---

🟡 Oportunidade competitiva — Presets com probabilidade in-range estimada exibida no próprio card

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3 — presets são labels geométricos sem retorno esperado nem risco quantitativo. User escolhe Ampla -50% — +100% sem saber se "ampla" significa "95% de chance in-range" ou "60%".
• Por que afeta o target: iniciante decide range estética/sentimentalmente ("parece largo o suficiente"); intermediário quer modelo. Sem dado, escolha vira chute.
• 4 perguntas-teste: (1) ✓ todos os concorrentes deixam presets como geometria pura (2) ✓ afeta iniciante e intermediário (3) ✓ razão = simulação probabilística exige modelo + cálculo (4) ✓ ganho perceptível — card Ampla mostra "~85% chance in-range (30d) / APR esperado: 18%" vs Estável mostra "~40% chance in-range / APR esperado: 60%".
• Hipótese de diferenciação: 3ª linha em cada card — P(in-range 30d): X% / APR esperado: Y%. User compara presets em retorno esperado vs risco. Combinado com 🔴 Fricção 2 (renomear pra tese), card vira "escolha de tese × probabilidade × retorno".
• Trade-off: modelo carrega risco (volatilidade muda); aceitar com caveat.
• Leverage estrutural alto — converte preset geométrico em preset probabilístico. Família consolidada com 🟡 "Slider probabilístico" (PosPop #11), 🟡 "Simulador no pool detail" (Tela 2), 🟡 "APR por range" (PosPop #1). Sistema acoplado.

---

Observação adicional — Redefinir do header reset o chart pra estado default, distinto do Redefinir da Tela 3 (que reseta par + tier). Mesmo label com escopo diferente entre telas — sutil mas pode confundir user que esperava reset global. Vale unificar semântica ou diferenciar label por escopo (Redefinir chart vs Redefinir tudo).

3. Nova Posição — VIRTUAL/USDC selecionado (Etapa 1)

Função: Step 1 do fluxo Nova posição com par VIRTUAL/USDC já pré-preenchido via deeplink da Tela 2 (Pool detail). User escolhe (ou confirma) o nível de tarifas antes de avançar pra configuração de range.

Componentes

• Breadcrumb: Suas posições / Nova posição.
• Header: Nova posição + Redefinir + dropdown Posição de v3 ⚙ (versão do protocolo).
• Stepper vertical à esquerda:
  • Etapa 1: Selecionar par de tokens e tarifas ✓ (ativa, círculo preenchido).
  • Etapa 2: Definir faixa de preço e valores de depósito (inativa, círculo vazio).
• Painel direito Selecionar par + microcopy "Escolha os tokens para os quais deseja fornecer liquidez. É possível selecionar tokens em todas as redes com suporte."
• 2 token selectors lado a lado: VIRTUAL ▼ + USDC ▼ (logos + ticker + dropdown).
• Section Nível de tarifas + microcopy "O valor ganho por oferecer liquidez. Escolha um valor compatível com sua tolerância a risco e estratégia."
• Card de fee tier: Nível de tarifas 0,3% + badge TVL máximo + microcopy "A porcentagem que você ganhará em tarifas" + botão Mais v (expandir).
• CTA Continuar (ativo, rosa primário).

Regras de negócio

• Par pré-preenchido via deeplink da Tela 2 — user veio do contexto da pool VIRTUAL/USDC.
• Default 0,3% selecionado por ser o tier com maior TVL do par (badge TVL máximo).
• Botão Mais v expande pra exibir os 4 tiers v3 canônicos (0,01% / 0,05% / 0,3% / 1%) com TVL e share por tier.
• Redefinir no header limpa par + tier (volta a estado vazio).
• Dropdown Posição de v3 ⚙ permite trocar pra v2 (sem fee tier configurável) ou v4 se disponível.
• Continuar só fica ativo com par + tier selecionados (ambos presentes via deeplink).

---

🟢 Insight 1 — Pre-fill via deeplink elimina re-trabalho de seleção. User veio da Tela 2 com decisão tomada; o produto carrega o contexto. Sem isso, user teria que re-selecionar 2 tokens + 1 tier — 3 decisões redundantes. Padrão a herdar pra Kotai — toda transição entre telas críticas deve preservar contexto via deeplink, nunca obrigar re-input.

🟢 Insight 2 — Stepper vertical com numeração + descrição completa de cada etapa funciona como sumário do fluxo. Etapa 1: Selecionar par e tarifas / Etapa 2: Definir faixa e depósito — user sabe o que vem depois antes de clicar Continuar. Sem stepper, user opera no escuro. Padrão a herdar — flows multi-step devem expor todas as etapas, não só o passo atual.

🟢 Insight 3 — Microcopy de cada section ("O valor ganho por oferecer liquidez...") é didática sem ser invasiva. Cor cinza, fonte menor, fica subordinada ao número. Iniciante lê; intermediário pula. Padrão a herdar — microcopy explicativa deve ter peso visual menor que a decisão que ela explica.

🟢 Insight 4 — Badge TVL máximo no card de fee tier comunica recomendação sem prescrever. Não diz "recomendado", diz "este tem mais TVL" — user decide se TVL alto importa pra ele. Padrão a herdar — produto deve mostrar o critério da recomendação, não a recomendação opaca.

---

🔴 Fricção 1 — Posição de v3 no header expõe escolha de versão de protocolo como decisão do user (estrutural — convenção técnica vaza pra UI sem tradução)

• Atrito real: v3 vs v2 é decisão técnica com consequências massivas — v2 = full-range automático, v3 = concentrated liquidity com range manual. Iniciante não sabe diferença e o dropdown não explica. Default v3 empurra todo iniciante pra configuração complexa de range (Etapa 2) sem entender que v2 seria mais simples e adequado pra primeira posição.
• Por que a solução óbvia falha: esconder v2 exclui user avançado que prefere fire-and-forget; explicar a diferença em modal toda vez é fricção.
• Alternativa: substituir o dropdown por toggle "Modo: Simples (v2) / Avançado (v3) ✓" com microcopy inline "Simples: liquidez em todo range, retorno menor mas sem risco de sair do range. Avançado: você escolhe a faixa de preço, retorno maior mas exige manutenção." Default permanece v3 pra preservar economia do produto, mas a escolha vira informada. Trade-off: opinião editorial forte sobre v2 = "simples"; aceitar.
• Perfil afetado: iniciante (principal — único que não decoda v3) + intermediário sem familiaridade com versionamento Uniswap.

🔴 Fricção 2 — Card Nível de tarifas 0,3% não mostra a distribuição dos outros tiers até clicar Mais v (estrutural — prova social escondida atrás de clique)

• Atrito real: badge TVL máximo afirma "este é o maior" mas não mostra por quanto. 0,3% poderia ter 51% do TVL (escolha contestável) ou 98% (escolha óbvia) — comportamento de produto é o mesmo (pré-selecionar), mas leitura do user é radicalmente diferente. User aceita default cego sem saber o quão concentrada é a adoção. Resolver isso exige clicar Mais v — atrito que iniciante não paga.
• Por que a solução óbvia falha: expandir sempre os 4 cards default polui (4× a altura); mostrar 78% do TVL no card único pode ser leído como tag aleatória.
• Alternativa: adicionar linha mini-stack abaixo do card único — 0,05% (12%) · 0,3% (78%) · 1% (10%) (3 valores, separados, dominante destacado). Sem expandir cards, mas com distribuição visível. Clique na linha leva pro detalhe (equivalente ao Mais v). Trade-off: mais 1 linha de altura; ganho: zero ambiguidade sobre o quão dominante é o default.
• Perfil afetado: intermediário (principal — interpreta TVL máximo mas quer saber margem) + iniciante atento.
• Família com 🔴 Fricção 3 da Tela 1 (Nível de tarifas sem distribuição) — mesma raiz: produto pré-seleciona sem mostrar a distribuição que justificou a escolha.

🔴 Fricção 3 — Botão Redefinir no header sem confirmação destrói o pre-fill silenciosamente (cosmética — affordance destrutiva sem fricção protetora)

• Atrito real: user veio da Tela 2 com par + tier carregados; um clique em Redefinir (por curiosidade, "o que faz isso?") apaga o contexto e força reseleção. Sem modal "Tem certeza?" — apenas executa.
• Por que a solução óbvia falha: modal toda vez é fricção pra avançado que sabe o que faz.
• Alternativa: Redefinir com tooltip on-hover "Limpa par e nível de tarifas selecionados" + undo inline por 5s ("Redefinido. Desfazer →"). Sem modal, mas com reversibilidade. Trade-off: exige toast de undo; ganho: zero perda acidental de contexto.
• Perfil afetado: iniciante (principal — único que explora botões).

---

🟡 Oportunidade competitiva — Wizard com sugestão de tier baseado em perfil de risco declarado, não em TVL agregado

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3, KyberSwap — default de fee tier é o de maior TVL/popularidade. Critério é cego ao user: mesmo iniciante e mesmo avançado recebem o mesmo default.
• Por que afeta o target: iniciante quer "menor risco que renda algo"; default por TVL pode levar a tier que exige range tight (0,05% exige range muito tight pra render fees — fora do range em horas). Intermediário quer otimização explícita.
• 4 perguntas-teste: (1) ✓ default por TVL é universal entre concorrentes (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = produto evita opinar sobre risco; falta de investimento editorial (4) ✓ ganho perceptível — user declara "Conservador" e vê 0,3% ou 1% recomendado com microcopy "range largo, menor concentração, menor IL".
• Hipótese de diferenciação: toggle de perfil acima dos cards — Conservador / Equilibrado / Agressivo. Cada perfil pré-seleciona tier + range default (Etapa 2). Default sem toggle = Equilibrado. Avançado ignora.
• Trade-off: opinião editorial sobre risco × tier; mitigado se mantido como sugestão (não bloqueio).
• Leverage estrutural alto — converte default técnico em default sob medida. Família com 🟡 "Ranking por perfil" (Tela 1) e 🟡 "Sugestão de fee tier amarrada à estratégia" (PosPop #7) — sistema integrado de personalização.

---

Observação adicional — banner X Layer está disponível agora segue presente. Mesmo cross-promo da Tela 1, persistente no flow. Não fricção da tela em si, mas registra-se como padrão de produto que prioriza growth de outra rede em telas críticas de conversão LP — decisão a desafiar pra Kotai (não competir com nosso próprio funil de aporte).

2. Pool detail VIRTUAL/USDC — Base

Função: página da pool específica com métricas históricas, transações e entry points pra ação. Aprofundamento após escolha na Tela 1 — user inspeciona TVL, volume, APR e decide entre Fazer swap (usar a pool como trader) ou + Adicionar liquidez (virar LP da pool).

Componentes

• Breadcrumb: Pools / VIRTUAL / USDC 0x529d...07fC (endereço encurtado + copy icon).
• Header: par VIRTUAL / USDC com logos dos 2 tokens + badge v3 + badge 0,3%.
• Big stat: 583,7 mil US$ + label Há um dia (volume da janela selecionada do chart).
• CTAs no header-direita: Fazer swap (rosa secundário) / + Adicionar liq... (rosa primário, truncado por largura do container).
• Chart de barras (volume diário) com eixos $0–$80K, ~20 barras visíveis.
• Toggle temporal abaixo do chart: 1D / 1S / 1M / 1A / ALL.
• Toggle de série: Preço / Volume ✓ / Liquidez.
• Sidebar direita Estatísticas:
  • APR total: 35,26% (destacado, fonte grande).
  • Saldos do pool: 779,4 mil VIRTUAL / 196,3 mil USDC com barra horizontal visualizando proporção.
  • TVL: 858,9 mil US$ (com delta +1,0% em verde).
  • Volume de 24 horas: 276,5 mil US$.
  • Tarifas de 24 h: 829,61 mil (provável bug — vide Observação adicional).
• Section Links abaixo (Etherscan etc., parcialmente visível).
• Tabela Transações no rodapé com colunas Horário / Tipo / USD / VIRTUAL / USDC / Carteira — exibe Vender VIRT... em vermelho.

Regras de negócio

• APR total = retorno anualizado de fees por unidade de TVL (sem deduzir IL).
• Saldos do pool refletem proporção dinâmica (preço atual define ratio entre tokens, não 50/50).
• Tabela Transações é live feed — última transação 4min atrás.
• CTAs Fazer swap e + Adicionar liquidez levam pra flows com par pré-preenchido (VIRTUAL/USDC herdado do contexto).
• Big stat 583,7 mil US$ é volume da janela ativa do chart (não 24h — Volume 24h está na sidebar como 276,5 mil).

---

🟢 Insight 1 — Entry point + Adicionar liquidez direto da pool > "Nova posição" do zero. User chega pela tabela da Tela 1 já com decisão ("essa pool aqui"); clica e o par + fee tier vêm pré-preenchidos na Tela 3 (Nova posição com VIRTUAL/USDC, 0,3% selecionado). Sem esse contexto, user teria que recriar a escolha de zero. Padrão a herdar pra Kotai — fluxos críticos devem carregar contexto de origem como deeplink.

🟢 Insight 2 — Saldos do pool com barra de proporção horizontal materializa imbalance. 779,4K VIRTUAL / 196,3K USDC em texto seria abstrato; barra horizontal mostra que pool está ~80% em VIRTUAL (preço de VIRTUAL caiu ou demanda comprou USDC). Iniciante vê de cara que pool não é 50/50 e entende sem ler. Padrão a herdar — proporções devem ter representação visual + numérica simultânea.

🟢 Insight 3 — Coexistência de Fazer swap e + Adicionar liquidez reconhece 2 personas na mesma página. Trader chega via descoberta de token; LP chega via descoberta de pool. Mesma page serve os 2 sem fragmentar o produto. Padrão a herdar — pool detail deve servir trader e LP, não forçar página por persona.

🟢 Insight 4 — Toggle Preço / Volume / Liquidez no chart permite leitura tripla sem mudar de tela. Trader olha Preço; LP olha Volume (proxy de fees) e Liquidez (concorrência). 3 lentes num único chart. Padrão a herdar — visualização principal deve permitir múltiplas projeções dos mesmos dados.

---

🔴 Fricção 1 — APR total exposto como número único sem decomposição (estrutural — APR isolado mascara componentes)

• Atrito real: 35,26% é APR "total" — mas total do quê? Inclui só fees ou inclui também appreciation/IL? É calculado sobre que janela (7d, 30d, 90d annualized)? Não há tooltip nem caveat. Iniciante lê "35% ao ano" e mentaliza retorno garantido — não sabe que: (a) IL pode comer 20%+ do retorno; (b) APR é trailing, não forward; (c) só é realizado se range cobrir todo o trading. Tela vende retorno; realidade entrega yield menos IL.
• Por que a solução óbvia falha: decompor APR em "Fees APR + IL implícito + APR líquido" exige escolher uma janela de IL (depende de range, não da pool) — número fica frágil. Esconder o APR e mostrar só fees aciona reclamação de avançado.
• Alternativa: trocar label de APR total por APR de fees (30d, full range) + microcopy abaixo "não inclui Impermanent Loss; seu APR real depende do range que você escolher". Mantém o number mas devolve precisão semântica. Trade-off: texto extra na sidebar; ganho: zero ilusão de "retorno garantido".
• Perfil afetado: iniciante (principal — único que toma APR como retorno literal) + intermediário sem treino financeiro.
• Família com 🟡 "APR estimado por range" (PosPop #1) e 🟡 "APR histórico por fee tier" (PosPop #8). Raiz comum: produto expõe APR único onde existem múltiplos APRs condicionais.

🔴 Fricção 2 — Big stat 583,7 mil US$ — Há um dia é ambíguo entre "volume da janela" e "volume de 24h" (estrutural — métrica principal sem rótulo claro)

• Atrito real: big stat é o number mais saliente da página. Label "Há um dia" sugere "volume de 1 dia" — mas a sidebar mostra Volume de 24 horas: 276,5 mil US$, metade do big stat. Os 2 numbers não batem. Provavelmente big stat é volume da janela ativa do chart (default mais largo) e "Há um dia" é caption do ponto final da série, não rótulo do total. User vê dois numbers de volume conflitantes na mesma tela e não sabe qual usar pra decisão.
• Por que a solução óbvia falha: alinhar os 2 (big stat = 24h igual à sidebar) perde a info da janela selecionada do chart; remover sidebar deixa avançado sem comparativo.
• Alternativa: rotular explicitamente o big stat com a janela — Volume (período: 30d): 583,7 mil US$ com atualização ao trocar o toggle 1D / 1S / 1M / 1A / ALL. Caption "Há um dia" some (ou vira tooltip do ponto final). Trade-off: big stat muda dinamicamente, exige redraw; ganho: zero conflito entre numbers da mesma tela.
• Perfil afetado: iniciante e intermediário (avançado decoda).

🔴 Fricção 3 — + Adicionar liq... truncado por largura do container (cosmética — label crítico cortado)

• Atrito real: CTA primário do flow LP tem label truncado (+ Adicionar liq...). User precisa hover ou intuir que liq... = liquidez. Iniciante pode ler como botão de outra coisa ("adicionar líquido"? "liquidação"?). É o CTA principal da página — não pode estar incompleto.
• Por que a solução óbvia falha: alargar container empurra layout; reduzir tamanho do font da CTA enfraquece hierarquia.
• Alternativa: trocar label por + Liquidez (mais curto, sem truncamento) ou + Adicionar (com ícone gota d'água). Trade-off: perde clareza de "adicionar liquidez" pra quem decoda; ganho: CTA inteiro visível sempre.
• Perfil afetado: iniciante (principal).

---

🟡 Oportunidade competitiva — Pool detail com simulador inline "se eu aportar $X num range Y, qual meu retorno esperado?"

• Padrão da indústria: Uniswap (esta tela), PancakeSwap, KyberSwap — pool detail é página de dados históricos. Decisão de aportar é feita em outra tela (Nova Posição) sem trazer simulação. User precisa imaginar quanto vai render antes de configurar.
• Por que afeta o target: iniciante e intermediário decide se vale aportar com base em "chute fundamentado". Avançado roda planilha. Ninguém tem ferramenta nativa.
• 4 perguntas-teste: (1) ✓ todos os concorrentes têm pool detail só descritivo (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = simulador requer modelo + UI; falta de investimento (4) ✓ ganho perceptível — user digita $500 + range ±10% e vê APR estimado: 28% / IL estimado em pior cenário 30d: 4% / Probabilidade de ficar in-range: 71%.
• Hipótese de diferenciação: mini-widget na sidebar abaixo de APR total — inputs Aporte $ e Range % com 2–3 numbers vivos (APR esperado, IL pior cenário, probabilidade in-range). Default usa preset Wide. Botão Configurar → leva pra Tela 3 com inputs pré-preenchidos.
• Trade-off: modelo carrega risco de erro (volatilidade muda); UI exige cálculo no client. Aceitar com caveat "baseado em volatilidade 30d; resultados reais podem variar".
• Leverage estrutural alto — converte pool detail de "tela informativa" em "tela de decisão". Família consolidada com 🟡 "APR estimado por range" (PosPop #1), 🟡 "Health Score" (PosPop #5), 🟡 "Slider probabilístico" (PosPop #11). Sistema acoplado: simular antes de aportar + monitorar depois.

---

Observação adicional — Tarifas de 24 h: 829,61 mil é provavelmente bug ou rendering quebrado. Number é maior que a TVL inteira (858,9 mil) e ~3× o volume de 24h (276,5 mil). Fees teóricas de 24h ≈ volume × fee tier = 276,5K × 0,3% ≈ $830. O number exibido (829,61 mil) é 1000× maior — provavelmente unidade trocada (deveria ser $829,61 mostrado como 829,61 com unidade auto-formatada erroneamente como "mil US$"). Não é fricção de UX (é defeito de implementação), mas é erosão direta de trust — iniciante atento percebe que o number não fecha contra TVL e perde confiança no resto dos numbers da página. Vale registrar e reportar como issue de qualidade analítica, não como fricção de design.

1. Pools list — Rede Base

Função: hub de descoberta de pools da rede Base com filtros e métricas comparativas em tabela. Entry point para o flow "criar nova posição de liquidez" — user chega aqui pra escolher em qual pool aportar capital antes de configurar range e fee.

Componentes

• Header: tabs Tokens / Pools ✓ / Transações (Pools selecionado).
• Filtros: + Adicionar liquidez (CTA primário, rosa) + dropdown rede (Base ✓) + dropdown Protocolos + busca por token/pool.
• Tabela com colunas: # / Pool / Protocolo / Nível de tarifas / TVL / Vol anual da pool / PR de recompensa / Vol. 1 dia / % 1 dia / TVL.
• 12 linhas visíveis (rank 1–12): TRUSD/USDC v3 0,3%, ORB/ETH v3 1%, ETH/SURGE v2 1%, VIRTUAL/REPPO v3 0,3%, BYTE/ETH v3 0,3%, ZORA/ETH v3 0,3%, VIRTUAL/USDC v3 0,3%, CLANKER/ETH v3 0,3%, REPLY/VIRTUAL v3 0,3%, BUDDY/ETH v3 1%, VIRTUAL/STAR v3 0,3%, VIRTUAL/MUTE v3 0,3%.
• Banner inferior-esquerdo: X Layer está disponível agora — Saber mais (cross-promo de outra L2).
• Endereço encurtado no canto superior direito (0x486f...) — wallet conectada.

Regras de negócio

• Ranking default por TVL decrescente (TRUSD/USDC $110,3M no topo; pools menores no fim).
• Mistura v2 e v3 na mesma lista — protocolo é coluna, não filtro pré-aplicado.
• Coluna % 1 dia / TVL = yield rate diário = (volume × fee tier) / TVL. Linhas visíveis: 3,00 / – / – / 0,54 / – / 0,42 / 0,51 — várias com hífen (sem dado ou volume zero).
• PR de recompensa aparece como – em todas — coluna provisionada pra incentivos LP (programa não ativo na Base).
• Fee tiers mais comuns na lista: 0,3% (8 pools), 1% (3 pools), 0,05% (raro).
• Pools v2 não têm fee tier configurável (default 0,3%); v3 lista o tier escolhido pelo criador da pool.

---

🟢 Insight 1 — Coluna % 1 dia / TVL é métrica única decisora superior a APR isolado. APR mistura yield + IL + janela temporal arbitrária; vol diário / TVL é dado bruto, sem suposição: "capital nessa pool girou X% no último dia". User compara linha-a-linha sem precisar entender modelo de retorno. Padrão a herdar pra Kotai — expor métrica bruta de utilização antes de derivar APR.

🟢 Insight 2 — Mistura v2/v3 com coluna Protocolo evita filtro duplicado. Se v2 e v3 fossem listas separadas, user inexperiente teria que escolher protocolo antes de descobrir as pools — decisão técnica empurrada pra cima. Mistura na mesma tabela permite descobrir pelo par e ver versão como atributo. Padrão a herdar — convenção técnica vira coluna, não filtro de entrada.

🟢 Insight 3 — CTA + Adicionar liquidez no header dá saída direta sem precisar escolher pool primeiro. User que já sabe o par que quer ("vim aqui pra criar pool USDC/X") não precisa scrollar lista — entra pelo CTA com par em branco. Dois caminhos coexistindo: "descobrir pool" (tabela) e "criar com par decidido" (CTA). Padrão a herdar — listagem deve permitir bypass pra user com decisão pronta.

---

🔴 Fricção 1 — Coluna % 1 dia / TVL sem unidade explícita nem âncora de comparação (estrutural — métrica decisora exposta sem contexto)

• Atrito real: linha 1 mostra 3,00 na coluna; linha 4 mostra 0,54. É 3,00% ou 3,00 (decimal)? E 3% é bom ou ruim? Iniciante não tem referência — não sabe se 3,00 é "excelente", "normal" ou "warning de pool sem TVL". Sem benchmark, métrica vira ruído numérico. Mesmo intermediário que entende a fórmula precisa estimar mentalmente se 3% diário ≈ 1000% anualizado é sustentável (provavelmente não — pool nova ou ilíquida).
• Por que a solução óbvia falha: adicionar tooltip explicando a fórmula é cosmético (resolve "o que é", não "é bom?"). Calcular APR anualizado e exibir junto cai na armadilha de outros DEXes (APR isolado enganoso).
• Alternativa: classificar visualmente em 3 faixas — < 0,1% cinza (pool dormida), 0,1–1% neutro, > 1% destaque amarelo com microcopy "yield alto = volatilidade ou TVL baixo, verificar". User vê 3,00 em amarelo com warning e não confunde com pool sólida. Trade-off: exige calibração das faixas por categoria de par (stable vs volátil); aceitar com faixa única no MVP.
• Perfil afetado: iniciante (principal — sem referência mental) + intermediário descuidado.

🔴 Fricção 2 — Coluna PR de recompensa vazia (–) em todas as linhas polui scan sem entregar valor (cosmética — coluna provisionada sem uso ativo)

• Atrito real: coluna ocupa espaço horizontal precioso e exibe – em 100% das linhas visíveis. Iniciante pensa "o que é PR? por que está vazio? é problema da minha rede?". Custo cognitivo alto pra zero informação. Provavelmente reservada pra programa de incentivos LP (UNI farming) — ativo em outras redes, dormente na Base.
• Por que a solução óbvia falha: remover a coluna quebra paridade entre redes (em Ethereum mainnet pode ter dados); deixar como está degrada experiência da Base.
• Alternativa: esconder coluna quando 100% dos valores são – — render condicional por rede. Em Base, a coluna some; em mainnet, aparece. Tabela fica mais densa e legível. Trade-off: user que troca de rede vê layout mudar (mas a mudança é melhoria, não regressão).
• Perfil afetado: todos os perfis (afeta scan da tabela inteira).

🔴 Fricção 3 — Nível de tarifas mostrado sem distribuição visual entre tiers do mesmo par (estrutural — fee tier crítico exposto como número solto)

• Atrito real: coluna mostra 0,3%, 1%, etc., mas não indica se aquele é o tier dominante do par (concentração de TVL) ou marginal. VIRTUAL/USDC 0,3% aparece, mas o user não sabe se existe também VIRTUAL/USDC 0,05% com TVL muito maior — escolher essa linha pode levar à pool errada. Decisão de fee fica desinformada já na escolha da linha.
• Por que a solução óbvia falha: listar todos os tiers do par em cada linha duplica entradas (1 par × 4 tiers = 4 linhas similares); colapsar tiers do mesmo par numa linha única perde a granularidade.
• Alternativa: agregar pools do mesmo par numa linha única com mini-stack de tiers — coluna Nível de tarifas mostra 0,05% / 0,3% (78%) / 1% com o dominante destacado. Clique expande a linha pra ver TVL/volume por tier. Trade-off: aumenta complexidade visual do row default; ganho: zero ambiguidade entre pools do mesmo par.
• Perfil afetado: iniciante e intermediário (avançado já sabe checar manualmente).
• Família com fricção "Default por TVL" (PosPop #7) — mesma raiz: produto expõe fee tier sem contexto comparativo entre alternativas do mesmo par.

---

🟡 Oportunidade competitiva — Ranking por "adequação ao perfil do user" em vez de TVL absoluto

• Padrão da indústria: Uniswap (esta tela), PancakeSwap, Curve — ranqueiam pools por TVL ou volume. Decisão de produto: "maior é melhor". Para LP iniciante isso é proxy ruim — pool gigante com par estável (USDC/USDT) tem yield baixíssimo; pool média com par correlacionado pode ter retorno melhor com risco controlado.
• Por que afeta o target: iniciante chega pensando "colocar liquidez" sem saber qual perfil de risco quer. Lista por TVL leva ele direto pra USDC/USDT (yield baixo) ou pares meme (yield alto + IL devastador). Não existe filtro nativo "qual perfil você quer?".
• 4 perguntas-teste: (1) ✓ todos os concorrentes ranqueiam por TVL/volume cego (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = clusterizar pools por perfil exige curadoria + modelo de risco; falta de investimento (4) ✓ ganho perceptível — user escolhe filtro Conservador / Moderado / Agressivo e vê lista reordenada com pools alinhadas à tese.
• Hipótese de diferenciação: 3 chips de perfil acima da tabela — Conservador (stablecoins, IL ≈ 0), Moderado (large-cap correlacionado, IL moderado), Agressivo (par volátil, alto yield/risco). Cada chip aplica filtro + reordena por % 1 dia / TVL dentro da categoria. Default = Todos. Avançado ignora os chips e usa colunas como hoje.
• Trade-off: classificação automática pode errar (par novo sem histórico); aceitar com badge "Sem histórico" e categoria default = "Agressivo". Manutenção da taxonomia é custo recorrente.
• Leverage estrutural alto — converte descoberta de pool em decisão de perfil informada, não busca cega. Família com 🟡 "Sugestão de fee tier amarrada à estratégia" (PosPop #7) e 🟡 "APR estimado por range" — sistema de ferramentas que substituem heurística "maior TVL = melhor" por casamento perfil × pool.

---

Observação adicional — banner X Layer está disponível agora no canto inferior-esquerdo compete com a CTA primária + Adicionar liquidez. Banner de cross-promo de L2 numa tela onde a decisão é "escolher pool" gera dispersão de foco. User pode clicar e sair do flow. Não é fricção da tela em si (decisão de growth é legítima), mas vale registrar como competição entre objetivos de produto — descoberta de pool vs adoção de nova rede.

Consolidado — Posição Populada Base (Uniswap)

Caráter geral do fluxo

O fluxo Posição Populada Base é o mais longo e tecnicamente denso do Uniswap analisado: 11 telas cobrindo a jornada completa de LP — pool discovery (1) → pool detail (2) → seleção de fee tier (3) → configuração de range (4) → aporte com erro de saldo (5, 6) → verificação externa de token (7) → review e assinatura (8, 9) → gestão pós-criação (10, 11).

O produto acerta sistematicamente em progressive disclosure, representação gráfica acoplada a decisões críticas, e preservação de contexto entre telas. Onde falha é estrutural: o produto expõe matemática de protocolo sem traduzir consequência e aceita configurações subótimas silenciosamente — sem guarda-rail quando a config é financeiramente irracional.

O perfil mais afetado é o iniciante em ambos os eixos: quem não sabe decodar "v2 vs v3", "±3 ticks", ou "uint256 max"; quem desiste na terceira assinatura sem entender por quê; quem sai do Portfolio acreditando ter perdido $11 porque a posição LP some do big stat (11).

---

🟢 Insights recorrentes

Representação gráfica acoplada a dado tabular em momentos de decisão crítica — telas 4, 5, 6, 8, 10

Padrão mais recorrente e mais forte do fluxo: toda vez que o produto pede decisão crítica, o número não aparece sozinho. Na configuração de range, o chart histórico mostra graficamente onde floor e ceiling estão em relação à volatilidade passada (4). Quando o ratio muda por saldo insuficiente, a cor do campo muda em tempo real junto com o number (5, 6). No modal de confirmação, o mini-chart com range em verde serve de sanity check visual antes de assinar (8). No card de posição pós-criação, o mini-chart inline mostra se o preço está dentro ou fora do range sem nenhum clique (10).

Diretriz a herdar: qualquer input ou confirmação financeira crítica deve ter representação gráfica adjacente — number cru sem contexto visual é fricção de leitura.

Pre-fill e preservação de contexto entre etapas — telas 2, 3

Pool detail carrega par + fee tier pré-selecionados ao abrir Nova Posição via deeplink (2 → 3). Sem isso, user teria que re-selecionar 2 tokens + 1 tier — 3 decisões redundantes após já tê-las tomado na tela anterior.

Diretriz a herdar: toda transição entre telas críticas deve preservar contexto como deeplink; nunca obrigar re-input de decisão já tomada.

Múltiplas representações do mesmo dado — telas 2, 3, 4

Toggle Preço / Volume / Liquidez no chart da pool detail oferece 3 lentes sobre os mesmos dados sem mudar de tela (2). O card de fee tier exibe tanto o percentual quanto o badge TVL máximo como critério da recomendação (3). Os inputs de preço Min/Max exibem valor absoluto e delta percentual simultâneos — iniciante lê o number, intermediário usa o % (4).

Diretriz a herdar: dados financeiros críticos devem carregar duas representações simultâneas — a que o usuário conhece e a que o protocolo conhece.

CTAs coexistentes para personas distintas na mesma tela — telas 1, 2

Na lista de pools, + Adicionar liquidez no header serve o user que já sabe o par enquanto a tabela serve o user em descoberta (1). Na pool detail, Fazer swap e + Adicionar liquidez coexistem porque trader e LP chegam pela mesma tela por caminhos diferentes (2).

Diretriz a herdar: telas de produto complexo devem permitir bypass para user com decisão pronta sem ocultar o path de descoberta.

Progresso explícito em flows multi-step e multi-tx — telas 3, 8, 9

O stepper vertical "Etapa 1 / Etapa 2" na configuração da posição deixa claro o que vem antes de clicar Continuar (3). O modal de confirmação exibe badge "Etapa 2 de 3" e microcopy "Você precisa aprovar 2 tokens" antes do primeiro popup da wallet (8, 9).

Diretriz a herdar: qualquer flow multi-step ou multi-tx deve expor todas as etapas antes de começar e o progresso durante.

---

🔴 Fricções recorrentes

Estrutural — Métricas de retorno sem contexto de qualidade ou decomposição — telas 1, 2, 10

A fricção mais recorrente do fluxo e a mais pesada para o iniciante: produto expõe número de retorno sem nível de referência, sem janela explícita, sem decomposição de componentes.

Na lista de pools, % 1 dia / TVL mostra 3,00 sem unidade explícita nem âncora — iniciante não sabe se 3,00 é bom, ruim ou alarme (1). Na pool detail, APR total: 35,26% aparece sem indicar janela de cálculo nem separar fees de IL — iniciante lê como "retorno garantido de 35% ao ano" (2). No card de posição recém-criada, APR: 36,42% coexiste com Tarifas: 0,00 US$ — APR trailing positivo numa posição que não acumulou um centavo de fee (10).

Por que a solução óbvia falha: decompor APR em "Fees + IL implícito" exige escolher uma janela de IL que depende do range individual — número fica frágil e disputável.

Direcionamento Kotai: (a) na lista de pools, classificar % 1 dia / TVL em 3 faixas visuais — < 0,1% cinza / 0,1–1% neutro / > 1% amarelo com "yield alto = volatilidade ou TVL baixo, verificar"; (b) no APR da pool detail e do card de posição, trocar label para APR de fees (30d, full range) com microcopy "não inclui Impermanent Loss; retorno real depende do range escolhido". Trade-off: faixas exigem calibração por categoria de par; aceitar com faixa única no MVP.

Perfil afetado: iniciante (principal — único que toma APR como retorno literal).

Estrutural — Convenções técnicas de protocolo vazando pra UI sem mediação — telas 3, 4, 5, 9, 10

O padrão mais amplo do fluxo — implementation details do protocolo aparecem como elementos primários de UI sem tradução de consequência.

O dropdown Posição de v3 força iniciante a escolher entre v2 e v3 sem saber que v2 = full-range automático e v3 = concentrated liquidity com range manual (3). O preset Estável: ± 3 ticks usa unidade de discretização interna enquanto os outros 3 presets usam percentagem — o preset mais conservador fica ilegível para o iniciante (4). O display de 1070,326180990420357 VIRTUAL expõe 15 casas decimais de BigNumber — parede numérica que o cérebro rejeita, pior em vermelho (5). O popup da wallet exibe Approve token: 115,792,089,237,316,... (uint256 max) sem microcopy explicando que é "aprovação infinita padrão" — número que parece catastrófico e que o user aprende a ignorar, hábito que será explorado pela próxima dApp maliciosa (9). O prompt Migrar para v4 aparece sem explicar o que é v4 (10).

Por que a solução óbvia falha: traduzir cada conceito em profundidade cria tooltips longos ignorados; esconder completamente retira controle do avançado.

Direcionamento Kotai: nome técnico + sub-label de consequência em uma linha — Avançado (v3): você escolhe a faixa de preço, retorno maior, exige manutenção / Estável: ±0,03% com tooltip "equivalente a ±3 ticks" / display de 2–4 casas com precisão completa on-hover / toggle no modal antes do popup de aprovação infinita. Trade-off: copy de manutenção contínua; ganho: consentimento real sobre o que está sendo aprovado.

Perfil afetado: iniciante (principal), intermediário sem familiaridade com versionamento.

Estrutural — Cross-promo concorrendo com a ação principal do funil — telas 1, 3, 10

Padrão de produto que compete contra seu próprio funil de conversão LP em três pontos. O banner X Layer está disponível agora — Saber mais aparece tanto na lista de pools (1) quanto no flow de Nova Posição (3), onde o objetivo deveria ser converter o user em LP, não levar para outra L2. Pós-criação, a sidebar de Pools com recompensas exibe pools com APR maior que a posição recém-criada — induzindo FOMO em user que deveria gerir o capital que acabou de aportar (10).

Por que a solução óbvia falha: remover cross-promo perde mecanismo de growth; manter erode conversão LP e tempo de gestão.

Direcionamento Kotai: segregar objetivos por contexto — em telas de criação de posição, zero cross-promo; no dashboard de posição, substituir sidebar de "Outras pools" por Saúde do seu portfólio LP. Discovery de novas pools fica no tab Pools principal — já existe. Trade-off: perde crescimento via cross-sell; ganho: retenção e gestão do capital já investido.

Perfil afetado: iniciante (principal — mais vulnerável a FOMO e dispersão).

Estrutural — Sensibilidade range → ratio invisível + mensagem de erro diagnostica sintoma — telas 5, 6

Fricções com mesma raiz e mesma solução, tratadas juntas. Ajuste de 0,012 no floor do range (0,852 → 0,840) gera queda de 50× no VIRTUAL exigido (de 1070 para 21). O comportamento é matematicamente correto — a curva de liquidez v3 é altamente não-linear próxima do preço atual — mas completamente invisível na UI (5, 6). Simultaneamente, "Saldo de VIRTUAL insuficiente" aponta para a solução errada: user lê "preciso comprar mais VIRTUAL" quando a causa raiz é o range tight — alargar 0,012 resolveria sem comprar nada (5). Na tela seguinte, a mesma mensagem persiste quando o gap caiu de 50× para 2-3×, sem nenhum feedback de progresso (6).

Por que as soluções óbvias falham: exibir a derivada da curva é técnico demais; warning "range muito tight" constante vira ruído; mensagem de erro composta cresce o footer.

Direcionamento Kotai: (a) gradient bar de sensibilidade abaixo do chart — zonas vermelhas próximas do preço atual (alta sensibilidade ao capital), zonas verdes longe; (b) mensagem de erro composta com 2 saídas — "Saldo insuficiente. Você pode: [Alargar o range] (recalcula com seu saldo) ou [Reduzir aporte] (mantém range)"; (c) footer dinâmico com gap absoluto durante resolução — "Faltam ~13 VIRTUAL ($11,50)". Trade-off: (a) nova visualização exige cálculo client; (b)+(c) footer cresce 2 linhas; leverage pedagógico alto.

Perfil afetado: iniciante e intermediário.

Estrutural — Mudança silenciosa de valores em momento crítico — telas 6, 9

Em 6, o USDC digitado pelo user (5) é reescrito automaticamente para 0,1 ao mover o floor do range — sem highlight, sem microcopy, sem aviso. User pode achar que digitou errado ou não perceber que o aporte caiu de ~$969 para ~$19,50. Em 9, o USDC no popup da wallet vai de 0,53968 (modal review) para 0,562854 — re-quote por movimento de preço nos segundos entre clicar Criar e o popup abrir, diferença de 4%, sem aviso.

Por que a solução óbvia falha: travar input quebra bidirecionalidade; cancelar tx por qualquer mudança gera abandono.

Direcionamento Kotai: highlight temporário no campo recalculado (fade in/out amarelo por 1,5s) + microcopy contextual — "USDC ajustado para manter ratio do range" no overwrite (6) / "Valores atualizados: +4% por movimento de preço" no re-quote (9). Trade-off: animação de estado; trivial de implementar.

Perfil afetado: iniciante (principal), intermediário desatento.

Estrutural — Fragmentação de patrimônio LP/Portfolio — telas 10, 11

Após criar posição com ~$12 em VIRTUAL/USDC, o user vai ao Portfolio e encontra 1,53 US$ como big stat (11). A posição LP de $11,72 existe e está visível no dashboard de posições (10), mas como NFT (ERC-721) não entra no cômputo da Visão geral. Reação natural do iniciante: pânico — "cadê meu dinheiro?". Sem saber que deve ir ao tab NFTs ou voltar para Suas posições, interpreta perda.

Por que a solução óbvia falha: somar LP ao big stat exige valuation em tempo real com risco de erro em momentos de volatilidade; caveat quebra a simplicidade do número.

Direcionamento Kotai: big stat segmentado — Total: $13,25 (Tokens $1,53 + Posições LP $11,72) com toggle para ocultar LP se o user preferir, e microcopy "Valor de LP é estimado pela cotação atual". Trade-off: cálculo adicional + caveat; ganho: zero pânico + visão real de patrimônio.

Perfil afetado: iniciante (principal — sofre pânico), intermediário (paga custo de agregação mental).

Estrutural — Fee tier exposto sem distribuição comparativa — telas 1, 3

Na lista de pools, a coluna Nível de tarifas lista 0,3% ou 1% sem indicar se aquele é o tier dominante do par — user pode escolher a linha errada do mesmo par (1). Na seleção de tier da Nova Posição, o badge TVL máximo pré-seleciona 0,3% sem mostrar por quanto margem — 0,3% poderia ter 51% ou 98% do TVL; o comportamento de produto é idêntico nos dois casos, mas a leitura do user é radicalmente diferente (3).

Direcionamento Kotai: (a) na tabela, agregar pools do mesmo par em linha única com mini-stack de tiers — 0,05% / 0,3% (78%) / 1% com dominante destacado, clique expande; (b) no card de seleção, adicionar linha de distribuição — 0,05% (12%) · 0,3% (78%) · 1% (10%). Trade-off: maior complexidade visual do row default; ganho: zero ambiguidade sobre dominância do default.

Perfil afetado: iniciante e intermediário.

Cosmética — Precisão de máquina exposta na UI — telas 5, 8

1070,326180990420357 VIRTUAL com 15 casas decimais no campo de depósito (5); 13 VIRTUAL sem decimais vs 0,53968 USDC com 5 casas no mesmo bloco de confirmação (8). Raiz: BigNumber/uint256 como precisão de leitura. Fix: 2–4 casas por padrão, precisão completa on-hover.

Cosmética — Labels truncados — telas 2, 11

+ Adicionar liq... (2) e Atividade re... (11). Labels não testados em container final. Fix: testar em breakpoints. Trivial.

---

🔴 Fricções estruturais de alta gravidade — tela única

Segurança de token delegada integralmente a terceiros — 7

O user abre 4–5 abas externas (CoinMarketCap, Etherscan, X do projeto, página de migração) para verificar se VIRTUAL é legítimo antes de criar posição (7). Uniswap não oferece nenhum sinal de trust inline. Iniciante que não conhece o ritual depositaria num token homônimo com contrato maliciosa sem nenhuma barreira. Direcionamento Kotai: ver 🟡 Camada nativa de verificação e trust de token abaixo.

Fricção de protocolo ERC-20 (3 popups) transferida integralmente ao user — 9

ERC-20 obriga transação de approval separada por token antes do mint da posição — 3 assinaturas sequenciais obrigatórias (9). Custo cognitivo idêntico em redes baratas e caras: 3 momentos de "e se eu assinar a coisa errada?". Principal causa de abandono em criação de posição LP. Solução exige decisão de produto, não só redesign de interface (ver 🟡 Smart wallet nativa abaixo).

---

🔴 Cosméticas — pontos isolados

• 🔴 Tela 1: coluna PR de recompensa exibe – em 100% das linhas — render condicional por rede, ocultar quando sem dados.
• 🔴 Tela 3: Redefinir apaga pre-fill sem undo — toast de undo por 5s.
• 🔴 Tela 4: Preço mínimo / Preço máximo sem sufixo de denominação do par — em pares ETH/USDC, erro de denominação inverte a estratégia inteira.
• 🔴 Tela 8: 0,54 US$ abaixo da taxa de rede sem label claro no modal — ambiguidade de o que o número representa.
• 🔴 Tela 10: header 0 UNI Recompensas ganhas ocupa 30% do espaço quando zerado — colapsar para 1 linha quando saldo = 0.
• 🔴 Tela 11: 0,001 ETH como único token visível parece que o saldo sumiu — badge Gas no nativo abaixo de $5.

---

🟡 Oportunidades competitivas do fluxo

Sistema integrado de simulação e assistência ativa — telas 2, 4, 5, 6, 8, 10

Padrão atual da indústria: em todos os concorrentes (Uniswap, PancakeSwap v3, KyberSwap), pool detail é página descritiva de dados históricos (2); presets de range são labels geométricos sem retorno esperado nem probabilidade (4); erros de saldo bloqueiam sem sugerir ajuste (5); chart de range não visualiza sensibilidade de capital (6); modal de review é descritivo, não prospectivo (8); card de posição é passivo, não prescreve ação (10).

Por que afeta nosso target: iniciante decide range, fee tier e aporte por intuição — sem modelo, sem probabilidade, sem alternativa calculada quando erro aparece. Intermediário itera manualmente. Avançado usa planilha externa. Ninguém tem ferramenta nativa integrada ao momento de decisão.

Hipótese de diferenciação Kotai: sistema acoplado de 6 pontos de contato:

1. Simulador inline na pool detail (2): mini-widget na sidebar — inputs Aporte $ + Range % → APR esperado, IL pior cenário, % in-range. Default usa preset Wide.
2. Presets com probabilidade e APR estimado (4): 3ª linha em cada card — P(in-range 30d): X% / APR esperado: Y%. User compara em retorno esperado vs risco, não em geometria.
3. Sugestão automática de ajuste de range (5): ao bloquear por saldo insuficiente, botão Ajustar para meu saldo recalcula floor mínimo viável e aplica com 1 clique.
4. Gradient bar de sensibilidade de capital (6): barra abaixo do chart com zonas vermelhas (alta sensibilidade) e verdes (baixa) em tempo real durante drag dos bounds.
5. Modal de review prospectivo com cenários (8): seção colapsável Ver cenários (3) — preço cai 10%: posição vira 100% VIRTUAL, para de render; preço fica: fees acumulam; preço sobe 30%: ainda dentro do range.
6. Card de posição proativo (10): 1 linha contextual baseada em regras — fees > 10× gas: sugere recolher; price < min + 5%: sugere ajustar; out_of_range > 24h: sugere fechar/migrar. 1 clique para executar.

Trade-off: cada ponto exige modelo probabilístico com risco de erro quando volatilidade muda; aceitar com caveat "baseado em volatilidade 30d; resultados reais podem variar" em todos os pontos.

Passa nas 4 perguntas-teste? (1) ✓ todos os concorrentes carecem de simulação nativa (2) ✓ afeta iniciante e intermediário nos 6 pontos (3) ✓ razão = exige modelo client-side + design; falta de investimento (4) ✓ diferença perceptível máxima — user não precisa de planilha externa para tomar decisão informada.

Leverage estrutural máximo — converte Kotai de "DEX que mostra dados" em "DEX que raciocina junto com o user".

---

Camada nativa de verificação e trust de token — tela 7

Padrão atual da indústria: Uniswap, PancakeSwap, KyberSwap — autocomplete por ticker sem badge de verificação, sem rank, sem backers, sem aviso de rebrand/migração (7). Segurança delegada 100% ao user via CoinGecko, CMC, Etherscan e X.

Por que afeta nosso target: iniciante é o alvo principal de scam — token homônimo com contrato malicioso engana exatamente quem não conhece o ritual de verificação. Intermediário sabe verificar mas paga custo de tab-switching.

Hipótese de diferenciação Kotai: "Trust card" ao buscar ou selecionar token — painel inline com: ID verificado em CoinGecko/CMC, rank de mercado, contratos por rede com badge Verificado on-chain, backers nomeados, age do contrato, aviso de rebrand/migração quando identificado, link para audit se houver. Tokens novos recebem Token novo, sem verificação — não bloqueia, alerta.

Trade-off: dependência de feeds externos — rate limit, custo de API, fallback degradado. Curadoria contínua para rebrands. Aceitar como custo recorrente — o custo de um scam bem-sucedido do target é infinitamente maior.

Passa nas 4 perguntas-teste? (1) ✓ todos os concorrentes delegam verificação integralmente (2) ✓ afeta iniciante diretamente — mais exposto ao risco de perda total (3) ✓ razão = integração com feeds externos + UI de trust; falta de investimento (4) ✓ ganho perceptível máximo — user não precisa de 4-5 abas e não cai em scam de ticker.

Leverage estrutural crítico — não é otimização de UX, é pré-requisito de segurança para o target. DEX que protege o iniciante sem que ele precise saber de proteção.

---

Smart wallet nativa com batch de transações (Account Abstraction) — tela 9

Padrão atual da indústria: Uniswap, PancakeSwap, KyberSwap assumem wallet EOA (MetaMask, Rabby, Coinbase clássica) e empurram 3 transações sequenciais para o user (9). Smart wallets existem mas não são default; produto não as trata como cidadão de 1ª classe.

Por que afeta nosso target: iniciante é quem mais abandona no fluxo de 3 popups. Smart wallet resolveria com 1 clique. Quem resolver o trilema — adoção de smart wallet × simplicidade de onboard × UX nativa — ganha o iniciante.

Hipótese de diferenciação Kotai: Kotai-as-smart-wallet — onboarding cria smart wallet ERC-4337 por default; toda interação vira userOp única; gas pago em USDC (não ETH nativo); approvals consolidados via Permit2 + multicall; recuperação social via guardians (não seed phrase). EOA continua suportada como modo "avançado". Resultado: criação de posição LP = 1 clique do ponto de vista do user.

Trade-off: abandona compatibilidade nativa com MetaMask como default. Custo de operar paymaster (sponsored gas inicial). Responsabilidade arquitetural sobre fundos — mitigada se smart wallet for self-custody. Investimento técnico altíssimo.

Passa nas 4 perguntas-teste? (1) ✓ todos os concorrentes assumem EOA e empurram 3 popups (2) ✓ afeta iniciante diretamente — é quem abandona (3) ✓ investimento técnico significativo mas factível (4) ✓ "15 segundos com 1 clique" vs "5 minutos com 3 popups".

Meta-oportunidade — se implementada, todas as outras oportunidades (simulação, trust card, portfolio unificado) ficam mais acessíveis porque o bottleneck da wallet desaparece. A diferenciação de UX vai bater no teto da carteira do user — Kotai pode decidir que a decisão mais importante não é "fazer DEX melhor" mas "fazer onboard de smart wallet melhor que tudo no mercado, e construir o DEX em cima dela".

---

Portfolio unificado — One-screen wealth — tela 11

Padrão atual da indústria: Uniswap, MetaMask, Rabby, Coinbase Wallet — Portfolio mostra ERC-20 como cidadão de 1ª classe (11). LPs, lending, staking ficam em abas separadas ou fora do app. User precisa abrir 3–5 telas para somar patrimônio total.

Por que afeta nosso target: iniciante "perde dinheiro de vista" — $11,72 de LP invisível vira pânico de perda. Intermediário usa planilha ou DeBank para agregar.

Hipótese de diferenciação Kotai: big stat que agrega tudo on-chain — Patrimônio: $13,25 (Tokens $1,53 / Posições LP $11,72). Cada categoria expansível para detalhes. Multi-chain agregado por default (toggle Todas as redes já existe).

Trade-off: integração com dezenas de protocolos é custo perpétuo; valuation aproximada exige caveat. Aceitar ambos — o custo alternativo é o user acreditando ter perdido dinheiro após cada aporte.

Passa nas 4 perguntas-teste? (1) ✓ todos os concorrentes fragmentam patrimônio por tipo (2) ✓ afeta iniciante e intermediário (3) ✓ razão = integração com múltiplos protocolos + modelo de valuation; falta de investimento (4) ✓ diferença perceptível imediata — zero pânico de "cadê meu dinheiro".

---

Sistema de personalização por perfil de risco — telas 1, 3

Padrão atual da indústria: Uniswap, PancakeSwap, Curve ranqueiam pools por TVL absoluto e selecionam fee tier pelo tier de maior TVL — critério cego ao perfil do user (1, 3).

Por que afeta nosso target: iniciante chega sem saber qual perfil de risco quer. Default por TVL leva a stablecoins (yield baixíssimo) ou pares meme (IL devastador). Não existe filtro nativo "qual perfil você quer?".

Hipótese de diferenciação Kotai: 3 chips de perfil acima da tabela — Conservador (stablecoins, IL ≈ 0), Moderado (large-cap correlacionado, IL moderado), Agressivo (par volátil, alto yield/risco). Cada chip reordena a lista por % 1 dia / TVL dentro da categoria. Na seleção de fee tier, toggle de perfil pré-seleciona tier + range default alinhados à tese. Avançado ignora os chips.

Trade-off: classificação automática pode errar para tokens novos sem histórico; aceitar com badge "Sem histórico" e categoria default = "Agressivo". Curadoria da taxonomia é custo recorrente.

Passa nas 4 perguntas-teste? (1) ✓ default por TVL/popularidade é universal (2) ✓ afeta iniciante e intermediário (3) ✓ razão = produto evita opinar sobre risco; falta de investimento editorial (4) ✓ user seleciona Conservador e vê lista completamente diferente.

Leverage moderado — família com o sistema de simulação; juntos formam a camada de "decisão informada desde o início".

---

Pontos isolados (1 tela)

• 🟢 Tela 1: mistura v2/v3 com coluna Protocolo evita forçar escolha técnica antes da descoberta do par.
• 🟢 Tela 2: barra horizontal de proporção de saldos do pool materializa imbalance visualmente sem cálculo.
• 🟢 Tela 3: badge TVL máximo comunica o critério da recomendação sem prescrever — user decide se o critério importa pra ele.
• 🟢 Tela 4: 4 presets de range traduzem tese de mercado em geometria — "Acumular se cair" vs "Vender em alta" em vez de labels neutros.
• 🟢 Tela 5: CTA disabled visível com mensagem nomeada — botão não desaparece quando inválido, user sabe que ação existe e por que está bloqueada.
• 🟢 Tela 7: Rank + Backers verificáveis como prova social de legitimidade do token — heurística que o iniciante não tem sem a tela.
• 🟢 Tela 8: link Pedir ajuda no header do modal de confirmação — admite que confusão é estado válido no momento de "última chance"; postura de produto a herdar como princípio.
• 🟢 Tela 8: taxa de rede exibida no review antes de assinar — sem surpresa de gas no popup da wallet.
• 🟢 Tela 9: badge Interacted before na wallet como sinal de trust vindo do contexto de segurança mais próximo do user.
• 🟢 Tela 10: badge ✓ Dentro do intervalo como semáforo binário — user entende saúde da posição sem decodar numbers.
• 🟢 Tela 10: Migrar para v4 como prompt contextual discreto — aparece na coisa migrável, não em banner global.
• 🟢 Tela 11: tabs Visão geral / Tokens / NFTs / Atividade organizam holdings por tipo de objeto — estrutura transferível.
• 🔴 Tela 2: bug Tarifas de 24h: 829,61 mil (~1000× maior que o correto) — erosão de trust, não fricção de UX.
• 🔴 Tela 2: big stat 583,7K US$ conflita com Volume de 24h: 276,5K US$ na sidebar — dois números de volume sem rótulo de janela.
• 🔴 Tela 4: Unilateral superior +100% pode ser lido como "+100% de retorno" pelo iniciante — nomeação do preset engana o target mais crítico.
• 🔴 Tela 8: CTAs Criar (modal) e Analisar (tela de fundo) competem visualmente como primários — clique acidental tem consequências diferentes.

---

Observação estratégica transversal

A sequência Tela 10 → Tela 11 é a evidência empírica mais forte do problema de fragmentação de patrimônio em DeFi: mesmo user, mesma carteira, mesma hora — $11,72 LP visível em uma tela, invisível na outra. Vale congelar essas duas telas como caso-âncora para design reviews internas: todo flow de criação de holding deve ser seguido por visualização que agrega o novo holding ao saldo total, não o esconde em outra aba.

A observação da Tela 9 é estratégica: "a diferenciação de UX vai bater no teto da carteira do user". Kotai pode decidir que a decisão mais importante não é "fazer DEX melhor" mas "fazer onboard de smart wallet melhor que tudo no mercado, e construir o DEX em cima dela".

Os drafts de lote estão preservados em analises/uniswap/_consolidado/_drafts/posicao-populada-base-lote-1.md e posicao-populada-base-lote-2.md como audit trail da cadeia de raciocínio.

3. Filtro Protocolo — Versão

Função: dropdown Protocolo aberto exibindo 3 versões do protocolo Uniswap (v4 / v3 / v2) com checkboxes pra filtrar a listagem. Tela revela que versão é dimensão de filtragem de primeira classe, ao lado de Status e Network.

Componentes (diff em relação à Tela 1)

• Toolbar com Protocolo v agora aberto.
• Dropdown com 3 itens em checkbox:
  • v4 ✓.
  • v3 ✓.
  • v2 ✓.
• Todos selecionados por default — filtro inativo na prática (mostra tudo).
• Background (empty state + sidebar) inalterado.

Regras de negócio

• 3 versões coexistem em produção; user pode ter posições em qualquer delas.
• Default v4 + v3 + v2 = mostrar tudo (filtro só restringe quando user desmarca).
• v2 = constant product (x*y=k) sem range; v3 = concentrated liquidity; v4 = v3 + hooks.
• Filtro é independente do dropdown + Novo > Nova posição de vX (este filtra exibição; aquele escolhe criação).

---

🟢 Insight 1 — v4 + v3 + v2 todos ativos por default = mostrar tudo, filtro é opt-in. User não precisa configurar pra ver suas posições. Filtro existe pra restringir, não pra exigir setup. Padrão a herdar pra Kotai — filtros devem default a "mostrar tudo" e só restringir por intenção explícita.

🟢 Insight 2 — Filtro Protocolo em pé de igualdade com Status reconhece que user multi-versão é caso real. Power user pode ter v2 (legado), v3 (atual), v4 (experimental). Filtrar por versão facilita auditoria. Padrão a herdar — quando uma dimensão técnica afeta comportamento, ela merece filtro de 1ª classe.

🟢 Insight 3 — Dropdown enxuto (só v4 / v3 / v2, sem microcopy) é decisão coerente pra esta tela. Diferente do dropdown + Novo da Tela 1 (onde versão decide flow), aqui versão é filtro de visualização — risco zero. Mantém UI limpa pra usuário power. Padrão a herdar — peso de explicação deve ser proporcional ao impacto da decisão.

---

🔴 Fricção 1 — Filtro Protocolo é redundante pro iniciante (só tem 1 versão ou nenhuma) e útil só pra power user (estrutural — UI pra power user ocupando espaço de iniciante)

• Atrito real: iniciante chega aqui com 0 posições (Tela 1 confirma) ou com 1 posição em 1 versão. Filtro Protocolo é literalmente inútil pra ele — desmarcar versões só esconde a única posição que tem. Mas o filtro ocupa mesmo peso visual que Status (útil pra todos). Iniciante olha, tenta usar, vê que não faz sentido, abandona com confusão.
• Por que a solução óbvia falha: esconder o filtro pra iniciante exige detecção (count de versões nas posições); remover de todos perde affordance pra power user.
• Alternativa: mostrar Protocolo filtro apenas quando user tem posições em ≥ 2 versões. Conditional render trivial. Iniciante com 1 ou 0 posição não vê o filtro; intermediário com v2+v3 vê. Trade-off: lógica condicional; ganho: toolbar adapta-se ao perfil real.
• Perfil afetado: iniciante (principal — único confuso) e intermediário com posição em 1 versão.

🔴 Fricção 2 — Labels v4 / v3 / v2 sem microcopy assumem que user entende versionamento de protocolo (estrutural — versão de protocolo exposta como label sem tradução)

• Atrito real: dropdown mostra v4 / v3 / v2. User iniciante: "qual é v3 mesmo? a com range?". Sem nada que diga o que cada versão é. Em dropdown de filtro (estado momentâneo), tooltip não dá conta — user fecha o tooltip e perde a info de novo. Inconsistente com a Tela 1 onde o split button + Novo faria sentido ter microcopy (e também não tem).
• Por que a solução óbvia falha: adicionar texto na linha do checkbox polui (v3 (concentrated liquidity)); fica longo.
• Alternativa: tooltip persistente on-hover com 1 frase — v3 mostra "concentrated liquidity, range manual" enquanto mouse fica em cima. Sem aumentar tamanho do dropdown. Trade-off: depende de hover (não-touch); aceitar pra desktop.
• Perfil afetado: iniciante (principal) + intermediário sem familiaridade.
• Família confirmada com 🔴 Fricção 1 da Tela 1 (split button) e 🔴 Fricção 1 da Tela 3 PP Base — versão de protocolo aparece em 4 lugares no produto sem tradução consistente.

🔴 Fricção 3 — Filtro Protocolo e split button + Novo > Nova posição de vX usam vocabulário inconsistente (cosmética — mesmo conceito com dois nomes)

• Atrito real: dropdown de criação fala Nova posição de v4 (com de); filtro fala simplesmente v4 (sem de). Mas o conceito é o mesmo — versão do protocolo. Inconsistência menor mas mina coerência do produto.
• Por que a solução óbvia falha: uniformizar pode ficar verboso.
• Alternativa: padronizar pra v4 em ambos os lugares (criação: Nova posição em v4; filtro: v4). Trade-off: trivial; ganho: coerência.
• Perfil afetado: todos os perfis (estrutural a coerência do produto).

---

🟡 Oportunidade competitiva — Esconder versão de protocolo como conceito de user-facing — substituir por outcome ("range manual / simples / hooks")

• Padrão da indústria: Uniswap (esta tela e Tela 1), PancakeSwap v3 — versão de protocolo é decisão visível pra user. Implementation detail vaza pra UI em múltiplas telas.
• Por que afeta o target: iniciante não tem mental model pra "versão". Aprende decorando ("v3 é a boa"), não compreendendo. Pior: cada DEX tem versões com semântica diferente — saber "v3 do Uniswap" não ajuda no PancakeSwap v3.
• 4 perguntas-teste: (1) ✓ todos concorrentes expõem versão (2) ✓ afeta iniciante e intermediário (3) ✓ razão = curadoria + reescrita de toda referência a versão = trabalho de produto; falta de investimento (4) ✓ ganho perceptível — user vê "Posições simples (v2) / Posições com range (v3) / Posições com hooks (v4)" e entende sem decorar versão.
• Hipótese de diferenciação: renomear versão por outcome em toda a UI — filtros: Range completo / Range manual / Customizadas (hooks). Versão técnica vira tooltip de detalhe. Power user que quer ver "v3" pode habilitar modo técnico nas configurações.
• Trade-off: glossário paralelo (Kotai usa "Range manual", indústria usa "v3"); precisa documentar bridge na ajuda. Custo de coerência da indústria.
• Leverage estrutural alto — converte conceito técnico em conceito de outcome. Família consolidada com fricções de versão (Telas 1, 3 PP Base, 10 PP Base, 1 SuasPos, 3 SuasPos) — 5 ocorrências = sistema-alvo claro pra diferenciação.

---

Observação adicional — v4 / v3 / v2 em ordem cronológica reversa (mais novo no topo) embute hierarquia editorial implícita. Sugere "v4 é melhor". Mas verdade técnica: cada versão tem use case válido (v2 é mais simples, v3 é mais eficiente em capital, v4 é mais flexível mas mais complexo). Ordenação alfabética/cronológica é editorial — vale tornar ordenação por adequação ao user se Kotai for personalizar ("a versão certa pra você está no topo").

1. Suas Posições — Dropdown "Novo" aberto

Função: hub de gestão LP em estado empty (carteira conectada 0xd09B...618a sem nenhuma posição). User clicou na seta v do split button + Novo pra escolher qual versão do protocolo usar antes de criar a posição. Tela revela arquitetura de produto onde versão é decisão do user antes mesmo de escolher o par.

Componentes

• Header (igual à Tela 10 do flow Posição Populada Base):
  • 0 UNI + Recompensas ganhas + Recolher recompensas (disabled).
  • Microcopy "Encontre pools com recompensas em UNI →".
• Section Suas posições com toolbar:
  • Split button + Novo: botão rosa (cria com default) + seta v (dropdown de versão).
  • Filtros: Status v + Protocolo v + toggle de view.
• Dropdown Novo aberto (esta tela) com 3 itens:
  • Nova posição de v4.
  • Nova posição de v3.
  • Nova posição de v2.
• Empty state principal:
  • Ícone (mochila/box) + Nenhuma posição encontrada.
  • Microcopy "Você não tem nenhuma posição de liquidez. Crie uma nova posição para começar a ganhar tarifas e recompensas em pools qualificados."
  • 2 CTAs: Explorar pools (secundário) + Nova posição (rosa primário).
• Microcopy abaixo: "Quer ver suas posições fechadas? Para vê-las, use o filtro na parte superior da página." (dismissable).
• Microcopy de migração: "Algumas posições de v2 não são exibidas automaticamente. Importar posições v2".
• Sidebar direita Maiores pools por TVL: WISE/ETH 0,00% APR, ETH/USDC 89,52% APR, USDC/ETH 14,05%, ETH/USDC 4,89%, ETH/USDT 45,55%, WBTC/ETH 14,05% — todos com badge de versão + fee tier.
• Card educacional sidebar: Saiba mais sobre provisão de liquidez + "Fornecer liquidez em protocolos diferentes".

Regras de negócio

• + Novo é split button — click no botão = criar com versão default (v3 provavelmente); click na seta v = escolher versão antes.
• Versão escolhida define qual flow Nova posição user entra (v2 sem fee tier, v3 com fee tier + range, v4 com hooks).
• Sidebar Maiores pools por TVL lista pools de outras versões misturadas (v2 0,3%, v3 0,05%, etc.) — coluna versão visível em cada linha.
• Empty state tem 2 CTAs distintos: Explorar pools (descoberta) e Nova posição (criar direto).

---

🟢 Insight 1 — Split button + Novo com dropdown de versão respeita 2 personas: default-aceptor e versão-escolhedor. Avançado clica no v pra escolher; iniciante clica no botão direto e vai pro default. Ambos completam a ação. Padrão a herdar pra Kotai — affordances de produto devem servir os 2 níveis sem fragmentar UI.

🟢 Insight 2 — Empty state com 2 CTAs (Explorar pools vs Nova posição) reconhece 2 mental models. "Não sei o que quero" vai explorar; "sei o par/versão" cria direto. Padrão a herdar — empty state crítico deve oferecer caminhos distintos pra graus diferentes de prontidão.

🟢 Insight 3 — Sidebar Maiores pools por TVL em empty state cumpre função de inspiração legítima. Diferente da sidebar da Tela 10 (com user já ativo, distrai gestão), aqui a sidebar substitui a posição inexistente como gatilho de ação. Sidebar é certa pro contexto. Padrão a herdar — discovery side-panels devem ser contextuais ao estado da tela principal, não constantes.

---

🔴 Fricção 1 — Dropdown Nova posição de v4 / v3 / v2 força user a decidir versão de protocolo antes de saber o que cada versão faz (estrutural — convenção técnica é primeira decisão sem decode)

• Atrito real: dropdown apresenta v4 / v3 / v2 em ordem cronológica reversa (mais nova primeiro), implicando "v4 é melhor". Mas iniciante não sabe:

  • v2 = full-range, simples, sem fee tier escolhível — adequado pra primeira posição low-stakes.
  • v3 = concentrated liquidity com range manual + fee tier — retorno maior mas exige gestão.
  • v4 = v3 + hooks (lógica customizável) — power user.

  Iniciante que clica v4 por estar no topo entra em flow com complexidade incompatível. Não há microcopy explicando o que cada versão faz pra você (só nome técnico).

• Por que a solução óbvia falha: explicar diferenças em modal toda vez é fricção; descartar versões antigas exclui user com posição legada.

• Alternativa: renomear itens com microcopy de outcome — Nova posição de v4 — Hooks customizáveis (avançado), Nova posição de v3 — Range manual + fees concentradas (recomendado), Nova posição de v2 — Range completo, simples. Default v3 marcado com badge Recomendado. Trade-off: labels mais longas (cabem); ganho: zero seleção cega.

• Perfil afetado: iniciante (principal — único que não decoda versão) + intermediário sem familiaridade.

• Família com 🔴 "Posição de v3 no header" (Tela 3 da PP Base) e 🔴 "Migrar para v4 →" (Tela 10 da PP Base) — versionamento de protocolo vaza pra UI em 3 lugares distintos no produto. Família estrutural confirmada.

🔴 Fricção 2 — 0 UNI Recompensas no topo aparece em carteira nova/empty sem contexto (cosmética — header com info irrelevante pra empty state)

• Atrito real: carteira sem posição garantidamente tem 0 UNI. O bloco inteiro do header 0 UNI / Recompensas ganhas / Recolher recompensas (disabled) ocupa 30% do espaço útil pra dizer "você não tem nada porque não interagiu". Em estado empty, esse bloco é ruído puro.
• Por que a solução óbvia falha: esconder pra user sem posições requer detecção; manter polui.
• Alternativa: header condicional ao estado — se posições == 0, substituir bloco UNI por mensagem de boas-vindas mais ativa ("Primeira posição em LP? Comece com Nova posição ou explore pools recomendadas."); se posições > 0, manter UNI rewards. Trade-off: renderização condicional; ganho: tela empty serve como onboarding em vez de status report vazio.
• Perfil afetado: iniciante novato (principal — primeira impressão da seção) + qualquer user em carteira nova.
• Família com 🔴 Fricção 2 da Tela 10 (PP Base) — mesma raiz: 0 UNI aparece em contextos onde não aplica.

🔴 Fricção 3 — Explorar pools (secundário) e Nova posição (primário) no empty state estão lado a lado sem hierarquia clara de "o que fazer primeiro" (cosmética — CTAs com força visual similar criam paralisia)

• Atrito real: iniciante que chega no empty state vê 2 CTAs com altura/largura similares. Cor difere (Nova posição rosa, Explorar pools outline), mas a hierarquia não traduz recomendação. Iniciante hesita: "qual eu deveria clicar primeiro?". Realidade pedagógica: 99% dos iniciantes deveriam clicar Explorar pools (descobrir antes de criar), não Nova posição (criar cego). Mas o produto destaca Nova posição por convenção (primário = ação principal).
• Por que a solução óbvia falha: inverter a hierarquia frustra avançado que sabe o que quer.
• Alternativa: microcopy entre os CTAs — "Novo em LP? Explore pools primeiro. Já sabe o par? Crie a posição." Cada parte da frase em link/botão. Sem mudar peso visual, mas devolvendo recomendação pedagógica. Trade-off: mais 1 linha; ganho: iniciante recebe nudge correto.
• Perfil afetado: iniciante (principal).

---

🟡 Oportunidade competitiva — Empty state como tutorial guiado com primeira posição low-stakes

• Padrão da indústria: Uniswap (esta tela), PancakeSwap, KyberSwap — empty state oferece CTAs (criar / explorar) mas não acompanha o user no flow. Iniciante que clica Nova posição cai no mesmo flow técnico que avançado: par, range, fee tier, deposit. Curva de aprendizado é cliff.
• Por que afeta o target: primeira posição LP é o momento mais arriscado e didático da jornada. Sem assistência, abandono é alto e perdas iniciantes são frequentes (-50% de IL em primeira posição mal calibrada é normal).
• 4 perguntas-teste: (1) ✓ todos os concorrentes têm empty state estático (2) ✓ afeta iniciante diretamente (target principal) (3) ✓ razão = exige flow tutorial separado + UI; investimento dedicado, factível (4) ✓ ganho perceptível — user vê "Primeira posição? Vamos juntos: $5 em USDC/USDT com retorno garantido pequeno pra você aprender." + botão Começar tutorial.
• Hipótese de diferenciação: "Modo tutorial" no empty state — botão único Primeira posição? Comece com $5 que executa: par stable (USDC/USDT), range wide, v2 (sem decisão de tier), aporte mínimo ($5). User aprende mecânica sem risco real. Ao fim, oferta de "agora crie posição real". Avançado ignora o modo e vai direto.
• Trade-off: mantém pool stable como caso default; exige fundos mínimos do user. Mitigação: tutorial pode ser "simulado" (sem capital real) em primeira passagem.
• Leverage estruturalíssimo — converte cliff de aprendizado em rampa. Família com 🟡 "Wizard de perfil" (Tela 3 PP Base), 🟡 "Presets probabilísticos" (Tela 4 PP Base), 🟡 "Card prescritivo" (Tela 10 PP Base) — Kotai como produto que acompanha o iniciante, não só serve.

---

Observação adicional — split button + Novo com dropdown de versão é decisão de UI que delata maturidade técnica do produto (e dos users assumidos). Uniswap mantém 3 versões coexistindo em produção e força user a escolher. Para Kotai mirar iniciante, decisão equivalente é single button com versão escondida atrás de uma escolha de outcome — "Quero posição simples (full range)" / "Quero posição customizada (range manual)". Versão de protocolo vira implementation detail, não decisão de produto.

2. Filtro Status — Faixa de range

Função: dropdown Status aberto exibindo 3 estados possíveis de uma posição LP (Dentro do intervalo / Fora do intervalo / Fechado) com checkboxes pra filtrar a listagem. Tela revela taxonomia de estados que o produto reconhece pra posições — vocabulário central do mental model LP.

Componentes (diff em relação à Tela 1)

• Toolbar com Status v agora aberto (chevron rotated).
• Dropdown com 3 itens em checkbox:
  • ● Dentro do intervalo ✓ (dot verde — selecionado por default).
  • ● Fora do intervalo ✓ (dot vermelho — selecionado por default).
  • ● Fechado ☐ (dot cinza — desmarcado por default).
• Background (empty state + sidebar) inalterado em relação à Tela 1.

Regras de negócio

• 3 estados refletem ciclo de vida de uma posição LP:
  • Dentro do intervalo = preço atual está entre Min/Max do range → posição rendendo fees.
  • Fora do intervalo = preço saiu do range → capital 100% num lado, parou de render fees, mas ainda existe on-chain.
  • Fechado = user removeu liquidez → posição encerrada, sem capital ativo.
• Default mostra ativos (in + out of range) e esconde Fechado — decisão razoável pra reduzir ruído.
• Dots coloridos antes de cada label = semáforo: verde / vermelho / cinza.
• Checkboxes permitem combinação livre (3 estados × 2 = 8 combinações; algumas degeneradas).

---

🟢 Insight 1 — Semáforo visual antes do label (● verde / ● vermelho / ● cinza) elimina necessidade de decode textual. User scan rapidamente "3 estados" sem ler. Padrão a herdar pra Kotai — qualquer dropdown de status binário/ternário deve ter affordance visual antes do label.

🟢 Insight 2 — Default In + Out (e não In só) reconhece que Out é estado que exige atenção, não que deve ser escondido. User precisa ver posições problemáticas pra agir. Esconder Out por default mascararia problemas. Padrão a herdar — defaults de filtro devem priorizar visibilidade de problemas, não limpeza visual.

🟢 Insight 3 — Fechado como estado nomeado separado de Removido/Excluído preserva histórico sem confundir com posição ativa. Posição existe on-chain pra sempre (NFT); fechada apenas significa "sem capital ativo". Vocabulário preciso. Padrão a herdar — posições/holdings que persistem on-chain devem ter taxonomia de estado, não dicotomia ativo/inexistente.

---

🔴 Fricção 1 — Microcopy do empty state (Nenhuma posição encontrada) NÃO se relaciona ao filtro ativo (estrutural — empty state ambíguo entre "não tem posição" e "filtro escondeu tudo")

• Atrito real: dropdown mostra In + Out selecionados; empty state diz "Você não tem nenhuma posição de liquidez". Mas a mensagem é a mesma se: (a) user de fato não tem posições; (b) tem posições mas todas em estado Fechado (desmarcado por default). Iniciante que tem posição fechada pensa "sumiu" — só descobre se desfizer o filtro por curiosidade.
• Por que a solução óbvia falha: detectar caso (b) exige saber o count total ignorando filtro; trivial mas precisa de impl.
• Alternativa: empty state condicional ao filtro — se total > 0 mas count filtrado = 0, mostrar "Nenhuma posição corresponde aos filtros. Você tem 3 posições Fechado ocultas. [Mostrar todas]". Sem ambiguidade. Trade-off: lógica condicional + cálculo de total ignoring filter; trivial.
• Perfil afetado: iniciante e intermediário com posição histórica fechada.

🔴 Fricção 2 — Dentro / Fora do intervalo é tradução técnica de "in/out of range" — corretamente literal, mas distante do mental model do user (cosmética — vocabulário precisa de tradução pra consequência)

• Atrito real: "Fora do intervalo" diz onde a posição está geometricamente, não o que significa pra você. User com 10 posições filtrando "Fora do intervalo" não vê de imediato que essas posições pararam de render fees. Iniciante lê "Fora do intervalo" e pode achar que é status neutro ("normal, faz parte").
• Por que a solução óbvia falha: renomear pra "Sem render" perde precisão técnica; manter exige decode.
• Alternativa: manter labels técnicas + adicionar tag de outcome — ● Dentro do intervalo (rendendo) / ● Fora do intervalo (parado, ação sugerida) / ● Fechado (sem capital). Pareia label técnica com consequência. Trade-off: labels mais longas; cabem no dropdown.
• Perfil afetado: iniciante (principal — único que não traduz status em ação).

🔴 Fricção 3 — Dropdown de filtro sem indicador no botão de quantos filtros estão ativos (cosmética — affordance fraca de "filtro aplicado")

• Atrito real: após fechar o dropdown, botão Status v volta ao estado neutro. User que esqueceu de re-selecionar Fechado (ou desmarcou In por engano) não vê pela toolbar que o filtro está "reduzido". Pode atribuir lista vazia a "não tenho posições" sem perceber que o filtro está restrito.
• Por que a solução óbvia falha: adicionar texto inline (Status: 2/3) polui toolbar.
• Alternativa: badge numérico discreto no botão — Status (2) quando filtro != default; Status puro quando default. Mostrar mudança em relação ao default protege user de auto-engano. Trade-off: adiciona contador; trivial.
• Perfil afetado: todos os perfis (estrutural a UX de filtros).

---

🟡 Oportunidade competitiva — Filtro de status com inteligência sobre "ação recomendada" por posição

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3 — filtro de status é descritivo (mostra onde a posição está). Não há filtro "precisa de ação" que agrupe Out of range > 24h, fees acumuladas > X, range desbalanceado, etc.
• Por que afeta o target: iniciante e intermediário não sabem qual posição cuidar primeiro. Filtro atual ajuda a categorizar; não ajuda a priorizar.
• 4 perguntas-teste: (1) ✓ todos concorrentes filtram por estado geométrico, não por urgência (2) ✓ afeta iniciante e intermediário (3) ✓ razão = exige modelo de urgência + regras editoriais (4) ✓ ganho perceptível — chip ⚠ Precisa de ação (3) no topo da toolbar lista posições urgentes.
• Hipótese de diferenciação: filtro Ação recomendada acima de Status — agrupa por urgência (Out > 24h, Fees > 10× gas, Range desbalanceado). User vê "o que cuidar" antes de "como está cada posição".
• Trade-off: opinião editorial sobre urgência; aceitar com regras transparentes.
• Leverage estrutural alto — converte filtro descritivo em filtro de ação. Família com 🟡 "Card prescritivo" (Tela 10 PP Base), 🟡 "Insight ativo" — sistema Kotai de assistência ativa em gestão.

---

Observação adicional — Fechado desmarcado por default é decisão de produto coerente, mas pode esconder "posições zumbi" que ainda mantêm allowances ativos do contrato Permit2. Posição fechada não tem capital, mas o approval do token pode continuar válido (uint256 max). Em produto que mire iniciante, vale acoplar revisão de allowances pendentes ao filtro Fechado — "você tem 3 posições fechadas com aprovações ativas. Revogar?". Não é fricção desta tela, mas é gap arquitetural revelado pelo design do filtro.

Consolidado — Suas Posições (Uniswap)

Caráter geral do fluxo

O fluxo "Suas Posições" cobre três estados de entrada: usuário sem wallet (#5), carteira conectada sem histórico (#1–#4, #6), e sistema de filtros tridimensional (Status × Protocolo × Rede). O produto acerta em defaults que respeitam o modelo mental do usuário — filtros chegam pré-configurados para mostrar tudo, split button + Novo em #1 serve iniciante e avançado sem fragmentar UI — e no uso de empty states como espaço editorial em vez de placeholder mudo (#5, #6). O atrito concentra em quatro eixos sistêmicos: versionamento de protocolo exposto como primeira decisão sem nenhum decode (#1, #3); empty state que não distingue "nunca tive posição" de "o filtro escondeu tudo" (#2, #6); conteúdo editorial voltado a power user nas exatas telas onde o público é 100% iniciante (#5, #6); e header de rewards zerado sem condicional de estado, ocupando 30% do espaço útil de onboarding (#1, #6). O perfil mais prejudicado é o iniciante pré-primeira-posição: chega ao hub central do produto e encontra sistema de filtros pensado para power user, empty state ambíguo que pode simular perda de posições, APR de 87% sem caveat de IL, e cards educacionais sobre hooks. As oportunidades de maior leverage são sistêmicas — embedded wallet nativa, empty state prescritivo por saldo e substituição de versão por outcome formam um arco de diferenciação que nenhum concorrente entregou.

---

🟢 Insights recorrentes

Defaults sensatos que servem todos os perfis sem fragmentar UI — telas 1, 2, 3, 4

Padrão mais consistente do fluxo: toda interface de controle chega configurada para o menor esforço cognitivo possível, e a granularidade fica disponível sem obrigar. O split button + Novo em #1 é o exemplo mais limpo — clique direto leva pro default (v3), clique no chevron abre escolha de versão. O iniciante nunca vê o dropdown; o avançado nunca perde a opção. O mesmo princípio aplica aos filtros: Status chega com In + Out ativos em #2 — iniciante vê tudo o que precisa agir, sem precisar configurar; Protocolo em #3 chega com todas as versões marcadas (filtro que não filtra nada por default é filtro opt-in correto); Rede em #4 chega em Todas as redes, agregando patrimônio cross-chain automaticamente.

Diretriz a herdar para Kotai: affordances de poder devem existir e ser acessíveis, mas nunca estar no caminho padrão. Default = menor fricção; customização = opt-in explícito.

Empty state como espaço editorial — telas 1, 5, 6

Em vez de placeholder mudo, o produto usa os três estados vazios como superfície de valor. Em #1, a sidebar Maiores pools por TVL substitui funcionalmente a lista de posições inexistente — pool discovery onde não há posição para mostrar. Em #5, sem wallet conectada, dois cards educacionais (Fornecer liquidez em protocolos diferentes e Hooks no v4) ensinam enquanto o usuário decide se conecta. Em #6, o layout de três zonas (header UNI / toolbar + lista / sidebar) preserva a arquitetura de informação mesmo com lista vazia — iniciante aprende a estrutura da tela sem precisar de posição para isso.

Diretriz a herdar: telas pre-conexão e empty states devem servir conteúdo contextualmente relevante. O vazio é oportunidade editorial, não ausência de UI.

Separação visual entre gestão pessoal e discovery pública — telas 5, 6

Decisão arquitetural correta que aparece nas duas telas: sidebar de discovery (Maiores pools por TVL) funciona igual com wallet conectada (#6) e sem wallet (#5). Discovery não exige identidade. Esquerda da tela = patrimônio + ações (privado, requer identidade); direita = mercado + educação (público, independente de quem é o usuário). O layout de #6 deixa essa hierarquia visualmente clara.

Diretriz a herdar: separar explicitamente UI de discovery (pública) de UI de gestão (privada). Nunca bloquear descoberta por ausência de login.

---

🔴 Fricções recorrentes

Estrutural — Versionamento de protocolo exposto como primeira decisão sem tradução — telas 1, 3

O produto força o usuário a decidir versão de protocolo em dois momentos distintos antes que qualquer posição seja criada ou filtrada. Em #1, o dropdown + Novo apresenta Nova posição de v4 / v3 / v2 como primeira decisão de criação — em ordem cronológica reversa, implicando editorial "v4 é melhor". Em #3, o filtro Protocolo expõe v4 / v3 / v2 sem microcopy. Em nenhum dos dois lugares há tradução de o que cada versão faz para o usuário: v2 = full-range, simples, sem decisão de tier; v3 = concentrated liquidity com range manual; v4 = v3 + hooks customizáveis. Iniciante que clica v4 por estar no topo entra em flow com complexidade incompatível. Iniciante que usa o filtro Protocolo não sabe o que está filtrando.

Por que a solução óbvia falha: explicar diferenças em modal de onboarding é fricção; tooltip sai no próximo clique e não persiste no mental model.

Alternativa concreta: renomear em todo o produto por outcome, não versão técnica — Range completo, simples (v2) / Range manual + fees concentradas (v3) — Recomendado / Customizável com hooks (v4) — Avançado. No dropdown de criação, badge Recomendado em v3 resolve a decisão pra 90% dos iniciantes. No filtro, o nome por outcome elimina a necessidade de decode. Trade-off: vocabulário paralelo ao da indústria; resolver com glossário bridge na ajuda.

Família sistêmica confirmada: esta fricção aparece em 5 pontos no produto total (esta tela #1, filtro #3, header "Posição de v3" na PP Base, "Migrar para v4" na PP Base, dropdown Nova Posição). Torna-se alvo de diferenciação sistêmica, não correção pontual.

Perfil afetado: iniciante (decisão incompatível com mental model) + intermediário sem familiaridade com versionamento.

---

Estrutural — Empty state ambíguo entre "sem posição" e "filtro escondeu tudo" — telas 2, 6

A mensagem Nenhuma posição encontrada é invariante, independentemente da causa. Em #2, com filtros In + Out ativos e Fechado desmarcado por default, usuário que tem posições fechadas vê empty state e pode concluir que "as posições sumiram". Em #6, essa é a tela canônica da fricção: a presença do banner "Quer ver suas posições fechadas? Use o filtro" é um patch que admite o problema sem resolvê-lo — o usuário já precisou ler o banner para entender que há algo oculto.

Por que a solução óbvia falha: banner pós-fato (como em #6) funciona apenas para usuários que leem microcopy; usuário ansioso com posição "sumida" já foi ao Discord antes de ler.

Alternativa concreta: empty state condicional ao filtro — se count(posições, ignorando filtro) > 0 e count(posições, com filtro) == 0, mostrar "Nenhuma posição corresponde aos filtros. Você tem 3 posições Fechado ocultas. [Mostrar todas]". Se count(posições, ignorando filtro) == 0, manter a mensagem atual. Diferenciação elimina ambiguidade. Trade-off: lógica condicional + query de count sem filtro; implementação trivial.

Perfil afetado: iniciante e intermediário com histórico de posições fechadas.

---

Estrutural — Conteúdo editorial voltado a power user nas telas de maior presença de iniciante — telas 5, 6

Os dois cards educacionais fixos no produto — Fornecer liquidez em protocolos diferentes e Hooks no v4 — aparecem em #5 (sem wallet conectada) e em #6 (carteira conectada, 0 posições). Esses são exatamente os estados onde o público é 100% iniciante/novato: quem chega em #5 sem wallet nunca usou DeFi; quem está em #6 com zero posições está na primeira visita à seção. Ambos os cards pressupõem familiaridade com o conceito de liquidez e com o ecossistema de versões. O iniciante lê Hooks no v4 e não tem frame de referência para processar a informação — o card não converte nem educa.

Por que a solução óbvia falha: trocar os cards inteiramente perde o usuário intermediário que retorna para ler material técnico. Duplicar conteúdo aumenta carga de curadoria.

Alternativa concreta: dois cards por nível de familiaridade — Primeira vez? Como funciona provisão de liquidez (3 min) (iniciante, link para guia com linguagem de outcome) e Fornecer liquidez em protocolos diferentes (intermediário). Ambos visíveis; hierarquia visual coloca iniciante em primeiro. Trade-off: curadoria de 2 cards; ganho: serve os 2 perfis em vez de exclusivamente o intermediário.

Perfil afetado: iniciante (principal — framing técnico é barreira imediata).

---

Estrutural — Header 0 UNI Recompensas sem condicional de estado — telas 1, 6

O bloco 0 UNI / Recompensas ganhas / Recolher recompensas (disabled) ocupa o topo da página e aparece tanto em #1 (dropdown aberto, empty state) quanto em #6 (tela canônica de empty state conectado). Em carteira sem posição, o bloco inteiro comunica: "você não tem nada porque não interagiu". Consome cerca de 30% do espaço útil pra dizer informação que o usuário já sabe. Para o iniciante, a primeira impressão da seção Pool é um painel de status de rewards zerados — sinalizando produto projetado para quem já tem histórico, não para quem está chegando.

Por que a solução óbvia falha: esconder condicionalmente requer detecção de count(posições) == 0; manter polui o empty state de onboarding.

Alternativa concreta: header condicional ao estado — se posições == 0, substituir bloco UNI por mensagem de boas-vindas ativa: "Primeira posição em LP? Comece aqui ou explore pools recomendadas."; se posições > 0, manter o bloco de rewards. Trade-off: renderização condicional; ganho: estado empty passa a servir como onboarding, não como status report vazio.

Família confirmada: 5 aparições no produto total (1, 6 deste fluxo + 3 aparições em PP Base). Dívida arquitetural: header global reusado sem condicional de estado da view.

Perfil afetado: iniciante (primeira impressão da seção Pool).

---

Cosmética — CTAs paralelos sem hierarquia pedagógica nos empty states — telas 1, 5

Em #1, o empty state apresenta Explorar pools (secundário, outline) e Nova posição (primário, rosa) com dimensões similares. O produto destaca Nova posição por convenção de UI (primário = ação principal), mas a realidade pedagógica é que 99% dos iniciantes deveriam explorar pools antes de criar — ver APRs, entender pares, comparar fee tiers. O CTA que mais beneficia o iniciante tem aparência de secundário. Em #5, sem wallet conectada, o par é Nova posição (outline) e Conectar carteira (branco/primário suave). Usuário exploratory não sabe qual escolher.

Por que a solução óbvia falha: inverter a hierarquia visual frustra o avançado que já sabe o que quer e espera o CTA de criação em destaque.

Alternativa concreta: microcopy entre os CTAs que devolvem recomendação sem mudar hierarquia visual — "Novo em LP? Explore pools primeiro. Já sabe o par? Crie a posição." Cada frase vinculada ao CTA correspondente. Em #5, acrescentar debaixo do Conectar: "Ainda explorando? Continue sem conectar →" destaca o caminho correto para o explorador sem alterar o primário. Trade-off: mais 1 linha de microcopy; ganho: iniciante recebe nudge correto sem mudar affordance visual.

Perfil afetado: iniciante (principal — sem guidance, paralisia de escolha).

---

Cosmética — Filtros sem indicador de estado ativo após fechar dropdown — telas 2, 4

Em #2, após fechar o dropdown Status, o botão retorna ao visual neutro sem mostrar quantos estados estão ativos. Usuário que desmarcou In range por engano não tem sinal visual na toolbar de que o filtro está restrito. Em #4, o filtro de rede é o único da toolbar sem label textual — só ícone composto + chevron. Os outros três filtros têm label (Status v, Protocolo v); o de rede não. Usuário que olha pela primeira vez pode não reconhecer o ícone como filtro de rede.

Alternativa concreta: para o filtro Status: badge numérico discreto no botão — Status (2) quando difere do default; Status quando default. Para o filtro de rede: adicionar label Rede v ao lado do ícone composto, ou Todas as redes v quando default ativo. Trade-off: mais espaço na toolbar; ganho: paridade de affordance entre os quatro filtros.

Perfil afetado: todos os perfis; iniciante demora mais para identificar o problema.

---

🟡 Oportunidades competitivas do fluxo

Onboarding sem pré-requisito de wallet — embedded wallet nativa — tela 5

Padrão atual da indústria: Uniswap (esta tela), PancakeSwap, KyberSwap, 1inch — todos iniciam o fluxo em "Conectar carteira". Nenhum oferece criação de carteira dentro do produto. Onboarding começa após pré-requisito externo cumprido: wallet EOA instalada, seed phrase salva, carteira financiada.

Por que afeta nosso target: iniciante absoluto — o maior pool de usuários potenciais — não tem wallet. Cada DEX atual exige jornada externa (instalar MetaMask, backup de seed, comprar crypto em exchange, transferir) antes da primeira interação. Esse funil elimina a maioria dos candidatos antes do produto ter qualquer chance de retê-los. O microcopy "Para visualizar posições e recompensas, conecte sua carteira" em #5 pressupõe que o usuário já concluiu essa jornada.

Hipótese de diferenciação Kotai: CTA primário Entrar com email ou Google ao lado de Conectar carteira existente. Email cria smart wallet self-custody via Privy ou Dynamic (passkeys, social recovery), sem seed phrase. On-ramp integrado (Moonpay, Transak) permite aporte fiat direto. Usuário não-cripto vira usuário DeFi sem sair do produto, em menos de 5 minutos.

Trade-off: custo de embedded wallet provider (~$0,05/MAU via Privy); responsabilidade de UX de recuperação (passkeys, social recovery); comunicar clareza de custódia ("seus fundos, não nossos"). Mitigação: smart wallet self-custody = Kotai nunca detém fundos.

Passa nas 4 perguntas-teste? (1) ✓ Nenhum DEX incorpora criação de wallet (2) ✓ Afeta iniciante absoluto, target principal (3) ✓ Embedded wallets (Privy, Dynamic, Coinbase Smart Wallet) existem e são maduras; razão de ninguém ter implementado é investimento de produto, não impossibilidade técnica (4) ✓ Ganho imediatamente perceptível — usuário sem cripto usa DeFi sem sair do produto.

Leverage: estruturalíssima — converte produto cripto-nativo em produto de massa. Família com 🟡 "Modo tutorial" (1) e 🟡 "Empty state prescritivo" (6).

---

Empty state prescritivo baseado em saldo da wallet — telas 1, 6

Padrão atual da indústria: Uniswap (telas #1 e #6), PancakeSwap — empty state é convite genérico ("Crie uma nova posição para começar a ganhar tarifas"). Não considera o que o usuário tem na carteira, qual par seria mais óbvio, ou qual configuração seria conservadora para uma primeira posição.

Por que afeta nosso target: iniciante com $1000 USDC + $500 ETH na carteira tem um caminho ideal de primeira posição baseado nos ativos que já possui. O empty state genérico ignora essa informação e força a jornada de descoberta completa (explorar pools → escolher par → escolher fee tier → configurar range). Específico converte; genérico não.

Hipótese de diferenciação Kotai: leitura on-chain de saldos da wallet ao conectar. Empty state em #6 passa a mostrar: "Você tem $1.000 USDC e $500 ETH. Pool sugerida: USDC/ETH 0,05% fee com range largo — segura para primeira posição. APR médio 30d: 4,89%. [Criar essa posição]". CTA Criar essa posição pré-configura par + range conservador + fee tier dominante. Avançado ignora a sugestão e vai direto para configuração manual. Em #1 sem posições mas com saldo, o mesmo padrão substitui o empty state genérico.

Trade-off: opinião editorial sobre par e range sugeridos; aceitar com critérios transparentes (par mais líquido com os ativos existentes + range de ±20% como conservador). Exige leitura on-chain de saldos ao conectar.

Passa nas 4 perguntas-teste? (1) ✓ Todos os concorrentes têm empty state genérico (2) ✓ Afeta iniciante diretamente (3) ✓ Razão = leitura on-chain + regras editoriais de recomendação; factível (4) ✓ Ganho perceptível — empty state passa de placeholder para assistente de primeira posição.

Leverage: alta — converte estado de maior abandono (vazio, sem direção) em assistente de onboarding. Família com 🟡 "Modo tutorial guiado" (1) e 🟡 "Card prescritivo" (PP Base Tela 10).

---

Versionamento de protocolo → outcome na UI — tela 3 (+ família sistêmica)

Padrão atual da indústria: Uniswap (tela #1 e #3), PancakeSwap v3, 1inch — versão de protocolo é decisão visível para o usuário em múltiplas telas. Implementation detail vaza para a UI como conceito de primeira classe.

Por que afeta nosso target: iniciante não tem mental model para "versão de protocolo". Aprende decorando ("v3 é a boa") sem compreender por quê. Cada DEX tem versões com semântica diferente — "v3 do Uniswap" não ajuda no PancakeSwap v3. O conhecimento não transfere; o usuário está sempre decodando siglas sem base semântica.

Hipótese de diferenciação Kotai: substituir versão por outcome em toda a UI. Filtros: Range completo / Range manual / Customizadas (hooks). Dropdown de criação em #1: Posição simples (full range) / Posição com range (concentrada) / Posição com hooks (avançado). Versão técnica (v2/v3/v4) fica disponível como tooltip de detalhe ou em modo técnico opt-in nas configurações.

Trade-off: glossário paralelo ao da indústria (Kotai usa "Range manual", mercado usa "v3"); custo de coerência com documentação externa. Mitigação: "Range manual (v3)" como label bridge durante período de transição.

Passa nas 4 perguntas-teste? (1) ✓ Todos os concorrentes expõem versão técnica (2) ✓ Afeta iniciante e intermediário (3) ✓ Curadoria + reescrita de toda referência à versão = investimento de produto; não impossibilidade técnica (4) ✓ Ganho perceptível — usuário vê "Range completo" e entende sem precisar decorar v2/v3/v4.

Leverage: alta e sistêmica — 5 ocorrências no produto, todas elegíveis para a mesma correção. Família com 🔴 Fricção 1 deste consolidado (1, 3) + fricções de versão em PP Base.

---

Filtro de ação recomendada por urgência — tela 2

Padrão atual da indústria: Uniswap (tela #2), PancakeSwap v3 — filtro de status é descritivo (mostra onde geometricamente a posição está: dentro ou fora do range). Não há filtro que agrupe por urgência de ação: "posição fora de range há mais de 24h", "fees acumuladas maiores que X× o custo de gas para coletar", "range desbalanceado com risco de conversão total".

Por que afeta nosso target: iniciante e intermediário com múltiplas posições não sabem qual cuidar primeiro. O filtro atual os ajuda a categorizar ("quantas estão fora de range?") mas não a priorizar ("qual precisa de ação hoje?"). A diferença entre filtro descritivo e filtro prescritivo é exatamente a diferença entre ferramenta de power user e assistente de gestão.

Hipótese de diferenciação Kotai: chip ⚠ Precisa de ação (N) na toolbar, acima dos filtros de Status/Protocolo/Rede. Clicar mostra apenas as posições com critério de urgência ativo (fora de range há >24h, fees acumuladas > 5× gas, ou exposição unilateral >80%). Cada posição no resultado exibe o motivo da urgência inline.

Trade-off: modelo editorial de urgência requer regras transparentes para o usuário — "o que faz uma posição aparecer aqui?". Aceitar com critérios visíveis nas configurações.

Passa nas 4 perguntas-teste? (1) ✓ Todos os concorrentes filtram por estado geométrico, não urgência (2) ✓ Afeta iniciante e intermediário (3) ✓ Modelo de urgência + regras editoriais = falta de investimento (4) ✓ Ganho perceptível — usuário abre hub de gestão e vê imediatamente "3 posições precisam de ação" sem precisar ler cada posição.

Leverage: média-alta — converte painel de gestão passivo em assistente ativo. Família com 🟡 "Card prescritivo" (PP Base Tela 10) — sistema Kotai de assistência ativa em gestão de posições.

---

Pontos isolados (1 tela)

• 🟢 Tela 2: semáforos visuais (dots verde/vermelho/cinza) antes do label de status eliminam decode textual — reconhecimento imediato do estado sem leitura.
• 🟢 Tela 2: default In + Out (não só In) reconhece que posição fora de range exige atenção, não deve ser escondida — visibilidade de problemas por default.
• 🟢 Tela 4: badge Novo em chains recém-integradas sinaliza produto vivo e atualizado — construção de confiança com power user.
• 🔴 Tela 3: filtro Protocolo é redundante para iniciante com posições em apenas 1 versão — ocupa espaço de toolbar sem entregar valor. Correção via conditional render: mostrar o filtro apenas quando count(versões distintas nas posições) ≥ 2.
• 🔴 Tela 4: badge Novo em Tempo aumenta atratividade sem entregar informação — usuário curioso clica e não recebe contexto (TPS, gas, maturidade). Correção via tooltip on-hover com 1 frase contextual por rede.
• 🔴 Tela 5: microcopy "Para visualizar posições e recompensas, conecte sua carteira" pressupõe wallet pré-existente — iniciante absoluto abandona por não entender o pré-requisito. Correção trivial: adicionar link "Primeira vez? Como começar →" abaixo do CTA.
• 🔴 Tela 6: APR de 87% na sidebar sem caveat de IL ou janela temporal — gatilho de FOMO para iniciante que entra no flow LP sem entender risco real. (estrutural, 1 tela); família de 5 ocorrências no produto total (PP Base Telas 2, 10; Swap; Pools).
• 🔴 Tela 6: Importar posições v2 relegado a microcopy de rodapé — usuário com posição v2 legada vê empty state e pode concluir que perdeu a posição. Solução via detecção on-chain: se wallet tem NFT v2, exibir banner amarelo no topo ao conectar.
• 🟡 Tela 4: seletor de rede categorizado por finalidade (Rápidas e baratas / Ethereum / Outras) em vez de lista plana — PASSA nas 4 perguntas-teste; leverage menor que as oportunidades principais por ser decisão pouco frequente.

4. Filtro Network — Lista de redes expandida

Função: dropdown do 4º filtro (ícone multi-rede) aberto exibindo lista completa de chains suportadas pra filtrar posições por rede. Tela revela amplitude do produto cross-chain do Uniswap — 9+ redes em produção, incluindo nova chain Tempo com badge Novo.

Componentes (diff em relação à Tela 1)

• Toolbar com 4º filtro aberto — ícone composto multi-colorido (mix de logos de chains).
• Dropdown rolável com itens:
  • ✓ Todas as redes (selecionado por default).
  • Ethereum (ícone Ξ).
  • Unichain (ícone Uniswap rosa).
  • Base (ícone azul).
  • Arbitrum (ícone azul claro).
  • Tempo + badge Novo (rosa).
  • Monad (ícone roxo).
  • Polygon (ícone roxo).
  • X Layer (ícone preto).
  • OP Mainnet (ícone vermelho).
  • … (provável continuação scrollável).
• Background (empty state + sidebar) inalterado.

Regras de negócio

• Default Todas as redes = agregação automática de posições cross-chain.
• Selecionar 1 rede restringe a listagem (e provavelmente afeta também o flow + Novo — criar posição na rede selecionada).
• Badge Novo em Tempo indica lançamento recente — sinal de mídia/produto pra promover adoção.
• Lista mistura L1 (Ethereum, Monad), L2 (Base, Arbitrum, OP Mainnet, Polygon, X Layer) e app-chain (Unichain) sem distinção visual.
• Uniswap como agregador cross-chain — produto unificado sobre múltiplas chains.

---

🟢 Insight 1 — Default Todas as redes agrega patrimônio cross-chain sem exigir setup. User com posições em Base e Arbitrum vê tudo junto. Sem isso, user teria que trocar manualmente entre redes — fricção de power user transferida pra default. Padrão a herdar pra Kotai — multi-chain deve ser default agregado, restrição é opt-in.

🟢 Insight 2 — Ícones coloridos por rede + label = identificação por reconhecimento, não leitura. User experiente reconhece Base pelo azul, Arbitrum pelo logo. Padrão a herdar — listas de redes devem ter affordance visual de marca, não só texto.

🟢 Insight 3 — Badge Novo em Tempo é sinal de produto vivo e atualizado. Comunica que o produto integra novas chains em ritmo — sinal de saúde da plataforma pra power user. Padrão a herdar — flags Novo / Beta / Deprecated em itens de catálogo aumentam confiança.

---

🔴 Fricção 1 — Lista de 9+ redes sem categorização semântica (L1/L2/app-chain) força user a saber o que é cada uma (estrutural — catálogo plano onde hierarquia ajudaria)

• Atrito real: lista mistura Ethereum (L1, gas alto), Base (L2, gas baixo), Polygon (L2 EVM), Unichain (app-chain Uniswap), Monad (L1 alternativo), Tempo (??). Iniciante não sabe diferença e o produto não explica. User pode escolher Ethereum por nome familiar e pagar 50× mais gas que faria na Base equivalente. Pior: cada rede tem custos, latências, segurança e ecossistema diferentes — escolha cega tem consequência real.
• Por que a solução óbvia falha: agrupar em headers (L1 / L2 / App-chain) é tecnicamente correto mas usa vocabulário que iniciante não decoda; descrição inline por rede polui.
• Alternativa: dividir o dropdown em 2 seções com headers humanizados — Redes rápidas e baratas (L2s: Base, Arbitrum, OP Mainnet, Polygon) / Outras redes (Ethereum, Unichain, Tempo, Monad, X Layer). Ou: badge inline ~$0.01 gas / ~$15 gas ao lado de cada item. Trade-off: opinião editorial sobre rede; aceitar com base em mediana de gas observada.
• Perfil afetado: iniciante (principal — único que escolheria Ethereum sem saber custo) + intermediário sem familiaridade cross-chain.

🔴 Fricção 2 — Ícone do filtro de rede (mix de logos sobrepostos) é affordance fraca de "filtrar por rede" (cosmética — affordance icônica sem label)

• Atrito real: os outros filtros (Status v, Protocolo v) têm label textual. O filtro de rede é só um ícone composto + chevron. User que olha pela primeira vez não sabe que é filtro de rede — pode achar que é "carteiras conectadas" ou "chains ativos". Iniciante não clica por incerteza; intermediário clica por curiosidade.
• Por que a solução óbvia falha: adicionar label Rede v aumenta largura da toolbar.
• Alternativa: adicionar label textual ao lado do ícone — Rede v (ou Todas as redes v quando default ativo) compactando ícone. Toolbar fica com 4 botões com label, não 3 + 1 puramente icônico. Trade-off: mais espaço; ganho: paridade de affordance entre filtros.
• Perfil afetado: todos os perfis (iniciante atrasa entendimento, intermediário tateia).

🔴 Fricção 3 — Tempo aparece sem contexto do que é a chain — badge Novo aumenta atratividade sem entrega de informação (estrutural — produto promove rede nova com badge sem explicar por que escolher)

• Atrito real: badge Novo é gatilho de curiosidade — "o que é Tempo?". User clica esperando descobrir. Mas a tela só restringe a listagem (que já está vazia). Não há contexto: TPS? gas? backers? Comparação com outras chains? Decisão de escolher Tempo vira aposta cega.
• Por que a solução óbvia falha: explicar cada rede em tooltip é trabalho de documentação extenso.
• Alternativa: tooltip on-hover por rede com 1 frase contextual — Tempo mostra "L2 de alta performance, lançada 2026, gas ~$0.005". Disponível em todas as redes (não só novas). Trade-off: curadoria contínua.
• Perfil afetado: iniciante e intermediário curioso sobre rede nova.
• Família confirmada com Fricção 1 da Tela 7 (PP Base) — produto promove descoberta de redes (cross-promo) mas não acompanha com info pra decisão informada.

---

🟡 Oportunidade competitiva — Seletor de rede com "agregação por finalidade" em vez de catálogo plano

• Padrão da indústria: Uniswap (esta tela), 1inch, Curve — dropdown lista chains alfabeticamente ou por TVL. Decisão de rede é técnica e cega ao caso de uso.
• Por que afeta o target: iniciante quer "a melhor rede pra meu caso" — par stable em rede barata, ou par ETH em rede líquida. Não tem feature de comparar redes pelo objetivo.
• 4 perguntas-teste: (1) ✓ todos concorrentes têm catálogo plano (2) ✓ afeta iniciante e intermediário (3) ✓ razão = exige curadoria + modelo de fit; falta de investimento (4) ✓ ganho perceptível — user vê Para iniciantes (gas barato, alta confiabilidade): Base 🥇 / Arbitrum 🥈 e escolhe com critério.
• Hipótese de diferenciação: seletor categorizado por adequação ao user — agrupa chains em Iniciante / Equilibrada / Avançada baseado em gas médio + maturidade + liquidez. Mostra recomendação top dentro de cada categoria.
• Trade-off: opinião editorial forte; aceitar com critérios transparentes.
• Leverage estrutural alto — converte escolha técnica em escolha de outcome. Família com 🟡 "Ranking por perfil" (Tela 1 PP Base), 🟡 "Wizard de versão" (Tela 3 PP Base) — sistema Kotai = transformar decisão técnica em decisão de outcome.

---

Observação adicional — Uniswap lista Unichain como uma rede entre outras, sem destaque editorial. Sendo a app-chain proprietária do Uniswap, faria sentido empurrá-la (Coinbase faz isso com Base). Decisão de mantê-la neutra é product-political — não "empurrar nossa rede". Vale registrar como observação de postura de produto: cross-promo é seletivo (X Layer cross-banner sim, Unichain destaque não). Inconsistência interna do produto.

1. Portfólio — Visão geral (estado vazio, carteira conectada sem saldo)

Função: Dashboard principal do portfólio após conexão de carteira EVM sem fundos. Entry point pós-onboarding: o produto precisa converter o estado vazio em decisão de funding (comprar, receber transfer ou puxar de CEX). É a tela mais delicada do flow inteiro — se aqui o usuário não souber o próximo passo, a sessão morre.

Componentes

• Header: logo Uniswap, nav (Negociar / Explorar / Pool / Portfólio ✓), search bar Pesquisar tokens, pools e carteiras, badge da wallet 0xd09B…618a no canto direito.
• Sub-header da página: avatar + 0xd09B…618a + microcopy +1 a mais (multi-wallet). Direita: CTA Compartilhar + seletor Todas as redes ▾.
• Tabs: Visão geral ✓ / Tokens / NFTs / Atividade.
• Big stat: 0,00 US$ em cinza-claro.
• Área central com layout de gráfico vazio (linha divisória horizontal + marcadores de eixo Y placeholder pontilhados à direita).
• Controles de timeframe abaixo: 1 hora / 1 dia ✓ / 1 semana / 1 mês / 1 ano / Tudo — todos clicáveis.
• Coluna direita: 3 cards CTA empilhados.
  • Compre criptos — "Compre com cartão de débito ou conta bancária."
  • Receber criptos — "Transfira fundos de outra carteira."
  • Transferência — "Transfira fundos de uma plataforma de negociação."

Regras de negócio

• Todas as redes agrega saldo cross-chain (escopo do número 0,00 US$).
• +1 a mais indica que existem outras wallets vinculadas — agregação multi-wallet sem expor todos os endereços.
• Os 3 cards mapeiam as 3 fontes possíveis de funding em DeFi: fiat on-ramp, transfer self-custody, transfer CEX.
• Timeframe pills ativas mesmo sem dados (clicar troca highlight mas não renderiza nada).

---

🟢 Insight 1 — Empty state convertido em 3 paths de funding explícitos. O estado mais doloroso do produto ("como coloco dinheiro aqui") é dissolvido em 3 cards nomeados por fonte de origem, não por jargão. Diferente de empty state genérico (ilustração + "nada aqui ainda"), este vira interface de decisão. Padrão a herdar para Kotai — toda tela com saldo zero precisa entregar caminho concreto de funding, não decoração.

🟢 Insight 2 — Microcopy descreve a modalidade, não o produto. "Cartão de débito ou conta bancária" (não "Moonpay"), "de outra carteira" (não "deposit address"), "de uma plataforma de negociação" (não "CEX"). Iniciante reconhece o conceito antes do nome do parceiro. Padrão a herdar — copy de empty state deve falar a língua da pergunta mental do user, não a do backend.

---

🔴 Fricção 1 — Gráfico placeholder com controles temporais ativos não faz sentido em saldo zero (estrutural — controle morto polui affordance)

• Atrito real: o eixo do gráfico + timeframe pills (1 hora / 1 dia / 1 semana ...) sugerem que há série temporal pra explorar. Iniciante clica 1 mês, nada acontece — saldo sempre foi 0. Controle interativo morto erode confiança no resto da UI ("o que mais não funciona?").
• Solução óbvia que falha: "esconder o gráfico até existir dado" — perde a affordance educativa de "aqui no futuro vai ver seu histórico" e desperdiça o espaço central da página.
• Alternativa: substituir as pills + placeholder por um estado único explicado — caption central "Seu histórico aparece aqui depois do primeiro depósito" com mock leve de linha (não interativo). Recupera-se a affordance pedagógica sem o controle falso. Trade-off: gráfico fica menos "técnico" no first impression, mas elimina clique sem resposta.
• Perfil afetado: iniciante (principal — testa controles pra entender o produto).

🔴 Fricção 2 — Todas as redes no header sem informar quais redes (estrutural — agregação opaca afeta confiança no número)

• Atrito real: o 0,00 US$ é agregado cross-chain, mas o user não sabe sobre quantas/quais redes. Se ele tiver token em rede não suportada (ex: Avalanche, BSC), o número mostra 0 e ele conclui que perdeu fundos quando na verdade só está fora do escopo. Risco de pânico falso e churn no momento mais frágil.
• Solução óbvia falha: listar as N redes inline — vira ruído visual no header.
• Alternativa: contador inline Todas as redes (18) + tooltip no hover com a lista completa. Iniciante percebe que existe um escopo definido (não é "todo o universo cripto"); avançado decoda direto. Trade-off: mais um número no header.
• Perfil afetado: iniciante e intermediário multi-chain.

🔴 Fricção 3 — Hierarquia entre os 3 cards de funding é plana (cosmética — recomendação implícita ausente)

• Atrito real: os 3 cards têm peso visual idêntico — mesma altura, mesma cor, mesmo destaque. Iniciante BR que nunca usou cripto não sabe qual escolher: comprar com cartão (rápido + caro), receber de outra carteira (não tem outra carteira), ou puxar de Coinbase (não tem Coinbase). Três opções sem recomendação contextual viram paralisia.
• Solução óbvia falha: ordenar por uso global "mais comum primeiro" — varia por região e perfil.
• Alternativa: detectar contexto e destacar 1 card como recomendado — primeiro acesso sem histórico → Compre criptos em destaque (rosa). Wallet com transações em outra chain → Receber criptos em destaque. Os outros dois ficam como secundários, não ocultos. Trade-off: exige heurística + risco de errar; aceitar com fallback neutro.
• Perfil afetado: iniciante (principal — sem heurística mental pra escolher).

---

🟡 Oportunidade competitiva — On-ramp local-first como primeiro card de funding (alta leverage no target BR/LatAm)

• Padrão da indústria: Uniswap, PancakeSwap, 1inch oferecem Comprar com cartão via on-ramp global (Moonpay, Transak, Ramp) com fee de 3–7% e UX desconectada da geografia. Para usuário BR, isso significa cobrança em USD, conversão cambial opaca, taxa alta vs alternativa local (PIX → CEX BR → wallet sai mais barato e mais rápido).
• Por que afeta o target: a barreira de entrada cripto no Brasil não é o produto DeFi, é o on-ramp. Iniciante BR que clica Compre criptos e cai em fluxo Moonpay com fee 6% + KYC internacional abandona a sessão. O empty state "perde" o user antes dele tocar no produto.
• 4 perguntas-teste: (1) ✓ todos usam on-ramp global (2) ✓ afeta iniciante BR diretamente (3) ✓ razão = falta de investimento em integrações locais (Mercado Bitcoin, Bitso, Notus, Transfero existem) (4) ✓ ganho perceptível — PIX em segundos vs cartão internacional com fee 6%.
• Hipótese de diferenciação Kotai: detectar região da wallet/IP e priorizar on-ramp local. Card Compre criptos mostra inline via PIX (BR) — taxa estimada 1,5% como default; cartão internacional vira fallback dentro do modal. Fee exibida ANTES do clique, não escondida no flow Moonpay.
• Trade-off: integração de N rampas locais por jurisdição + manutenção de compliance KYC por país. Investimento real, mas vetor competitivo direto pra LatAm, onde o ecossistema BR já é um dos top-5 globais em volume de cripto retail.

---

Observação adicional: +1 a mais no avatar é progressive disclosure correta para multi-wallet, mas não há indicação do que acontece ao clicar (lista? troca de wallet ativa? agregação?). Não é fricção desta tela, mas é nota pra checar consistência do flow multi-wallet — o número é affordance que precisa cumprir o que sugere.

4. Portfólio — Modal Receber criptos

Função: Modal de funding por transferência. Acionado pelo card Receber criptos da tab Visão geral. Entrega os endereços de depósito da wallet do user, organizados por família de chain (EVM agregado + Solana separada) + atalho De uma conta pra puxar de CEX. É o modal mais sensível do flow inteiro — endereços errados/redes erradas custam dinheiro real e irreversível.

Componentes

• Modal centralizado sobre a página de portfólio (que continua visível desfocada atrás).
• Header do modal: link 📧 Pedir ajuda (suporte contextual) à esquerda + X fechar à direita.
• Título: Receber criptos.
• Subtítulo: "Abasteça sua carteira transferindo criptos de outra carteira ou conta."
• Card 1 (EVM agregado): avatar rosa + 0xd09B…618a + caption Ethereum +17 redes + 2 botões à direita (📋 Copiar | ▦ QR).
• Card 2 (Solana): ícone ampulheta cinza + EQp4…BDxK + caption Solana + 2 botões idênticos (📋 Copiar | ▦ QR).
• Separador: De uma conta.
• Card 3 (CEX): ícone Coinbase azul + label Coinbase (sem CTA secundário; clique navega).

Regras de negócio

• Card 1 reflete que um único endereço EVM funciona em N chains EVM-compatíveis (Ethereum + 17 redes — Arbitrum, Base, Optimism, Polygon etc.) porque todas usam Secp256k1 / mesma derivação.
• Card 2 é separado porque Solana usa Ed25519 — endereço incompatível com EVM. Decisão de arquitetura correta (misturar EVM e Solana num mesmo endereço seria perda garantida).
• Card 3 (Coinbase) é deeplink pra Coinbase Onramp/transfer — pré-preenche endereço da wallet + sugere envio na rede correta. Não é endereço, é integração de aplicativo.
• Modal não tem seletor de rede explícito — assume que user sabe qual rede usar dentro do conjunto EVM.

---

🟢 Insight 1 — Agregação EVM num endereço único é decisão arquitetural correta. Listar Ethereum, Arbitrum, Base etc. como cards separados (cada um repetindo o mesmo endereço) seria poluição vazia — o endereço é o mesmo. Caption Ethereum +17 redes comunica o escopo sem repetir o endereço. Padrão a herdar — quando o protocolo subjacente é o mesmo, agregar; quando é diferente (Solana), separar.

🟢 Insight 2 — 📧 Pedir ajuda no header do modal é affordance de suporte exatamente no momento mais sensível. Transfer de cripto é o ponto de não-retorno; ter suporte 1 clique de distância (não enterrado no footer da app, não em chatbot lateral) é decisão consciente de segurança. Padrão a herdar — affordance de ajuda deve viver dentro de modais de ação irreversível, não global na app.

🟢 Insight 3 — De uma conta — Coinbase como caminho não-onchain reconhece a realidade do funding. Maioria do user iniciante não tem "outra wallet" pra puxar — tem CEX. Diferenciar visualmente "De uma carteira" (endereços) vs "De uma conta" (CEX integration) educa sem precisar de jargão. Padrão a herdar.

🟢 Insight 4 — QR Code + Copy como ações pareadas. Cobre os dois caminhos reais: copy pra colar em app desktop, QR pra escanear no celular. Padrão correto.

---

🔴 Fricção 1 — +17 redes sem listar quais redes (e quais NÃO estão) (estrutural — vetor #1 de perda de fundos)

• Atrito real: o user tem token X em rede Y (ex: USDT em Avalanche, BNB em BSC, USDC em Linea). Vê Ethereum +17 redes e assume que sua rede está incluída — copia endereço, envia, fundos somem em chain não suportada (ou pior: chegam em chain suportada mas o produto não detecta o token, então user vê wallet "vazia" e entra em pânico). "+17" oculta exatamente a informação que evita perda: quais são as 17 e quais não são.
• Solução óbvia que falha: listar todas as 17 redes inline — vira ruído enorme dentro do card, quebra a estética do modal.
• Alternativa: Ethereum +17 redes ▾ expandível que abre a lista completa inline; alternativamente, tooltip no hover. Mais importante ainda: separar a lista em "redes suportadas" e "redes populares NÃO suportadas" (ex: "Avalanche não está incluída — não envie"). Trade-off: lista negativa é decisão delicada (pode ofender ecossistemas), mas é a única que evita erro silencioso.
• Perfil afetado: iniciante e intermediário multi-chain (principal — único caminho de erro irreversível).

🔴 Fricção 2 — Modal entrega endereço sem nenhuma proteção de token-rede mismatch (estrutural — vetor #1 de perda real em DeFi)

• Atrito real: user envia USDT-TRC20 (rede Tron) pro endereço EVM. Fundos perdidos pra sempre. Modal entrega o endereço e confia que o user sabe qual token + rede está mandando. Para iniciante, esse pressuposto é exatamente o que falha. Vale recordar: token-rede mismatch é o vetor de perda mais comum em DeFi pra iniciante, e este modal é onde ele acontece.
• Solução óbvia que falha: bloquear copy até user confirmar token+rede em um formulário — UX cansa, avançado reclama.
• Alternativa: fluxo guiado de 2 passos — (1) user escolhe token + rede; (2) modal mostra apenas o endereço daquela rede + aviso reforçado "Envie APENAS [Token] na rede [Rede]. Outras combinações resultarão em perda de fundos." O modo atual (lista de endereços) vira modo "avançado" opcional. Para o caminho De uma conta — Coinbase, integração já pré-seleciona token+rede e o problema some por construção. Trade-off: 1 clique a mais; ganho: zero perda silenciosa.
• Perfil afetado: iniciante (principal — quem mais sofre o vetor).
• Família com 🟡 abaixo — mesma raiz.

🔴 Fricção 3 — Ícone ampulheta cinza pra Solana é semanticamente errado (cosmética — signal visual contradiz atributo da chain)

• Atrito real: card Solana usa ícone "ampulheta cinza" que visualmente sugere "pendente / loading / espera". Solana é literalmente conhecida por velocidade (block time sub-segundo). O ícone está contradizendo o atributo principal da chain. Provavelmente é placeholder/decoração, mas para iniciante parece signal de que Solana "está demorando" ou "está em manutenção". Pequeno mas inadequado.
• Solução óbvia falha: trocar por qualquer ícone aleatório — mantém o problema.
• Alternativa: ícone logo da chain (Solana sun-circle) consistente com o tratamento do card EVM (avatar customizado). Trade-off: nenhum relevante.
• Perfil afetado: cosmético, todos.

---

🟡 Oportunidade competitiva — Receber como fluxo guiado token-rede-first em vez de endereço-first (alta leverage no target)

• Padrão da indústria: Uniswap (esta tela), Zerion, Zapper, Phantom, Rabby — todos entregam endereço como artefato principal. "Aqui está seu endereço, copia e usa". Token e rede ficam por conta do user lembrar. Isso transfere o risco do produto pro user iniciante, que é exatamente quem não tem ferramenta para gerenciar esse risco.
• Por que afeta o target: mismatch token-rede é a perda mais comum e mais cara em DeFi pra iniciante. Não é hack, não é scam — é usabilidade. Endereço cru sem contexto de token/rede transforma uma decisão técnica complexa em ação de 1 clique sem fricção e sem rede de segurança.
• 4 perguntas-teste: (1) ✓ todos os concorrentes entregam endereço cru (2) ✓ afeta iniciante diretamente — é O vetor de perda (3) ✓ razão = exige fluxo guiado, modelo de detecção de token e rede; falta de investimento (4) ✓ ganho perceptível — diferença entre "perdi $500 mandando USDT-TRC20" e "o produto não me deixou cometer o erro".
• Hipótese de diferenciação Kotai: fluxo guiado — usuário escolhe token (busca com lista) + rede (filtrada pelas redes onde aquele token existe + tem liquidez). Modal mostra apenas o endereço daquela rede com aviso reforçado e ícone de token+rede no topo. QR Code embute metadata da rede (alguns wallets já leem isso). Atalho De uma conta — Coinbase permanece como fast-path para quem está em CEX (integração já resolve token+rede automaticamente). Modo "endereço cru" sobrevive como toggle "avançado" no canto.
• Trade-off: 1–2 cliques a mais no caminho receber; UX adicional para construir; necessidade de manter mapa atualizado de "em quais redes cada token existe". Aceitar — o custo de UX é trivial vs custo de perda real do user.
• Leverage: estrutural alta — converte o vetor de perda mais caro em fluxo seguro. Diferencial direto e perceptível para iniciante BR/LatAm/global south (que entram em cripto por on-ramp local + transfer manual, exatamente este flow).

---

Observação adicional: Coinbase é a única CEX listada — exclusão deliberada de Binance, Kraken, OKX, MercadoBitcoin etc. Pode refletir parceria comercial (Coinbase Onramp API), pode refletir geografia do target (Coinbase é forte em US/UE, fraco em LatAm/Ásia). Para iniciante BR a integração "Coinbase" é praticamente inútil — vetor de exclusão geográfica não-óbvio. Vale registrar como decisão estratégica do Uniswap (não fricção desta tela) e mapear como Kotai pode capturar o caminho que falta: integração local-first (Mercado Bitcoin/Bitso/Notus pra BR/LatAm) na mesma posição visual do Coinbase aqui.

2. Portfólio — Tab Tokens vazia

Função: Sub-página da tab Tokens (URL /portfolio/tokens) no estado em que a carteira não tem nenhum token detectado pelo indexer. Função primária: confirmar ausência sem alarmar e direcionar pra ação concreta de funding.

Componentes

• Header e sub-header idênticos à Visão geral (avatar 0xd09B…618a, +1 a mais, Compartilhar, Todas as redes ▾).
• Tabs: Visão geral / Tokens ✓ / NFTs / Atividade.
• Big stat: 0,00 US$ + linha secundária ▲ 0,00% · 0 tokens (seta verde, texto cinza).
• Search bar à direita: Procurar tokens (input ativo mesmo no empty).
• Empty state central: ilustração de moedas/dados translúcidos cinza + título Nenhum token ainda + subtítulo Transfira tokens de outra carteira para começar.
• Sem CTA explícito na área central do empty.

Regras de negócio

• URL muda pra /portfolio/tokens — cada tab é estado URL-able.
• Saldo no topo da tab Tokens reflete escopo da tab (soma de tokens), não saldo total do portfólio — coincide com Visão geral só porque ambos são 0.
• Delta ▲ 0,00% é calculado sobre janela default (1d) — verde+seta vêm do template do estado populado.
• Search bar funciona como filtro sobre lista de tokens detectados; no empty, é affordance "escala-pronta".

---

🟢 Insight 1 — Copy do empty state é instrução imperativa e específica. "Transfira tokens de outra carteira para começar" diz exatamente o que fazer e de onde (outra carteira). Não usa jargão ("deposit address", "on-chain transfer") nem genericidade ("adicione fundos"). Iniciante sai com instrução acionável. Padrão a herdar — empty state nunca como decoração; sempre instrução acionável em verbo no imperativo + objeto específico.

🟢 Insight 2 — Search bar visível mesmo com lista vazia. Comunica implicitamente que a lista pode crescer e será buscável quando crescer. É affordance "escala-pronta" — o user entende que esta tela escala sem ele precisar imaginar como. Padrão a herdar — controles que farão sentido depois devem permanecer visíveis (não escondidos) no empty.

---

🔴 Fricção 1 — Instrução do empty state sem CTA correspondente inline (estrutural — gap entre dizer e fazer)

• Atrito real: a copy ordena "Transfira tokens de outra carteira". O modal que executa exatamente isso (Receber criptos, com endereços por rede + QR) existe — mas só na tab Visão geral, como card lateral. Aqui na tab Tokens, o user lê a instrução e não tem botão. Cenário típico: abre Etherscan/MetaMask manualmente, faz transfer com endereço copiado de outro lugar — desnecessariamente fora do produto, com risco de copiar endereço errado.
• Solução óbvia que falharia: replicar os 3 cards de funding (Compre/Receber/Transferência) embaixo do empty — duplica navegação, dilui foco e contradiz a copy que pediu apenas "transferir".
• Alternativa: botão único Receber criptos inline abaixo da copy, abrindo o mesmo modal que existe na Visão geral. Um CTA alinhado a uma instrução. Trade-off: mais um botão na tela; ganho: zero gap entre dizer "transfira" e dar a ferramenta de transfer.
• Perfil afetado: iniciante (principal) e intermediário sem hábito de navegar entre tabs.

🔴 Fricção 2 — Delta ▲ 0,00% · 0 tokens em verde sugere performance positiva onde não há nada pra medir (estrutural — métrica nonsense renderizada como signal positivo)

• Atrito real: seta pra cima (▲) + cor verde + sufixo de variação são pattern visual de "ganho". Aplicado a 0 sobre 0, vira leitura ambígua: iniciante pode interpretar como "meu portfólio está performando bem (0% é estável)" quando na realidade é "não há nada pra medir". Pior — quando ele de fato tiver token e o delta for negativo, a transição de verde-seta-pra-cima pra vermelho-seta-pra-baixo vira choque visual desproporcional ao que mudou.
• Solução óbvia falha: ocultar a linha — perde paridade visual com o estado populado e some o conceito de "variação" da tela.
• Alternativa: renderizar o delta em neutro (cinza, sem seta) quando saldo = 0, com copy Sem variação para medir. Mantém o slot, remove o falso signal. Trade-off: regra extra de renderização por estado; ganho: zero leitura ambígua e transição visual proporcional quando popular.
• Perfil afetado: iniciante (principal).

🔴 Fricção 3 — Big stat 0,00 US$ ambíguo entre "total tokens" e "total portfólio" (estrutural — escopo do número não está rotulado)

• Atrito real: o 0,00 US$ aparece grande, idêntico ao da Visão geral. No vazio coincide; quando o portfólio for misto (tokens + NFTs + posições em pool), o número da tab Tokens será subset do número da Visão geral. Sem rótulo, user que troca de tab vê o saldo "cair" e não entende — "perdi algo?". É bomba-relógio: a fricção aparece quando o produto for usado de verdade, não no empty.
• Solução óbvia falha: remover o saldo da tab Tokens — perde âncora de "quanto vale o que está nesta tab".
• Alternativa: rotular explicitamente o escopo — label menor acima do number: Total em tokens na tab Tokens, Patrimônio total na Visão geral. Hierarquia clara: o number é do escopo da tab, não do portfólio inteiro. Trade-off: label adicional consome vertical; ganho: zero confusão quando o portfólio for misto.
• Perfil afetado: iniciante e intermediário (avançado já sabe checar).
• Família com fricção da Visão geral sobre Todas as redes: mesma raiz — produto exibe agregados sem rotular o escopo da agregação.

---

🟡 Oportunidade competitiva — Distinguir valor declarado × valor recuperável por token (média-alta leverage no target)

• Padrão da indústria: Uniswap (esta tela), Zapper, DeBank, Zerion mostram saldo de tokens em US$ usando preço de tela (preço last-trade ou oracle). Não informam se o token é líquido o suficiente pra realizar aquele valor — usuário com shitcoin de baixo volume vê "100 US$ em $PEPE2024" e acredita que pode vender. Tenta, recebe 12 US$ por slippage devastador. Trust quebra no momento de saída.
• Por que afeta o target: iniciante e intermediário avaliam patrimônio pelo number da tela. Se o number é ficção (declarado mas não recuperável), o portfólio inteiro vira ilusão contábil. É exatamente o vetor que dispara reclamação "essa cripto não vale o que diz" — mas o problema é de exibição, não de mercado.
• 4 perguntas-teste: (1) ✓ todos os concorrentes usam preço de tela como valor (2) ✓ afeta iniciante diretamente (3) ✓ razão = exige cálculo de saída via rota de venda e modelo de slippage por liquidez de pool; falta de investimento, não impossibilidade (4) ✓ ganho perceptível — user vê linha 100 US$ · saída estimada 14 US$ e ajusta expectativa antes de tentar vender.
• Hipótese de diferenciação Kotai: segunda linha por token na lista — Valor: 100 US$ · Saída estimada: 14 US$ (calculado com slippage real da melhor rota de venda em USDC/ETH). Na hero do portfólio, dois numbers — Patrimônio declarado e Patrimônio recuperável. Toggle pra avançado esconder.
• Trade-off: requer cálculo on-demand por token (cota de RPC, cache de rotas) + modelo de slippage. Pode irritar avançado que sabe o que está fazendo — aceitar com toggle. Pode também classificar shitcoin do user como "sem saída" e gerar atrito político ("por que vocês acham meu token ruim?") — mitigar com copy neutra ("liquidez limitada", não "valor irreal").
• Leverage: estrutural — converte portfólio de "contabilidade de fantasia" em "contabilidade realizável". Diferencia o produto de toda a categoria de portfolio trackers.

---

Observação adicional: a URL muda corretamente pra /portfolio/tokens (deeplink por tab) — padrão a herdar. Permite compartilhar a aba específica e voltar via histórico do browser. Pequeno detalhe técnico que sustenta navegação séria; vale checar se as outras tabs (NFTs, Atividade) também são URL-able com o mesmo rigor.

3. Portfólio — Tab Atividade vazia + popover Compartilhar aberto

Função: Tab Atividade (URL /portfolio/activity) em estado sem histórico, com o popover Compartilhar (acionado a partir do botão do header) aberto sobre a UI. Tela serve dois objetivos simultâneos: confirmar ausência de transações e expor o vetor social do produto (compartilhar wallet pública).

Componentes

• Header e sub-header padrão da página de portfólio (avatar 0xd09B…618a, +1 a mais, CTAs Compartilhar + Todas as redes ▾).
• Tabs: Visão geral / Tokens / NFTs / Atividade ✓.
• Linha de controles: dropdown Todos os tipos ▾, dropdown Todo o período ▾, search bar Procurar atividade (à direita).
• Empty state central: ilustração de recibos cinza + título Nenhuma atividade ainda + subtítulo "Quando você fizer transações, elas aparecerão aqui."
• Popover Compartilhar aberto, ancorado abaixo do botão direito, com 3 itens:
  • ícone Ethereum + Copiar link do portfólio
  • ícone Solana + Copiar link do portfólio (label idêntico ao anterior — só o ícone diferencia)
  • ícone X (Twitter) + Compartilhar no Twitter
• Popover cobre parcialmente a search bar Procurar atividade.

Regras de negócio

• Compartilhar gera URL pública da wallet (read-only) — vetor social: "mostrar meu portfólio para X".
• Os 2 "Copiar link" refletem que a wallet tem identidade EVM + Solana (endereços diferentes); cada link aponta para uma URL pública distinta.
• Empty state copy é causal: "quando ... aparecerão" — vincula ação esperada (fazer transação) ao resultado (aparecer na lista).
• Filtros Todos os tipos e Todo o período ativos mesmo no empty — clicar abre dropdown mas não tem efeito sobre a lista vazia.

---

🟢 Insight 1 — Empty state com copy causal supera empty state imperativo. "Quando você fizer transações, elas aparecerão aqui" descreve a causa (fazer transação) E o efeito (aparecer aqui), sem ordem imperativa nem instrução acionável que não pertence à tela. Diferente da tab Tokens (que pede transferência), a tab Atividade não pode ser "populada por ação direta" — só populates como consequência de outras ações. A copy reconhece isso. Padrão a herdar — empty state declarativo onde não há ação local, imperativo onde há.

🟢 Insight 2 — Compartilhamento de portfólio como objeto público é vetor DeFi nativo. Wallets são públicas on-chain — o produto não "esconde" isso, materializa como compartilhável. Reconhece o etos do espaço (transparência radical) e abre vetor orgânico de crescimento (amigo manda link → conversão). Padrão a herdar.

---

🔴 Fricção 1 — Dois itens Copiar link do portfólio com label idêntico, diferenciados apenas por ícone (estrutural — ambiguidade no momento da ação)

• Atrito real: o user clica num item, o sistema copia uma URL — ele não vê qual URL foi copiada nem por qual chain. Cenário: clica no segundo item (Solana) pensando que é "a versão completa", manda pro amigo que abre e vê endereço Solana, mas o amigo é EVM-only. Pior: o user não sabe que clicou no errado até receber feedback (e talvez nunca receba). Label idêntico mata a diferenciação no ato da decisão.
• Solução óbvia que falha: remover um dos dois — quebra paridade multi-chain (Solana é cidadã de primeira classe no Uniswap atual).
• Alternativa: rotular explicitamente a rede no label — Copiar link (Ethereum) e Copiar link (Solana). Ou consolidar em um link único que abre uma página pública mostrando ambos os endereços. Trade-off: labels ficam mais longos; ganho: zero ambiguidade no clique.
• Perfil afetado: iniciante e intermediário (ambos podem clicar errado sem perceber).

🔴 Fricção 2 — Compartilhar exposto no header com peso primário mesmo em estado vazio (estrutural — affordance social desalinhada com o estado do produto)

• Atrito real: o user está numa wallet com 0,00 US$, zero atividade, zero NFTs. O CTA Compartilhar permanece no header como botão de destaque equivalente a Todas as redes. Compartilhar o quê? Quem recebe o link vê wallet vazia — signal social negativo ("esse user não tem nada", "o produto é vazio"). A affordance está convidando uma ação que prejudica o user que aceita.
• Solução óbvia que falha: desabilitar Compartilhar até existir saldo — perde flexibilidade (dev wallet, wallet de teste, wallet recém-criada de propósito).
• Alternativa: rebaixar Compartilhar para botão secundário/ícone enquanto saldo = 0; promover quando houver atividade. Ou adicionar microcopy de aviso no popover ("Seu portfólio está vazio — talvez você queira adicionar fundos primeiro") com link pros 3 caminhos de funding. Trade-off: hierarquia muda dinamicamente; ganho: zero auto-sabotagem social.
• Perfil afetado: iniciante (principal — único que compartilharia sem perceber o problema).

🔴 Fricção 3 — Popover obstrui a search bar Procurar atividade (cosmética — sobreposição entre controles da mesma tela)

• Atrito real: o popover Compartilhar cobre parcialmente o input de busca. Se o user abre o popover por curiosidade e depois decide buscar, precisa fechar o popover primeiro — clique extra desnecessário. É micro-fricção, mas é fricção de dois controles primários disputando o mesmo espaço.
• Solução óbvia que falha: mover a search bar — quebra a linha horizontal de controles.
• Alternativa: ancorar o popover para a esquerda do botão Compartilhar (não para baixo direito) ou usar dropdown vertical mais curto que termine antes da linha da search. Trade-off: anchoring extra; ganho: zero sobreposição.
• Perfil afetado: todos (cosmética).

---

🟡 Oportunidade competitiva — Compartilhamento de portfólio com contexto + atribuição (média leverage no target)

• Padrão da indústria: Uniswap (esta tela), Zerion, Zapper, DeBank — "compartilhar wallet" gera link público read-only sem contexto adicional. Quem recebe vê o estado bruto da wallet (saldo + tokens + atividade), sem narrativa do porquê foi compartilhado, sem atribuição (quem referenciou quem). Vetor social é desperdiçado.
• Por que afeta o target: referral via amigo é o vetor #1 de aquisição em DeFi no target iniciante (não é Twitter, não é blog — é mensagem pessoal de quem já usa). Sem sistema de atribuição, esse vetor não é mensurado, não pode ser otimizado e não pode ser incentivado. Iniciante que apresenta o produto ao próximo iniciante não recebe nada por isso.
• 4 perguntas-teste: (1) ✓ todos compartilham link cru sem atribuição (2) ✓ afeta iniciante (que é vetor e destinatário do referral) (3) ✓ razão = sistema de incentivos + URL com ref-code exige investimento (4) ✓ ganho perceptível se houver micro-recompensa (descontos em fees, badges) atrelados.
• Hipótese de diferenciação Kotai: link compartilhado inclui ref-code automático. Destinatário que conecta wallet via aquele link entra como referral do user de origem. Dashboard "quem você trouxe" com micro-incentivo (1bp de fee de swaps do referido por X dias, badge, etc.). Compartilhar no Twitter gera preview card com saldo agregado (sem expor números individuais por privacidade).
• Trade-off: sistema de incentivos cria risco de farming/sybil (criação massiva de wallets fake para auto-referenciar). Aceitar com cap (referral só ativa após primeira transação de valor > X) e detecção de sybil clusters.
• Leverage: média — depende de combinar URL+ref-code+incentivo coerente; isoladamente é só botão de copiar. Família com qualquer iniciativa de growth/loyalty.

---

Observação adicional: o popover está funcionalmente acoplado à página inteira (não à tab Atividade) — o mesmo botão Compartilhar aparece nas 4 tabs. Faz sentido como ação de wallet, não de tab. Mas, ao posicioná-lo no header e mantê-lo ativo em qualquer tab, o produto está dizendo "compartilhar é tão importante quanto navegar entre tabs". Vale checar se a prioridade implícita bate com o roadmap social do produto — se compartilhar é estratégico, fica; se é feature secundária, rebaixar para menu de ações da wallet.

Consolidado — Portfólio (Uniswap)

Caráter geral do fluxo

O fluxo de Portfólio do Uniswap é, na prática, um mapa de estados vazios — quase todas as telas analisadas mostram a wallet antes de ter qualquer ativo. As melhores decisões do produto estão exatamente aqui: empty states que viram instruções acionáveis (1), microcopy que fala a língua do usuário sem jargão (2), suporte contextual posicionado no momento de maior risco (4). O atrito se organiza em três vetores estruturais: (1) agregações que escondem escopo e criam risco de erro (4, 11); (2) affordances que fingem funcionar em estados onde não funcionam (1, 8); (3) ausência de capacidade contábil/fiscal — log bruto onde o target BR/LatAm precisa de instrumento de declaração (8, 10). Iniciante BR é o perfil mais afetado em praticamente todos os vetores — o produto trata funding como problema global quando é problema local, e trata o portfólio como dashboard de vaidade quando deveria ser instrumento contábil.

---

🟢 Insights recorrentes

Empty state convertido em instrução acionável — telas 1, 2, 3, 7, 8

Em nenhuma das telas o estado vazio é decoração. A tela 1 entrega 3 cards de funding nomeados por fonte de origem (1) — "Cartão de débito ou conta bancária", "de outra carteira", "de uma plataforma de negociação". A tab Tokens (2) e a tab NFTs (7) usam imperativo direto com objeto específico ("Transfira tokens / NFTs de outra carteira para começar"). A tab Atividade (8) diferencia: como não pode ser populada por ação direta, usa copy causal — "Quando você fizer transações, elas aparecerão aqui" — reconhecendo que o gatilho está em outra tela. Padrão a herdar integralmente — cada empty state precisa entregar instrução na língua do ato que o usuário precisaria fazer, não do produto que executa por trás.

Microcopy na linguagem mental do usuário, não do backend — telas 1, 2, 3, 6

Quatro pontos distintos do flow evitam jargão de forma consistente: "Cartão de débito ou conta bancária" (não Moonpay) e "de uma plataforma de negociação" (não CEX) na visão geral (1); "Transfira tokens de outra carteira" (não "deposit address") na tab Tokens (2); "quando você fizer transações" (não "on-chain activity") na tab Atividade (3); "Plataforma de negociação" no modal de Transferência (6). O padrão é deliberado e consistente — o produto fala o conceito mental do usuário, não o termo do protocolo. Padrão a herdar — copy de empty states e modais de funding sempre pelo conceito do usuário, não pela nomenclatura técnica.

Controles de descoberta visíveis no empty state — telas 2, 8, 9, 10

A tab Tokens mantém search bar ativa mesmo sem nenhum token detectado (2). A tab Atividade exibe os dropdowns Todos os tipos e Todo o período + search bar mesmo sem histórico (8), e a estrutura de 11 categorias (9) e 4 janelas temporais (10) estabelece o modelo mental futuro. User aprende a arquitetura de filtros antes de precisar dela — quando o portfólio crescer, ele já sabe onde recortar. Padrão a herdar — controles que farão sentido depois devem ser visíveis no empty (mas ver abaixo a ressalva crítica sobre estado enabled/disabled).

Declaração de erro/ausência > silêncio — telas 3, 5, 8

A tab Atividade usa copy causal que explica o gatilho sem fingir ação disponível (3). A tela de gráfico com erro mantém o widget cinza com tooltip Dados do gráfico ausentes (5) — preserva o slot e declara o que faltou, em vez de ocultar silenciosamente. Ambos priorizam honestidade visual. Padrão a herdar — error/empty declarativo supera silêncio; suprimir o widget é pior que explicá-lo.

Suporte contextual dentro de modais de ação sensível — telas 4, 6

Ambos os modais de funding — Receber criptos (4) e Transferência (6) — têm 📧 Pedir ajuda no header, não no footer global da app. Affordance de ajuda posicionada no momento de maior risco (transferência irreversível). Decisão consciente e consistente. Padrão a herdar — ajuda contextual dentro de modais de ação irreversível, não global.

---

🔴 Fricções recorrentes

Estrutural — Affordances interativas ativas em estados onde não funcionam — telas 1, 5, 8, 9

Diagnóstico do atrito real: o produto expõe controles clicáveis que não produzem nenhum efeito útil no estado em que estão. As timeframe pills 1 hora / 1 dia / 1 semana... são clicáveis no empty state limpo (1) e também no estado de erro do gráfico (5). Os dropdowns Todos os tipos e Todo o período abrem, permitem selecionar categorias, mas a lista de Atividade continua vazia sem nenhum feedback de "0 resultados" (8). A search bar de Atividade aceita input mas retorna sempre o mesmo empty, sem mensagem de "0 resultados" (9). Cada clique morto erode confiança na UI — o usuário conclui "o que mais não funciona aqui?". No contexto de erro (5), é pior: as pills de timeframe são interpretadas como "talvez clicando em outro período resolva o problema".

Por que a solução óbvia falha: desabilitar os controles completamente destrói o padrão "controles visíveis no empty" (Insight 3 acima) — eles têm valor pedagógico real.

Alternativa: manter visíveis + desabilitados no estado inativo — chevron cinza, sem dropdown, com tooltip "Disponível após a primeira transação" (ou "Aguardando dados"). Restaurar ao estado ativo quando há conteúdo. É a única solução que preserva o valor pedagógico sem o custo do clique morto.

Trade-off: dois estados visuais por controle (disabled empty / enabled populated); ganho: zero clique sem resposta, zero confiança erodida. Perfil afetado: iniciante (principal).

---

Estrutural — Agregações sem escopo declarado — telas 1, 2, 4, 11

Diagnóstico do atrito real: o produto exibe números e listas agregadas sem declarar o escopo da agregação em quatro pontos distintos do flow. O 0,00 US$ da Visão geral é cross-chain, mas Todas as redes não informa quais redes estão incluídas (1). O mesmo número na tab Tokens é subset do portfólio total, mas visualmente idêntico ao da Visão geral — quando o portfólio for misto, o user verá o saldo "cair" ao trocar de tab sem entender por quê (2). O modal Receber criptos exibe Ethereum +17 redes sem listar quais são as 17 nem quais estão excluídas — o user envia token em rede não suportada e perde os fundos (4). O seletor Todas as redes tem 18+ opções sem indicar quais o user usa e sem listar redes populares não suportadas (11).

Consequência de segunda ordem: a instância mais grave é a tela 4 — mesma raiz estrutural (agregação opaca), consequência irreversível (perda de fundos). Resolver essa em primeiro lugar.

Alternativa por instância: (1) Todas as redes (18) com tooltip de lista completa; (2) label explícito Total em tokens vs Patrimônio total; (3) +17 redes ▾ expandível + aviso de redes populares NÃO suportadas; (4) dropdown em 3 seções — "Suas redes", "Outras suportadas", "Não suportadas". A raiz é uma só — resolver em design system como princípio: todo agregado rotula o escopo da agregação.

Trade-off: cada instância tem implementação distinta; o esforço é distribuído. Perfil afetado: iniciante e intermediário multi-chain; perda irreversível na instância do modal (tela 4).

---

Estrutural — Gap entre instrução do empty state e CTA correspondente — telas 2, 7

Diagnóstico do atrito real: a tab Tokens diz "Transfira tokens de outra carteira para começar" — o modal que executa exatamente isso (Receber criptos) existe, mas só é acessível pela tab Visão geral; na tab Tokens não há botão (2). A tab NFTs replica o mesmo gap (7), com a complicação adicional de que o iniciante pode não saber se o endereço EVM vale para NFTs. Dois empty states que ordenam uma ação e não entregam a ferramenta para executá-la.

Por que a solução óbvia falha: replicar os 3 cards de funding completos abaixo do empty duplica navegação e dilui o foco da instrução.

Alternativa: botão único alinhado à instrução — Receber tokens / Receber NFTs — abrindo o modal correspondente. A variante de NFTs confirma no header que o endereço EVM é válido para ERC-721/1155.

Trade-off: variação de modal para NFTs; ganho: zero gap entre "o que fazer" e "como fazer". Perfil afetado: iniciante (principal).

---

Estrutural — Exclusão geográfica nos dois pontos de entrada de funding — telas 1, 6

Diagnóstico do atrito real: o card Compre criptos aponta para on-ramp global (fee 3–7% em USD + KYC internacional) sem alternativa local (1). O card Transferência lista exclusivamente Coinbase — CEX praticamente irrelevante para BR/LatAm/Ásia — sem fallback para quem não a usa (6). Os dois pontos de entrada de funding são, na prática, teatrais para o target BR: o iniciante clica, não reconhece nenhum caminho, fecha a tela antes de tocar no produto.

Família: esta fricção e a 🟡 On-ramp/CEX local-first (abaixo) compartilham raiz — o produto usa localization de língua (PT-BR) sem localization de infraestrutura de funding.

Perfil afetado: iniciante e intermediário BR/LatAm (principal para o target Kotai).

---

Estrutural (1 tela) — Vetor de perda por token-rede mismatch no modal Receber — tela 4

Diagnóstico: o modal entrega endereço cru sem guiar o usuário por token + rede. Para iniciante, isso transfere a ele o risco de um erro irreversível: enviar USDT-TRC20 para endereço EVM perde os fundos para sempre. Uma única tela, mas com a consequência mais alta do fluxo. Família direta com a 🟡 Receber guiado (abaixo).

Perfil afetado: iniciante (principal). (Estrutural, 1 tela — peso máximo.)

Estrutural (1 tela) — Filtro temporal sem date picker bloqueia auditoria fiscal — tela 10

Diagnóstico: 24h / 7d / 30d / Todo o período sem range customizado por data. Declarar IR no Brasil exige filtro por ano civil específico — o usuário exporta tudo e filtra fora do produto, anulando a utilidade do log nativo. Família direta com 🟡 Atividade como instrumento fiscal (abaixo).

Perfil afetado: iniciante e intermediário BR em jurisdição com IR cripto obrigatório. (Estrutural, 1 tela — peso alto para target BR.)

Estrutural (1 tela) — Escopo do filtro de rede ambíguo e sem feedback de estado — tela 11

Diagnóstico: o seletor Todas as redes fica no header da página com escopo global (filtra saldo + gráfico + tokens + NFTs + atividade simultaneamente), enquanto os filtros da tab ficam na linha abaixo — dois níveis de filtragem sem hierarquia visual explícita. Agravado: o label do botão não muda ao selecionar uma rede específica (11, continua "Todas as redes"), então o usuário pode estar com Ethereum selecionado, ver o portfólio "reduzido", e não entender por quê.

Perfil afetado: iniciante (principal). (Estrutural, 1 tela — peso médio-alto.)

---

🟡 Oportunidades competitivas do fluxo

On-ramp e CEX local-first detectados por geografia — telas 1, 6

Padrão atual da indústria: Uniswap, PancakeSwap, 1inch usam on-ramp global (Moonpay/Transak, fee 3–7%) e integração de CEX com Coinbase como único parceiro. Ambos assumem usuário US/EU como base geográfica.

Por que afeta nosso target: no Brasil, Coinbase é praticamente irrelevante (6); on-ramp global cobra em USD com conversão opaca e fee 6× maior que PIX → CEX BR (1). O iniciante BR que clica em Compre criptos ou Transferência não encontra nenhum caminho funcional — abandona antes de tocar no produto.

Hipótese de diferenciação Kotai: detectar região por IP/locale e priorizar: card Compre criptos mostra via PIX (BR) — taxa estimada 1,5% como default; card Transferência lista Mercado Bitcoin / Binance BR / Bitso no topo, Coinbase como fallback internacional. Fee exibida antes do clique, não enterrada no flow do parceiro.

Trade-off: integração + manutenção por jurisdição (compliance KYC local, APIs de múltiplos parceiros). Custo recorrente real — mas é o vetor competitivo mais direto contra Uniswap no target BR/LatAm.

Passa nas 4 perguntas-teste? (1) ✓ todos os concorrentes usam on-ramp global / CEX US-centric (2) ✓ afeta iniciante BR diretamente — é o ponto de entrada de funding (3) ✓ falta de investimento em integrações locais (infraestrutura existe: Mercado Bitcoin, Bitso, Notus, Transfero) (4) ✓ ganho diretamente perceptível — PIX em segundos vs cartão internacional com 6% de fee.

---

Receber como fluxo guiado token-rede-first, não endereço-first — tela 4

Padrão atual da indústria: Uniswap, Zerion, Zapper, Phantom, Rabby — todos entregam endereço como artefato principal. Token e rede ficam por conta do usuário lembrar. O risco é transferido para quem não tem ferramenta para gerenciá-lo.

Por que afeta nosso target: mismatch token-rede é o maior vetor de perda não-maliciosa em DeFi para iniciante. Não é hack, não é scam — é usabilidade. Endereço cru sem contexto transforma uma decisão técnica complexa em ação de 1 clique sem rede de segurança.

Hipótese de diferenciação Kotai: fluxo guiado de 2 passos — (1) usuário escolhe token + rede (lista filtrada pelas redes onde aquele token tem liquidez); (2) modal mostra apenas o endereço daquela rede com aviso reforçado e ícone token+rede no topo. Modo "endereço cru" sobrevive como toggle "avançado" opcional. O caminho via Transferência – Coinbase (e futuros parceiros locais) já resolve esse risco por construção — integração deve ser o caminho destacado para iniciante.

Trade-off: 1–2 cliques a mais no caminho receber; exige mapa atualizado de "em quais redes cada token existe". Aceitar — custo de UX trivial vs custo de perda real do usuário.

Passa nas 4 perguntas-teste? (1) ✓ todos os concorrentes entregam endereço cru (2) ✓ afeta iniciante — é O vetor de perda (3) ✓ falta de investimento, não impossibilidade (4) ✓ ganho perceptível e mensurável — diferença entre perder $500 e não perder.

---

Atividade como instrumento contábil/fiscal, não só log cronológico — telas 8, 10

Padrão atual da indústria: Uniswap, Zerion, Zapper, DeBank — Atividade é log cronológico bruto. Sem cálculo de ganho/perda por operação, sem conversão cambial baseada em data, sem agrupamento por categoria fiscal, sem exportação fiscal-ready. Usuário que precisa declarar IR paga R$300–500/ano em serviço terceiro (Koinly, Coinpanda).

Por que afeta nosso target: no Brasil, declarar cripto no IR é obrigatório para operações > R$30k/mês ou ganhos tributáveis. A ausência de date picker (10) e de exportação fiscal são sintomas da mesma raiz: o produto não reconhece o "ano fiscal" como unidade de medida relevante (8).

Hipótese de diferenciação Kotai: tab Atividade gera relatório fiscal exportável (PDF + CSV padrão IR) com cálculo de ganho/perda, conversão cambial em moeda local na data da transação, agrupamento por categoria fiscal. Filtro de primeira classe Período fiscal 2025 ao lado dos existentes. As 11 categorias do dropdown Todos os tipos já mapeiam para classes fiscais — a base técnica existe.

Trade-off: regras fiscais variam por jurisdição; modelo precisa ser mantido por país. Custo recorrente alto — mas diferencial competitivo direto e sem concorrente no segmento DEX.

Passa nas 4 perguntas-teste? (1) ✓ nenhum DEX tem capacidade fiscal nativa (2) ✓ afeta iniciante e intermediário — IR é obrigação legal (3) ✓ falta de investimento (catálogo de causas + classes fiscais existe, problema estabelecido) (4) ✓ ganho perceptível e mensurável (R$ economizados/ano, risco fiscal mitigado).

---

Portfólio com valor recuperável vs valor declarado — tela 2

Padrão atual da indústria: Uniswap, Zapper, DeBank, Zerion — saldo exibido usa preço de tela (last-trade ou oracle). Não informa se o token tem liquidez suficiente para realizar aquele valor. Usuário com shitcoin de baixo volume vê "100 US$" e tenta vender — recebe 12 US$ por slippage devastador.

Por que afeta nosso target: iniciante e intermediário avaliam patrimônio pelo número da tela. Se o número é ficção (declarado mas não recuperável), o portfólio inteiro vira ilusão contábil — exatamente o vetor por trás de "essa cripto não vale o que diz".

Hipótese de diferenciação Kotai: segunda linha por token — Valor: 100 US$ · Saída estimada: 14 US$ (calculado com slippage real da melhor rota de venda). Na hero do portfólio: Patrimônio declarado e Patrimônio recuperável como dois numbers. Toggle para avançado esconder. Copy neutra para tokens com liquidez limitada ("saída limitada pela liquidez do pool").

Trade-off: cálculo on-demand por token (cota de RPC, cache de rotas); risco de "classificar tokens como ilíquidos" gera atrito político — mitigar com copy neutra.

Passa nas 4 perguntas-teste? (1) ✓ todos usam preço de tela como valor (2) ✓ afeta iniciante diretamente (3) ✓ exige cálculo de saída via rota + slippage; falta de investimento (4) ✓ ganho perceptível — user ajusta expectativa antes de tentar vender.

---

Error states com diagnóstico + ação (cross-cutting) — tela 5

Padrão atual da indústria: Uniswap, Zerion, DeBank, MetaMask Portfolio — "Dados indisponíveis", "Algo deu errado", "Tente novamente mais tarde". Sem causa, sem ação, sem tempo estimado.

Por que afeta nosso target: iniciante não diferencia "erro temporário de uma sub-feature" de "produto quebrado". Em DeFi essa percepção é amplificada pela desconfiança de base. Cada error state genérico é vetor de abandono.

Hipótese de diferenciação Kotai: catálogo declarativo — cada falha mapeia para (causa, ação, tempo estimado). Dados do gráfico ausentes vira "Indexador da rede X atrasado · ~30s · [Recarregar]". Banner global se múltiplas redes falharem. Status page linkável.

Trade-off: custo de mapeamento (cada feature nova precisa do seu error state declarado); risco de diagnóstico errado assustar mais que mensagem genérica. Aceitar — investimento se paga em retenção.

Passa nas 4 perguntas-teste? (1) ✓ todos usam copy genérica de erro (2) ✓ afeta iniciante diretamente (3) ✓ exige catálogo de causas + UI condicional; falta de investimento (4) ✓ ganho perceptível — converte "produto quebrado" em "problema localizado e endereçável".

---

Seletor de rede contextualizado com escopo declarado — telas 4, 11

Padrão atual da indústria: todos os concorrentes listam apenas redes suportadas, sem hierarquizar por uso do usuário e sem indicar redes populares não suportadas. O usuário multi-chain navega lista plana sem hierarquia útil.

Por que afeta nosso target: iniciante BR multi-chain tem token em 2–3 redes e rola lista de 18+ para encontrar as suas (11). Mais grave: usuário que tenta receber token em rede não listada entre as 17 EVM só descobre o problema depois de enviar (4).

Hipótese de diferenciação Kotai: dropdown em 3 seções — "Suas redes" (com saldo inline, ordenadas por valor decrescente), "Outras redes suportadas", "Não suportadas" (lista mínima com copy neutra "não suportada nesta versão"). Família direta com Receber guiado — mesma raiz: todo contexto de rede sempre declara o escopo.

Trade-off: curadoria da lista "não suportadas" é decisão delicada (pode parecer cross-promo negativa); aceitar com lista mínima e revisão trimestral.

Passa nas 4 perguntas-teste? (1) ✓ todos listam só suportadas sem hierarquia por uso (2) ✓ afeta iniciante e intermediário (3) ✓ falta de investimento — dado de saldo por rede o produto já tem (4) ✓ ganho perceptível — user vê Ethereum · $42 no topo + nota "Avalanche: não suportada".

---

Pontos isolados (1 tela)

• 🟢 Tela 4: agregação EVM num endereço único é decisão arquitetural correta — mesmo endereço para Ethereum + 17 L2s, Solana separada por incompatibilidade de curva. Padrão a herdar.
• 🟢 Tela 7: ausência de big stat na tab NFTs é decisão consciente correta — NFT não tem preço fungível; forçar US$ seria ficção contábil.
• 🟢 Tela 11: Unichain em 3º lugar no seletor (após Ethereum, antes das L2s mais usadas) sem virar default — restrição de cross-promo deliberada. Padrão a herdar.
• 🔴 Tela 9: 11 categorias de transação sem agrupamento funcional — Trading / Liquidez / Movimentação / Sistema seriam subseções naturais. Intermediário que usa filtros escaneia lista grande sem hierarquia.
• 🔴 Tela 9: filtro de tipos provavelmente radio (1 categoria), não multi-select — bloqueia combinações ("Swaps + Envios") necessárias para auditoria fiscal séria. Família com 🟡 Atividade fiscal.
• 🔴 Tela 6: modal Transferência com 1 única opção é overhead sem valor — dois cliques para começar uma ação que não filtra nada. Resolver integrando mais opções (justifica o modal) ou eliminando o nível intermediário.
• 🔴 Tela 10: default Todo o período ótimo para wallet nova, inadequado para wallet madura com 2 anos de histórico. Default contextual (wallet > 30 dias → padrão 30 dias) resolve sem perda para novos usuários.
• 🔴 Tela 7: ilustrações de empty pouco distintas entre tabs — oportunidade cosmética de identidade visual por tipo de ativo (token = moeda, NFT = polaroid, atividade = recibo).

---

Observações adicionais

Consistência URL por tab (telas 2, 3, 7, 8): cada tab tem URL própria (/portfolio/tokens, /portfolio/nfts, /portfolio/activity) — deeplink por tab correto. Padrão a herdar integralmente.

Família "produto US-first com tradução PT-BR": on-ramp global (t1), Coinbase única (t6), i18n incompleta no dropdown (t9), ausência de período fiscal (t10) — todos são sintomas da mesma decisão de produto. Para Kotai, a aposta é produto BR-first, não produto global traduzido. A diferença aparece exatamente no funding, na linguagem e na contabilidade.

Família "portfólio como instrumento contábil": valor recuperável vs declarado (t2), atividade como ferramenta fiscal (t8, t10), multi-select de tipos de transação (t9) — todos convergem para a mesma visão: portfólio não como dashboard de vaidade, mas como ferramenta que ajuda o usuário a entender o que tem, o que pode realizar, e o que precisa declarar.

Botão Compartilhar como gatilho de referral futuro (3): o ponto de gatilho natural de um futuro programa de referral já existe — é o botão Compartilhar do portfólio. A oportunidade real é o sistema de incentivos (dashboard + recompensa + badge), não o botão em si. Sem esse sistema, o ref-code embutido no link é invisível ao usuário-alvo iniciante — o ganho perceptível é condicional à existência de um produto de growth/loyalty que vai além desta tela. Não passa nas 4 perguntas-teste no escopo deste fluxo (Q4 ⚠ condicional → padrão CLAUDE.md: defaultar pra convenção válida).

Revogar aprovação inline em Aprovações (Observação adicional de portfolio-09): quando o log de Atividade for populado, vale incluir affordance [Revogar] direto na linha da categoria Aprovações — converte log passivo em ação de segurança DeFi (revoga approve() antigas, evita drain attacks). Nenhum DEX expõe isso nativamente. Leverage média — afeta mais intermediário e avançado que iniciante. (Origem: Observação adicional de portfolio-09, sem bloco formal — tela declara "Sem 🟡".)

Os drafts de lote estão em analises/uniswap/_consolidado/_drafts/ como audit trail — portfolio-lote-1.md (telas 1–6) e portfolio-lote-2.md (telas 7–11).

5. Empty state — Carteira NÃO conectada

Função: versão sem wallet conectada da página Suas posições. Em vez do bloco 0 UNI Rewards / toolbar de filtros / lista, exibe CTA de conexão como gatekeeper. Tela revela arquitetura: até o user conectar wallet, produto não tem identidade pra mostrar nada relevante.

Componentes (diff em relação às Telas 1–4)

• Header global:
  • CTA Conectar (rosa primário, canto superior direito) — substitui o endereço encurtado.
  • Tabs Negociar / Explorar / Pool ✓ / Portfólio (Pool selecionado).
• Title: Suas posições.
• Card de conexão no centro:
  • Ícone de carteira.
  • Conectar carteira (título).
  • Microcopy "Para visualizar posições e recompensas, conecte sua carteira."
  • 2 CTAs:
    • Nova posição (secondary outline — permite criar sem conectar? provavelmente leva pra Connect).
    • Conectar carteira (primary branco — ação esperada).
• 2 cards educacionais abaixo:
  • Fornecer liquidez em protocolos diferentes (ícone rosa de gráfico).
  • Hooks no v4 (ícone livro com badge v4).
• Sidebar Maiores pools por TVL igual às outras telas.

Regras de negócio

• Sem wallet conectada, produto não mostra UNI rewards header — só faz sentido com identidade do user.
• 2 CTAs no card central oferecem caminho "explorar" (Nova posição sem conexão) e caminho "acessar" (Conectar carteira).
• Cards educacionais (Fornecer liquidez, Hooks no v4) substituem o conteúdo dinâmico — produto usa empty state como espaço editorial.
• Sidebar discovery (Maiores pools por TVL) é idêntica com ou sem wallet — discovery não depende de identidade.

---

🟢 Insight 1 — Empty state sem wallet é usado como espaço editorial em vez de tela vazia. Cards Fornecer liquidez em protocolos diferentes e Hooks no v4 ensinam enquanto user decide se conecta. Padrão a herdar pra Kotai — telas pre-conexão devem servir conteúdo educacional, não placeholder mudo.

🟢 Insight 2 — Sidebar Maiores pools funciona igual com/sem wallet — discovery não exige identidade. Decisão de produto correta: descoberta de mercado independe de quem é o user. Padrão a herdar — separar UI de discovery (público) de UI de gestão (privado/conectado).

🟢 Insight 3 — Nova posição como CTA secundário sem wallet conectada é affordance honesta. Produto admite "você pode começar a explorar sem conectar". Iniciante curioso entra no flow sem comprometer com Connect. Padrão a herdar — flows críticos devem permitir exploração sem identidade até o momento que ela é necessária.

---

🔴 Fricção 1 — 2 CTAs Nova posição (secundário) + Conectar carteira (primário branco) sem hierarquia clara de qual escolher (estrutural — paralisia de escolha em momento de baixa intenção)

• Atrito real: user que chega na página sem wallet conectada está em estado exploratório ("o que é Pool? como funciona?"). Os 2 CTAs no card pedem decisão imediata: explorar (sem conectar) ou conectar (e ver suas posições — mas ainda não tem posição). Iniciante sem mental model de "o que LP faz pra mim" não sabe escolher. Pior: cor do Conectar carteira é branco/cinza claro, não rosa primário — o produto não está empurrando conexão forte como faz outros DEXes. Mas iniciante interpreta isso como ambiguidade, não respeito.
• Por que a solução óbvia falha: destacar Conectar agressivamente perde a postura respeitosa de "não empurra conexão"; remover Nova posição perde a opção de exploração.
• Alternativa: substituir os 2 CTAs por 1 fluxo guiado de 3 etapas — (1) Entenda o que é LP / (2) Veja pools de exemplo / (3) Conecte pra criar sua posição. Cada etapa avança com 1 clique. Iniciante percorre o tutorial; intermediário pula direto pra Conectar. Trade-off: mais UI; ganho: pedagógico em vez de transacional.
• Perfil afetado: iniciante (principal — sem mental model).

🔴 Fricção 2 — Cards educacionais Fornecer liquidez em protocolos diferentes e Hooks no v4 têm framing de power user, não de iniciante (estrutural — conteúdo editorial mira público errado pra esta tela)

• Atrito real: "Fornecer liquidez em protocolos diferentes" assume que user já sabe o que é liquidez e o gancho é "comparar protocolos". "Hooks no v4" assume v4 conhecido. Tela sem wallet conectada é exatamente onde iniciantes recém-chegados chegam — público que precisaria de O que é LP? ou Como ganhar com fees?, não de comparações de protocolo.
• Por que a solução óbvia falha: trocar conteúdo só pra iniciante pode chatear intermediário que volta pra ler material avançado.
• Alternativa: 2 cards por nível — Primeira vez? Como funciona LP (3 min) (iniciante) e Fornecer liquidez em protocolos diferentes (intermediário). Ambos disponíveis. Trade-off: mais conteúdo; ganho: serve os 2 níveis.
• Perfil afetado: iniciante (principal — perdido pelo framing power user).

🔴 Fricção 3 — Microcopy "Para visualizar posições e recompensas, conecte sua carteira" assume que user já tem carteira (estrutural — onboarding pressupõe etapa anterior cumprida)

• Atrito real: user que nunca teve carteira cripto não entende a frase. "Conectar carteira" significa o quê? MetaMask? Como pego uma? Tela não oferece caminho de criar carteira, só de conectar existente. Iniciante recém-chegado bate aqui e abandona.
• Por que a solução óbvia falha: integrar criação de carteira é onboarding complexo (custódia, seed phrase, education, segurança).
• Alternativa: microcopy expandida com 2 caminhos — "Já tem carteira? [Conectar]. Primeira vez? [Como começar →]" (link pra guia ou onboarding). Sem prometer criação dentro do app; oferecendo material pra continuar. Trade-off: trivial; ganho: zero abandono por falta de wallet pré-existente.
• Perfil afetado: iniciante absoluto (principal — recém-chegado a cripto).
• Família com 🟡 "Smart wallet nativa" (Tela 9 PP Base) — mesma raiz arquitetural: produto assume wallet EOA pré-existente.

---

🟡 Oportunidade competitiva — DEX com onboarding integrado de wallet pra usuários sem carteira pré-existente

• Padrão da indústria: Uniswap (esta tela), PancakeSwap, KyberSwap — todos assumem que user já tem wallet. Onboarding começa em "conectar", não em "você precisa de uma carteira; aqui está como".
• Por que afeta o target: iniciante absoluto (recém-chegado a cripto) é o maior pool de usuários potenciais e exatamente o público que não tem carteira ainda. Cada DEX exige onboarding externo antes de usar — barreira que afasta majoritariamente.
• 4 perguntas-teste: (1) ✓ nenhum DEX incorpora criação de wallet (2) ✓ afeta iniciante absoluto, target principal (3) ✓ razão = embedded wallets (Magic, Privy, Dynamic, Coinbase Smart Wallet) emergiram nos últimos anos; integração técnica factível (4) ✓ ganho perceptível — user faz login com email/Google e tem smart wallet criada automaticamente; pode aportar fiat direto, criar posição em 5 minutos.
• Hipótese de diferenciação: "Login com email" como CTA primário ao lado de "Conectar carteira existente". Login com email cria smart wallet self-custody via Privy/Dynamic + onboarding de fiat (Moonpay, Transak). User não-cripto vira user-cripto sem sair do produto.
• Trade-off: custos de embedded wallet provider (Privy: ~$0.05/MAU); responsabilidade de UX de recuperação (passkeys, social recovery). Mitigação: smart wallet self-custody = user dono dos fundos, Kotai não.
• Leverage estruturalíssimo — converte produto cripto-nativo em produto de massa. Família consolidada com 🟡 "Smart wallet AA" (Tela 9 PP Base), 🟡 "Modo tutorial" (Tela 1 SuasPos) — sistema Kotai = onboarding inclusivo + assistência ativa + smart wallet nativa.

---

Observação adicional — Conectar no header está em rosa primário (CTA forte), mas Conectar carteira dentro do card está em branco (CTA suave). Mesma ação, 2 cores na mesma tela. Inconsistência minar atende a hierarquia (CTA do header é catch-all, CTA do card é contextual), mas pode confundir user que tateia. Vale unificar — ou ambos primários, ou diferenciar com cores intencionais (não acidentais).

5. Portfólio — Visão geral com gráfico placeholder (sem dados)

Função: Variação do estado de Visão geral em que o saldo está em skeleton e o gráfico aparece desenhado em cinza com tooltip declarativo "Dados do gráfico ausentes". É um estado intermediário/de erro — diferente do empty state "limpo" do relatório 1 (que mostra 0,00 US$ resolvido). Aqui o produto declara não ter o que mostrar e renderiza um chart simulado para preservar o layout.

Componentes

• Header e sub-header de portfólio padrão (avatar, +1 a mais, CTAs).
• Tabs: Visão geral ✓ / Tokens / NFTs / Atividade.
• Skeleton box cinza no lugar do big stat de saldo (em vez de 0,00 US$ ou número resolvido) + skeleton menor abaixo (provavelmente delta).
• Área do gráfico com linha ondulada cinza simulada (não dados reais) + 5 marcadores cinza horizontais à direita (eixo Y) + 5 marcadores abaixo (eixo X).
• Tooltip central sobre o gráfico: ícone de aviso + título Dados do gráfico ausentes + subtítulo "Dados de saldo do portfólio indisponíveis."
• Timeframe pills 1 hora / 1 dia ✓ / 1 semana / 1 mês / 1 ano / Tudo — todas clicáveis.
• Coluna direita: mesmos 3 cards (Compre criptos / Receber criptos / Transferência).

Regras de negócio

• Estado provavelmente disparado por falha do indexer/RPC ou wallet sem histórico ainda (não tem como diferenciar pelo UI).
• Skeleton do saldo permanece indefinidamente enquanto o gráfico já declarou ausência — duas semânticas de loading no mesmo viewport.
• Cards de funding seguem operacionais — fallback de ação independe do gráfico carregar.

---

🟢 Insight 1 — Tooltip declarativo Dados do gráfico ausentes supera ocultar o widget. Apagar o gráfico no erro tiraria o user da affordance de "aqui no futuro vai aparecer histórico". Manter o chart cinza + dizer explicitamente o que faltou é honestidade visual — preserva o slot, evita fingir dado, comunica o estado. Padrão a herdar — error/empty state declarativo > silêncio.

🟢 Insight 2 — Skeleton no saldo separa duas semânticas de loading no mesmo viewport. Saldo (number bruto) e gráfico (série temporal) carregam de fontes diferentes; o produto resolve isso renderizando dois estados separadamente — skeleton no number, mensagem explícita no chart. Reconhece que loading não é monolítico. Padrão a herdar — granularidade no loading reduz a frustração de "está tudo carregando há 10s".

---

🔴 Fricção 1 — Dados do gráfico ausentes é ambíguo entre "temporário" e "definitivo" (estrutural — copy de error state sem diagnóstico nem caminho de recuperação)

• Atrito real: a copy não diz por que os dados estão ausentes. É erro do servidor (tente de novo em 30s)? É a wallet que ainda não tem histórico (espere a primeira transação)? É a rede selecionada que não tem indexer? Iniciante vê isso pela primeira vez e não tem como decidir entre: aguardar, recarregar, mudar de rede, ou desistir. Sem botão Recarregar, sem caveat de tempo, sem causa. Error state que descreve o sintoma mas não o caminho.
• Solução óbvia que falha: retry automático silencioso — entra em loop se a causa é estrutural (RPC permanentemente quebrado, ou wallet sem dados mesmo).
• Alternativa: causa + ação inline. "Não conseguimos carregar o histórico de saldo desta wallet — [Recarregar] [Reportar problema]". Se a causa for "wallet sem histórico", trocar copy: "Sem histórico ainda. Seu gráfico aparece após a primeira transação." — diagnóstico determina a copy. Trade-off: exige distinguir causa no backend; ganho: zero leitura ambígua do estado.
• Perfil afetado: iniciante (principal) e intermediário.

🔴 Fricção 2 — Skeleton no saldo + erro declarado no gráfico = signal contraditório (estrutural — dois sub-estados que não conversam)

• Atrito real: o gráfico já declarou "dados indisponíveis" (estado terminal de erro). Mas o saldo continua em skeleton (estado "chegando"). Iniciante vê e pensa: "o saldo ainda está carregando, então é só esperar — o aviso do gráfico vai sumir junto". Mas o saldo pode estar em loop infinito sem feedback. Skeleton sem timeout vira affordance que mente.
• Solução óbvia falha: timeout fixo para skeleton (3s → renderiza placeholder) — pode esconder dado que está chegando lento mas chegando.
• Alternativa: timeout escalonado — skeleton por até 5s; se persistir, vira "Não conseguimos carregar o saldo — [Recarregar]". Resolve a contradição entre o gráfico ter falhado terminal e o saldo continuar pendurado. Trade-off: regra de timeout adicional; ganho: zero estado contraditório no viewport.
• Perfil afetado: iniciante e intermediário.

🔴 Fricção 3 — Timeframe pills permanecem ativas no estado de erro (cosmética — affordance morta amplifica frustração)

• Atrito real: mesma classe da fricção 1 do relatório 1, mas pior aqui — o user em estado de erro pode interpretar as pills 1 hora / 1 dia / ... como "talvez clicando em outro período resolva". Clica em 1 semana, nada muda. Clica em 1 mês, nada muda. Cada clique morto erode confiança ativamente.
• Alternativa: desabilitar pills enquanto o gráfico estiver em estado de erro/sem-dados. Restaurar ao recarregar com sucesso. Trade-off: mínimo.
• Perfil afetado: iniciante (principal).

---

🟡 Oportunidade competitiva — Error states com diagnóstico + ação em vez de "indisponível" genérico (média-alta leverage, cross-cutting)

• Padrão da indústria: Uniswap (esta tela), Zerion, DeBank, MetaMask Portfolio — error states genéricos: "Dados indisponíveis", "Algo deu errado", "Tente novamente mais tarde". Nem causa, nem ação, nem tempo estimado. Iniciante interpreta como "o produto está quebrado" e perde confiança no resto da experiência (mesmo quando só uma feature secundária falhou).
• Por que afeta o target: iniciante não diferencia "erro temporário de uma sub-feature" de "produto quebrado". Cada error state genérico é vetor de abandono. Em DeFi essa percepção é amplificada porque o user já está suspeitoso ("vai sumir com meu dinheiro?").
• 4 perguntas-teste: (1) ✓ todos os concorrentes usam copy genérica de erro (2) ✓ afeta iniciante diretamente (3) ✓ razão = exige catálogo de causas + UI condicional; falta de investimento (4) ✓ ganho perceptível — "RPC da rede X está lento, tente em 30s" converte erro de "produto quebrado" para "problema localizado e endereçável".
• Hipótese de diferenciação Kotai: catálogo declarativo de error states — cada falha possível mapeia para (causa, ação, tempo estimado). Tooltip do gráfico atual viraria "Histórico do indexador atrasado · ~30s" + [Recarregar]. Banner global se múltiplas redes falharem. Status page linkável.
• Trade-off: custo de mapeamento (cada nova feature precisa do seu error state declarado) + risco de "diagnóstico errado" assustar mais que mensagem genérica. Aceitar — investimento se paga em retenção.
• Leverage: estrutural alta, cross-cutting — afeta toda a aplicação, não só esta tela. Família com qualquer fricção de error state em outros flows (swap fail, pool fail, etc.).

---

Observação adicional: vale confirmar se este estado é gatilhado por erro de carregamento ou por wallet sem histórico — visualmente são idênticos no produto atual, mas a copy ideal seria diferente nos dois casos. Se for o segundo, o tooltip deveria dizer "Sem histórico ainda" e não "dados indisponíveis" (que carrega conotação de falha).

6. Suas Posições — Full page conectada (estado limpo, sem filtros)

Função: view canônica de Suas posições com wallet conectada (0xd09B...618a) e sem nenhuma posição — empty state "real" do produto. Diferente das Telas 1–4 (mesma página com dropdowns abertos), Tela 6 mostra a página sem interação, em viewport maior — captura layout default que iniciante vê quando chega aqui pela primeira vez já conectado.

Componentes

• Header global: tabs Negociar / Explorar / Pool ✓ / Portfólio + busca + endereço 0xd09B...618a.
• Bloco superior:
  • 0 UNI + Recompensas ganhas (com ícone info i).
  • CTA Recolher recompensas (disabled).
  • Microcopy "Encontre pools com recompensas em UNI →" + "Pools qualificados oferecem tokens como recompensa; você pode ganhar mais".
• Section Suas posições com toolbar:
  • + Novo v (split button).
  • Status v / Protocolo v / ícone-rede v.
• Card de empty state central:
  • Ícone de piscina/pool com bandeira.
  • Nenhuma posição encontrada.
  • Microcopy "Você não tem nenhuma posição de liquidez. Crie uma nova posição para começar a ganhar tarifas e recompensas em pools qualificados."
  • 2 CTAs: Explorar pools (secundário) + Nova posição (branco/primário).
• Banner abaixo com i icon: "Quer ver suas posições fechadas? Para vê-las, use o filtro na parte superior da página." + × dismiss.
• Microcopy rodapé: "Algumas posições da v2 não são exibidas automaticamente. Importar posições v2".
• Sidebar direita:
  • Maiores pools por TVL: WISE/ETH 0,00% APR, ETH/USDC 87,74% APR, USDC/ETH 13,88%, ETH/USDC 4,8%, ETH/USDT 45,52%, WBTC/ETH 14,04%.
  • Link Explorar mais pools →.
  • Section Saiba mais sobre provisão de liquidez: cards Fornecer liquidez em protocolos diferentes + Hooks no v4 + link Saber mais →.

Regras de negócio

• Empty state aparece quando count(positions) == 0 independente de filtros.
• Wallet conectada mas sem histórico = primeira interação com Pool.
• Banner Quer ver suas posições fechadas? é assumption check — produto admite que default esconde fechadas e oferece caminho pra ver.
• Importar posições v2 é caminho de migração — v2 NFT format precisa de import explícito.
• APRs na sidebar variam significativamente entre versões/tiers (WISE/ETH v2 0%, ETH/USDC v3 87%) — variabilidade real de mercado, não bug.

---

🟢 Insight 1 — Layout em 3 zonas (header UNI / toolbar+lista / sidebar discovery) cria hierarquia clara de "o seu / o do mercado". Esquerda = patrimônio + ações; direita = inspiração + educação. User não confunde "o que tenho" com "o que existe". Padrão a herdar pra Kotai — separação visual entre dashboard pessoal e descoberta de mercado.

🟢 Insight 2 — Banner dismissable Quer ver suas posições fechadas? é affordance honesta de "sei que escondi algo". Em vez de assumir que user vai descobrir o filtro, o produto antecipa a dúvida. Padrão a herdar — defaults que escondem conteúdo devem ser anunciados explicitamente (não silenciosos).

🟢 Insight 3 — Sidebar com Maiores pools + cards educacionais combina inspiração quantitativa (APRs) + educação qualitativa (Fornecer liquidez em protocolos diferentes). Iniciante lê educação; intermediário scaneia APRs. Padrão a herdar — sidebar de descoberta deve servir os 2 perfis simultaneamente.

🟢 Insight 4 — APRs na sidebar variam (0% → 87%) sem ranking artificial. Produto não esconde pools de baixo APR — mostra realidade. Padrão a herdar — discovery deve ser honesta, não curada pra otimizar conversão.

---

🔴 Fricção 1 — Empty state vê Nenhuma posição encontrada independente do filtro — não distingue "sem posição" de "filtro escondeu" (estrutural — mesma fricção da Tela 2 mas confirmada em estado idle)

• Atrito real: já analisada na Tela 2 (Fricção 1) — mesma raiz, mesma alternativa. Aqui é o estado canônico da fricção: user conectado, 0 posições, banner abaixo lembra "você pode estar com filtros restritivos". A presença do banner é patch parcial — admite o problema mas não resolve.
• Por que a solução óbvia falha: ver Tela 2.
• Alternativa: mesma da Tela 2 — empty state condicional ao filtro + count total ignoring filter.
• Perfil afetado: iniciante e intermediário.
• Família confirmada — fricção do empty state aparece nas Telas 1, 2, 5, 6 (4× a mesma raiz).

🔴 Fricção 2 — APRs sidebar com variação 0% — 87% não tem caveat sobre IL nem janela temporal (estrutural — APR isolado já flagrado, agora em discovery)

• Atrito real: sidebar mostra ETH/USDC v3 87,74% APR como número grande, atraente. Iniciante curioso clica e entra em flow LP achando que "vou ganhar 87% ao ano". Realidade: APR isolado, sem IL, trailing — em par volátil como ETH/USDC 0,3%, IL pode comer 50% do retorno. Fricção igual à Tela 2 (PP Base) mas aqui ela serve como gatilho de discovery, com efeito amplificado.
• Por que a solução óbvia falha: ver Tela 2 PP Base.
• Alternativa: mesma — label APR de fees (30d) + microcopy de IL.
• Perfil afetado: iniciante (principal — APR isolado é gatilho de FOMO).
• Família consolidada de APR isolado: Telas 1, 2 PP Base, 10 PP Base, 6 SuasPos = 5 lugares onde APR aparece sem caveat. Sistema de fricção confirmado.

🔴 Fricção 3 — Importar posições v2 no rodapé é affordance escondida pra problema crítico (estrutural — fluxo de migração relegado a microcopy)

• Atrito real: user que tem posição legada em v2 (criada anos atrás, antes de v3 existir) verá Nenhuma posição encontrada mesmo conectado com a carteira certa. Solução é clicar em Importar posições v2 — link em texto cinza pequeno, no rodapé, abaixo de todo o resto. User com posição v2 antiga pode achar que perdeu (pânico) e gastar horas no Discord do Uniswap pra descobrir o link.
• Por que a solução óbvia falha: import automático de v2 perde simplicidade do v3+ default; banner alarmista ("você tem posição v2!") assusta user sem v2.
• Alternativa: detecção on-chain de posições v2 ao conectar wallet — se detectar, mostrar banner amarelo no topo ("Detectamos posições v2 nesta carteira. [Importar agora]"); caso contrário, esconder o link inteiramente. Trade-off: exige query on-chain do contrato v2 NFT; trivial.
• Perfil afetado: holder de posição v2 legada (subset menor mas com alto custo de fricção).

---

🟡 Oportunidade competitiva — Empty state que "recomenda primeira posição" com base no saldo da wallet

• Padrão da indústria: Uniswap (esta tela), PancakeSwap — empty state é convite genérico (Crie uma posição). Não considera o que o user tem na carteira.
• Por que afeta o target: iniciante com 0 posições mas com $1000 USDC + $500 ETH na carteira tem caminho ideal de primeira posição baseado nos ativos. Genérico ignora; específico converte.
• 4 perguntas-teste: (1) ✓ todos concorrentes têm empty state genérico (2) ✓ afeta iniciante diretamente (3) ✓ razão = exige leitura on-chain de saldos + regras editoriais de recomendação; investimento factível (4) ✓ ganho perceptível — empty state mostra "Você tem $1000 USDC + $500 ETH. Pool sugerida: USDC/ETH 4,89% APR com range largo. [Criar com 1 clique]".
• Hipótese de diferenciação: "Primeira posição sugerida" no empty state — lê saldos da wallet, sugere par mais óbvio com config conservadora (full range, fee tier dominante). CTA Criar essa posição cria com config recomendada. Avançado ignora.
• Trade-off: opinião editorial sobre par sugerido; aceitar com critérios transparentes.
• Leverage estruturalíssimo — converte empty state de placeholder em assistente de onboarding. Família consolidada com 🟡 "Modo tutorial" (Tela 1 SuasPos), 🟡 "Card prescritivo" (Tela 10 PP Base) — sistema Kotai onboarding-driven.

---

Observação adicional — 0 UNI Recompensas ganhas ainda ocupa header mesmo em wallet conectada sem posições. Já flagrado na Tela 10 PP Base e Tela 1 SuasPos — agora é a 5ª aparição deste header inadequado pra contextos sem posição. Família confirmada: produto reusa header global sem condicional pra estado da view. Vale registrar como dívida de produto: header global precisa ter modo "sem posições" + modo "com posições".

6. Portfólio — Modal Transferência (Coinbase como única CEX)

Função: Modal de funding via plataforma centralizada de negociação (CEX). Acionado pelo card Transferência da Visão geral. Reconhece que muito user vem de CEX, não de "outra carteira", e oferece atalho de integração. Mas o modal lista apenas Coinbase — a tela inteira é construída sobre a hipótese de que o user tem Coinbase, o que não cobre LatAm, Ásia, e nem todo o usuário americano.

Componentes

• Modal centralizado sobre a página de portfólio (que continua visível desfocada atrás, com o gráfico em estado placeholder renderizando — sinal de que este modal pode coexistir com o estado de erro do gráfico).
• Header do modal: 📧 Pedir ajuda + X fechar.
• Título: Transferência.
• Subtítulo: "Transfira fundos de uma plataforma de negociação."
• Único card: ícone Coinbase (logo C azul) + label Coinbase + chevron implícito de navegação à direita.

Regras de negócio

• Clique no card Coinbase provavelmente dispara OAuth + integração Coinbase Onramp/Transfer — sai do produto, autoriza, escolhe valor, retorna com transfer iniciado.
• Subtítulo educa sobre o que é "plataforma de negociação" sem usar acrônimo CEX (decisão consciente — iniciante não decoda "CEX").
• Modal não lista alternativas nem caminho fallback para quem não tem Coinbase.

---

🟢 Insight 1 — Single-option modal evita paradox of choice sem inflar com placeholders. Em vez de listar 8 CEX das quais 7 ainda não estão integradas, o modal mostra só a que funciona de verdade. Sem teasers ("em breve: Kraken"), sem disabled cards. É a versão honesta de "o que está disponível agora". Padrão a herdar — não fingir features futuras como se já existissem.

🟢 Insight 2 — Subtítulo educa sobre a categoria sem jargão. "Plataforma de negociação" em vez de "CEX" / "exchange" / "corretora cripto". Iniciante que nunca viu cripto entende. Padrão a herdar — sempre preferir o conceito mental do user ao termo da indústria.

🟢 Insight 3 — Pedir ajuda no header repete o pattern do Receber criptos. Consistência: ações sensíveis de funding têm sempre suporte 1 clique de distância. Pattern coerente entre modais.

---

🔴 Fricção 1 — Modal com 1 única opção é camada de overhead sem valor agregado (estrutural — passo intermediário sem ganho)

• Atrito real: o flow é: card Transferência (Visão geral) → modal Transferência (1 item) → click Coinbase → integração. Dois cliques pra começar uma ação. Modal não filtra nada (não há opções pra comparar), não educa muito além do subtítulo, não tem CTA secundário. É puramente uma camada entre o card de entrada e a integração de saída.
• Solução óbvia que falha: remover o modal e fazer o card Transferência da Visão geral apontar direto pra Coinbase — colapsa a affordance "Transferência = categoria genérica" em "Transferência = Coinbase", perdendo espaço pra futuras integrações.
• Alternativa: manter o modal, mas usá-lo de verdade — listar 2+ caminhos (Coinbase + alguma alternativa local + link "Como conectar outra CEX?"). Enquanto for 1-opção, o modal não justifica. Ou, no curto prazo, eliminar o modal e mover o subtítulo + ícone de ajuda direto pro fluxo de integração. Trade-off: arquitetura precisa decidir entre "modal como hub futuro" vs "navegação direta agora".
• Perfil afetado: todos.

🔴 Fricção 2 — Coinbase como única CEX exclui geograficamente sem caminho fallback (estrutural — vetor de churn para target BR/LatAm/Ásia)

• Atrito real: user BR/Mexicano/Indonésio chega aqui esperando a CEX dele (Mercado Bitcoin, Bitso, Indodax). Não está. Não tem Coinbase (Coinbase é fraca/inexistente em LatAm e parte da Ásia). Não há link "se você não tem Coinbase, use o caminho Receber criptos". O user fecha o modal e desiste — ou pior, conclui que o produto não é pra ele.
• Solução óbvia falha: listar todas as CEX globais — viola Insight 1 (não fingir integrações que não existem).
• Alternativa: footer do modal com link de escape — "Não usa Coinbase? Veja outras formas de fundear sua carteira →" leva pro modal Receber criptos. Reconhece a limitação e direciona ao caminho funcional alternativo. Médio prazo: detectar geografia e priorizar integração local (vide 🟡 abaixo). Trade-off: footer mínimo extra; ganho: zero usuário preso.
• Perfil afetado: iniciante e intermediário fora de US/UE (principal — geografia do target Kotai inclui BR/LatAm).

🔴 Fricção 3 — Card de Coinbase (aqui) e cards de endereços (Receber criptos) são visualmente idênticos, mas semanticamente diferentes (cosmética — affordance ambígua entre endereço local vs integração externa)

• Atrito real: o card Coinbase parece quase idêntico aos cards de endereço do modal Receber criptos. Mas clicar em endereço copia o address (ação local); clicar em Coinbase redireciona pra OAuth da Coinbase (sai do produto). Mesma affordance visual, dois comportamentos diferentes — surpresa de UX quando user clica esperando uma coisa e recebe outra.
• Alternativa: badge ou ícone de external-link (↗) no card de integração, sinalizando "vai sair do produto". Diferencia visualmente "endereço local" de "integração externa". Trade-off: mínimo.
• Perfil afetado: iniciante (principal — surpresa de comportamento).

---

🟡 Oportunidade competitiva — Integração de CEX local-first detectada por geografia (alta leverage no target)

• Padrão da indústria: Uniswap (esta tela), 1inch, PancakeSwap — quando oferecem integração de CEX, é Coinbase global como padrão (decisão US-centric). Para LatAm/Ásia/África, essa integração é vazia — não convergem com a CEX real do user. Resultado: o caminho Transferência é teatral pra metade do mundo.
• Por que afeta o target: Kotai mira target BR como principal. No Brasil, Coinbase é praticamente irrelevante — Mercado Bitcoin, Binance BR, Bitypreto, Foxbit dominam. Sem integração local, o card Transferência é decoração; o user vai usar o caminho "Receber criptos" e copy-paste manual (perigoso e lento).
• 4 perguntas-teste: (1) ✓ todos usam CEX global (2) ✓ afeta iniciante BR/LatAm diretamente (3) ✓ razão = falta de investimento em integrações regionais (4) ✓ ganho diretamente perceptível — "transferir do Mercado Bitcoin em 1 clique" vs "copiar endereço EVM, abrir MB, colar, escolher rede, mandar".
• Hipótese de diferenciação Kotai: detectar região (IP/locale) e listar CEX local-first. BR → Mercado Bitcoin + Bitso + Binance BR no topo, Coinbase rebaixado. MX → Bitso. SE Ásia → Indodax/Tokocrypto. Cada integração usa o equivalente da Coinbase Onramp API local. Família com 🟡 "on-ramp local-first" do relatório 1 — mesma raiz: produto US-first vs produto geo-aware.
• Trade-off: integração + manutenção por jurisdição (custo recorrente alto, compliance variável). Aceitar — é o vetor competitivo mais direto vs Uniswap no target BR.
• Leverage: estrutural alta. Marca a diferença entre "produto global com tradução PT-BR" e "produto pensado pra BR".

---

Observação adicional: o modal coexiste com o gráfico em estado de erro renderizado atrás (vide relatório 5). Modais devem ser estado isolado da página de fundo — vale checar se o erro do gráfico continua escalonando timers/retries enquanto o modal está aberto. Não é fricção desta tela, mas é nota técnica de boa higiene de estado.

7. Portfólio — Tab NFTs vazia

Função: Sub-página da tab NFTs (URL /portfolio/nfts) sem nenhum NFT detectado pela wallet. Função primária: confirmar ausência sem alarmar e orientar pra ação de funding específica desse tipo de ativo.

Componentes

• Header e sub-header padrão da página de portfólio.
• Tabs: Visão geral / Tokens / NFTs ✓ / Atividade.
• Sem big stat de saldo (diferente da tab Tokens).
• Sem search bar (diferente da tab Tokens).
• Empty state central: ilustração de "imagem genérica" cinza (frame com placeholder de foto) + título Nenhum NFT ainda + subtítulo Transfira NFTs de outra carteira para começar.
• Sem CTA explícito.

Regras de negócio

• URL muda pra /portfolio/nfts (deeplink por tab — pattern consistente com Tokens/Atividade).
• Ausência de big stat é decisão correta: NFTs não têm preço universalmente confiável (floor price varia, last-sale é ruído). Sumarizar valor de NFT em USD seria ficção.
• Copy do empty state segue o pattern da tab Tokens (imperativo + objeto específico).

---

🟢 Insight 1 — Ausência de big stat de saldo na tab NFTs é decisão consciente correta. Tabs Tokens e Atividade têm contexto numérico no topo (saldo, contador); NFTs não tem. Reconhece a natureza diferente do ativo — NFT não tem preço fungível, sumarizar "valor total de NFTs em USD" seria mentira contábil. Padrão a herdar — não forçar métrica única em tipos de ativo que resistem à fungibilidade.

🟢 Insight 2 — Empty state segue o pattern visual da tab Tokens. Ilustração + título + subtítulo causal-imperativo. Sistema de design coerente entre tabs com semântica parecida ("transfira X de outra carteira"). Reduz cognitive load — user que aprendeu o pattern numa tab decoda a outra sem reaprender. Padrão a herdar — empty states de tabs irmãs devem compartilhar gramática visual.

---

🔴 Fricção 1 — Instrução do empty sem CTA inline (mesmo problema da tab Tokens) (estrutural — gap entre dizer e fazer, família com fricção do relatório 2)

• Atrito real: copy diz "Transfira NFTs de outra carteira para começar", mas não há botão. User precisa lembrar/intuir que a ação está no modal Receber criptos (que está em outra tab). Mas pior: Receber criptos é construído pra tokens fungíveis (endereço EVM + Solana). NFTs também usam endereços EVM, mas o user iniciante pode duvidar ("o mesmo endereço serve pra NFT?"). Sem botão e sem confirmação, ele fica em loop mental.
• Solução óbvia que falha: replicar Receber criptos sem ajuste — não responde à dúvida específica de NFT ("qual rede? qual contrato?").
• Alternativa: botão inline Receber NFTs que abre variação do modal Receber criptos com copy adaptada ("NFTs ERC-721/1155 em [rede] enviados pra este endereço aparecerão aqui"). Confirma para iniciante que o endereço EVM é o canal correto. Trade-off: nova variação de modal; ganho: zero dúvida sobre canal de recebimento.
• Perfil afetado: iniciante (principal — confusão sobre semântica do endereço pra ativos não-fungíveis).

🔴 Fricção 2 — Ausência de search bar quebra a promessa "escala-pronta" da tab Tokens (estrutural — inconsistência cross-tab sobre descobrir conteúdo futuro)

• Atrito real: tab Tokens tem search bar visível mesmo no empty ("você verá buscar tokens quando tiver"). Tab NFTs não tem nada — quando o user tiver 80 NFTs, vai ter busca/filtro? Galeria por coleção? Sort por floor? Não sabemos do empty. A ausência implica "quando popular, vai aparecer alguma coisa, talvez" — affordance promissória ausente.
• Solução óbvia falha: copiar a search bar da tab Tokens — pode não ser a affordance certa pra NFT (filtro por coleção/floor faz mais sentido que search por nome).
• Alternativa: mostrar controles de descoberta apropriados ao tipo de ativo já no empty — exemplo: chips desabilitados Coleção ▾, Ordenar por ▾, Procurar NFT. User vê o futuro funcionamento; consistência com Tokens preservada na lógica, adaptada ao asset. Trade-off: mais elementos no empty; ganho: zero surpresa quando popular.
• Perfil afetado: intermediário (principal — quem planeja crescer a coleção). Iniciante não nota.

🔴 Fricção 3 — Ilustração de empty pouco distinta da tab Tokens (cosmética — vocabulário visual sub-aproveitado)

• Atrito real: a ilustração da tab Tokens (moedas) e a da tab NFTs (frame de imagem) são reconhecíveis individualmente, mas no contexto da troca rápida de tab, parecem ambas "placeholder cinza genérico". Cada tab tem identidade própria de ativo que poderia ser celebrada visualmente — moeda viva, polaroid com cantos, lista de recibos. A oportunidade gráfica está sub-aproveitada.
• Alternativa: ilustrações com vocabulário visual distinto por tipo de ativo (token = moeda dourada, NFT = quadro/polaroid colorido, atividade = lista de recibos). Trade-off: design extra; ganho: identidade visual entre tabs.
• Perfil afetado: cosmético, todos.

---

Sem 🟡 nesta tela — NFT discovery/curadoria seria oportunidade interessante mas não passa nas 4 perguntas-teste pro target iniciante DeFi (NFTs não são prioridade do user iniciante que busca swap/yield). Registrar como possível observação futura quando/se o produto Kotai expandir pra NFT-first.

---

Observação adicional: tab NFTs poderia educar sobre a diferença entre NFTs detectados automaticamente (via indexer) e NFTs que precisam ser importados manualmente (contratos não indexados, NFTs em chains menos comuns). É vetor real de "meu NFT sumiu" quando na verdade só não foi indexado. Não é fricção desta tela específica (estado vazio), mas é nota pra quando o estado popular — vale incluir affordance "Não vê seu NFT? [Importar manualmente]".

7. Verificação de contrato — Página externa (CryptoWatchlist)

Função: página de terceiro (cryptowatchlist.io) usada pelo user como fonte de verdade pra validar o contrato real do token VIRTUAL antes de criar a posição. Padrão anti-scam crítico em DeFi — usuário sai do Uniswap, busca o token em fonte confiável, copia o endereço do contrato e cola/compara dentro do DEX.

Componentes (página externa, fora do Uniswap)

• Header do token: logo + nome Virtuals Protocol (VIRTUAL) + tag Blockchain Infrastructure + Rank: 95 + 4013 Watchlists.
• Preço: $0,850 + delta 1,33% / +0,011 + range 24h Low $0,810 — High $0,877.
• CTAs: + Add Alert (secundário) / Buy (primário, externo).
• Banner alerta amarelo: "PathDAO (PATH) has rebranded to the Virtuals Protocol (VIRTUAL) and migrated from its old contract to a new one. The old token page: [link]".
• Tabs: Overview ✓ / Fundraising / Markets / Arbitrage / Analytics / Historical data / News / Team.
• Section General Info:
  • Contracts/Explorers: 2 contratos listados — Ethereum 0x44f...bf73 + Base 0x9c2...c7eb com ícones copy + abrir explorer.
  • Funds and Backers: DeFiance Capital + outros logos.
  • Tags: Token / AI Agent Platform / DeFi.
  • Description: "Virtuals Protocol is a co-ownership layer for AI agents" + More Details.
  • Links: Website / X / Telegram.
• Chart Virtuals Protocol (VIRTUAL) Chart no rodapé (TradingView-like).

Regras de negócio (pattern de segurança)

1. User suspeita de scam ("VIRTUAL" pode ter homônimos com contratos diferentes).
2. Busca o token em fonte agregadora (cryptowatchlist.io, CoinMarketCap, CoinGecko).
3. Verifica banner de rebrand/migração (caso PathDAO → VIRTUAL = migração documentada, contrato antigo virou stale).
4. Copia o contrato da rede correta (Base, não Ethereum, pra este flow).
5. Cola no Uniswap em vez de buscar por ticker (VIRTUAL) — ticker pode ter colisão; contrato é único.

---

🟢 Insight 1 — Banner de rebrand/migração no agregador externo cumpre função de proteção que o DEX não cumpre. "PathDAO migrou pra Virtuals Protocol" alerta user sobre token velho que ainda circula com mesmo símbolo. Sem essa info, user com saldo do contrato antigo (PATH) tentaria aportar e veria token com 0 liquidez. Padrão a herdar pra Kotai — agregador externo virou load-bearing pro pattern anti-scam.

🟢 Insight 2 — Contracts/Explorers exibidos lado a lado (Ethereum + Base) deixam claro que existe "o mesmo token em 2 redes". User aprende que tokens são por-rede, não globais. Padrão a herdar — qualquer UI que exibe token deve carregar a rede explicitamente.

🟢 Insight 3 — Rank + Watchlists + Funds and Backers funcionam como prova social legítima. Token com Rank 95 e backers nomeados (DeFiance Capital) tem credibilidade verificável. Sem esses sinais, user iniciante usaria "se tem logo bonito é legítimo" — heurística falha. Padrão a herdar — exibir credenciais verificáveis (não badges arbitrários).

---

🔴 Fricção 1 — Toda essa verificação acontece FORA do Uniswap — produto não ensina nem oferece o pattern (estrutural — dependência crítica de terceiros pra segurança do user)

• Atrito real: segurança contra scam de token é delegada a CryptoWatchlist/CMC/CoinGecko. Uniswap não diz "verifique o contrato", não mostra Rank, não tem Funds and Backers. Iniciante que não conhece esse pattern colaria endereço de scam token (com mesmo nome) e teria perda total. Avançado conhece o ritual mas paga custo de tab-switching.
• Por que a solução óbvia falha: integrar CMC dentro do DEX exige licença/API; copiar a UI vira responsabilidade legal do produto sobre claims de "token legítimo".
• Alternativa: badge inline no autocomplete do Uniswap — quando user busca VIRTUAL, mostrar 3 sinais ao lado do token: ✓ Verificado (CoinGecko ID 28250) + Rank #95 + Contrato Base: 0x9c2...c7eb. Sem opinar sobre legitimidade, apenas surfaçar dados pública. Trade-off: depende de feed externo (rate limit, fallback necessário); ganho: zero scam por colisão de ticker.
• Perfil afetado: iniciante (principal — não conhece o pattern e cairia em scam) + intermediário descuidado.
• Família com 🟡 "Ranking por perfil" (Tela 1) — mesma raiz produto: descoberta de token é cega ao contexto de risco.

🔴 Fricção 2 — Banner de rebrand existe no agregador, não no DEX (estrutural — informação crítica de "este contrato está obsoleto" não vaza pro flow de aporte)

• Atrito real: user com saldo do antigo contrato PATH (não migrado pra VIRTUAL) entraria no Uniswap, buscaria "PATH", veria 0 liquidez ou pool morto e abandonaria sem entender o motivo. O agregador externo sabe sobre a migração; o DEX não.
• Por que a solução óbvia falha: manter base de "tokens migrados" exige curadoria contínua; falsos positivos prejudicam tokens legítimos com baixa liquidez.
• Alternativa: microcopy quando user busca um token com 0 ou baixa liquidez — "PATH parece descontinuado ou migrado. Verifique [link → CoinGecko]". Sem afirmar; sugerindo investigação. Trade-off: curadoria de heurística "liquidez baixa = pode estar morto"; aceitar com link externo.
• Perfil afetado: iniciante (principal) + holder de token antigo migrado.

🔴 Fricção 3 — O fato do user precisar abrir 4-5 abas (Uniswap, CryptoWatchlist, Etherscan, X) pra fazer 1 swap é fricção estrutural do ecossistema DeFi inteiro (estrutural — orquestração de confiança fragmentada entre múltiplas fontes)

• Atrito real: o screenshot mostra 5 abas abertas no browser do user: agregador de volume, mídia social do projeto, página de migração, screen do Uniswap, e CryptoWatchlist. Cada aba é um nó na rede de confiança que o user monta manualmente. Iniciante não monta essa rede — confia cego e perde.
• Por que a solução óbvia falha: consolidar tudo num único produto é missão impossível (e perigosa — quem decide o que é confiável?).
• Alternativa: trust dashboard inline no Uniswap — pequeno painel "Sobre VIRTUAL" no Pool detail (Tela 2) com 4-5 sinais agregados de fontes confiáveis (CoinGecko rank, backers, age do contrato, audits, social proof). Cada sinal linka pra fonte original. User não substitui o ritual de verificação, mas economiza 80% do tab-switching. Trade-off: curadoria + dependência de feeds externos.
• Perfil afetado: iniciante (principal — único que não tem o ritual internalizado) + intermediário cansado de re-fazer.

---

🟡 Oportunidade competitiva — DEX com camada nativa de verificação de contrato e prova social

• Padrão da indústria: Uniswap, PancakeSwap, KyberSwap — autocomplete por ticker sem badge de verificação, sem rank, sem backers. Segurança contra scam é 100% delegada a terceiros (CMC/CoinGecko).
• Por que afeta o target: iniciante é o alvo dos scams — token homônimo com contrato malicioso engana exatamente quem não conhece o pattern de verificação. Intermediário sabe verificar mas paga custo de tab-switching. Avançado tem extensão (Pocket Universe, Blockaid, Scam Sniffer) — mas ferramentas avançadas têm baixa adoção pelo target.
• 4 perguntas-teste: (1) ✓ todos os concorrentes delegam verificação (2) ✓ afeta iniciante e intermediário diretamente (3) ✓ razão = exige integração com feeds externos + UI de trust; falta de investimento (4) ✓ ganho perceptível — user vê ✓ Verificado por CoinGecko · Rank #95 · Contrato Base · Audit OpenZeppelin direto no autocomplete e ganha confiança sem sair do produto.
• Hipótese de diferenciação: "Trust card" ao buscar token — painel lateral mostrando: ID em CoinGecko/CMC, rank, contratos por rede (com badge Verificado on-chain), backers nomeados, age do contrato (em dias/anos), top 5 holders, link pro audit (se houver). Tokens novos sem dados aparecem com badge Token novo, sem verificação (não bloqueia, alerta).
• Trade-off: dependência de APIs externas (CMC/CoinGecko/DefiLlama) — rate limit, custo, fallback degradado. Curadoria contínua. Aceitar como custo recorrente.
• Leverage estrutural altíssimo — converte busca cega de ticker em decisão informada de trust. Família consolidada com 🟡 "Ranking por perfil" (Tela 1), 🟡 "Pool detail simulador" (Tela 2) — Kotai como produto que internaliza o ritual de verificação que o user faz hoje em 5 abas.

---

Observação adicional — esta tela revela que o produto Uniswap depende implicitamente de produtos externos pra cumprir função básica de "posso confiar neste token?". É dependência arquitetural invisível: sem CoinGecko/CMC, Uniswap seria perigoso pra iniciante. Vale registrar como insight de mercado — Kotai pode posicionar-se como "DEX que não precisa de outras 4 abas pra ser usado com segurança".

5. Ratio extremo — Saldo de VIRTUAL insuficiente

Função: mesmo Step 2 com range muito tight no floor (-0,07% do preço atual) revelando que pool exige quantidade absurda de VIRTUAL pra cobrir o range. Sistema bloqueia o aporte com mensagem Saldo de VIRTUAL insuficiente.

Componentes (diff em relação à Tela 4)

• Section Estratégias de preço colapsada no topo (4 cards ainda visíveis mas sem expansão de detalhe).
• Inputs de preço:
  • Preço mínimo: 0,85249377 + (-0,07%) em vermelho — floor quase no preço atual.
  • Preço máximo: 1,2000864 + (+40,53%) em verde — ceiling 40% acima.
• Section Depositar tokens:
  • 1070,326180990420357 VIRTUAL + 964,03 US$ — number em vermelho (saldo insuficiente).
  • 5 USDC + 5,00 US$.
• Footer: Saldo de VIRTUAL insuficiente (CTA disabled, fundo cinza).

Regras de negócio

• Range com floor próximo do preço atual → posição precisa estar quase 100% no token de baixo (VIRTUAL).
• Sistema valida saldo da wallet em tempo real — 1070 VIRTUAL excede o saldo do user (carteira do tutorial tem ~$2).
• Vermelho no number indica valor > saldo disponível.
• USDC fixo em 5 (input do user); VIRTUAL recalculado automaticamente pela math da pool.
• CTA disabled bloqueia avanço até user reduzir aporte ou alargar range.

---

🟢 Insight 1 — Validação de saldo em tempo real evita transação que falharia na wallet. Sistema bloqueia antes do user pagar gas pra ver erro on-chain. Padrão a herdar pra Kotai — validações de saldo, allowance e slippage devem rodar no client antes de chamar wallet.

🟢 Insight 2 — Number em vermelho ancorado ao input é affordance forte de "erro neste campo". User olha o vermelho, sabe onde está o problema. Padrão a herdar — erros de validação devem manchar o campo, não só o footer.

🟢 Insight 3 — CTA disabled (não removido) com mensagem clara devolve diagnóstico. Botão visível mas inativo + mensagem Saldo de VIRTUAL insuficiente é melhor que CTA escondido — user vê que ação existe, só está bloqueada por motivo nomeado. Padrão a herdar.

---

🔴 Fricção 1 — Mensagem Saldo de VIRTUAL insuficiente diagnostica sintoma, não causa raiz (estrutural — erro escondendo a real decisão a tomar)

• Atrito real: user vê "Saldo de VIRTUAL insuficiente" e mental model é "preciso comprar mais VIRTUAL". Mas a causa raiz não é saldo — é o range tight no floor que força ratio extremo. User pode alargar o range (mover Preço mínimo pra 0,7) e o sistema pediria 50× menos VIRTUAL. Mensagem atual leva user pro caminho errado (comprar VIRTUAL) em vez do caminho certo (ajustar range).
• Por que a solução óbvia falha: trocar a mensagem por "Range muito tight, alargue o floor" é prescritivo (e errado pra user que de fato quer aportar mais VIRTUAL); duas mensagens diferentes exigem heurística pra detectar caso.
• Alternativa: mensagem composta com 2 saídas — "Saldo de VIRTUAL insuficiente. Você pode: [Alargar o range] (recalcula com seu saldo) ou [Reduzir USDC] (mantém range)." Dois CTAs com cálculo automático. Trade-off: footer cresce 2 linhas; ganho: user vê a decisão real.
• Perfil afetado: iniciante (principal — único que toma "saldo insuficiente" literal) + intermediário descuidado.
• Família com 🔴 Fricção 1 da Tela 6 (sensibilidade do ratio invisível) — mesma raiz: produto não conecta input de range a output de ratio.

🔴 Fricção 2 — Number 1070,326180990420357 (15+ casas decimais) é ruído visual puro (cosmética — precisão técnica vazando pra UI)

• Atrito real: display de 15 casas decimais é a precisão interna do BigNumber/uint256, não a precisão de leitura humana. User precisa de 2–4 casas decimais (1070,33 ou 1070); 15 casas viram parede de números que o cérebro rejeita. Pior: vermelho intensifica a parede.
• Por que a solução óbvia falha: truncar pra 2 casas perde precisão pra avançado que copia o number; manter 15 quebra leitura.
• Alternativa: display com 2–4 casas decimais por padrão + tooltip on-hover com precisão total (1070,326180990420357). Avançado clica pra copiar, iniciante lê limpo. Trade-off: implementação dupla precisão; trivial.
• Perfil afetado: todos os perfis (ruído universal).
• Família com fricção "17 casas decimais" da PosPop equivalente — mesma raiz: precisão de máquina exposta como precisão de leitura.

🔴 Fricção 3 — Não há feedback de "o que mudou no chart" entre Tela 4 e Tela 5 (estrutural — relação range × ratio não materializada)

• Atrito real: user moveu o Preço mínimo de 0,85 (Tela 4) pra 0,85249377 (Tela 5) — diferença microscópica de 0,003. Resultado: VIRTUAL exigido pulou de razão razoável pra 1070. A causa é a sensibilidade da curva de liquidez perto do preço atual — fato matemático contra-intuitivo. Produto não mostra esse comportamento; user vê só o number vermelho final e atribui a "saldo insuficiente" em vez de "range muito sensível".
• Por que a solução óbvia falha: explicar a curva exige modal técnico; user dismissa.
• Alternativa: chart com overlay mostrando ratio esperado por posição do floor — barra horizontal abaixo do chart de preço com gradiente "100% USDC ← centro → 100% VIRTUAL". User arrasta floor e vê a barra mover. Materializa a sensibilidade. Trade-off: nova visualização exige design; alto leverage.
• Perfil afetado: iniciante e intermediário (avançado conhece a math).

---

🟡 Oportunidade competitiva — Validação ativa de range com sugestão automática de ajuste

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3 — produto valida saldo e bloqueia, mas não sugere ajuste. User precisa descobrir sozinho que o problema é range, não saldo.
• Por que afeta o target: iniciante para no Saldo insuficiente e abandona o flow ("preciso comprar mais VIRTUAL primeiro"). Intermediário entende mas perde tempo iterando manualmente.
• 4 perguntas-teste: (1) ✓ nenhum concorrente sugere ajuste automático (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = exige modelo client-side; falta de investimento (4) ✓ ganho perceptível — user vê "Seu saldo cobre range -10% / +40% (em vez de -0,07% / +40%). [Aplicar]".
• Hipótese de diferenciação: botão Ajustar para meu saldo abaixo da mensagem de erro — recalcula floor mínimo viável dado o saldo do user e oferece aplicar com 1 clique. Avançado ignora; iniciante usa.
• Trade-off: opinião editorial sobre "range razoável" (qual o tradeoff entre tightness e saldo); aceitar com cálculo determinístico baseado em saldo disponível.
• Leverage estrutural alto — converte erro em ação. Família com 🟡 Oportunidade da Tela 2 (simulador inline) e 🟡 "Health Score" (PosPop #5) — sistema de assistência ativa.

---

Observação adicional — denominação 964,03 US$ abaixo de 1070 VIRTUAL confirma que o produto sabe converter token → USD em tempo real. Capacidade subutilizada na Tela 4 (inputs de preço em token-ratio cru) e na Tela 6 (mesmo). Existe conversor USD nativo — vale acoplar conversor a TODOS inputs financeiros, não só ao display de saldo.

6. Range ajustado — ratio recalculado com floor menos tight

Função: user ajustou o Preço mínimo de 0,85249377 (Tela 5) pra 0,84 — diferença de 0,012. Resultado: VIRTUAL exigido caiu de 1070,32... pra 21,40 — redução de ~50×. Tela materializa sensibilidade extrema da curva de liquidez ao floor do range.

Componentes (diff em relação à Tela 5)

• Inputs de preço:
  • Preço mínimo: 0,84 + (-1,05%) em vermelho (era 0,85249377 / -0,07%).
  • Preço máximo: 1,2000864 + (+40,53%) em verde (inalterado).
• Section Depositar tokens:
  • 21,4065236198084075 VIRTUAL + 19,39 US$ — number em cor normal (não mais vermelho).
  • 0,1 USDC + 0,10 US$ — USDC recalculado pra baixo (era 5).
• Footer: Saldo de VIRTUAL insuficiente ainda — ratio menor mas ainda excede saldo da carteira tutorial.

Regras de negócio

• Diferença de 0,012 no Preço mínimo → redução de ~50× no VIRTUAL exigido.
• Bidirecional: alterar inputs de range OU de tokens recalcula o outro lado.
• USDC ajustou automaticamente de 5 pra 0,1 — sistema preservou ratio implicado pelo range, não preservou input do user.
• Range mais largo no floor = mais USDC + menos VIRTUAL necessário pro mesmo capital.
• Status Saldo insuficiente persiste mesmo com ratio reduzido — saldo de VIRTUAL da carteira tutorial ainda menor que 21,40.

---

🟢 Insight 1 — Bidirecionalidade input range ↔ input token preserva agência do user. User pode chegar ao mesmo aporte por 2 caminhos: definir range e ver tokens recalculados, ou definir tokens e ver range recalculado. Padrão a herdar pra Kotai — inputs acoplados devem permitir edição em qualquer lado.

🟢 Insight 2 — Cor normal do number (após vermelho da Tela 5) confirma resolução parcial. User vê que mexer no range mudou o status do campo — feedback visual imediato. Padrão a herdar — estados de validação devem responder a ajustes em tempo real, não exigir clique de "validar".

🟢 Insight 3 — Number 0,1 USDC / 0,10 US$ mostra que produto preserva precisão sub-centavo. Sem flooring/rounding agressivo. Padrão a herdar — precisão financeira em DeFi exige fidelidade, mesmo em valores pequenos.

---

🔴 Fricção 1 — Sensibilidade 0,012 → 50× é contra-intuitiva e não tem feedback proporcional (estrutural — não-linearidade da curva invisível pro user)

• Atrito real: user moveu floor 0,852 → 0,84 esperando mudança incremental ("ah, alarguei um pouco, vai pedir um pouco menos"). Sistema responde com queda de 50× no ratio. Comportamento correto matematicamente (curva tick × liquidez é altamente não-linear perto do preço atual), mas invisível: nada na UI sinaliza a sensibilidade. User pode mover o floor mais 2 ticks e ver ratio dobrar de novo — não tem mental model.
• Por que a solução óbvia falha: exibir a derivada da curva é técnico demais; mostrar warning "range muito tight" toda vez vira ruído.
• Alternativa: gradient bar abaixo do chart de preço mostrando "sensibilidade do ratio" — zonas vermelhas perto do preço atual (alta sensibilidade) e zonas verdes longe (baixa sensibilidade). User arrasta floor e vê em qual zona caiu. Trade-off: nova visualização; alto leverage pedagógico.
• Perfil afetado: iniciante e intermediário (avançado já modela).
• Família com 🔴 Fricção 3 da Tela 5 (relação range × ratio invisível) — mesma raiz, mesma alternativa (gradient bar resolve as duas).

🔴 Fricção 2 — USDC mudou de 5 (input do user) pra 0,1 sem aviso explícito (estrutural — overwrite de input do user sem feedback)

• Atrito real: user digitou 5 USDC na Tela 5; ao mover o range, sistema reescreveu o USDC pra 0,1 automaticamente. Sem highlight, sem mensagem "USDC reajustado pra manter ratio". User olha de novo a tela e pode achar que digitou errado, ou pior, não perceber que o aporte total caiu de ~$969 pra ~$19,50.
• Por que a solução óbvia falha: travar o input do user (USDC fixo em 5) seria fricção quando user quer aporte automático; perguntar toda vez é fricção.
• Alternativa: highlight temporário no input recalculado (fade in/out amarelo por 1,5s) + microcopy abaixo "USDC ajustado pra manter ratio do range". Sem bloquear, mas tornando o overwrite visível. Trade-off: anima estado; trivial.
• Perfil afetado: iniciante (principal — único que não rastreia mudanças entre estados) + intermediário.

🔴 Fricção 3 — Status Saldo de VIRTUAL insuficiente persiste como mesma mensagem entre estados muito diferentes (cosmética — erro genérico não reflete proximidade da solução)

• Atrito real: Tela 5 exigia 1070 VIRTUAL (50× saldo); Tela 6 exige 21,40 VIRTUAL (provavelmente 2-3× saldo). User está muito mais perto de resolver, mas a mensagem é literalmente idêntica. Sem feedback de progresso, user pode achar que está estagnado.
• Por que a solução óbvia falha: detalhar saldo no footer (Você tem X, precisa de Y) cresce footer.
• Alternativa: footer dinâmico com gap absoluto — "Faltam ~13 VIRTUAL ($11,50)". User vê que está perto e decide se compra a diferença ou ajusta mais o range. Trade-off: footer com 1 linha extra; ganho: progresso visível.
• Perfil afetado: iniciante e intermediário (motivacional).

---

🟡 Oportunidade competitiva — Visualização de "densidade de capital exigida" no chart durante drag do range

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3 — chart de preço é estático; user move bounds e só vê resultado em tokens exigidos (number frio). Relação range geométrico → capital exigido é caixa preta.
• Por que afeta o target: iniciante move bounds aleatoriamente; intermediário precisa iterar várias vezes pra entender; só avançado modela. Custo de aprendizado alto.
• 4 perguntas-teste: (1) ✓ todos concorrentes têm chart passivo (2) ✓ afeta iniciante e intermediário (3) ✓ razão = visualização de densidade exige cálculo client + render; falta de investimento (4) ✓ ganho perceptível — user arrasta floor e vê heatmap colorido mudando em tempo real abaixo do chart.
• Hipótese de diferenciação: gradient bar densidade de capital exigida abaixo do chart — colorido em verde (pouco capital) a vermelho (muito capital) baseado na distância tick × liquidez. User arrasta bounds e o gradient atualiza ao vivo. Combinado com 🔴 Fricção 1 (sensibilidade invisível), resolve o gap pedagógico.
• Trade-off: mais 1 row visual no chart; alto valor educacional.
• Leverage estrutural alto — converte decisão geométrica em decisão informada quanto a capital. Família com 🟡 "Simulador inline" (Tela 2), 🟡 "Slider probabilístico" (PosPop #11), 🟡 "Validação ativa" (Tela 5) — sistema integrado de feedback visual durante config de range.

---

Observação adicional — diferença entre Tela 5 e Tela 6 é a melhor evidência empírica do kotai-thesis "DeFi expõe matemática, esconde consequência". O mesmo flow, mesma carteira, 1 clique de diferença → ratio muda 50×. Iniciante depositaria na Tela 5 sem entender; intermediário aprende caro. Vale congelar essas 2 telas como caso-âncora pra design reviews internas — toda decisão de UX no nosso produto deve passar pelo teste "este input causa surpresa proporcional ou desproporcional ao output?".

8. Portfólio — Tab Atividade vazia (estado base, sem popovers)

Função: Estado base da tab Atividade (URL /portfolio/activity), sem popover aberto. É o mesmo viewport do relatório 3, mas no estado neutro — sem o Compartilhar expandido. Tela serve dois propósitos no estado vazio: confirmar ausência de histórico e expor a estrutura de filtros que existirá quando popular.

Componentes

• Header e sub-header padrão.
• Tabs: Visão geral / Tokens / NFTs / Atividade ✓.
• Linha de controles à esquerda: dropdown Todos os tipos ▾ + dropdown Todo o período ▾.
• Search bar à direita: Procurar atividade (input ativo).
• Empty state central: ilustração de "recibos cinza com diamante" + título Nenhuma atividade ainda + subtítulo "Quando você fizer transações, elas aparecerão aqui."

Regras de negócio

• URL muda pra /portfolio/activity — deeplink por tab consistente.
• Filtros Todos os tipos e Todo o período clicáveis mesmo no empty (abrem dropdown — vide relatórios 9 e 10).
• Search bar aceita input — sem efeito sobre lista vazia.
• Copy do empty é declarativa-causal ("quando ... aparecerão"), não imperativa — reconhece que Atividade não é populada por ação local nesta tab, e sim como consequência de uso do produto.

---

🟢 Insight 1 — Estrutura de filtros visível no empty estabelece o modelo mental futuro. User vê que existirá tipo de transação + período como dimensões de filtro quando a lista crescer. Aprende a arquitetura antes de precisar dela — quando os primeiros 50 swaps + envios estiverem listados, ele já sabe onde recortar. Padrão a herdar — controles que farão sentido futuramente devem ser visíveis no empty, não revelados depois.

🟢 Insight 2 — Copy causal supera imperativa onde não há ação local. Já elogiada no relatório 3 — "Quando você fizer transações, elas aparecerão aqui" descreve o gatilho (fazer transação) e o efeito (aparecer aqui) sem ordenar ação que esta tab não pode disparar. Diferente das tabs Tokens/NFTs (ação local = transferir), Atividade só popula por consequência de outras telas. Padrão a herdar.

---

🔴 Fricção 1 — Filtros clicáveis sobre lista vazia disparam dropdown sem efeito (estrutural — affordance morta, mesma classe de outras telas do flow)

• Atrito real: o user, curioso ou por hábito, clica em Todos os tipos ▾. Dropdown abre (vide relatório 9). Ele seleciona Swaps. Volta pro empty — ainda vazio, agora com filtro Swaps ativo (sem nada pra filtrar). Repete com Todo o período. Cada interação é controle morto. Pior: a UI não dá feedback de que "o filtro está ativo mas não há nada que ele recorte" — só fica vazio do mesmo jeito.
• Solução óbvia que falha: desabilitar os filtros completamente — perde a oportunidade pedagógica de mostrar a arquitetura.
• Alternativa: manter os filtros visíveis (Insight 1) mas desabilitados no empty — chevron cinza, sem dropdown, com tooltip "Disponível após primeira transação". User aprende que existe sem poder cair no buraco da affordance morta. Trade-off: dois estados visuais pros filtros (disabled empty / enabled populated); ganho: zero clique sem resposta.
• Perfil afetado: iniciante (principal — único que testa controles "pra ver o que faz").

🔴 Fricção 2 — Search bar aceita input mas retorna sempre vazio (estrutural — input ativo que mente)

• Atrito real: user digita "swap" na search bar Procurar atividade. Nada acontece — nem mensagem "0 resultados", nem auto-clear. O estado original (empty) continua porque era empty antes da busca. Para o user, parece bug — "digitei e ele ignorou". Diferente da search da tab Tokens, que pode buscar em catálogo global (e portanto faz sentido manter ativa), a search de Atividade é estritamente sobre o histórico do user — histórico vazio = busca inerte por construção.
• Solução óbvia que falha: ocultar a search bar até existir histórico — quebra a affordance escala-pronta (Insight 1).
• Alternativa: search desabilitada com placeholder "Pesquise sua atividade após a primeira transação" — mantém o slot, evita o engano de input ativo sem efeito. Restaurar como ativa quando lista > 0. Trade-off: regra a mais; ganho: zero input que finge funcionar.
• Perfil afetado: iniciante e intermediário.

🔴 Fricção 3 — Espaço entre header de filtros e empty state é desperdiçado (cosmética — superfície educacional não-explorada)

• Atrito real: existe ~30% de viewport entre a linha de filtros e a ilustração de empty central. Esse espaço pode educar (link "Como funciona o histórico de Atividade", preview de como uma transação aparece, exemplos das 11 categorias do filtro Todos os tipos). Hoje é silêncio visual.
• Alternativa: usar o espaço pra preview educacional — "Quando você fizer um swap, ele aparecerá aqui [exemplo card]". Onboarding-by-example, opcional, dismissible. Trade-off: mais conteúdo no empty pode pesar; ganho: vetor educacional dentro do contexto.
• Perfil afetado: iniciante.

---

🟡 Oportunidade competitiva — Atividade como instrumento contábil/fiscal, não só log cronológico (alta leverage no target BR/jurisdições com IR cripto)

• Padrão da indústria: Uniswap (esta tela), Zerion, Zapper, DeBank — Atividade é log cronológico bruto. Cada linha mostra timestamp + tipo + tokens envolvidos. Sem cálculo de ganho/perda por operação, sem conversão cambial baseada em data, sem agrupamento por categoria fiscal, sem exportação fiscal-ready. Quem precisa declarar IR exporta CSV e contrata serviço terceiro (Koinly, Coinpanda, CryptoTax) — R$300-500/ano por wallet.
• Por que afeta o target: no Brasil, declarar cripto no IR é obrigatório (operações > R$30k/mês ou ganhos tributáveis). Usuário iniciante/intermediário BR não tem ferramenta nativa — escolhe entre: pagar serviço externo, fazer planilha manual (erros caros), ou ignorar (risco de multa). Em outras jurisdições com IR cripto obrigatório (US, UE, Índia, Austrália), idêntico.
• 4 perguntas-teste: (1) ✓ todos os concorrentes só logam, não calculam fiscal (2) ✓ afeta iniciante e intermediário diretamente — IR é obrigação legal (3) ✓ razão = exige cálculo de basis, FIFO/LIFO, conversão BRL/USD por data, classificação por categoria fiscal; falta de investimento (não é trivial mas é estabelecido) (4) ✓ ganho diretamente perceptível e mensurável (R$ economizado, tempo poupado, risco fiscal mitigado).
• Hipótese de diferenciação Kotai: tab Atividade gera relatório fiscal exportável (PDF + CSV padrão IR), com cálculo de ganho/perda por operação, conversão cambial em moeda local na data da transação, agrupamento por categoria fiscal (renda variável, ganho de capital, swap = alienação). Plug-in pra preenchimento direto do IR. Filtro extra Período fiscal (ano civil) ao lado dos existentes.
• Trade-off: regras fiscais variam por jurisdição; exige manter modelo atualizado por país. Custo recorrente alto. Mas é vetor competitivo diretamente diferenciador — nenhum DEX hoje atende esse caso de uso nativamente.
• Leverage: estrutural alta — transforma "log de transações" em "instrumento contábil" com valor real recorrente. Família com a 🟡 do relatório 2 (valor declarado × recuperável) — mesma raiz: portfólio como instrumento contábil sério, não como dashboard de vaidade.

---

Observação adicional: vale notar que esta tela é o estado-base do relatório 3 (mesmo viewport sem popover) — os dois relatórios poderiam ser consolidados em um só, com o popover tratado como variação de estado. Decisão de produto: manter os dois reflete que o popover é interação significativa (não trivial); consolidar reflete que economia de superfície analítica importa. Não há resposta única — anotar como decisão de organização do estudo, não fricção do produto.

8. Review — Modal "Criando posição"

Função: modal de confirmação final antes de submeter à blockchain. Consolida par + range + tokens + taxa de rede num único painel, com CTA Criar que dispara a sequência de aprovações na carteira.

Componentes

• Modal overlay sobre a Etapa 2 (fundo escurecido).
• Header do modal:
  • Title: Criando posição + link Pedir ajuda (direita do título).
  • Botão × (fechar).
• Identificação da posição:
  • VIRTUAL / USDC com logos sobrepostos + badge v3 + 0,3%.
• Mini-chart de preço com range destacado em verde:
  • Mín: 0,84233 USDC/VIRTUAL (esquerda) / Máx: 1,20009 USDC/VIRTUAL (direita).
• Section Depositando:
  • 13 VIRTUAL + 11,55 US$ (com logo VIRTUAL).
  • 0,53968 USDC + 0,540 US$ (com logo USDC).
• Taxa de rede: ~0,01 US$ + toggle ✓ (gas fee).
• 0,54 US$ (provável soma de USDC ou total — ver Observação).
• CTA principal: Criar (rosa primário grande, full-width).
• CTA secundário fora do modal: Analisar (visível atrás, rosa primário também).

Regras de negócio

• Modal é "última chance de revisar" — fechar leva user de volta à Etapa 2 com config preservada.
• Mini-chart com range em verde = double-check visual de "estou na faixa que escolhi?".
• Taxa de rede ~0,01 US$ é gas estimado da chain (Base, baixíssimo custo).
• Aporte total: $11,55 + $0,54 ≈ $12,10 (carteira de tutorial).
• CTA Criar dispara 3 transações sequenciais: Aprovar VIRTUAL → Aprovar USDC → Confirmar posição (vide Tela 9).
• Link Pedir ajuda no header é caminho de fuga raro em DEXes (vide Insight 1).

---

🟢 Insight 1 — Link Pedir ajuda no header do modal de confirmação é affordance rara e poderosa. Maioria dos DEXes assume que se user chegou no review é porque sabe o que faz. Uniswap admite que mesmo no review user pode estar confuso e oferece saída. Reduz abandono silencioso ("vou fechar e sair") e canaliza dúvida pra suporte. Padrão a herdar pra Kotai — momentos de "última chance" devem oferecer ajuda, não só OK/Cancelar.

🟢 Insight 2 — Mini-chart embedded no modal materializa o range escolhido como sanity check. User não confia em number cru (0,84233 / 1,20009) — confia em ver que a banda verde cobre uma faixa razoável do preço. Sem o chart, review seria parede de numbers. Padrão a herdar — qualquer modal de confirmação financeira deve incluir representação gráfica da decisão, não só dados tabulares.

🟢 Insight 3 — Taxa de rede exibida ANTES de assinar elimina surpresa de gas pago. User vê ~0,01 US$ e sabe que essa transação custará isso. Em mainnet Ethereum o number seria $15-50 e o user teria chance de abortar. Padrão a herdar — fees devem ser exibidos no review, não emergir só no popup da wallet.

🟢 Insight 4 — Logos dos tokens repetidas em cada linha do Depositando reforçam identidade do par. Mesmo com title "VIRTUAL / USDC" no header, cada linha de depósito mostra o logo de novo. Iniciante confirma visualmente que está depositando o que entende — não confunde linhas. Padrão a herdar — identificação visual deve ser redundante em UIs de confirmação financeira.

---

🔴 Fricção 1 — 0,54 US$ solto abaixo da taxa de rede é número sem rótulo claro (cosmética — orphan number polui review final)

• Atrito real: no review onde a expectativa é "todo number tem um label", aparece 0,54 US$ sem contexto óbvio. É a soma do USDC? É um sub-total? É o valor da taxa de rede em outra unidade? Iniciante para nesse number tentando decodar. Provavelmente é display redundante do USDC depositado (0,540 US$ → 0,54 US$ arredondado), mas a redundância confunde sem ajudar.
• Por que a solução óbvia falha: remover number perde informação se for soma; manter sem label degrada.
• Alternativa: se for sub-total, rotular explicitamente — Total depositado: $12,09 (soma de VIRTUAL + USDC). Se for redundância, remover. Trade-off: exige decisão de produto sobre o que o number representa.
• Perfil afetado: iniciante (principal).

🔴 Fricção 2 — Criar no modal e Analisar fora do modal competem visualmente como CTAs primários (estrutural — hierarquia de ação ambígua entre modal e tela de fundo)

• Atrito real: modal de review tem Criar (rosa primário). Mas atrás do modal, ainda visível e ativo, está o CTA Analisar (também rosa primário) da tela de Etapa 2. Iniciante pode clicar no botão errado — especialmente em viewport pequeno onde Analisar aparece pelas bordas. "Analisar" abre o review (já está aberto); "Criar" submete à blockchain. Confusão entre eles tem consequências diferentes.
• Por que a solução óbvia falha: esconder/desabilitar o CTA de fundo quando o modal abre é o esperado, mas o produto não faz; alterar cor degrada consistência.
• Alternativa: escurecer mais o backdrop do modal e desabilitar CTAs da tela de fundo (cinza claro, não-clicável). Backdrop atual já escurece mas mantém affordance do Analisar lá. Trade-off: trivial; ganho: zero clique acidental no botão errado.
• Perfil afetado: iniciante (principal — único que tateia) + intermediário descuidado.

🔴 Fricção 3 — 13 VIRTUAL exibido sem fração mas 0,53968 USDC com 5 casas — inconsistência de precisão entre as linhas do mesmo bloco (cosmética — formatação inconsistente)

• Atrito real: VIRTUAL aparece como inteiro 13 (sem decimais visíveis); USDC aparece com 5 casas 0,53968. Provavelmente VIRTUAL é exatamente 13,0 (input do user) e USDC é recalculado pela math. Mas a inconsistência de display sugere que VIRTUAL é "limpo" e USDC é "sujo" — leitura pode levar iniciante a desconfiar do number "sujo".
• Por que a solução óbvia falha: padronizar 13,00000 / 0,53968 em 5 casas decimais polui; padronizar em 2 casas 13,00 / 0,54 perde precisão do USDC.
• Alternativa: 2 casas decimais por padrão (13,00 / 0,54) + tooltip on-hover com precisão completa. Consistência visual com fallback informativo. Trade-off: perde precisão visível pra avançado; aceitar.
• Perfil afetado: iniciante (principal — único que percebe inconsistência como sinal de bug).
• Família com 🔴 "15 casas decimais" (Tela 5) — mesma raiz: precisão de máquina exposta sem normalização editorial.

---

🟡 Oportunidade competitiva — Modal de review com simulação "o que acontece se preço sair do range"

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3 — modal de review é descritivo (mostra o que você está fazendo) mas não prospectivo (não mostra cenários). User vê Min 0,84 / Max 1,20 mas não vê "se preço cair pra 0,80, sua posição vira 100% VIRTUAL e para de render fees".
• Por que afeta o target: iniciante e intermediário não internalizam consequências de sair do range. Modal de review é o último momento pra ensinar antes do dinheiro sair.
• 4 perguntas-teste: (1) ✓ nenhum DEX faz review prospectivo (2) ✓ afeta iniciante e intermediário (3) ✓ razão = exige modelo + UI; falta de investimento (4) ✓ ganho perceptível — user vê 3 cenários (Preço cai 10% → 100% VIRTUAL, 0 fees / Preço fica → fees acumulam / Preço sobe 30% → ainda dentro do range, fees acumulam) antes de clicar Criar.
• Hipótese de diferenciação: section colapsável no modal — Ver cenários (3) v que expande pra mostrar 3 outcomes possíveis com probabilidade estimada e ação resultante ("posição fica 100% USDC, parar de render"). Default colapsado pra não inflar modal de avançado.
• Trade-off: modelo é estimativa; aceitar com caveat.
• Leverage estrutural alto — converte review de descritivo em educativo. Família com 🟡 "Pool detail simulador" (Tela 2), 🟡 "Presets probabilísticos" (Tela 4).

---

Observação adicional — Pedir ajuda no header do modal é uma pequena revolução de affordance que vale destacar como decisão estratégica. Em 99% dos modais de confirmação financeira (banco, broker, DEX), a opção é "OK / Cancelar". Uniswap adiciona uma 3ª via: "não sei o que fazer, me ajude". Não é só usabilidade — é postura de produto que admite que confusão é estado válido. Vale herdar pra Kotai como princípio, não só padrão visual.

9. Wallet Sign — Aprovações sequenciais (Rabby Wallet)

Função: após clique em Criar (Tela 8), modal Uniswap atualiza pra mostrar sequência de aprovações on-chain necessária; carteira (Rabby) abre popup paralelo pedindo assinatura de cada uma. Etapa de handoff entre app e wallet — ponto crítico de abandono em DeFi.

Componentes

• Modal Uniswap (centro):
  • Title: Criando posição + × + título do par VIRTUAL / USDC ainda visível.
  • Mini-chart com range em verde (igual Tela 8) + numbers Mín 0,84233 / Máx 1,20009.
  • Depositando: 13 VIRTUAL ($11,55) / 0,562854 USDC ($0,562) — USDC ligeiramente diferente da Tela 8 (re-quote após delay?).
  • Section nova: Continuar na carteira + microcopy "Você precisa aprovar 2 tokens".
  • Lista sequencial de steps:
    • Aprovar VIRTUAL ✓ (concluído, check verde).
    • Aprovar USDC (atual — destacado).
    • Confirmar na carteira (próximo, cinza).
  • Badge: Etapa 2 de 3.
• Popup Rabby Wallet (canto superior direito):
  • URL: https://app.uniswap.org.
  • Title: Token Approval.
  • Approve token: 115,792,089,237,316,... (limite máximo uint256 — aprovação infinita).
  • My balance: 13.7841 VIRT....
  • Approve to: 0xC36AAA... (endereço do contrato Permit2 ou roteador).
  • Protocol (label sem valor visível).
  • Interacted before (badge de histórico).
  • Advanced Settings (collapse).
  • Botão Sign with Seed Phrase (Rabby seed wallet).
  • Transaction created ✓ (confirmação inline).

Regras de negócio

• ERC-20 padrão exige transação de approval separada antes de o contrato gastar tokens do user — overhead de design do protocolo, não escolha do Uniswap.
• Cada token = 1 transação de approval + 1 de mint da posição. Total: 3 transações sequenciais (Approve VIRTUAL, Approve USDC, Mint position).
• Valor Approve token: 115,792,089,237,316,... é 2^256-1 (uint256 max) — convenção de "aprovação infinita" pra evitar pagar gas de re-approval em transações futuras.
• Permit2 (do Uniswap) consolida múltiplas aprovações via assinatura off-chain, mas só funciona se o token implementar EIP-2612 — VIRTUAL não implementa, daí o approval ERC-20 tradicional.

---

🟢 Insight 1 — Stepper inline Etapa X de 3 no modal devolve agência ao user durante o handoff pra wallet. Sem stepper, user clica Aprovar VIRTUAL na wallet, volta, vê "loading" no Uniswap, e não sabe quantas vezes ainda vai precisar assinar. Stepper concreto ("2 de 3") deixa claro o que falta. Padrão a herdar pra Kotai — qualquer fluxo multi-tx deve expor progresso explícito.

🟢 Insight 2 — Microcopy "Você precisa aprovar 2 tokens" antecipa o número de assinaturas antes de começar. User sabe que serão 3 cliques na wallet antes de começar, não descobre no meio. Padrão a herdar — flows com side-effect na wallet devem declarar "você vai assinar X vezes" antes do primeiro popup.

🟢 Insight 3 — Badge Interacted before na Rabby Wallet sinaliza que o contrato é familiar. Sinal de trust vindo da wallet (não do DEX) — se você já interagiu antes com 0xC36AAA..., provavelmente é Permit2 oficial. Padrão a herdar — sinais de trust devem ser orquestrados entre app e wallet, não duplicados.

---

🔴 Fricção 1 — 3 popups consecutivos de wallet (Aprovar VIRTUAL + Aprovar USDC + Confirmar) é a principal causa de abandono em criação de posição LP (estrutural — fricção de protocolo ERC-20 transferida pro user)

• Atrito real: cada popup exige: read → understand → click → wait for transaction → return → repeat. Em rede com gas alto (mainnet) cada approval custa $5-15 — 3× é $15-45 só em fees antes de a posição existir. Em rede barata (Base, esta tela) o custo financeiro é trivial mas o custo cognitivo é o mesmo — user tem 3 momentos de "e se eu assinar a coisa errada?". Avançado é cínico; iniciante hesita e abandona. Pior: se user para no meio (assina VIRTUAL mas não USDC), tem allowance pendente que pode ser explorada no futuro.
• Por que a solução óbvia falha: "esconder" approval do user é impossível — wallet é a fonte de autoridade. Reduzir pra 1 tx exige cooperação do token (EIP-2612) ou bundler (Account Abstraction) — fora do controle do DEX no caso de tokens legados.
• Alternativa: Permit2 com batch + signature off-chain quando suportado pelo token, com fallback explícito pra approval ERC-20. UI deve sinalizar "Este token (VIRTUAL) requer 2 aprovações on-chain. USDC suporta assinatura única." — admite a complexidade, não a esconde. Mais agressivo: Account Abstraction (ERC-4337) com smart wallet que faz batch de tudo numa única tx do ponto de vista do user. Trade-off: exige smart wallet adoption do user (Safe, Coinbase Smart Wallet, etc.).
• Perfil afetado: iniciante (principal — abandona) + intermediário (irritado mas completa).
• Família com 🟡 "Validação ativa" (Tela 5) e 🟡 "Simulador inline" (Tela 2) — sistema integrado: produto deve assumir complexidade do protocolo em vez de transferir pro user.

🔴 Fricção 2 — Approve token: 115,792,089,237,316,... (uint256 max) é o number mais assustador da tela e ninguém explica que é "aprovação infinita padrão" (estrutural — convenção técnica de segurança exposta como dado bruto)

• Atrito real: user vê 115 quatrilhões e mais um caminhão de zeros como valor sendo aprovado. Reação racional: pânico ("vão drenar minha carteira?"). Reação real do user: assina mesmo assim porque é o que o produto pede, sem entender. Pior cenário cognitivo: user aprende a ignorar números na wallet porque "isso aí é normal". Hábito que vai ser explorado pela próxima dApp maliciosa.
• Por que a solução óbvia falha: trocar uint256 max por valor exato 13.7841 VIRT exige re-approval em cada nova transação — gas overhead que avançado rejeita.
• Alternativa: toggle no modal Uniswap antes do popup wallet — Aprovação: ✓ Infinita (recomendado) / Apenas esta transação (paga gas extra na próxima). Default infinita pra preservar economia; user iniciante que tem dúvida tem out. Microcopy "Aprovação infinita = você não paga gas de re-approval; apenas o contrato Permit2 pode gastar e ele é open-source/auditado". Trade-off: mais UI no modal; ganho: zero pânico do user + educação sobre por que infinito é padrão.
• Perfil afetado: iniciante (principal — única vítima do pânico) + intermediário consciente.
• Família com 🔴 "15 casas decimais" (Tela 5) — mesma raiz: número técnico exposto como número de leitura.

🔴 Fricção 3 — Inconsistência de USDC entre Tela 8 e Tela 9 (0,53968 → 0,562854) (estrutural — re-quote silencioso no momento crítico de assinar)

• Atrito real: modal review (Tela 8) mostrou 0,53968 USDC ($0,540). Modal de assinatura (Tela 9) mostra 0,562854 USDC ($0,562) — 4% maior. Provavelmente preço de mercado mudou nos segundos entre clicar Criar e o popup abrir. Mas: (a) user não foi avisado; (b) diferença pode crescer em rede congestionada; (c) iniciante atento percebe e desconfia ("essa tela mudou os numbers depois que eu confirmei?").
• Por que a solução óbvia falha: congelar quote pra sempre é impossível (preço move); cancelar tx por mudança de preço gera abandono.
• Alternativa: microcopy explícita no modal de assinatura — "Valores atualizados: USDC foi de 0,540 → 0,562 (+4%) por movimento de preço. Slippage permitido: 5%." + opção de cancelar e re-quotar. Trade-off: mais linhas no modal; ganho: trust restaurada.
• Perfil afetado: iniciante atento + intermediário desconfiado.

---

🟡 Oportunidade competitiva — DEX nativo em smart wallet (Account Abstraction) com batch + sponsored gas

• Padrão da indústria: Uniswap (esta tela), PancakeSwap, KyberSwap — assumem wallet EOA (MetaMask, Rabby, Coinbase clássica) e empurram 3 transações sequenciais pro user. Smart wallets (Safe, Coinbase Smart Wallet, Ambire) existem mas não são default — produto não trata como cidadão de 1ª classe.
• Por que afeta o target: iniciante é exatamente quem mais sofre com 3 popups; smart wallet resolveria com 1 clique. Mas onboarding de smart wallet hoje é fricção do tamanho do produto inteiro. Quem resolver o trilema (adoção de smart wallet × simplicidade onboard × UX nativa) ganha o iniciante.
• 4 perguntas-teste: (1) ✓ todos concorrentes assumem EOA (2) ✓ afeta iniciante e intermediário (3) ✓ razão = exige integração com bundler/paymaster, contratos de smart wallet; investimento técnico não-trivial mas factível (4) ✓ ganho perceptível — user faz 1 clique e a posição é criada com VIRTUAL + USDC + gas tudo na mesma tx.
• Hipótese de diferenciação: Kotai-as-smart-wallet — onboarding cria smart wallet (Safe + paymaster Kotai) por default; toda interação vira userOp única; gas pago em USDC (não ETH); approvals consolidados via Permit2 + multicall; recuperação social via guardians (não seed phrase). EOA continua suportada como modo "avançado".
• Trade-off: abandona compatibilidade nativa com MetaMask como default (re-onboarding); custo de operar paymaster (sponsored gas inicial); responsabilidade arquitetural sobre fundos do user. Mitigação: smart wallet self-custody (user controla, Kotai não).
• Leverage estruturalíssimo — converte criação de posição LP de "5 minutos com 3 popups" em "15 segundos com 1 clique". Família consolidada com 🟡 "Trust dashboard" (Tela 7), 🟡 "Validação ativa" (Tela 5), 🟡 "Simulador" (Tela 2). Sistema Kotai = smart wallet + verificação nativa + simulação preditiva.

---

Observação adicional — Sign with Seed Phrase na Rabby é affordance de fallback que revela um dado crítico: a wallet do user é seed-based, não hardware nem smart. Isso significa que todo o flow assume EOA, perpetuando os 3 popups. Para Kotai mirar iniciante, decisão de produto mais importante pode não ser "fazer DEX melhor" — pode ser "fazer onboard de smart wallet melhor que tudo no mercado, e depois construir o DEX em cima dela". A diferenciação de UX no DEX vai bater no teto da carteira do user.

9. Portfólio — Filtro Todos os tipos expandido (categorias DeFi-nativas)

Função: Dropdown do filtro de tipo de transação na tab Atividade. Define o vocabulário do produto sobre "o que conta como transação" — 11 categorias DeFi-nativas que cobrem swap, LP, transfer, sistema. É o filtro que materializa a granularidade do log e, indiretamente, o que o produto considera relevante registrar.

Componentes

• Tab Atividade vazia atrás (empty state ainda visível).
• Botão Todos os tipos ▴ ativo (chevron para cima = aberto).
• Dropdown ancorado abaixo do botão, lista com 12 itens (cada um com ícone à esquerda):
  • Todos os tipos ✓ (selecionado, check rosa)
  • Swaps (logo Uniswap rosa)
  • Envios (ícone avião/seta)
  • Recebimentos (ícone download)
  • Wraps (ícone embrulho)
  • Withdrawals (ícone download alternativo)
  • Aprovações (ícone cadeado)
  • Pools criados (ícone onda)
  • Liquidez adicionada (ícone +)
  • Liquidez removida (ícone –)
  • Tarifas resgatadas (ícone moeda)
  • Emissões (ícone emit)
• Filtro Todo o período ▾ permanece colapsado ao lado.

Regras de negócio

• 11 categorias funcionais + 1 "Todos" (default).
• Wraps = WETH wrap/unwrap (ETH ↔ WETH); Withdrawals = saques (pool, staking); Aprovações = ERC-20 approve(); Emissões = mint (NFT, LP token, governance token).
• Categorias mapeiam decoders on-chain — cada uma implica heurística de classificação (event topics + interface detection).
• Provavelmente seleção radio (1 categoria por vez), não múltipla.

---

🟢 Insight 1 — Granularidade alta cobre o vocabulário DeFi completo. 11 categorias incluem operações triviais (Swap, Envio) e operações de sistema (Aprovações, Emissões) — auditoria fina possível. Padrão a herdar — não esconder categorias técnicas porque iniciante não as usa; elas são fundamentais pra uso sério, e quem precisa precisa.

🟢 Insight 2 — Todos os tipos como default e primeira opção. Iniciante vê tudo sem ter que escolher. Padrão correto — default amplo, filtros como refinamento opcional.

🟢 Insight 3 — Ícones distintos por categoria reduzem leitura textual. User aprende vocabulário visual e decoda a lista futura por ícone, não por label completa. Pattern correto pra listas densas. Padrão a herdar.

---

🔴 Fricção 1 — Mistura PT-BR e EN inconsistente (Wraps, Withdrawals no meio de itens traduzidos) (estrutural — i18n quebrada afeta confiança e entendimento)

• Atrito real: lista tem Envios, Recebimentos, Aprovações, Emissões (traduzidos) coexistindo com Wraps e Withdrawals (em inglês). Pra iniciante BR que não sabe o que é "wrap", a palavra é ruído puro. Pior: Withdrawals tem tradução óbvia (Retiradas) e foi deixada em EN — sinal de tradução incompleta, não decisão consciente. Erode confiança no resto da UI traduzida.
• Solução óbvia que falha: traduzir literal — Wraps → Empacotamentos soa estranho e perde o termo técnico que avançado reconhece.
• Alternativa: rotulagem descritiva PT-BR + tooltip com termo técnico — Trocas WETH ↔ ETH (tooltip: "wrap/unwrap"); Retiradas (tooltip: "withdrawals"). Iniciante decoda; avançado mantém ponte com terminologia internacional. Trade-off: labels mais longos; ganho: iniciante BR entende.
• Perfil afetado: iniciante BR (principal — único que trava em "wrap").

🔴 Fricção 2 — 11 categorias planas sem agrupamento funcional (estrutural — cognitive load no scan)

• Atrito real: lista mistura "o que o user faz a maior parte do tempo" (Swaps, Envios, Recebimentos) com "o que ele faz raramente" (Aprovações, Emissões, Pools criados). Sem agrupamento, ele scaneia 11 itens lineares pra encontrar Swaps. Aprovações no meio é especialmente disruptivo — é categoria "de sistema", quase nunca o user filtra por ela conscientemente.
• Solução óbvia que falha: ordenar por frequência de uso individual — exige rastreamento por user, primeiros acessos sem dado.
• Alternativa: agrupar por subseção visual — Trading: Swaps, Wraps; Liquidez: Liquidez adicionada, Liquidez removida, Pools criados, Tarifas resgatadas; Movimentação: Envios, Recebimentos, Withdrawals; Sistema: Aprovações, Emissões. Header de seção pequeno em maiúsculas/cinza. Trade-off: dropdown fica mais alto; ganho: scan ~3× mais rápido.
• Perfil afetado: intermediário (principal — usa filtros mais).

🔴 Fricção 3 — Seleção provavelmente radio (single), não múltipla (estrutural — granularidade visualmente alta, funcionalmente limitada)

• Atrito real: dropdown padrão Uniswap é radio (1 categoria por vez). Mas auditoria fiscal/contábil exige combinações — "Swaps + Envios" (vendas tributáveis), "Tudo exceto Aprovações" (limpar ruído). Com radio, user exporta tudo e filtra fora do produto, anulando a granularidade da lista.
• Solução óbvia que falha: mudar pra checkbox sem ajustar UX — Todos os tipos como checkbox não faz sentido (é o agregado).
• Alternativa: multi-select com toggle no item Todos os tipos (clicar marca/desmarca todos) + footer com Limpar / Aplicar. Single-click rápido continua funcionando (clica 1 item → filtra só por ele). Trade-off: dropdown ganha estado de aplicação; ganho: filtragem flexível pra casos sérios.
• Perfil afetado: intermediário e iniciante BR que precisa declarar IR. Família com 🟡 Atividade-como-instrumento-fiscal do relatório 8 — combinações flexíveis são pré-requisito pra relatório fiscal correto.

---

Sem 🟡 nesta tela — categorias dinâmicas baseadas em uso (ocultar vazias, destacar com volume) seria melhoria, mas leverage no target é média-baixa e o ganho não passa nas 4 perguntas-teste com clareza. Registrar como possível otimização futura.

---

Observação adicional: Aprovações aparecer como categoria de primeira classe sinaliza que o produto reconhece eventos approve() como objeto contábil — padrão correto. Quando o log popular, vale incluir affordance [Revogar] direto na linha de aprovação — converte log passivo em ação de segurança. Vetor de higiene DeFi (revogar aprovações antigas pra evitar drain attacks) raramente exposto pelos concorrentes.

6. Posição Populada — Nova Posição (Step 1) com seletor de versão aberto

Função: primeira tela do flow de criação de posição, aterrissada via + New da Tela 5 (ou via + Add liquidity da Tela 1). Layout em 2 colunas + stepper vertical à esquerda: stepper mostra Step 1 (Select token pair and fees) ativo / Step 2 (Set price range and deposit amounts) bloqueado; coluna direita exibe seções Select pair, Fee tier, CTA Continue (desabilitado). Estado capturado tem o dropdown de versão aberto mostrando v4 position (default selecionado) + opções New v3 position / New v2 position.

Componentes

• Breadcrumb: Your positions › New position.
• Título grande: New position.
• Stepper à esquerda (2 steps): círculo 1 rosa (Step 1 ativo, label "Select token pair and fees") + círculo 2 cinza (Step 2 bloqueado, "Set price range and deposit amounts").
• Header secundário com 3 controles à direita:
  • ↻ Reset (texto, secundário).
  • Dropdown v4 position v (default) — aberto neste print, revelando: New v3 position / New v2 position.
  • ⚙ settings gear.
• Section Select pair com subcopy "Choose the tokens you want to provide liquidity for. You can select tokens on all supported networks."
  • Slot 1: token preenchido ETH (ícone roxo + ticker + chevron).
  • Slot 2: Choose token v (vazio).
• Link inline: + Add a Hook (Advanced) ⓘ — exclusivo de v4.
• Section Fee tier com subcopy "The amount earned providing liquidity. Choose an amount that suits your risk tolerance and strategy."
  • Estado placeholder: "— fee tier" + "The % you will earn in fees" + botão More v à direita.
• CTA primário: Continue (desabilitado, cinza — Step 1 incompleto).

Regras de negócio

• Default da seleção de versão é v4 — produto empurra v4 como padrão para criação nova (coerente com tag Migrate to v4 na Tela 5).
• ETH vem pré-preenchido pelo contexto (provavelmente herdado da URL ?currency0=NATIVE visível na address bar).
• + Add a Hook (Advanced) só aparece quando versão = v4. Hooks são feature-killer de v4 (lógica custom em swap/add/remove) — mas escondida atrás de label "(Advanced)" + ⓘ.
• Fee tier fica oculto até par completo — não dá pra escolher fee antes de saber qual o par (decisão de fluxo: par determina quais tiers são canonicamente sensatos).
• Dropdown de versão fica no header global do flow, não dentro de uma section — sinaliza que versão é decisão transversal (afeta arquitetura inteira da posição), não setting "do par".

---

🟢 Insight 1 — Stepper vertical com 2 steps anuncia desde a entrada que o flow é curto e linear. Em vez de wizard interminável estilo Sushiswap ou OneInch (5+ steps), Uniswap reduz a 2 etapas. Iniciante vê de cara "vou clicar Continue 1 vez e acabou" — reduz fricção de antecipação. Padrão a herdar pra Kotai: stepper visível desde a entrada > stepper que aparece progressivamente; quanto menos steps explícitos, mais o user comete-se.

🟢 Insight 2 — Dropdown de versão no header (não no body) sinaliza decisão arquitetural transversal. v4/v3/v2 não é "atributo do par" — é "qual AMM você quer usar". Por isso fica no header, junto com Reset e Settings, não dentro de Select pair. Padrão a herdar — decisões transversais ao flow (testnet, multichain, versão) merecem slot global; decisões locais (par, fee, range) ficam no body.

🟢 Insight 3 — Hook como link em vez de tab. v4 introduz hooks (lógica custom). Uniswap não promove a tab "Configure hook" no flow — mostra como link inline + Add a Hook (Advanced). Decisão deliberada: hooks são feature avançada que a maioria dos LPs não vai usar, mas precisa estar visível pra quem usa. Link colapsado = affordance honesta. Padrão a herdar — features de poucos não merecem tab dedicada; merecem link inline com (Advanced) explícito.

---

🔴 Fricção 1 — Dropdown v4 position na posição mais alta da página induz iniciante a pensar que escolher versão é o primeiro passo, mas o Step 1 do stepper diz "Select token pair and fees" (estrutural — conflito entre dois sistemas de navegação na mesma tela)

• Atrito real: dois "passos iniciais" disputam o olhar do user. (a) Stepper à esquerda diz 1. Select token pair and fees. (b) Header tem dropdown v4 position ativo + Reset + Settings. User iniciante não sabe se deve mexer no dropdown primeiro (parece importante, está no topo) ou no Select pair (é o que o stepper manda). Resultado típico: clica no dropdown sem saber o que significa "v4 position", abre o menu, vê v3 / v2 sem contexto, fecha com inércia em v4. Decisão de versão fica por default em vez de escolha — exatamente o oposto da pedagogia que a tela tenta entregar.
• Por que a solução óbvia falha: mover o dropdown pra dentro de Select pair quebra o Insight 2 (decisão transversal); esconder o dropdown atrás de Settings reduz acessibilidade de uma decisão real; explicar v4 vs v3 vs v2 inline polui.
• Alternativa: expor explicitamente "Etapa 0: Versão" no stepper — 0. Choose AMM version (v2/v3/v4) → 1. Select token pair and fees → 2. Set price range and deposit amounts. Stepper passa a ter 3 marcos, primeiro marco é "Versão" com card-resumo das 3 opções (v4: hooks, mais flexível / v3: concentrated, padrão / v2: full-range, simples). User escolhe versão com contexto, depois cai no Select pair. Trade-off: mais 1 step antes de tudo (custo de antecipação) mas decisão informada em vez de default cego. Aceitar pelo target iniciante.
• Perfil afetado: iniciante (principal — primeira vez no flow, nunca viu v2/v3/v4 em UI) + intermediário sem mental model claro de versão.
• Família com 🔴 Fricção 2 da Tela 1 (Tab Liquidity sem affordance v3) — mesma raiz: produto trata versão como atributo invisível, transferindo o custo de decoda pro user.

🔴 Fricção 2 — + Add a Hook (Advanced) ⓘ aparece mesmo antes do par estar completo (cosmética — affordance fora de ordem)

• Atrito real: o link de hook está visível com slot 2 do par ainda vazio (Choose token). User pode clicar em hook sem ter par; produto provavelmente vai bloquear ou abrir modal estranho. Em flow linear de 2 steps, ações condicionais (hook = feature de v4) deveriam aparecer só quando pré-condições estão satisfeitas.
• Por que a solução óbvia falha: esconder o link até par completo perde discoverability — user pode terminar o flow sem saber que hook existia.
• Alternativa: manter link visível mas desabilitado com tooltip "Selecione o par antes de adicionar hook". Trade-off: link cinza em tela majoritariamente cinza pode passar despercebido (perde a discoverability tentada); compensar com cor de destaque quando habilita.
• Perfil afetado: intermediário curioso.

🔴 Fricção 3 — Continue desabilitado sem indicação de o que falta (cosmética — botão silenciosamente bloqueado)

• Atrito real: CTA Continue cinza não diz por que está bloqueado. Faltam três coisas: (a) token 2 do par, (b) fee tier. User precisa olhar a tela inteira e descobrir o que está incompleto. Em flow simples (2 steps) isso é tolerável, mas em flows densos vira problema.
• Por que a solução óbvia falha: banner de erro permanente acima do botão polui; tooltip on-hover do botão desabilitado é raramente descoberto.
• Alternativa: label dinâmico no próprio botão — Select second token (enquanto slot 2 vazio) → Choose fee tier (depois) → Continue. Botão se autocomenta. Trade-off: label muda muito, pode parecer inconsistente; ganho: clareza do gating sem elementos extras.
• Perfil afetado: iniciante (principal).
• Família com 🟡 "transparência ativa para iniciante" — mesma raiz: produto comunica estado por presença/ausência de affordance, em vez de copy explícito.

---

🟡 Oportunidade competitiva — Card-comparador de versões (v2/v3/v4) no momento da escolha

• Padrão da indústria: Uniswap (esta tela), PancakeSwap (v2 vs v3 stableswap vs v3), Curve (stable vs crypto pools) — todos oferecem múltiplas versões/tipos, mas a escolha entre elas acontece via dropdown nu (label + label + label). Sem contexto comparativo. User decide com nome do produto, não com diferença real.
• Por que afeta o target: iniciante não sabe que v4 = hooks + custom logic, v3 = concentrated liquidity, v2 = full range. Intermediário sabe os nomes mas não sabe o trade-off prático ("v4 é mais barato em gás? v3 perde fee em ranges errados?"). Decisão de versão = decisão de retorno + complexidade + risco, mas é tomada sem âncora.
• 4 perguntas-teste: (1) ✓ todos os concorrentes usam dropdown nu (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = produto trata versão como detalhe técnico em vez de decisão de produto (4) ✓ ganho perceptível — user vê 3 cards comparativos ("v2: simples, full range, fee fixo / v3: concentrated, mais yield se ranger bem / v4: hooks, automação custom") e escolhe com base no perfil.
• Hipótese de diferenciação: modal "Escolha sua versão" no início do flow — 3 cards lado a lado com 1 frase resumo + 1 caso de uso ("Iniciante: v2 é a aposta mais segura — full range, sem precisar pensar em tick") + indicador de complexidade (1–3 estrelas). User vê de cara qual encaixa no perfil dele. Default pode continuar v4, mas com escolha informada.
• Trade-off: mais 1 step antes do flow real (custo de antecipação); risco editorial em "qual versão recomendar pra iniciante" (Uniswap empurra v4 porque é a feature nova; nós podemos empurrar v2 ou v3 porque é mais seguro pra iniciante).
• Leverage estrutural — converte decisão default em decisão informada. Família consolidada "transparência ativa para iniciante" + "escolha com contexto" (PosPop #1, #2, #3, #5). Aqui é a manifestação no momento de entrada do flow de criação.

---

Observação adicional — URL revela que ETH veio via ?currency0=NATIVE. A address bar mostra app.uniswap.org/positions/create/v4?currency0=NATIVE&.... Decisão arquitetural: o flow herda contexto da URL (deeplinkável), permitindo que Pools/Pool Detail/Cards de "Top pools" levem o user pro flow com par pré-preenchido. Padrão a herdar pra Kotai — flow de criação deve aceitar ?token0=X&token1=Y&fee=Z como parâmetros, possibilitando deep-link em qualquer entrypoint (pool detail, banner promocional, link compartilhado).

9. Posição Populada — Nova Posição (Step 2) com Custom range default

Função: entrada do Step 2 (Set price range and deposit amounts) após Continue da Tela 7/8. Stepper muda: círculo 1 cinza (Step 1 concluído), círculo 2 rosa (Step 2 ativo). Panel revela section Set price range com tabs Full range / Custom range — Custom range default selecionado — chart histórico de preço (Mar 15 a Apr 12, ~30 dias) e current price denominado em 0,00045 WETH/USDC ($0,892). Toggle de denominação USDC | ETH no canto direito.

Componentes

• Stepper inalterado em estrutura; Step 1 marcado completo, Step 2 ativo.
• Header do panel: par USDC / ETH + v3 + fee 0,05% + botão ✏ Edit (volta ao Step 1).
• Tabs grandes: Full range | Custom range ✓ (default em Custom).
• Microcopy abaixo das tabs: "Custom range allows you to concentrate your liquidity within specific price bounds, enhancing capital efficiency and fee earnings but requiring more active management."
• Linha Current price: 0,00045 WETH/USDC ($0,892) + toggle de denominação USDC | ETH ✓ (radio-pair de seleção mútua).
• Chart grande de preço histórico ocupando o centro: linha branca/clara representando preço; eixo X com datas (Mar 15, Mar 22, Mar 29, Apr 05, Apr 12); volume/liquidity column visível à direita do chart.

Regras de negócio

• Default = Custom range. Decisão de produto: Uniswap empurra concentração ativa (feature core de v3) como caminho default.
• Toggle USDC | ETH muda a denominação do current price: USDC = preço de USDC em ETH (0,00045 WETH); ETH = preço de ETH em USDC ($2.222 ≈ 1/0,00045). Decisão arquitetural — par ETH/USDC pode ser lido em duas direções, e a escolha afeta como o range será definido (min/max em "WETH por USDC" ou "USDC por WETH").
• Chart mostra os últimos ~30 dias por padrão (vide Tela 10 que revela os toggles de tempo).
• Edit no header do panel é re-entry ao Step 1 — não há "Cancel" ou "Back" no stepper.

---

🟢 Insight 1 — Default Custom range empurra o user pra feature diferenciadora de v3. Tab Full range está visível mas não-selecionada; produto sinaliza "você escolheu v3, então concentrar é o ponto". Decisão de funil: se default fosse Full range, user nunca exploraria concentrated liquidity e v3 viraria "v2 com extra step". Padrão a herdar pra Kotai — quando arquitetura tem feature core, default deve dirigir a ela (com escapatória clara).

🟢 Insight 2 — Microcopy embaixo da tab carrega trade-off explícito. "...enhancing capital efficiency and fee earnings but requiring more active management". Não vende só o lado bom (yield maior) — declara o custo (manutenção ativa). Sinceridade rara em DeFi onboarding. Padrão a herdar — microcopy de feature avançada deve carregar trade-off na mesma frase, não em FAQ separado.

🟢 Insight 3 — Toggle de denominação como primary control, não setting escondido. USDC | ETH fica colado no current price, no nível visual mais alto da decisão. Reconhece que denominação muda a leitura inteira do range (min/max em token A é diferente de min/max em token B; user que confunde paga caro). Padrão a herdar — controles que mudam unidade de medida devem viver no mesmo nível que o number que medem.

🟢 Insight 4 — Botão Edit no header do panel preserva fluidez ao voltar pro Step 1. Não há "Voltar" no stepper (decisão de produto: stepper marca progresso, não navegação). Mas user pode precisar trocar fee (ex: percebeu que 0,05% é tier errado). Edit resolve sem confundir o modelo do stepper. Padrão a herdar — re-entry a steps anteriores via "Edit" no contexto, não via setas do stepper.

---

🔴 Fricção 1 — Current price 0,00045 WETH/USDC é a denominação menos legível pra iniciante; o produto começa com a leitura difícil (estrutural — default de denominação inverte intuição)

• Atrito real: iniciante pensa em ETH como "$2.200" (valor de mercado em USD), não "0,00045 WETH por dólar". A denominação default (WETH/USDC) força o user a inverter o number: 1/0,00045 ≈ $2.222. Em pares com stablecoin, a direção convencional cripto-nativa é stablecoin como quote ($X por ETH) — exatamente o que o toggle ETH ✓ daria. Mas o default escolhido é USDC ✓, que mostra WETH/USDC (i.e., quantos WETH você ganha por 1 USDC). Decisão arquitetural defensável (USDC é "token 0" no contrato), mas semanticamente confusa pro user.
• Por que a solução óbvia falha: trocar default pra ETH-as-quote ($2.222 USDC/WETH) é fácil mas pode quebrar paridade com contrato (campos internos esperam token0 = USDC); mostrar ambos lado a lado polui.
• Alternativa: default da denominação = stablecoin-as-quote em pares com stablecoin; em pares sem stablecoin (ETH/WBTC, etc.), default = ordem alfabética ou token de maior cap. Inversão fácil via toggle. Trade-off: default precisa de regra de roteamento (stablecoin detection); ganho: iniciante vê o preço que ele conhece ($2.222) em vez de inverso.
• Perfil afetado: iniciante (principal) + intermediário em pares heterogêneos.
• Família com 🔴 Fricção 1 do VisualizarPool #2 (ordem do par invertida sem âncora) — mesma raiz: produto privilegia ordem de contrato sobre legibilidade humana.

🔴 Fricção 2 — Custom range default sem range pré-preenchido deixa o user em "white canvas" estado (estrutural — affordance ausente no momento de maior incerteza)

• Atrito real: Custom range está selecionado, mas nenhum range está pré-configurado. Iniciante vê o chart, vê o current price, e tem que escolher min/max do zero. Sem âncora, escolha vira chute. "Coloco ±5%? ±20%? Full range é melhor mesmo?" — paralisia de decisão. As tabs Full vs Custom funcionam como Hobson's choice: Full = "deixa quieto" (não exige decisão); Custom = "decida agora" (exige escolha sem âncora). Iniciante racional volta pra Full por inércia.
• Por que a solução óbvia falha: pré-preencher Custom range com valor arbitrário ancora errado; pré-preencher com Stable (±3 ticks) privilegia uma das 4 price strategies sem contexto.
• Alternativa: default Custom range = volatilidade observada nos últimos 30 dias (ex: se preço variou ±15%, range default = ±20% pra dar margem). User vê valor pré-calculado, ajusta a partir dele. Padrão "default informado por dado, não opinião". Trade-off: exige cálculo de volatilidade no client; default pode parecer prescritivo demais. Aceitar com microcopy "Sugerido com base na volatilidade dos últimos 30 dias".
• Perfil afetado: iniciante (principal — é quem trava com white canvas) + intermediário inseguro com v3.
• Família com 🟡 "APR estimado por range" (PosPop #1) e 🟡 "Simulador na curva" (PosPop #3). As 3 oportunidades convergem aqui: simular antes (curva interativa) + estimar APR no momento (PosPop #1) + default informado (esta tela). Sistema completo de range-aware UX.

🔴 *Fricção 3 — Microcopy "requiring more active management" anuncia custo de gestão sem dizer quanto ou com que frequência (cosmética — caveat honesto mas vago)

• Atrito real: "more active management" — quanto é "mais"? Checar 1x por semana? 1x por dia? Reposicionar quando o range fica out? Iniciante não tem heurística. Caveat fica como ameaça vaga em vez de orientação acionável.
• Por que a solução óbvia falha: dar number específico ("verifique 2x por dia") soa prescritivo; FAQ separado é dismissado.
• Alternativa: microcopy condicional ao range escolhido — quando range tight (±2%), produto mostra "Posições tight saem do range em ~12h em períodos voláteis. Considere notificações." Quando range amplo (±50%), microcopy fica neutra. Acompanha decisão de range com expectativa real de manutenção.
• Perfil afetado: iniciante (principal).

---

🟡 Oportunidade competitiva — Range "presets inteligentes" baseados em volatilidade histórica, não em ticks ou %

• Padrão da indústria: Uniswap (esta tela e Tela 10), PancakeSwap v3, KyberSwap Elastic — oferecem presets como Stable (±3 ticks) / Wide (-50%—+100%) / One-sided. Presets nomeados por forma (stable/wide), não por resultado esperado (% chance de ficar in-range). User escolhe preset por estética sem âncora probabilística.
• Por que afeta o target: iniciante quer saber "se eu colocar tight, qual a chance da minha posição sair do range em 24h?". Esse é o question real — não "tight é ±3 ticks ou ±5 ticks?". Produto pode calcular: dado volatilidade histórica + range escolhido = % chance de in-range nas próximas X horas.
• 4 perguntas-teste: (1) ✓ todos os concorrentes oferecem presets nomeados por forma (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = cálculo probabilístico exige modelo de volatilidade; falta de investimento (4) ✓ ganho perceptível — user vê preset Conservative: 95% chance in-range nas próximas 24h (±18%) em vez de Wide (-50%—+100%).
• Hipótese de diferenciação: substituir os 4 presets Stable / Wide / One-sided lower / One-sided upper por 3 presets probabilísticos — Conservador (95% in-range 24h), Equilibrado (80% in-range 24h), Agressivo (50% in-range 24h). Microcopy de APR estimado por preset. Override pra power user com "Custom (definir ticks/percentual)".
• Trade-off: cálculo probabilístico carrega risco de erro (volatilidade muda); presets de Uniswap são robustos por serem agnósticos. Aceitar com caveat e backtest visível ("nos últimos 30 dias, o preset Conservador acertou 93%").
• Leverage estrutural — converte "range é decisão técnica" em "range é decisão de risco". Família consolidada "transparência ativa para iniciante" + "decisões probabilísticas, não paramétricas". Diferenciador estrutural contra paradigma Uniswap (tick-thinking).

---

Observação adicional — Edit no header do panel revela que Step 1 e Step 2 são edição independente, não wizard estrito. User pode terminar Step 2 parcialmente, voltar ao Step 1 (mudar par ou fee), voltar ao Step 2 com o trabalho preservado. Decisão arquitetural valiosa — wizard rígido (perde estado ao voltar) é fonte clássica de frustração. Vale herdar pra Kotai: flows multistep devem preservar estado em cada etapa, e oferecer Edit contextual (não Back/Cancel).

10. Posição Populada — Step 2 com tab Full range ativa (estratégia simples)

Função: mesma tela do Step 2 com o user trocando pra tab Full range. Chart inteiro fica coberto por banda azul (cobertura de 0 → ∞), microcopy muda pra explicar trade-off de full range, e revela-se barra inferior com toggles de tempo (1D / 1W / 1M / 1Y / All time) + controles de zoom + botão Reset. Abaixo do chart, section Price strategies com 4 cards: Stable (±3 ticks) / Wide (-50%—+100%) / One-sided lower (-50%) / One-sided upper (+100%).

Componentes (diff em relação à Tela 9)

• Tab Full range ✓ (mudou).
• Microcopy: "Providing full range liquidity ensures continuous market participation across all possible prices, offering simplicity but with potential for higher impermanent loss."
• Chart inteiro coberto por banda azul translúcida — visualização de "minha liquidez cobre todo o eixo X".
• Toggle de tempo abaixo do chart: 1D | 1W | 1M ✓ | 1Y | All time + ícones ⊞ (zoom-fit) + 🔍 (zoom-in) + botão Reset (à direita).
• Section Price strategies (revela-se com scroll): 4 cards horizontais:
  • Stable — "± 3 ticks".
  • Wide — "-50% — +100%".
  • One-sided lower — "-50%".
  • One-sided upper — "+100%".

Regras de negócio

• Em Full range, escolha de min/max é dispensada — o range é matematicamente [0, ∞]. Capital fica continuamente in-range, mas espalhado entre todos os preços.
• Microcopy explicita o trade-off: continuous market participation (vantagem) vs higher impermanent loss (custo). IL aumenta com amplitude do range em pares voláteis.
• Cards de Price strategies ficam visíveis mesmo na tab Full range — mas selecioná-los provavelmente muda automaticamente pra Custom range (presets são custom, não full). Não há indicação visual disso.
• Toggle de tempo afeta só a janela do chart (visualização), não o range escolhido. Cuidado conceitual.
• Reset zera qualquer range custom definido — em Full range a função é inerte (já está em "default máximo").

---

🟢 Insight 1 — Tab Full range carrega trade-off honesto na microcopy: "simplicity but higher impermanent loss". Igual à Tela 9 mas inverte: aqui vende simplicidade e admite IL maior. Decisão pedagógica simétrica. Padrão a herdar pra Kotai — quando duas opções têm trade-offs opostos, a microcopy de cada lado deve admitir o custo da própria opção, não esconder.

🟢 Insight 2 — Banda azul cobrindo o chart inteiro é resposta visual instantânea pro "o que é full range?". Sem necessidade de explicação textual. Iniciante vê "minha liquidez cobre tudo" em 1 segundo. Padrão a herdar — quando feature tem representação visual óbvia (overlay no chart), usar.

🟢 Insight 3 — Toggle de tempo + zoom + reset abaixo do chart é UX de finanças madura. 1D / 1W / 1M / 1Y / All time é convenção universal (TradingView, Coingecko, Robinhood). User vindo de qualquer plataforma financeira reconhece. Padrão a herdar — em DeFi onde tudo parece novo, herdar convenções de fintech reduz onboarding.

🟢 Insight 4 — Price strategies cards horizontais convivem com a tab Full range. Permite descoberta — user vê "ah, posso escolher Wide ou One-sided sem ir em Custom range manualmente". Card-shortcuts atalham a escolha. Padrão a herdar — presets devem estar visíveis na tela default, não escondidos atrás de "Advanced".

---

🔴 Fricção 1 — Cards Price strategies na tab Full range são affordance ambígua: clicar muda pra Custom sem aviso (estrutural — clique em preset abandona silenciosamente a tab atual)

• Atrito real: user está em Full range, vê Price strategies: Stable (±3 ticks), clica. Sem aviso, a tab muda pra Custom range (presets são custom por definição) e o range vira ±3 ticks ao redor do preço. User pode não perceber que abandonou Full range — e o trade-off agora é o oposto (concentração + manutenção ativa). Decisão tomada por inércia, sem clareza.
• Por que a solução óbvia falha: modal de confirmação ("Mudar pra Custom range?") é fricção desnecessária pra 80% dos casos; banner permanente sobre os cards polui.
• Alternativa: microcopy condicional acima dos cards — "Clicar em um preset muda pra Custom range" visível só quando Full range está ativo. Em Custom range a microcopy some. Sinaliza sem bloquear. Trade-off: texto extra na tela; aceitar pelo trust signal.
• Perfil afetado: iniciante (principal — único que clica em preset sem entender que Full ≠ Custom).
• Família com 🔴 "Mudança silenciosa v4→v3 perde Hook" (PosPop #7) — mesma raiz: produto altera estado por consequência de outra ação, sem feedback explícito.

🔴 *Fricção 2 — Microcopy "continuous market participation" glamouriza full range, mas na maior parte dos pares voláteis o LP em full range perde dinheiro vs hold simples (estrutural — texto deliberadamente otimista esconde a realidade matemática)

• Atrito real: "continuous market participation" soa positivo (sempre ativo, sempre ganhando fees). Mas em pares voláteis (ETH/USDC) o LP em full range em v3 ganha menos que LP em v2 (que tem mesmo perfil de range, mas curve diferente) e muito menos que LP em v3 tight bem gerenciado. E IL em full range é igual ou pior que hold simples na maioria dos cenários. O texto descreve a vantagem técnica (always-in-range) sem dizer que essa "vantagem" custa em retorno. "potential for higher impermanent loss" é caveat real mas vago — não compete em peso visual com "continuous market participation".
• Por que a solução óbvia falha: trocar microcopy pra "Full range geralmente rende menos que hold" é prescritivo demais e desencoraja LP iniciante; remover full range como opção é redutor.
• Alternativa: adicionar number ancorado abaixo da microcopy — "Nos últimos 30 dias, LPs em full range ETH/USDC ganharam X% (vs Y% em hold simples)". Dado real, não opinião. User decide com âncora. Trade-off: exige cálculo de backtest; risco de cherry-picking de janela (30d vs 90d podem dar conclusões opostas). Aceitar com janela ajustável.
• Perfil afetado: iniciante (principal — único que aceita microcopy como conselho).
• Família com 🟡 "Health Score com IL" (PosPop #5) — mesma raiz: produto exibe métrica positiva (fees, participação) sem contraste com baseline (hold simples).

🔴 Fricção 3 — Toggle de tempo (1M ✓) é o único elemento que sinaliza que o chart é histórico, não predictivo (cosmética — confusão de mental model sobre o que o chart "mostra")

• Atrito real: chart com banda azul pode parecer "o range projetado pra o futuro" (predição). Mas é histórico — mostra o preço dos últimos 30 dias. Só o 1M ✓ no toggle inferior denuncia. Iniciante pode olhar e pensar "ETH vai oscilar nesse range nos próximos 30 dias". Erro de leitura crítico — chart histórico não promete movimento futuro.
• Por que a solução óbvia falha: banner "Histórico, não predição" é didático demais; trocar pra chart de probabilidade exige modelo.
• Alternativa: label do toggle expandido — em vez de 1M, usar Últimos 30 dias no estado ativo. Anchored "you're looking at history". Trade-off: mais largura no toggle; pequeno.
• Perfil afetado: iniciante (principal).

---

🟡 Oportunidade competitiva — Comparativo "Full range vs Hold vs Custom otimizado" no momento da decisão

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3, KyberSwap — apresentam Full range vs Custom como escolha técnica de range, sem comparar com alternativa fora do produto (hold simples). User decide entre LP-modes sem saber se LP é melhor que não-LP.
• Por que afeta o target: iniciante decide aportar como LP assumindo que rende mais que hold. Em muitos cenários, full range em par volátil rende menos que hold com staking simples. Sem comparação visível, o iniciante acredita na premissa errada.
• 4 perguntas-teste: (1) ✓ todos os concorrentes evitam comparação LP vs hold (conflito de interesse: cada $1 fora de LP = $1 fora de TVL = $1 fora de fees do protocolo) (2) ✓ afeta iniciante e intermediário diretamente (3) ✓ razão = conflito comercial, não impossibilidade técnica (4) ✓ ganho perceptível — user vê "Full range: 8% APR / Hold simples ETH+USDC 50/50: 12% projetado / Custom tight ±2%: 45% APR (75% in-range)".
• Hipótese de diferenciação: mini-tabela "Compare estratégias" abaixo dos cards Price strategies — 3 linhas: Hold simples, LP Full range, LP Custom (sugerido) — com APR estimado e %-chance-de-perder-vs-hold. Honestidade radical. Produto admite que LP não é sempre a resposta.
• Trade-off: estrategicamente perigoso (Kotai diz "talvez não vire LP") mas reputacionalmente diferencial. Marketing inverso: "produto que te recomenda não usar o próprio produto quando não vale a pena" vira tese de credibilidade — mesma jogada do Vanguard contra fundos ativos.
• Leverage estrutural alto — define posicionamento "Kotai te dá a verdade, mesmo quando ela é não-aportar". Diferenciação reputacional grande. Família com 🟡 "Health Score" e "APR estimado por range" — sistema completo de honestidade ativa.

---

Observação adicional — Reset na tab Full range é botão inerte mas presente. UI mantém affordance consistente entre tabs (Reset aparece sempre). Em Full range não há nada pra resetar (range já é máximo). Decisão arquitetural defensável (consistência > clareza condicional), mas vale considerar: button visível e clicável que não faz nada quebra contrato implícito de affordance. Alternativa: desabilitar com tooltip "Já está em Full range". Cosmético.

8. Posição Populada — Fee tiers expandidos (4 cards com prova social)

Função: mesmo Step 1 com a section Fee tier expandida (More virou Less ^). Em vez da linha resumo da Tela 7, agora aparecem 4 cards lado a lado mostrando todos os fee tiers disponíveis em v3 ETH/USDC, com perfil ideal, TVL absoluto e % de seleção (prova social quantificada).

Componentes (diff em relação à Tela 7)

• Botão More v virou Less ^ (collapse).
• Linha resumo 0,05% fee tier ainda visível acima dos cards.
• 4 cards horizontais (ordem da esquerda pra direita):
  • 0,05% ✓ (selected — borda destacada + checkmark) — "Best for stable pairs" — $501.1M TVL — 77,985% select.
  • 0,3% — "Best for most pairs" — $24.2M TVL — 16,685% select.
  • 0,01% — "Best for very stable pairs" — $3.1M TVL — 5,715% select.
  • 1% — "Best for exotic pairs" — $786.0K TVL — 0,007% select.
• CTA Continue permanece ativo (já estava ativo na Tela 7).

Regras de negócio

• Os 4 tiers são os canônicos do Uniswap v3 (0,01% / 0,05% / 0,3% / 1%); pares novos podem ativar ou não cada um.
• Microcopy por tier carrega heurística do produto: stable / most / very stable / exotic. "Very stable" implica correlação altíssima (USDC/USDT, DAI/USDC); "exotic" implica pares ilíquidos/voláteis.
• % select = participação daquele tier no total de posições do par. Soma deveria dar 100% mas dá ~100,4% nos números visíveis — provavelmente arredondamento ou métrica de share-of-deposits ponderado.
• TVL exibido por tier, não total da pool — diferente da Tela 1 que mostra TVL agregado.
• Tier selecionado é mantido entre toggle More/Less (decisão de estado coerente).

---

🟢 Insight 1 — Card de fee tier combina 3 dimensões de evidência em layout único: microcopy editorial + TVL absoluto + share de seleção. As 3 cumprem papéis diferentes: microcopy ensina ("best for stable"), TVL ancora ordem de grandeza ("$501M ≠ $3M"), share quantifica adoção ("77% das pessoas escolhem isso"). Iniciante decide por microcopy; intermediário cruza com TVL; avançado checa share pra detectar arbitragem. Padrão a herdar pra Kotai: card de decisão deve servir 3 níveis de leitor sem virar dashboard.

🟢 Insight 2 — % select como prova social quantificada é mais honesto que badge Highest TVL. Tela 7 mostrou só o badge; Tela 8 mostra a distribuição. User vê que 77% escolhe 0,05% e 16% escolhe 0,3% — duas decisões legítimas. Sem isso, o badge Highest TVL da Tela 7 parece "única escolha certa". Distribuição completa devolve agência ao user. Padrão a herdar — quando produto pré-seleciona com base em popularidade, mostrar a distribuição completa (não só o vencedor) preserva escolha informada.

🟢 Insight 3 — Microcopy curta orienta sem prescrever. Best for stable pairs / most pairs / very stable pairs / exotic pairs é minimal: não diz "recomendado", não diz "use isso", diz "encaixa nesse caso". User cruza com seu próprio par (ETH/USDC = stable? volátil?) e decide. Padrão a herdar — microcopy de decisão deve dar tag de caso, não recomendação.

🟢 Insight 4 — Progressive disclosure preservada. User satisfeito com default continua sem clicar More (Tela 7); user que quer entender clica e explora (Tela 8); user pode voltar ao colapso. Toggle simétrico = sem fricção. Padrão a herdar — colapso/expansão deve ser sempre reversível e gratuito.

---

🔴 Fricção 1 — Microcopy Best for stable / most / very stable / exotic pairs é taxonomia vaga e não diz onde ETH/USDC encaixa (estrutural — produto ensina a régua mas não aplica ao caso do user)

• Atrito real: user está no par ETH/USDC. ETH/USDC é "stable" (USDC é stablecoin)? Ou "most" (par mais usado)? Ou nada disso porque ETH é volátil contra USDC? A microcopy não responde — apenas tag genericamente cada tier. User precisa decoda sozinho onde o par dele encaixa. Iniciante que vê "Best for stable pairs" no tier 0,05% pode pensar "ETH/USDC não é stable, então 0,05% não é pra mim" e ir pro 0,3% (Best for most pairs). Mas o agregado mostra 77% das pessoas usam 0,05% pra ETH/USDC — i.e., a taxonomia subentende algo específico (USD-denominated trading pair) que iniciante não decoda.
• Por que a solução óbvia falha: classificar cada par explicitamente exige tabela editorial gigantesca (todos os pares × todos os tiers); deixar genérico (como agora) transfere o custo de classificação pro user.
• Alternativa: anotação contextual no card recomendado — adicionar "Recomendado para ETH/USDC (77% dos LPs)" embaixo do card 0,05%, dinâmico ao par escolhido. As taxonomias gerais (stable/most/etc.) ficam, mas há ancoragem específica. Trade-off: texto extra dentro do card; ganho: zero ambiguidade pro user.
• Perfil afetado: iniciante (principal — único que tenta decodar taxonomia sem conhecer convenção) + intermediário com par novo.
• Família com 🔴 "Default por TVL" (PosPop #7) — mesma raiz: produto entrega prova social agregada mas não amarra ao caso específico do user.

🔴 Fricção 2 — % select como métrica é semanticamente ambígua (% de posições? % de TVL? % de transações?) (cosmética — número sem unidade definida)

• Atrito real: "77,985% select" é um number preciso (4 casas decimais!) sem unidade clara. É share de número de posições (77,985% dos NFTs LP estão nesse tier)? De TVL (77,985% do capital total)? De fluxo (77,985% das criações nos últimos 30 dias)? Cada interpretação muda a decisão: share de posições reflete sentimento agregado de LPs; share de TVL reflete onde está o capital; share de fluxo reflete tendência recente. As 3 são úteis, mas o number único nivela.
• Por que a solução óbvia falha: rótulo "% de posições" no card polui; tooltip ⓘ é dismissado.
• Alternativa: trocar o label select por dos LPs escolhem este tier (frase explícita) ou similar. Ou expor as 3 métricas em hover (ganho marginal).
• Perfil afetado: intermediário e avançado (iniciante aceita o number cego).

🔴 Fricção 3 — Hierarquia visual dos 4 cards é flat: o card selecionado tem checkmark mas é fácil perder no scan (cosmética — affordance de "selecionado" subdimensionada)

• Atrito real: os 4 cards têm o mesmo peso visual (mesma cor de fundo, mesmo tipo de borda). O card 0,05% tem checkmark verde sutil + borda ligeiramente diferente, mas no scan rápido (especialmente em monitor médio) os 4 parecem iguais. Iniciante que clica Less pra colapsar pode achar que perdeu sua escolha — quando na verdade o default ainda está marcado.
• Por que a solução óbvia falha: destacar muito o card selecionado (fundo rosa pleno, borda dupla) torna a fricção 1 (default cego) ainda mais agressiva pela ancoragem visual.
• Alternativa: borda do card selecionado em cor primária (rosa) + label "Selecionado" no topo do card (em texto, não badge). Sinal explícito mas não opressor. Trade-off: ancora um pouco mais o default; minimizado se a alternativa da Fricção 1 (sempre expandido, com "Recomendado para ETH/USDC") for adotada — aí o selecionado fica diferenciado por contexto, não por peso visual nu.
• Perfil afetado: iniciante (principal).

---

🟡 Oportunidade competitiva — Cards de fee tier mostrando APR histórico (não só TVL e share)

• Padrão da indústria: Uniswap (esta tela), PancakeSwap v3, KyberSwap — mostram TVL e share por tier, mas não APR histórico do tier. User precisa abrir cada pool separadamente pra comparar yields. Decisão de fee é feita por proxy (TVL = popularidade) em vez de retorno direto.
• Por que afeta o target: iniciante e intermediário quer saber "se eu colocar capital aqui, quanto rende?" — o number-resposta é APR. TVL e share são proxies imperfeitos. Pode ser que o tier menos populado (1%) tenha APR maior por ter menos competição. Sem dado, ninguém explora.
• 4 perguntas-teste: (1) ✓ todos os concorrentes mostram TVL/share, não APR por tier (2) ✓ afeta iniciante e intermediário direto (3) ✓ razão = APR depende de range escolhido + caveat de IL → custo de calcular um APR "representativo" por tier (4) ✓ ganho perceptível — user compara 0,05%: 12% APR full range / 0,3%: 28% APR tight / 1%: 45% APR tight tighter e escolhe com retorno como âncora.
• Hipótese de diferenciação: acrescentar 4ª linha em cada card — "APR médio (30d): X%" — usando a posição mediana de cada tier como referência. Caveat "depende do range que você escolher" abaixo do bloco. CTA Simular APR no meu range → que abre o range picker direto no card.
• Trade-off: APR médio do tier carrega mesma armadilha do "Total APR" da Tela 1 (PosPop #1 fricção 1) — number único mascarando variabilidade por range. Aceitar com caveat explícito + entrada pra simulação por range.
• Leverage alto — converte escolha de fee em escolha de retorno. Família consolidada com 🟡 "APR estimado por range" (PosPop #1), 🟡 "Sugestão de fee tier amarrada à estratégia" (PosPop #7). As três juntas formam um sistema acoplado fee × range × APR — exatamente o que Uniswap entrega como 3 decisões independentes.

---

Observação adicional — soma de % select não bate 100%. 77,985 + 16,685 + 5,715 + 0,007 = 100,392%. Excede 100% — provavelmente arredondamento por casa decimal, ou métrica que pondera de forma que cruza limite (ex: share por TVL onde uma pool é contada em 2 tiers via migração). Não é fricção do user (números são plausíveis), mas é detalhe que iniciante atento percebe e que mina trust no produto ("se a soma não bate, esses numbers são confiáveis?"). Vale registrar como observação de qualidade analítica: numbers expostos ao user devem fechar matematicamente, ou carregar caveat explícito ("share por TVL com sobreposição de pools migradas").